cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
18395
Views
22
Helpful
10
Replies

ACL Best Practice - On the Internet interface

petermann
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

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!

View solution in original post

10 Replies 10

Jon Marshall
Hall of Fame
Hall of Fame

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

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

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!

If that ACL is used as an example then I would think that it is expected that you would add additional entries between the "deny ip host 0.0.0.0 any" and the "deny ip any any"

Based on that assumption the lines 4 - 8 prevent traffic from the private addresses based on lines that you may add.

Mike

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.

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

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.

I know this is a very old post but to those that may still come across this topic I wanted to add some insight to the purpose of an ACL of this type. The top lines while they would be covered in the "deny IP any any" statement are placed at the top so you can get "hits". That is when you do a "show ip access-list xxxxx" then you will see hit counters next to each line item. At the bottom of any ACL is the implicit deny ip any any statement, so you technically don't need to write it, but we do that to see how many hits are coming in. 

 

 

for example I could have an Internet-facing ACL that looks like:

 

ip access-list extended acl-Internet-In

deny tcp any any eq 22
deny tcp any any eq telnet
deny udp any any range netbios-ns netbios-ss
deny tcp any any range 137 139
deny udp any any eq 445
deny tcp any any eq 445
deny udp any any eq 135

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

 

This essentially blocks all traffic which i wouldn't want - but using it to illustrate a point. None of this is needed... technically you can apply a blank acl and do the same thing. However, each line being explicitly listed allows me to capture hits. Anyone trying to SSH to an IP will be caught on the first line, while telnet access captured on the second line. If nothing else matches then the bottom deny ip any any flags. This lets me know what kind of traffic is hitting my router. 

 

It blocks everything but now i know what is being blocked the most or least. That is the purpose of an ACL like this.

 

 

-Toby


Please don't forget to rate any helpful post.

_____________________________________
There are no great limits to growth because there are no limits of human intelligence, imagination, and wonder.
- Ronald Reagan

Hi Jon,

Thanks a lot for this info sir. I did apply the ACLs as advised and which seem to be working since I could see bunch of hit counts on the deny rules:

!
RTR#show running-config interface Gig0/1
Building configuration...

Current configuration : 170 bytes
!
interface GigabitEthernet0/1
ip address x.x.x.x 255.255.255.192
ip access-group INBOUND in
negotiation auto
crypto map VPN
end
!
!
RTR#show ip access-lists INBOUND
Extended IP access list INBOUND
10 permit icmp any any echo (70 matches)
20 permit icmp any any echo-reply
30 permit icmp any any unreachable
40 deny icmp any any
50 deny ip 10.0.0.0 0.255.255.255 any (1185 matches)
60 deny ip 172.16.0.0 0.15.255.255 any
70 deny ip 192.168.0.0 0.0.255.255 any (10025494 matches)
80 deny ip 127.0.0.0 0.255.255.255 any
90 deny ip host 0.0.0.0 any (41770 matches)
100 permit ip any any (10585585 matches)
RTR#

However, I noticed that I am still seeing connection between my vpn tunnel interface and some addresses within 192.168.0.0/16 subnet and from unwanted IP 142.56.131.1 afterwards! Any idea what could be wrong here? See the attached file for details. Many Thanks

Hi Jon,

Thanks a lot for this info. I did apply the ACLs as advised and which seem to be working since I could a bunch of hit counts against the deny rules.

!
RTR#show running-config interface GigabitEthernet0/1
Building configuration...

Current configuration : 170 bytes
!
interface GigabitEthernet0/1
ip address x.x.x.x 255.255.255.192
ip access-group INBOUND in
negotiation auto
crypto map VPN
end
!
!
RTR#show ip access-lists INBOUND
Extended IP access list INBOUND
10 permit icmp any any echo (70 matches)
20 permit icmp any any echo-reply
30 permit icmp any any unreachable
40 deny icmp any any
50 deny ip 10.0.0.0 0.255.255.255 any (1185 matches)
60 deny ip 172.16.0.0 0.15.255.255 any
70 deny ip 192.168.0.0 0.0.255.255 any (10025494 matches)
80 deny ip 127.0.0.0 0.255.255.255 any
90 deny ip host 0.0.0.0 any (41770 matches)
100 permit ip any any (10585585 matches)
RTR#

However, I could still see some communication between my vpn tunnel interface and some IPs within the 192.168.0.0/16 subnets as well as unwanted IP address 142.56.131.1 afterwards! Any idea what could be the issue here? See the attached file for details. Many Thanks.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: