HyperGressive Technologies

Dual ISP Load Balancing Configuration

noreply@blogger.com (T. Cole) — Tue, 31 Mar 2009 19:29:00 +0000

Security involves authentication, authorization, confidentiality, data integrity and availability. This document involves network availability. In this example we explore a high availability, load balancing solution for Internet redundancy. Although the example here is for dual Internet service providers the principles of this configuration could be applied in other situations where dual gateways are needed.

In a topology where dual ISP’s customer premise equipment provides an Ethernet port for connection to their service, configuring two static routes with or without metric won’t have the desired effect. Since your equipment connects to an Ethernet port, that connection will always appear to be up as long as you have a link light indicating layer one connectivity. Ethernet ports won’t lose the carrier signal typical with a serial connection so your data path will never fail over to the other configured static route.

In Cisco IOS versions 12.3T and 12.4 mainline object tracking features have been greatly improved and can now be applied to monitor the up/down status of interfaces. The solution contemplated in this article monitors ISP reachability by pinging a host on each of the ISPs networks that is only reachable through that ISPs interface. The ability to ping a host in the core of the ISPs network as opposed to pinging the ISPs gateway provides a means of monitoring that ISPs network health and not just the status of your local connection. The configuration presented here requires a Cisco IOS version of 12.3T or above.

In my own research I found many examples of solutions to this problem. Many of them I dismissed immediately because they were just plain flawed, others were not flexible or provided only failover capabilities without load balancing or were not compatible with the way I needed to provide address translation services. If you prefer just failover without load balancing add a metric to tracked default route for your backup ISP in the configuration below like this “ip route 0.0.0.0 0.0.0.0 10.10.10.1 200 track 123”.

The following configuration is in part the work of Josh Horton at blindhog,net and the original configuration can be seen here, http://www.blindhog.net/cisco-dual-internet-connections-without-bgp/. I’ve am making a similar configuration available here due the difficulty of finding this information on the Internet.

I have made some enhancements and at the expense of failover have provided a way to force certain traffic out a particular interface. I’ve also added a host specific route to the ping monitored host on each network. This assures that the host will be reachable when the router is powered up or service is reestablished and forces the ICMP ping packet out the interface we want to monitor. A host specific route also assures that the monitored host is only reachable through it’s network gateway.

version 12.4
!
hostname Router_Name
!
ip cef
!
!#### Establish sla monitors for use in tracking objects. These objects ####!
!#### are used to track reachability of a host on each ISPs network ####!
!
ip sla monitor 1
type echo protocol ipIcmpEcho 10.10.10.10
ip sla monitor schedule 1 life forever start-time now
ip sla monitor 2
type echo protocol ipIcmpEcho 10.20.20.10
ip sla monitor schedule 2 life forever start-time now
!
!#### Configure Tracking objects (referencing IP SLA monitor’s above) ####!
!
track 123 rtr 1 reachability
delay down 5 up 5
!
track 124 rtr 2 reachability
delay down 5 up 5
!
!#### Configure Interfaces for NAT, 'ip nat inside' and 'ip nat outside '####!
!
interface GigabitEthernet0/1
description Connect to firewall outside interface or inside networks
ip address 192.168.1.1 255.255.255.0
ip nat inside
!
interface GigabitEthernet0/2
description ISP1 Internet Interface
ip address 10.10.10.2 255.255.255.252
ip nat outside
!
interface GigabitEthernet0/3
description ISP2 Internet Interface
ip address 10.20.20.2 255.255.255.252
ip nat outside
!
!#### Configure gateway of last resort with tracking objects ####!
!
ip route 0.0.0.0 0.0.0.0 10.10.10.1 track 123
ip route 0.0.0.0 0.0.0.0 10.20.20.1 track 124

!#### Configure host specific routes for sla monitors. Without ####!
!#### these, tracking objects cannot recover after full failure. note ####!
!#### the ‘permanent’ keyword installed the route into the RIB ####!
!#### regardless of reachability ####!
!
ip route 10.10.10.10 255.255.255.255 10.10.10.1 permanent
ip route 10.20.20.10 255.255.255.255 10.20.20.1 permanent
!
!#### Configure additional routes for inside subnets not directly connected ####!
!
ip route [inside subnet / mask] GigabitEthernet0/1
ip route [inside subnet / mask] GigabitEthernet0/1
!
!#### Outbound dynamic NAT for each interface with overload parameter ####!
!
ip nat inside source route-map ISP1_MAP interface GigabitEthernet0/2 overload
ip nat inside source route-map ISP2_MAP interface GigabitEthernet0/3 overload
!
!#### Additional static NAT for dedicated one to one NAT addresses and /or ####!
!#### tcp/udp port translations. Note first two statements translate SMTP (25) ####!
!
ip nat inside source static tcp 192.168.1.5 25 10.10.10.5 25 route-map ISP1_MAP extendable
ip nat inside source static tcp 192.168.1.5 25 10.20.20..5 25 route-map ISP1_MAP extendable
ip nat inside source static 192.168.226.5 71.151.39.129 route-map ISP2_MAP extendable
ip nat inside source static 192.168.226.6 71.151.39.130 route-map ISP2_MAP extendable
!
!####Configure a single ACL or an ACL for each interface if####!
!####needed to direct specific traffic to a specific interface####!
!####Both ACLs have the same permit statement but other####!
!####permit or deny statements can be added as required####!
!
ip access-list extended ISP1_ACL
remark ACL for ISP1 interface - permit or deny specific traffic on this interface / ISP
permit ip 192.168.226.0 0.0.0.255 any
!
ip access-list extended ISP2_ACL
remark ACL for Comacst interface - permit or deny specific traffic on this interface / ISP
permit ip 192.168.226.0 0.0.0.255 any
!
!####Configure route maps for reference in NAT statements####!
!####These route-maps direct NATs to appropriate interface####!
!
route-map ISP1_MAP permit 10
description associates outside NAT addresses with the correct interface
match ip address ISP1_ACL
match interface GigabitEthernet0/2
!
route-map ISP2_MAP permit 10
description associates outside NAT addresses with the correct interface
match ip address ISP2_ACL
match interface GigabitEthernet0/3
!
banner motd ^C
********************************************

SECURITY NOTICE

********************************************
This is a private secured computer system.
It is for authorized use only.
Users (authorized or unauthorized) have no
explicit or implicit expectation of privacy.
Any or all uses of this system and all
files on this system may be intercepted,
monitored, recorded, copied, audited,
inspected, and disclosed to authorized
site, law enforcement personnel, as well
as authorized officials of other agencies,
both domestic and foreign. By using this
system, the user consents to such
interception, monitoring, recording,
copying, auditing, inspection, and
disclosure at the discretion of site
personnel. All activity is logged
with your host name and IP address.
Unauthorized or improper use of this
system may result in civil and criminal
penalties. By continuing to use this
system you indicate your awareness of and
consent to these terms and conditions of
use. LOG OFF IMMEDIATELY if you do not
agree to the conditions stated in this
warning.

********************************************
^C

Identification, Naming Conventions and Color Coding

noreply@blogger.com (T. Cole) — Mon, 16 Mar 2009 22:45:00 +0000

Or a Rose by any other name is hard to correctly identify

Technology is simple. Here’s a summary...

Scrape the tape,
Pop the top,
Twitch the switch,
Put what you got in the slot,
Load the code…

Well, Not exactly. There is a little more to it than that if you do it right.

Let’s start at the very beginning because that is the very first opportunity we have to make mistakes.

A naming convention, labeling practices, color coding and use of a change log and auditing methodology can help you stay organized, improve problem resolution times and minimize mistakes with security consequences.

Here’s how easily thing can get out control. I had been working with a client that has maintained two unconnected networks for internal production and Internet connectivity. The reasoning was straight forward and simple. If you’re not connected you can’t be compromised. I’ve been telling them for years that they would be more secure connected where hosts could stay patched and network access could be controlled, logged and audited. My time has finally come and I am replacing firewalls, reconfiguring the topology and adding redundant ISP services in preparation for the collapse of these networks into a single topology. During the process of testing the load balancing ISP NAT configuration I was very surprised to see inside addresses from the production network being translated on the outside of my new Internet firewall cluster. Remember these are totally isolated networks, or so they thought. Obviously things are not always as they seem. It would seem that similar switches in a common rack in a common wiring closet and same color patch cables have resulted in an inadvertent connection between the two systems. The production network gateway and DNS servers are logically isolated from the outside and provide no Internet resolution so the client was completely unaware of a potential security fiasco.

Practical Advice:

Label the cable, pathways and spaces.
Adopt a labeling and color coding standard such as the ANSI/TIA/EIA 606-A Administrative Standard and make your contractor, consultants and peers to use it religiously. You don’t have to adopt this standard verbatim but its principles should apply. Know where your horizontal cabling, backbone cables, grounding and bonding systems and telecommunication outlets terminate. Use a labeling convention that identifies the floor, closet, rack, panel and port for instance at each data outlet.

Example:

0047-1A-1A45
UTP cable originates in Building 047, Telecommunications Room 1A.in Rack #1, Patch Panel A, Port 45.

Manage your pathways, spaces and racks. This effort pays big dividends in reduced administration and improved problem resolution times down the road. Your cabling contractor should be very familiar with this standard and its principles.

Network Electronics, Routers and Switches:

Physically and logically label all devices with a naming convention that identifies it’s purpose or use and configure electronic port or interface labels to identify mission critical equipment connections.

Example of a Cisco configuration:

hostname CC50_InterValve
!
interface GigabitEthernet0/2
description Embark Internet Interface
!
interface serial0/2
description Crosstown Complex, circuit ID # FL-0000-2236472-XX

An exception to the descriptive electronic name would apply in the case of edge devices or those with publically routable addresses. Although “security by obscurity” ranks really low in terms of effective security strategies, Internet routers and firewalls and wireless devices, shouldn’t be named “bastion_host” or “super_secret_FW” or indicate the company name or specific location. These names imply a purpose and a challenge to the wrong people and may open the consultant to liability issues. Names like “SWI_Valve1” or “Gate_SB50” are far less interesting to an attacker.

Network Host Devices:

Here you can be a little less descriptive in the machine name opting for important but never changing information like the manufacturer, serial number or asset tag and acquisition date i.e “Dell_34672_07”. This naming convention does little help you locate the machine but PC and printers may move from person to person or be redeployed or repurposed into another department or division. Make use of the “Computer Description” field on the Windows Computer Name tab of the computer properties or similar “Comment” fields for other equipment. These fields can be easily changed when machines are moved, redeployed or repurposed and show up in the detail view of the network browser.

Name.......................Computer Description
HP_34672_07 ..........Bldg J, HR, Rm 102. Jackie M., ext 5427
Dell_222476_08 .......Bldg C, Lobby, Public Kiosk #1

Printers show up in the network browser the same way so they can be named similarly. In the installed printer applet in on individual Windows PCs, printers are named for their device driver by default but can be changed if necessary to a descriptive name for the end user like this.

Research_HP_LaserJet_4050N

Network Management:

There are an abundance of network management tools for every conceivable need imaginable. Some are free and some are commercial applications. Some are single purpose and some are feature rich but inevitably you will need the capability to perform an administrative task that is not supported by whatever you have. One of the best and most effective management tools for a large network deployment is an administrator with scripting skills. VBScript, KixTart, Windows script, AutoIT and numerous other languages are relatively simple to learn and offer the ability to rename, add comments, change or add device drivers, perform inventory etcetera.

ANSI/TIA/EIA 606-A Implementation Example-
http://net-services.ufl.edu/infrastructure/labelstandardhorizontal.htm

ANSI/TIA/EIA 606-A Standard quick reference- this is an expansive standard. Here is a summary.
http://74.125.47.132/search?q=cache:bzuzMHx14kwJ:www.flexcomm.com/library/606aguide.pdf+ansi/tia/eia+606a&cd=1&hl=en&ct=clnk&gl=us
KixTart Scripting Language-
http://www.kixtart.org

Email Security Policy

noreply@blogger.com (T. Cole) — Tue, 24 Feb 2009 16:32:00 +0000

Email security is a very broad and in-depth subject. I won't attempt to cover every aspect here but rather provide a basic understanding of the issues and some practical solutions.

Why should we care-

Email systems, their protocols, transport mechanisms and even even the carbon based life forms that are the end target of such systems are ripe and furtile attack vectors for hackers, spammers and phishing attacks. In addition they are a major source of information disclosure and breaches of confidentiality.

Any email security policy must thought of in bidirection terms. Inbound email can contain viruses, executable code such as .exe files or macros, automatic HTML links and mailto links . Marketing companies will routinely send email with graphics that are fetched from an marketing server allowing them to confirm the validity of a email address and possible sending other valuable marketing information such as the contents of email address books and cookies. Email may request that a recipient perform or complete a action that could compromise your network. Outbound email can propagate viruses and worms, propogate or originate SPAM, contain profanity, pornography or abusive language exposing the company or agency to legal liabilities.

Courts have repeatedly upheld that employers must provide a safe work environment free of abuse and harassment. Employees have sued and won over reciept of abusive or pornagraphic email or accidental disclosure of private information. Another company could also sue you for loss of productivity, loss of reputation, mitigation and repair costs associated with malicious or damaging email originating from your domain.

What can be done-

Develop and enforce an email policy within your organization. That simple step will provide evidence of you attempting to control dangerous, malicious and abusive content. That alone could mitigate some of the legal liablitiy and damage awards as a result of a legal action. A written policy and evidence of enforcement is key here.

Install and maintain effective anit-virus and anti-spam solutions. Inspect outbound mail for companie secrets, customer lists, credit card numbers, drivers license numbers, social security numbers etcetera to prevent disclosure of sensitive or confidential information.

Stategies-

Don't include plain text lists of email addresses on your website. Addresses in the form of 'username@domainname.ext' can easialy be read by web spiders or 'bots' harvesting email addresses for use in unsolicited email campaiges. Use a script to build those addresses dynamically for display in an HTML page. If they can't harvest them they can use them.

Install an email policy device or engine configured to inspect all parts of an email inbound and outbound for threats such as viruses, worms, executables, attachments not complying with corporate policy, confidential information such as D/L, social security numbers, customer lists and other confidential information. The goal is to keep threats to your network out, confidential information in and enforce a corporate or agency policy.

Any such device should recursively disassemble an email in all it's parts and attachments and inspect each component. Multi level hueristic and lexical analysis against managed expression lists, realtime block lists and managed spam fingerprint or digital DNA lists should be performed. The device should have configurable actions for every policy. Reject RBL addresses and known spammer addresses, cure or delete virus and worms and quarantine executables, ebay emails and multimedia files according to policy. For ease of management the device or appliance should integrate with Active Directory or other LDAP directory to validate recipient addresses.

Validation of the sender domain is a valuable anti-spam strategy since spammer rarely use a valid domain to originate emails however, in my experience many email systems are not properly configured and reverse DNS lookup produce no results thereby blocking what might be valid email. To make matters worse, if you try to advise a sender that their sender domain cannot be validated, their email administrator will frequently advise you that it is your problem and that they don't have problems with other companies. Until email and security administrators understand RFC compliance and do their part in the overall scheme of email security you will be left with dealing with their mess and they will expose themselves to legal liability issues.

In short, ant-virus and anti-malware is not enough to prevent inbound threats and does nothing to mitigate liability issues.

Anecdotal story-

Recently, I installed and configured and tested a high end clustered email policy solution for a governmental agency. Shortly after the installation the helpdesk received a report of email being denied by the new appliance and the report was relayed to me.

I placed a call to the sender since the appliance logs had absolutely no mention of the rejected message. The sender's email administrator told me that the non delivery receipt (NDR) reported that the email had a spam signature. "That explains the lack of log file info as the system was configured to summarily reject spam", I explained to the admin. He advised me that the originator was a high profile public official, not a spammer; sending email to another high profile public official and that the email was in no way spam. They received the email through their ant-spam device and the sender didn't consider it spam. He wanted the recipient to have the infomation. The admin asked me to whitelist the sender.

I temporarily adjusted my policy to quarantine known spam instead of rejecting it and requested that the message be resent. About an hour later the message was quarantined in my system where I could take a look at it to see haw I needed to adjust my policy. Upon inspection I found a blatent email spam from a bookstore advertising a "143 page manual" with web links, a chapter summary, author's bio and a printable order form complete with instructions for purchasing by credit card.

This spam email had been propagated by the sender with a simple "FYI" added at the top. Seems that the appliance and my policy did what it was supposed to do! I put my "reject" policy back in place.

If the sender had sent a short comment with a web link or just cut and paste a summary from the original spam, it would have gone through or at worst been quarantined so an admin could review it and release as appropropriate.

There are several points to take from this story.

1. All anti-spam engines are not equal.
2. Spam is spam no matter who sends it.
3. One persons treasure is another's spam.
4. Policies need to be flexible.

Email security white papers

Protecting Network Edge Devices

noreply@blogger.com (T. Cole) — Fri, 20 Feb 2009 19:09:00 +0000

Most administrators think of firewalls as the one device that protects their internal information resources but that may not be the case. In most networks there are additional devices outside of the firewall such as routers, switches and modems. In some cases a network may have directly connected remote sites that are generally considered to be on the inside of their network but utilize some manner of public transport that is not directly within their control. These devices may provide an attack vector for those with malicious intent. Some of these devices will even host public IP addresses that can be found by simply querying a DNS or whois server.

Compromise of these network devices will allow an attacker to gain valuable information about your network, provide a stepping stone for another attack, create an intentional or unintentional Denial of Service, redirect or clone information on the transport or even disclose administrative credentials. These devices should be hardened, maintained and monitored as part of your security strategy.

Here are some recommendations to address the vulnerabilities and exposure these devices present. Limit administrative access with ACLs and use only secure protocols, Don’t use clear text or insecure protocols to access these devices particularly form the outside as might be the case for a consultant or an “on call” IT staff member. For instance, use SSH instead of telnet or HTTP to access the administrative interface and disable insecure protocols.

Edge devices in most cases should not run a routing protocol or exchange routing information with devices not under your direct control as the routing tables created by these protocols provide an accurate map of your internal network. Use static routes.

Disable CDP (Cisco Discovery Protocol) at minimum on the outside interfaces of these devices. Don’t configure DNS servers or host lists on the routers. Disable IP redirects and directed broadcasts. Disable SNMP. Proper use ACLs to allow these devices to log security events to an inside trusted syslog service and configure the syslogger to alert via email and/or audible alerts on significant events.

Here is a typical best practices recommendation for Cisco routers.

Guideline for securing a typical enterprise perimeter (Gateway) router.
* Security issues related to routing protocols (BGP, OSPF, RIP, VRRP etc) are beyond the scope of this document.
* Latest IOS version available from CISCO (www.cisco.com) should be used.

Access Management
I. Console -
Router# config t
Enter configuration commands, one per line. End with CNTL/Z.
Router (config)# line con 0
Router (config-line)# login local //Enforce local user login; Local user must be
created
Router (config-line)# exec-timeout 5 0 //Set automatic session timeout

IOS - Create local users -Create at least one local user with password to enable
console login
Router(config)# username user_name password

II. Auxiliary port-
Router(config)# line aux 0
Router(config-line)# transport input none
Router(config-line)# login local
Router(config-line)# exec-timeout 0 1
Router(config-line)# no exec

III. VTY -
Disable access through VTY (Telnet)
Router(config)# no access-list 90
Router(config)# access-list 90 deny any log
Router(config)# line vty 0 4
Router(config-line)# access-class 90 in
Router(config-line)# transport input none
Router(config-line)# login local
Router(config-line)# exec-timeout 0 1

Securing VTY (Telnet) if required
Allow only specific IP to telnet the Router
Router(config)# ip telnet source-interface loopback0
Router(config)# access-list 99 permit IP_allowed log
Router(config)# access-list 99 deny any log
Router(config)# line vty 0 4
Router(config-line)# access-class 99 in
Router(config-line)# exec-timeout 5 0
Router(config-line)# transport input telnet
Router(config-line)# transport output none ---Disable telnet outside
Router(config-line)# login local
Router(config)# service tcp-keepalives-in
Disable unnecessary VTY lines
Router(config)# no line vty 5

IV. Enable Secret
Router(config)#enable secret

Disable unnecessary Services
Router(config)# no service finger
Router(config)# no ip identd
Router(config)# no ip finger
Router(config)# no ip http server
Router(config)# no service tcp-small-servers
Router(config)# no service udp-small-servers
Router(config)# no ip bootp server
Router(config)# no cdp run
Router(config)# no service config -- Disable loading of remote configs.
Router(config)# no tftp-server INSTANCE
Router(config)# no boot network
Router(config)# no ip domain-lookup

SNMP Security
Disable SNMP if not in use.
Router(config)# no snmp-server
If the network requires SNMP, then configure an SNMP ACL and hard-to-guess SNMP community strings.
Router(config)# no snmp community public ro
Router(config)# no snmp community private rw
Router(config)# access-list 51 permit Permited_IP_Address
Router(config)# snmp community Your_Password ro 51

Routing Rules
I. Turn off opportunities for crafted spoof attacks & probes
Router(config-if)# no ip directed-broadcast // Disable IP directed broadcast on each
interface
Router(config-if)# no ip proxyarp // Disable proxy ARP
Router(config-if)# no ip directed-broadcast // Disable directed broadcast
Router(config-if)# no ip unreachables // Disable host unreachable reply
Router(config-if)# no ip mask-reply // Disable mask reply message
Router(config-if)# no ip redirects //Disable ip redirects
Router(config)# no ip source-route // Disable source routing.
Router(config)# service tcp-keepalives-in // Use tcp keepalives to kill sessions
where the remote side has died.
II. Unicast reverse path forwarding
Router(config)# ip cef
Router(config-if)# ip verify unicast reverse-path // Unicast Reverse Path Forwarding (RPF) helps to mitigate problems caused by malformed or forged IP source addresses passing through a router.
Ref h ttp://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/uni_rpf.htm

Access control lists
The ACLs mentioned here are designed for restricting inbound traffic of a perimeter router.
*The access_list number (101) given is user defined. User can change it as per their requirement
*The access list has to be applied to inbound traffic on external interface.

I. Filter all RFC 1918,3330 address space and special/reserved addresses
Router(config)# access-list 101 deny ip 10.0.0.0 0.255.255.255 any log
Router(config)# access-list 101 deny ip 172.16.0.0 0.15.255.255 any log
Router(config)# access-list 101 deny ip 192.168.0.0 0.0.255.255 any log
Router(config)# access-list 101 deny ip 127.0.0.0 0.255.255.255 any log
Router(config)#access-list 110 deny ip 192.0.2.0 0.0.0.255 any log
Router(config)# access-list 101 deny ip 255.0.0.0 0.255.255.255 any log
Router(config)# access-list 101 deny ip 224.0.0.0 7.255.255.255 any log
Router(config)# access-list 101 deny ip host 0.0.0.0 any log
Router(config)#access-list 110 deny ip host 255.255.255.255 any log
Router(config)# access-list 101 deny ip 169.254.0.0 0.0.255.255 any log
II. Apply ingress filtering (RFC 2827)
Stop spoofing Deny anything source address as own address
Router(config)#access-list 101 deny ip my_network_id any log
III. Permit the required services for the required IP Addresses only
!! Incoming Requests
! Permit access to Public web, Mail
access-list 101 permit tcp any host web_server_ip eq www
access-list 101 permit tcp any host mail_server_ip eq smtp
! Allow DNS request to DNS Servers
access-list 101 permit tcp any host dns_server_ip eq domain
access-list 101 permit tcp any host dns_server_ip eq domain
access-list 101 permit udp any host dns_server_ip eq domain
access-list 101 permit udp any host dns_server_ip eq domain
!! Return traffic
! Allow only ACKed tcp packets to your network or only to specific IPs accessing
Internet
access-list 101 permit tcp any my_network gt 1023 established
! Allow DNS query return traffic
access-list 110 permit udp any eq 53 host DNS_Client_IP gt 1023
! Allow FTP Clients return traffic
access-list 110 permit tcp any eq 20 my_network gt 1023
! Permit limited ICMP message types
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 echo-reply
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 net-unreachable
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 host-unreachable
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 port-unreachable
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 packet-too-big
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 administratively-prohibited
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 source-quench
access-list 101 permit icmp any 100.100.100.0 0.0.0.15 ttl-exceeded
IV. Block everything else
Router(config)# access-list 101 deny ip any any log
V. Apply the following on the External Interface as in
Router(config-if)# ip access-group 101 in
VI. OutBound ACLs
Include all ACLs of section 6.1
Permit packets only from own network only
access-list 102 permit ip My_network any
Deny and log everything else

Logging
Turn on the Router’s logging capability, send all log errors and blocked packets to a trusted syslog server.
Router(config)# logging buffered
Router(config)# logging syslog_server_ip

Reference
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00
801afc76.shtml