ACL Best Practice - On the Internet interface

Answered Question
Oct 29th, 2008
User Badges:

I have a question relating to ACL's on a routers 'Internet' facing interface.


Further to reading several whitepapers on the topic, a recommended ACL would typically contain the following statements.

In addition, the Cisco SDM automatically generates a similar externally facing ACL:


ip access-list extended INBOUND

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any unreachable

deny ip 10.0.0.0 0.255.255.255 any

deny ip 172.16..0.0 0.15.255.255 any

deny ip 192.168.0.0 0.0.255.255 any

deny ip 127.0.0.0 0.255.255.255 any

deny ip host 0.0.0.0 any

deny ip any any

!




My question is thus...

What is the point of lines 4-8 when the last line blocks them anyway?

I appreciate that when we view the ACL we can see the number of matches per explicit ACL entry, but in terms of blocking functionality, I can't see the added benefit.

Instead, the following ACL would provide the same benefit and be simpler to maintain.



ip access-list extended INBOUND

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any unreachable

deny ip any any

!




Am I missing something obvious?


Thanks in advance for assistance,

Regards.


Correct Answer by pawest about 8 years 7 months ago

Hello Peter,

I believe that when people post these examples, they assume that you will put additional statements in before the "deny ip any any" at the end. There are really a few rules that you should use when creating an Internet facing ACL:

1. Deny incoming traffic sourced from your registered IP addresses to prevent spoofing.

2. Deny incoming Microsoft LAN traffic (port 445, 137-139, etc) - any legitimate Microsoft LAN traffic should be confined to a VPN.

3. Deny traffic sourced from private or null addresses.


I'm sure that you realize that packets can be crafted with the established bit set, and use private addresses (broadcast or unicast) or your registered addresses as their source to create unwanted traffic or denial of service attacks. This is why those statements are called out separately. You would use them before the "permit tcp any (your registered IP range) established" statement.


Your proposed ACL only permits tcp responses to internally generated requests. Unless you really don't want any UDP traffic, you should include a reflexive access list statement to permit UDP. I also hope you have a big log server or just a few hosts on your network -- logging all tcp traffic will take up quite a bit of space!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.8 (4 ratings)
Loading.
Jon Marshall Wed, 10/29/2008 - 05:15
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Peter


That access-list would block all traffic except ICMP, and even then only certain ICMP types. You are right in your analysis but i suspect that the last line is meant to be "permit ip any any".


If it isn't then all return traffic inbound would be blocked so a user on your LAN connects to a wbe server but the return traffic from the web server will get dropped by this access-list. Probably not what you want.


The other thing is ICMP is covered by IP so your'e original access-list should read


ip access-list extended INBOUND

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any unreachable

deny icmp any any

deny ip 10.0.0.0 0.255.255.255 any

deny ip 172.16..0.0 0.15.255.255 any

deny ip 192.168.0.0 0.0.255.255 any

deny ip 127.0.0.0 0.255.255.255 any

deny ip host 0.0.0.0 any

permit ip any any


This allows only the ICMP traffic you want, then denies all other ICMP traffic + the addresses you should not be seeing coming from the Internet and then all other legitimated traffic.


Note that this is just an ACL on the Internet facing router to do preliminary filtering. You should then have a firewall behind this for more detailed filtering.


Jon

petermann Wed, 10/29/2008 - 06:59
User Badges:

thanks Jon for your response.


With regard to your first suggestion relating to a possible typo, my intention was not "permit ip any any".

My main point is that there are several example configurations posted on the Internet which at the top of the ACL explicitly deny specfic types of traffic then have a blanket 'DENY ALL' at the end. Here's another example someone else has posted:


http://www.velocityreviews.com/forums/t34618-cisco-837-wan-interface-accesslist.html



With regard to your second suggestion, your right, I should have included a command like:


permit tcp any any established log



I appreciate this ACL is not stateful and I should use either the firefall feature set or a dedicated firewall applicance.


My question primarily is related to my first point. i.e. what is the point of :


deny ip 10.0.0.0 0.255.255.255 any

deny ip 172.16..0.0 0.15.255.255 any

deny ip 192.168.0.0 0.0.255.255 any

deny ip 127.0.0.0 0.255.255.255 any

deny ip host 0.0.0.0 any


when we have the following statement at the end:

deny ip any any



There are many example Internet facing ACLs posted on the net that propose this same example configuration.




thanks again for your response.

- peter

Correct Answer
pawest Wed, 10/29/2008 - 07:39
User Badges:
  • Cisco Employee,

Hello Peter,

I believe that when people post these examples, they assume that you will put additional statements in before the "deny ip any any" at the end. There are really a few rules that you should use when creating an Internet facing ACL:

1. Deny incoming traffic sourced from your registered IP addresses to prevent spoofing.

2. Deny incoming Microsoft LAN traffic (port 445, 137-139, etc) - any legitimate Microsoft LAN traffic should be confined to a VPN.

3. Deny traffic sourced from private or null addresses.


I'm sure that you realize that packets can be crafted with the established bit set, and use private addresses (broadcast or unicast) or your registered addresses as their source to create unwanted traffic or denial of service attacks. This is why those statements are called out separately. You would use them before the "permit tcp any (your registered IP range) established" statement.


Your proposed ACL only permits tcp responses to internally generated requests. Unless you really don't want any UDP traffic, you should include a reflexive access list statement to permit UDP. I also hope you have a big log server or just a few hosts on your network -- logging all tcp traffic will take up quite a bit of space!

srue Wed, 10/29/2008 - 07:53
User Badges:
  • Blue, 1500 points or more

rfc2827 can offer some good advice here. dont forget to allow traffic to your own networks. you can also implement outbound acl's that allow traffic to leave only from your IP range. etc etc.


You also might want to look into the firewall feature set if this router will be acting as your firewall. if this router is just a router (and you have a real firewall behind it), you are probably ok as is.

just my two cents.

Jon Marshall Wed, 10/29/2008 - 09:24
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Peter


Apologies i made an incorrect assumption.


The reason you need


deny ip 10.0.0.0 0.255.255.255 any

deny ip 172.16..0.0 0.15.255.255 any

deny ip 192.168.0.0 0.0.255.255 any

deny ip 127.0.0.0 0.255.255.255 any


is because you would then follow that with a


permit tcp any any established log


and then a deny ip any any


If you didn't have those 4 lines before your "permit tcp .." line then packets could come in that have the ack bit set and have a source IP address of one of those ranges. You know that you will never want any traffic from those ip address ranges coming from the Internet so you block all IP traffic from those ranges which obviously includes TCP/UDP, then you all TCP established from all IP ranges and then you deny any other IP.


Jon

srue Wed, 10/29/2008 - 10:16
User Badges:
  • Blue, 1500 points or more

make sure you deny rfc1918 addresses entering and exiting your network. only allow your assigned ip range to receive traffic, or to source traffic.

the 'established' keyword is one of the least preferred ways of allowing traffic. anyone can set the established bit in a packet and send it through. it only 'simulates' statefulness, but is not actually stateful in nature. use the firewall feature set instead at least.

Actions

This Discussion