Posted by: rolande | April 14, 2007

Best Practices for Inbound Cisco Access Lists

The following is a commented example of an Access List configuration for a router that acts as a “choke” device on the inside or outside of a true firewall device. The ! signifies a commented line in Cisco’s notation. Non-commented lines are the actual configuration syntax as it would be entered on the Cisco router.

The information supplied in this configuration is in no way guaranteed or supported by the author to “secure” your network. This is meant to provide an example of generally accepted configuration practices when securing routers that provide access to untrusted networks.

This access-list should be applied inbound on your choke router to what is considered your external or outside interface. In most cases, for routers outside your firewall this will be some sort of WAN interface like a serial port, BRI interface, frame relay sub-interface, or ATM PVC. This filters traffic that is coming from the Internet or untrusted network “inbound” on the external interface connecting to the Internet.


DISCLAIMER

No Warranty of any kind is expressed or implied with respect to the information contained in this document!

The information found here is compiled for the convenience of anyone looking for general guidelines and best practices for configuration based on my own professional experience, as well as industry standards.

Use this information at your own risk!

Scott S. 2007


! In light of the latest Cisco interface buffer vulnerability you may need
! to implement the following filter to deny the associated protocol types
! if you have not or can't upgrade your code to a patched version.
! If you need Multicast don't implement the deny pim line...
deny   53 any any log-input
deny   55 any any log-input
deny   77 any any log-input
deny   pim any any log-input

! Deny all standard external spoofing attacks and log all attempts
! from illegal addresses, your external block, and reserved space
! For obvious reasons, non-routable Internet addresses should not be allowed to
! come inbound. A favorite of hackers is to spoof private source addresses or
! even masquerade as public addresses on your own external networks.
!
deny ip 0.0.0.0 0.255.255.255 any log-input
deny ip 10.0.0.0 0.255.255.255 any log-input
deny ip 127.0.0.0 0.255.255.255 any log-input
deny ip 169.254.0.0 0.0.255.255 any log-input
deny ip 172.16.0.0 0.15.255.255 any log-input
deny ip 192.168.0.0 0.0.255.255 any log-input
deny ip 224.0.0.0 15.255.255.255 any log-input
deny ip host 255.255.255.255 any log-input
deny ip host 0.0.0.0 any log-input
deny ip <your network here> <wildcard mask> any log-input
deny ip host <ip address of serial interface> any log-input

!Deny any abusive networks here...
!
deny ip xxx.xxx.xxx.xxx 0.0.0.255 any log-input

! The commands below are all for routers being used as a firewall device.
! If you plan on using another device for a firewall, then do not add any other
! configuration lines except for the following:
! permit ip any any

! If you plan on using your router as your only firewall device you can permit
! or deny particular services as outlined below. The following are only examples.
! There are hundreds of services and non-standard configurations you may need to
! allow based on your indivdual requirements. If you do not have the budget
! for a true firewall such as a PIX, Checkpoint or Netscreen, you should still use
! a router that is sized properly to do the job you need. A Cisco 2620 or 2640
! should have plenty of CPU for Reflexive ACLs or Context Based Access
! Control for a full T-1 worth of traffic. The other key component is RAM. Allow for
! a minimum of 32MB or 64MB if possible. If your budget is still an issue, you are
! probably better off building a firewall using a PC server (under $1000) with 2
! network cards using Linux or NetBSD and IPChains firewall software. You can get a
! lot more mileage out of a machine like that than a low-end Cisco router which
! really wasn't designed for that purpose anyway.
!
! Include the inbound Reflexive Access-Lists if you are using this
! function. If you have CBAC available on your router, the inspection
! function is a better option to implement instead of Reflexive ACLs as it
! provides for tighter stateful control over traffic sessions. In this
! case, do not use the evaluate option in your inbound ACL. CBAC will
! automatically take care of this for you.
!
! *WARNING* Reflexive Access Lists and CBAC are CPU and memory intensive
! on your router. Make sure that your hardware is properly sized to
! support your volume of traffic.
!
! For further explanation of these services and port numbers please refer to
! documentation for the specific protocols.
!
evaluate alliptraffic

! If you will be implementing a firewall behind your outside edge router you
! can end the access-list at this point with...
!
permit ip any any

! If your router is your only firewall device and you need to host any inbound
! services behind your router do not use the above permit ip any any statement.
! The following config may help you out with some example setups. You will
! need to make sure you specifically define each service you need to provide
! access to from the Internet. If you have access to the IOS Firewall feature
! set you should use the ip inspect configuration to handle inbound access to
! services.
!
! Allow outside ftp sessions inbound
!
permit tcp any host <ftp server ip address> eq 21

! Allow ftp to work from inside your network (requires port 20 to be open
! for incoming data session)
!
permit tcp any eq 20 host <ftp client ip address or proxy server> gt 1024

! Allow auth/identd traffic for smtp mail and for other client apps
!
permit tcp any host <smtp server ip address> eq 113
permit tcp any host <proxy server ip address> eq 113

! Allow smtp traffic inbound to mail servers
!
permit tcp any host <smtp server ip address> eq smtp

! Allow http traffic inbound to all web servers
!
permit tcp any host <web server ip address> eq www

! Allow SSL traffic inbound to all SSL servers
!
permit tcp any host <ssl server ip address> eq 443

! Allow Microsoft PPTP/VPN sessions to connect inbound and log control channel
!
permit tcp any host <vpn server ip address> eq 1723 log-input
permit tcp any host <vpn server ip address> eq 1731
permit gre any host <vpn server ip address>

! Allow only certain remote addresses to perform tcp DNS transfers from
! specific DNS servers for secondary DNS service and log each connection
!
permit tcp host <external dns server ip address> host <dns server ip address> eq domain log-input

! Allow inbound client DNS requests to all DNS servers
!
permit udp any host <dns server ip address> eq domain

! Allow DNS resolution from the router's serial port for testing purposes
!
permit udp any eq 53 host <ip address of serial port>

! Allow only particular types of icmp packets inbound to
! maintain integrity of data flow and sanity and for troubleshooting etc.
!
permit icmp any <network address> <wildcard> net-unreachable
permit icmp any <network address> <wildcard> host-unreachable
permit icmp any <network address> <wildcard> port-unreachable
permit icmp any <network address> <wildcard> parameter-problem
permit icmp any <network address> <wildcard> packet-too-big
permit icmp any <network address> <wildcard> administratively-prohibited
permit icmp any <network address> <wildcard> source-quench
permit icmp any <network address> <wildcard> ttl-exceeded
permit icmp any <network address> <wildcard> echo-reply

! Deny all other ICMP explicitly so it isn't logged
!
deny icmp any any

! Deny all other ip traffic explicitly and log it.
!
deny   tcp any range 0 65535 any range 0 65535 log-input
deny   udp any range 0 65535 any range 0 65535 log-input
deny ip any any log-input

DISCLAIMER

No Warranty of any kind is expressed or implied with respect to the information contained in this document!

The information found here is compiled for the convenience of anyone looking for general guidelines and best practices for configuration based on my own professional experience, as well as industry standards.

Use this information at your own risk!

Scott S. 2007


Advertisements

Responses

  1. […] Best Practices for Inbound Access Lists […]

    Like


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: