ACL - permit ip any any

[chrislgicale]

Guys,

I have my below access-list input in the interface for incoming to our default gateway (i.e. "ip access-group 107 in").

I have a concern if the line 590 is appropriate in the network or should I input instead a "deny ip any any".

I want to have a clear understanding for what is the purpose of line 590.

Appreciate any input about this.

================================================================

Extended IP access list 107
    10 permit tcp host 172.32.16.11 any (486135 matches)
    20 permit tcp host 172.32.16.14 any (1375 matches)
    30 permit tcp host 172.32.16.12 eq 3389 host 192.168.1.6
    40 permit tcp host 172.32.16.12 eq 3389 host 192.168.1.70 (3341 matches)
    50 permit tcp host 172.32.16.12 eq 3389 host 192.168.1.71
    60 permit tcp host 172.32.16.15 eq 3389 host 192.168.1.6
    70 permit tcp host 172.32.16.15 eq 3389 host 192.168.1.70 (528 matches)
    80 permit tcp host 172.32.16.15 eq 3389 host 192.168.1.71
    90 permit tcp 172.32.16.0 0.0.3.255 any eq 4370
    100 permit udp 172.32.16.0 0.0.3.255 any eq 4569
    110 permit udp 172.32.16.0 0.0.3.255 any range 10000 20000 (1133610 matches)
    120 permit tcp 172.32.16.0 0.0.3.255 any eq domain
    130 permit udp 172.32.16.0 0.0.3.255 any eq domain (28690 matches)
    140 permit tcp 172.32.16.0 0.0.3.255 any eq echo
    150 permit udp 172.32.16.0 0.0.3.255 any eq echo
    160 permit tcp 172.32.16.0 0.0.3.255 any eq 22
    170 permit udp 172.32.16.0 0.0.3.255 any eq 22
    180 permit tcp 172.32.16.0 0.0.3.255 any eq 993 (28468 matches)
    190 permit tcp 172.32.16.0 0.0.3.255 any eq 995 (164579 matches)
    200 permit tcp 172.32.16.0 0.0.3.255 any eq 23399 (4 matches)
    210 permit udp 172.32.16.0 0.0.3.255 any eq 23399 (2830 matches)
    220 permit tcp 172.32.16.0 0.0.3.255 any eq 587 (162034 matches)
    230 permit tcp 172.32.16.0 0.0.3.255 any eq 445 (38 matches)
    240 permit tcp 172.32.16.0 0.0.3.255 eq 445 192.168.1.0 0.0.0.255 (381 match
es)
    250 permit tcp 172.32.16.0 0.0.3.255 any eq 465
    260 permit tcp 172.32.16.0 0.0.3.255 any eq ftp
    270 permit tcp 172.32.16.0 0.0.3.255 any eq www (974427 matches)
    280 permit tcp 172.32.16.0 0.0.3.255 any eq 443 (1008812 matches)
    290 permit tcp 172.32.16.0 0.0.3.255 any eq 143
    300 permit tcp 172.32.16.0 0.0.3.255 any eq 389
    310 permit tcp 172.32.16.0 0.0.3.255 any eq 522
    320 permit tcp 172.32.16.0 0.0.3.255 any eq 636
    330 permit tcp 172.32.16.0 0.0.3.255 any eq 135
    340 permit udp 172.32.16.0 0.0.3.255 any eq 135
    350 permit tcp 172.32.16.0 0.0.3.255 any eq 3389
    360 permit tcp 172.32.16.0 0.0.3.255 any eq pop3 (1748 matches)
    370 permit tcp 172.32.16.0 0.0.3.255 any eq 5223 (1440 matches)
    380 permit tcp 172.32.16.0 0.0.3.255 any eq 9339 (448 matches)
    390 permit tcp 172.32.16.0 0.0.3.255 any eq smtp
    400 permit tcp 172.32.16.0 0.0.3.255 any eq telnet (485 matches)
    410 permit tcp 172.32.16.0 0.0.3.255 any eq 5242 (63 matches)
    420 permit tcp 172.32.16.0 0.0.3.255 any eq 4244 (3162 matches)
    430 permit udp 172.32.16.0 0.0.3.255 any eq 5243
    440 permit udp 172.32.16.0 0.0.3.255 any eq 9785
    450 permit tcp 172.32.16.0 0.0.3.255 any eq 1720
    460 permit tcp 172.32.16.0 0.0.3.255 any eq 1494 (236933 matches)
    470 permit tcp 172.32.16.0 0.0.3.255 any eq 1503
    480 permit tcp 172.32.16.0 0.0.3.255 any eq 1731
    490 permit udp 172.32.16.0 0.0.3.255 any eq 1719
    500 permit udp 172.32.16.0 0.0.3.255 any eq 2727 (48 matches)
    510 permit udp 172.32.16.0 0.0.3.255 any eq 2427
    520 permit tcp 172.32.16.0 0.0.3.255 any eq 2000
    530 permit tcp 172.32.16.0 0.0.3.255 any eq 5060
    540 permit udp 172.32.16.0 0.0.3.255 any eq 5060 (46731 matches)
    550 permit tcp 172.32.16.0 0.0.3.255 any eq 8080 (20 matches)
    560 permit tcp 172.32.16.0 0.0.3.255 any eq 27000
    570 deny tcp 172.32.16.0 0.0.3.255 any (9986 matches)
    580 deny udp 172.32.16.0 0.0.3.255 any (220131 matches)
    590 permit ip any any (342462 matches)

[Peter Paluch]

Hi Christopher,

Whether the line 590 should be a permit or a deny line depends mostly on your security policy, and I can only try to guess it. What I can do is to have a look at the ACL in general and tell you if the line 590 makes any sense in combination with the rest of the ACL entries.

Your ACL can currently be split and logically explained by breaking it down into following sections:

• Entries 10 through 80 provide a permission to four specific hosts 172.32.16.{11,12,14,15} to access specific outside resources
• Entries 90 through 560 provide permissions to your internal networks in the range 172.32.16.0/22 to access specific outside resources
• Entries 570 and 580 make sure that outside the explicit permissions given by entries 10-560, your internal networks in the range 172.32.16.0/22 can not access any other resources.
• Entry 590 makes sure that every other traffic is permitted.

To me, it appears that the ACL entries 10 - 580 specifically focus on traffic sourced from 172.32.16.0/22. They define a set of permitted resources that can be accessed by this source address range, and explicitly block all other traffic from this range. However, if there was any other traffic flowing through this ACL which is not sourced from 172.32.16.0/22, this traffic is not filtered in any way, and this is what the entry 590 is about. If the entry 590 was not present, or if it was changed to deny ip any any, it would not have any influence on the traffic sourced by 172.32.16.0/22 as that is being dealt with by preceding entries; however, it would influence traffic sourced from different source IP addresses.

Actually, an observant reader would say that the lines 570 and 580 deal only with TCP and UDP traffic sourced from 172.32.16.0/22, and that other traffic from this source that is not TCP nor UDP, such as ICMP, IPsec, GRE, IPIP, 6to4, DCCP,  SCTP, UDP-Lite, etc. is permitted by the entry 590. This would be very true. At this point, I cannot say if that is an intention or just an omission. You must answer this doubt yourself because - as I said - I can only guess what your security policy looks like.

I hope this helps.

Best regards,
Peter

[chrislgicale]

Hi Peter,

Well appreciate your explanation.

Ports that is not TCP nor UDP, is the thing that I have no idea. Grateful that you cite an example. If you have suggested website I can check it and learn it more, that would be so much thanks.

I just learned from my bootcamp, I think the basic, that is why I'm looking what's the purpose of "permit ip any any" at the end.

I'm also thinking to "deny ip any any" in our network instead, however would it be more recommended, or what should I consider in implementing "deny ip any any" if I decided to.

Thanks much!

Chris

[Jon Marshall]

Chris

A common occurrence of acls is to permit any any at the end because of internet traffic ie. the destination IP could be anything.

However if you have accounted for that in your acl already then you don't need to permit any any at the end.

You have a permit line for the network to any IP for ftp, www and https so it may be that covers everything you need.

You can see from your acl output that you are getting a lot of hits on the permit any any line so you need to know what they are if you are going to remove it. It may be traffic you do not want to allow anyway but if you remove it you may find something you have not accounted for in your acl stops working.

As Peter mentioned that line is allowing other things, the most common one being ICMP eg. ping and traceroute.

It really is up to you and your security needs in terms of what you do as we cannot tell you that.

If you said you only wanted to allow certain ports and they have been accounted for in the specific lines in your acl and deny everything else then yes you should replace the permit ip any any line but you yourself would need to be sure you have accounted for everything as we just don't know.

Jon

[chrislgicale]

Jon / Peter,

Thanks for your response. Last question, does port 53 (DNS) need for everyone? Like the line 130 I created.

  130 permit udp 172.32.16.0 0.0.3.255 any eq domain

Thanks.

Chris

[Jon Marshall]

Chris

Yes you will need that line because people usually use names and not IP addresses when they are connecting to applications.

Jon

[Peter Paluch]

Chris,

With DNS, you should actually allow both UDP and TCP ports 53. UDP is used for the majority of DNS requests; however, for responses bigger than approximately 512 bytes, TCP will be used instead. In fact, failing to open both UDP and TCP port 53 for DNS can result into obscure problems where small and compact response make it through because they are sent over UDP while larger responses will cause clients to revert to TCP which is not allowed, and the lookup will ultimately fail.

Whenever DNS is involved, keep this in mind: both UDP and TCP ports 53 should be permitted.

Best regards,
Peter

[rizwanr74]

Hi Christopher,

All your permit lines for subnet "172.32.16.0 0.0.3.255" is applicable and works, only when there is an explicit deny lines for same subnet exists at 570 and 580, if it is not for line 570 and 580, all your permit lines from top to 560-lines means nothing due to your explicit permit line at 590.

Normally a DMZ interface with security level less than 100, requires an ACL to access any other interfaces, however for an interface with 100 security level do not require an ACL but if you choose to have ACL for inside, you can do so and then it requires explicit permit lines for subnets need to access any other interfaces.

Your permit line at 590, basically opens up a flood-gate to access anything and everything through other interfaces and it treats that interface as if it is an inside interface and defeats the purpose of having a DMZ.

Hope that answers your question.

Thanks

Rizwan Rafeek.