ACLs and how they work again LOL! need refresher.
Okay I know that ACLs have a IMPLIED deny any any at the end. That I do remember but how do you read these?
ip access-list extended PCWireless-Traffic
permit udp any any eq bootpc
permit udp any any eq bootps
permit ip 192.168.237.64 0.0.0.63 192.168.237.64 0.0.0.63
deny ip 192.168.237.64 0.0.0.63 192.168.0.0 0.0.255.255
deny ip 192.168.237.64 0.0.0.63 10.0.0.0 0.255.255.255
permit ip any any.........................(doesn't this forget all above and allow all and above is useless?)
ip access-list extended less-Traffic
permit udp any any eq bootpc
permit udp any any eq bootps
permit ip 192.168.237.0 0.0.0.63 192.168.237.0 0.0.0.63
deny ip 192.168.237.0 0.0.0.63 192.168.0.0 0.0.255.255
deny ip 192.168.237.0 0.0.0.63 10.0.0.0 0.255.255.255
permit ip any any .........................(doesn't this forget all above and allow all and above is useless?)
deny ip any any
ip access-list extended BOZO
deny udp any host 192.168.194.52
deny ip any host 192.168.194.52
permit ip any any.........................(doesn't this forget all above and allow all and above is useless?)
I get confused when I see permit, deny, and then permit any any and why would they say at end Deny any any even if there is an implied deny any any (maybe they do not know this?) but I am use to seeing deny first, and then permits not permit, deny, permit. can you set me straight on this...thanks been a while and the acls I am used to seeing are not like this...
Comments
-
networker050184 Mod Posts: 11,962 ModYou read it from top to bottom and take action on a match. Something further down in the process does not overwrite something earlier in the ACL.An expert is a man who has made all the mistakes which can be made.
-
techfiend Member Posts: 1,481 ■■■■□□□□□□The way I understand it in PCWireless-Traffic all traffic except 192.168.1.64/26 going to 192.168.0.0/16 or 10.0.0.0/8 is allowed. The first 3 permits are unnecessary.2018 AWS Solutions Architect - Associate (Apr) 2017 VCAP6-DCV Deploy (Oct) 2016 Storage+ (Jan)
2015 Start WGU (Feb) Net+ (Feb) Sec+ (Mar) Project+ (Apr) Other WGU (Jun) CCENT (Jul) CCNA (Aug) CCNA Security (Aug) MCP 2012 (Sep) MCSA 2012 (Oct) Linux+ (Nov) Capstone/BS (Nov) VCP6-DCV (Dec) ITILF (Dec) -
itdaddy Member Posts: 2,089 ■■■■□□□□□□Yeah techfiend that is how I read it. deny the specifics and the permit everything else or snap the denies and let all else through IP level.
-
techfiend Member Posts: 1,481 ■■■■□□□□□□Actually the first 3 permits are useful.2018 AWS Solutions Architect - Associate (Apr) 2017 VCAP6-DCV Deploy (Oct) 2016 Storage+ (Jan)
2015 Start WGU (Feb) Net+ (Feb) Sec+ (Mar) Project+ (Apr) Other WGU (Jun) CCENT (Jul) CCNA (Aug) CCNA Security (Aug) MCP 2012 (Sep) MCSA 2012 (Oct) Linux+ (Nov) Capstone/BS (Nov) VCP6-DCV (Dec) ITILF (Dec) -
d4nz1g Member Posts: 464Actually the first 3 permits are useful.
How? I don't see any statement there that is not shadowed by the permit ip any any.
Edit: now I see it haha
Forgot to read the whole ACL -
itdaddy Member Posts: 2,089 ■■■■□□□□□□is it because it is UDP that they are useful? and not IP ? but what about TCP is TCP covered by IP? and UDP is not?
-
itdaddy Member Posts: 2,089 ■■■■□□□□□□in the OSI model IP is under TCP and UDP so I think you are right the first two permits are not needed because of the permit ip any any.
-
networker050184 Mod Posts: 11,962 ModTake a sample packet from your network and go down the line. As soon as a match is made it's allowed or denied. Really the best way to go about it.An expert is a man who has made all the mistakes which can be made.
-
devilsadvocate Member Posts: 6 ■□□□□□□□□□TCP and UDP are included within IP.
Access Lists apply in a top down order so when the packet is read by the ACL it starts on line 1 and asks
'Does this traffic match line 1?'
If yes, apply the permit or deny as appropriate.
If no, move on to line 2.
Continue down until a match is met.
Initially I agreed with most of the other posters in that I thought your permit statements were redundant as it would be covered by the ip any any line. However you have some deny statements so that may not be the case.
If we take the first ACL, the first two permit statements effectively allow DHCP from any host to any host.
The third line seems to allow the 192.168.237.64 /26 subnet to access itself which may seem odd but I have seen this be required in the past when the hosts on that subnet were split among different access switches.
The forth and fifth lines deny anything on the 192.168.237.64 /26 subnet from accessing anything on the 10.0.0.0 /8 and 192.168.0.0 /16 subnets.
Then comes the any any.
I think the reason that the permit statements are there is to control what the 192.168.237.64 /26 subnet can access before the deny statement kicks in. If you remove the top 3 permit statements, the 192.168.237.64 /26 subnet will not be able to access anything in the 10.0.0.0 /8 or 192.168.0.0 /16. What if you need a host in the 192.168.237.64 /26 subnet to be able to obtain a DHCP address from a DHCP server with the IP address 10.1.1.1? If you remove the top 3 permit lines, the DHCP discover packets will hit the deny lines and its game over. The ACL will never get to the ip any any because of the deny statements.
I suspect (and I could be wrong) that whoever created this ACL wanted hosts in the 192.168.234.64 /26 subnet to be able to get a DHCP address from a DHCP server within one of the 192.168.0.0 /16 or 10.0.0.0 /8 networks, hence the allow statements before the deny.
I think anyway -
ph4ntom74 Member Posts: 10 ■□□□□□□□□□anything that is not specifically permitted by the ACL is denied, so ACL's should be kept simple and intuitive. I've seen so many awful and unnecessary statements in ACL's that gives me the creeps, and headaches...
-
itdaddy Member Posts: 2,089 ■■■■□□□□□□Devilsadvocate:
you said which I agree.
'Does this traffic match line 1?'
If yes, apply the permit or deny as appropriate.
If no, move on to line 2.
Continue down until a match is met.
but then the 2 top permit statements are doing nothing since when the packet reaches bottom of ACL it allows them any ways. correct? -
techfiend Member Posts: 1,481 ■■■■□□□□□□The top 2 entries are there to allow bootpc and bootps on the 192.168.27.64/26 network otherwise they might be denied by entries 4 and 5, depending on the destination.2018 AWS Solutions Architect - Associate (Apr) 2017 VCAP6-DCV Deploy (Oct) 2016 Storage+ (Jan)
2015 Start WGU (Feb) Net+ (Feb) Sec+ (Mar) Project+ (Apr) Other WGU (Jun) CCENT (Jul) CCNA (Aug) CCNA Security (Aug) MCP 2012 (Sep) MCSA 2012 (Oct) Linux+ (Nov) Capstone/BS (Nov) VCP6-DCV (Dec) ITILF (Dec) -
devilsadvocate Member Posts: 6 ■□□□□□□□□□Devilsadvocate:
you said which I agree.
'Does this traffic match line 1?'
If yes, apply the permit or deny as appropriate.
If no, move on to line 2.
Continue down until a match is met.
but then the 2 top permit statements are doing nothing since when the packet reaches bottom of ACL it allows them any ways. correct?
That was my initial thought but then I thought about it a little more.
If it were simply a list of permit statements (i.e no deny) with an ip any any permit at the end, then yes, all the permit statements above the ip any any would be pointless. However, they have some deny statements above the ip any any for the 192.168.27.64 /26 network.
The first couple of permit statements are for bootpc and bootps.
What if they want to permit bootpc for the 192.168.27.64 /26 network but block access for this network to everything else?
Without the first two permit statements, this network would be blocked from accessing the 192.168.0.0 /16 and 10.0.0.0 /8 networks (because of the deny statements).
Hopefully that makes sense!