Infrastructure Access-List

As I explained in my lesson about the router security policy, routers are often used at the edge of our network where they are vulnerable to attacks. Because of this, you should have an access-list that blocks some of the most common attacks while you only permit traffic that is really required.

What your access-list will look like really depends on the the role of your router. Do you use it for NAT/PAT with some users behind it for Internet access or is it a transit router on the Internet? Do you use any VPNs or BGP? What kind of traffic flows through your router? These are all questions that you need to answer before you create an infrastructure access-list.

To give you an idea what a infrastructure access-list could look like I’ll show you some common statements that you might find in an infrastructure access-list.

Configuration

Here’s the topology:

The router above is connected to the Internet with one interface and has a public IP address. Behind the router is a host that requires Internet access.

ICMP Packet Filtering

ICMP is an important protocol for debugging, troubleshooting and error reporting so you shouldn’t completely block it. However it can be misused for reconnaissance or DoS attacks so it might wise to restrict it:

R1(config-ext-nacl)#permit icmp any any echo-reply 
R1(config-ext-nacl)#permit icmp any any unreachable 
R1(config-ext-nacl)#permit icmp any any time-exceeded 
R1(config-ext-nacl)#deny icmp any any

With the access-list statements above we only allow echo-reply so that we can respond to pings. Unreachable and time-exceeded are required for a traceroute. All other ICMP types are denies.

IP Fragment Filtering

Fragmentation is the process of breaking down IP packets into multiple smaller packets. This can be useful if your packets are too large for the interface MTU.

The problem with fragmentation is that there are a number of exploits so it might be wise to drop all fragmented packets:

R1(config-ext-nacl)#deny ip any any fragments

RFC 3330 Address Filtering

RFC 3330 describes the special addresses that were assigned for IPv4. There are no legitimiate packets that you could receive from your Internet connection that have these special addresses as the source address:

R1(config-ext-nacl)#deny ip host 0.0.0.0 any
R1(config-ext-nacl)#deny ip 127.0.0.0 0.255.255.255 any    
R1(config-ext-nacl)#deny ip 192.0.2.0 0.0.0.255 any
R1(config-ext-nacl)#deny ip 224.0.0.0 15.255.255.255 any

Let me explain these statements:

• You should never see an IP packet that uses 0.0.0.0 as its source IP address so we block it.
• The 127.0.0.0 /8 range is for the loopback, you should never see an IP packet from the Internet that uses this address.
• 192.0.2.0 /24 was assigned as the TEST-NET by IANA and addresses in this range are never used on the Internet.
• 224.0.0.0 /4 is the multicast range.

RFC 1918 Address Filtering

Private addresses are used on our local network, you shouldn’t expect to see any IP packets from the Internet with a private address as the source.

R1(config-ext-nacl)#deny ip 10.0.0.0 0.255.255.255 any
R1(config-ext-nacl)#deny ip 172.16.0.0 0.15.255.255 any
R1(config-ext-nacl)#deny ip 192.168.0.0 0.0.255.255 any

RFC 2827 Address Filtering

If you have your own public address space then you should add it in your access-list. You should never see an IP packet from the Internet that has one of your own IP addresses as the source: