10-29-2008 05:03 AM - edited 02-20-2020 09:41 PM
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.
Solved! Go to Solution.
10-29-2008 07:39 AM
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!
10-29-2008 05:15 AM
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
10-29-2008 06:59 AM
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
10-29-2008 07:39 AM
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!
10-29-2008 07:42 AM
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
10-29-2008 07:53 AM
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.
10-29-2008 09:24 AM
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
10-29-2008 10:16 AM
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.
08-26-2020 07:25 PM
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.
11-08-2023 01:35 PM - edited 11-08-2023 01:44 PM
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
11-08-2023 01:57 PM
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.
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: