Access Control Lists (ACL) - Questions and their Answers
Q1. Design an IP access list that permits traffic from host 193.5.2.76, but denies all other IP traffic.
A1. Here are three solutions to this problem:
access-list 2 permit host 193.5.2.76
access-list 1 permit 193.5.2.76 0.0.0.0
access-list 3 permit 193.5.2.76
Any of these three single-line access lists will give the required result. Remember that there is always an implied "deny" following the last line of an access list, and that standard IP access-list numbers can be anything within the range of 1-99. It could also be done with an extended access list, for example:
access-list 101 permit ip host 193.5.2.76 any
but why use an extended list when a standard list will do?
------
Q2. Design an IP access list that denies traffic from host 11.5.25.239, but permits all other IP traffic.
A2. One solution to this problem:
access-list 7 deny host 11.5.25.239
access-list 7 permit any
------
Q3. Design an IP access list that permits IP traffic from hosts on network 196.25.1.0/24, and denies other IP traffic.
A3. Since there are 254 possible host addresses on this network, we don't want to specify them individually. Therefore, we will use a wildcard mask. An access list that meets the requirements is:
access-list 7 permit 196.25.1.0 0.0.0.255
------
Q4. Design an access list that denies IP traffic from hosts 152.5.35.83 and 104.2.64.33, permits IP traffic from all hosts on network 185.25.0.0/16, and denies all other IP traffic. Invoke your access list inbound on interface E2.
A4. One solution to this problem:
interface e2
ip access-group 13 in
access-list 13 deny host 104.2.64.33
access-list 13 deny host 152.5.35.83
access-list 13 permit 185.25.0.0 0.0.255.255
Again, we can use the keyword "host", as in "host 104.2.64.33", or we can use the mask "0.0.0.0" following a host address, such as "252.5.35.83 0.0.0.0". Note also that since the first two "denies" are covered by the implicit "deny any" that ends a standard IP access list, we can devise a more efficient solution as follows:
interface e2
ip access-group 13 in
access-list 13 permit 185.25.0.0 0.0.255.255
------
Q5. Given the statements:
interface ethernet 1
ip access-group 25 in
access-list 25 permit host 101.2.3.40
access-list 25 deny 203.45.0.0 0.0.255.255
access-list 25 permit any
What will the result be?
A5. Access list 25 has been placed inbound on interface E1. Therefore, any IP traffic from host 101.2.3.40 will be allowed into the router via E1. No IP traffic from any of the 256 Class "C" networks starting with 203.45.0.0 will be allowed into E1, but any other IP traffic will be permitted.
Since the traffic from host 101.2.3.40 is also permitted by the last line, the first line is superfluous, and the same result could be obtained by using:
access-list 25 deny 203.45.0.0 0.0.255.255
access-list 25 permit any
------
Q6. Design an access list that permits IP traffic from hosts 1.2.3.98 and 1.2.3.99, and denies all other IP traffic. Invoke your access list outbound on interface Token Ring 3/1.
A6. The most straightforward solution:
interface token-ring 3/1
ip access-group 66 out
access-list 66 permit host 1.2.3.98
access-list 66 permit host 1.2.3.99
On the other hand, we could get cute and use a wildcard mask. If we examine the bit patterns for the two host addresses, we notice that they are identical in the first three octets, and identical up to the last bit in the fourth octet, where the two possibilities are our two host addresses. Therefore, we can cover both addresses with one line, and an alternative solution is as follows:
interface token-ring 3/1
ip access-group 66 out
access-list 66 permit 1.2.3.98 0.0.0.1
Note that this just might be too clever for our own good, in that it only saved us one line, and it is no longer readily apparent what the access list is doing.
------
Q7. Design an extended IP access list that denies HTTP traffic intended for the web server at 47.23.67.102, permits HTTP traffic to other web servers, and denies all other IP traffic. Invoke your access list inbound on interface E0, and outbound on FDDI interface 3.
A7. The most straightforward solution:
interface ethernet 0
ip access-group 101 in
interface fddi 3
ip access-group 101 out
access-list 101 deny tcp any host 47.23.67.102 eq www
access-list 101 permit tcp any any eq www
Q8. Given the statements:
interface ethernet 0
ip access-group 95 in
access-list 95 deny host 101.202.3.4
access-list 95 deny 203.45.6.0 0.0.0.255
access-list 95 permit any
What will the result be?
A8. This configuration denies any IP traffic from host 101.202.3.4 from entering interface E0, it denies all IP traffic from any host on network 203.45.6.0/24 from entering interface E0, and it permits any other IP traffic to enter through interface E0.
------
Q9. Design an IP access list that permits TFTP traffic to TFTP servers that have host addresses ending in even numbers, denies TELNET traffic to TELNET servers that have host addresses ending in odd numbers, permits traffic to other TELNET servers, and denies all other IP traffic. Activate your list inbound on interface E1.
A9. To check for even and odd addresses, we only care that the last bit is a zero or a one, respectively. We can do it with:
interface ethernet 1
ip access-group 102 in
access-list 102 permit udp any 0.0.0.0 255.255.255.254 eq tftp
access-list 102 permit tcp any 0.0.0.0 255.255.255.254 eq telnet
------
Q10. Design an extended access list that permits all IP traffic from hosts on network 215.23.45.0/24, denies all IP traffic going to subnet 52.54.0.0/16, permits anyone to open a Telnet session with either 14.63.73.66 and 221.63.62.88 (and logs such packets to the console), and denies all other IP traffic. Invoke your list inbound on the first Token Ring interface on the card in slot 2.
A10. One solution:
interface token-ring 2/0
ip access-group 158 in
access-list 158 permit ip 215.23.45.0 0.0.0.255 any
access-list 158 deny ip any 52.54.0.0 0.0.255.255
access-list 158 permit tcp any host 14.63.73.66 eq telnet log
access-list 158 permit tcp any host 221.63.62.88 eq telnet log
------
Q11. Given the statements:
interface serial 0
ip access-group 164 out
access-list 164 deny tcp 14.3.6.234 0.0.0.0 host 6.5.4.1 eq 23
access-list 164 deny udp any any eq tftp
access-list 164 permit ip any any
What will the result be?
A11. This configuration denies TELNET traffic from 14.3.6.234 bound for host 6.5.4.1 from leaving interface S0, it denies all TFTP traffic bound for TFTP servers, and it permits all other IP traffic. Consistency is a good thing, so, unlike this exercise, use either the keyword "host" or the mask "0.0.0.0". Don't mix and match.
------
Q12. Design an access list that permits web traffic from the server at 101.54.32.2 to all hosts on subnet 149.23.8.0/24, permits pings in either direction between the hosts on network 39.0.0.0/8 and subnet 197.2.5.96/27, and denies everything else. Place this access list in force in the outbound direction on the router's E2 port.
A12. One solution:
interface ethernet 2
ip access-group 199 out
access-list 199 permit tcp host 101.54.32.2 eq www 149.23.8.0 0.0.0.255
access-list 199 permit icmp 39.0.0.0 0.255.255.255 197.2.5.96 0.0.0.31 echo
access-list 199 permit icmp 39.0.0.0 0.255.255.255 197.2.5.96 0.0.0.31 echo-reply
access-list 199 permit icmp 197.2.5.96 0.0.0.31 39.0.0.0 0.255.255.255 echo
access-list 199 permit icmp 197.2.5.96 0.0.0.31 39.0.0.0 0.255.255.255 echo-reply
Some explanations are in order here.
In the first line of the access list, we are interested in traffic that is coming from the web server, so we place the port identifier after the source address, not the destination address.
The second and third lines take care of pings (ICMP echo) and replies (ICMP echo-reply) leaving 39.0.0.0/8.
The fourth and fifth lines take care of pings and replies leaving 197.2.5.96/27.
Remember, using a "/27" subnet mask (same as "255.255.255.224") with a class "C" network means that we have set aside three bits in the fourth octet for subnetting. For the "96" subnet, the bit pattern is "011XXXXX", where the X's mean we don't care. Since the first three bits must be "011", and we don't care about the last five bits, the last octet of the wildcard mask must be "00011111", which is 31. The first three octets have to match exactly, so the wildcard mask is "0.0.0.31".
------
Q13. Given the statements:
interface fddi 3/2
ip access-group 66
access-list 66 permit 100.200.0.0 0.0.255.63
What will the result be?
A13. This configuration permits IP traffic from any host within the range from 100.200.0.0 - 100.200.0.63, 100.200.1.0 - 100.200.1.63 ... 100.200.255.0 - 100.200.255.63 to pass outbound (the default direction for "access-group" statements) via FDDI 3/2. By the way, letting it choose "outbound" by default is bad practice. You should specify the direction you desire.
------
Q14. Design an access list that permits all IP traffic except pings in either direction between subnets 10.20.0.0/16 and 40.50.60.0/24.
A14. One solution:
access-list 197 deny icmp 10.20.0.0 0.0.255.255 40.50.60.0 0.0.0.255 echo
access-list 197 deny icmp 10.20.0.0 0.0.255.255 40.50.60.0 0.0.0.255 echo-reply
access-list 197 deny icmp 40.50.60.0 0.0.0.255 10.20.0.0 0.0.255.255 echo
access-list 197 deny icmp 40.50.60.0 0.0.0.255 10.20.0.0 0.0.255.255 echo-reply
access-list 197 permit ip any any
We need to cover the pings and replies in both directions.
------
Q15. Given the statements:
interface token-ring 7
ip access-group 13 in
ip access-group 184 out
access-list 13 permit host 201.3.4.2
access-list 13 deny 203.45.0.0 0.0.255.255
access-list 13 deny 84.7.22.240 0.0.0.7
access-list 13 permit any
access-list 184 permit ip any host 101.202.3.4 log
access-list 184 permit tcp 203.45.6.0 0.0.0.255 any eq www
access-list 184 permit udp any any
What will the result be?
A15. This configuration places access list 13 inbound on Token Ring interface 7. Accordingly, all IP traffic from host 201.3.4.2 is allowed in on To7, IP traffic from host addresses 203.45.0.0 through 203.45.255.255 is denied access inbound through To7, IP traffic from host addresses 84.7.22.240 through 84.7.22.247 is denied access inbound through To7, and all other IP traffic is permitted inbound through To7. Since 201.3.4.2 is a subset of the last line of access list 13, the first line of access list 13 is superfluous, and the list could be written more concisely as:
access-list 13 deny 203.45.0.0 0.0.255.255
access-list 13 deny 84.7.22.240 0.0.0.7
access-list 13 permit any
This configuration also places access list 184 outbound on Token Ring interface 7. This allows IP traffic from any host to destination 101.202.3.4 (and logs any such traffic to the console), permits HTTP traffic from hosts on 203.45.6.0/24 from going to any web server, and permits any UDP traffic.
Q16. Design an access list that permits all IP traffic from the hosts on networks 222.111.3.0/24 through 222.111.7.0/24, and denies all other IP traffic.
A16. One efficient solution:
access-list 98 permit 222.111.3.0 0.0.0.255
access-list 98 permit 222.111.4.0 0.0.3.255
The first line covers network 222.111.3.0/24,
and the second line covers networks 222.111.4.0/24 through 222.111.7.0/24.
------
Q17. Given the statements:
interface token-ring 2/1
ip access-group 23 in
access-list 23 deny host 201.3.4.2
access-list 23 deny 84.7.22.248 0.0.0.7
access-list 23 deny 153.45.0.0 0.0.255.255
access-list 23 deny 203.45.6.0 0.0.0.255
What will the result be?
A17. Because there are no "permit" statements in the list, this configuration will deny all IP traffic inbound via Token Ring interface 2/1.
------
Q18. Design an access list that denies all FTP traffic from the hosts on subnets 101.202.8.0/24 through 101.202.13/24 that is destined for FTP servers, but permits all other IP traffic.
A18. One solution:
access-list 128 deny tcp 101.202.8.0 0.0.0.255 any eq ftp
access-list 128 deny tcp 101.202.9.0 0.0.0.255 any eq ftp
access-list 128 deny tcp 101.202.10.0 0.0.0.255 any eq ftp
access-list 128 deny tcp 101.202.11.0 0.0.0.255 any eq ftp
access-list 128 deny tcp 101.202.12.0 0.0.0.255 any eq ftp
access-list 128 deny tcp 101.202.13.0 0.0.0.255 any eq ftp
access-list 128 permit ip any any
And yet another using four lines:
access-list 138 deny tcp 101.202.8.0 0.0.3.255 any eq ftp
access-list 138 deny tcp 101.202.12.0 0.0.0.255 any eq ftp
access-list 138 deny tcp 101.202.13.0 0.0.0.255 any eq ftp
access-list 138 permit ip any any
And this one gets it down to three lines, the best we can do:
access-list 148 deny tcp 101.202.8.0 0.0.3.255 any eq ftp
access-list 148 deny tcp 101.202.12.0 0.0.1.255 any eq ftp
access-list 148 permit ip any any
There are other schemes, including:
access-list 158 permit tcp 101.202.14.0 0.0.0.255 any eq ftp
access-list 158 permit tcp 101.202.15.0 0.0.0.255 any eq ftp
access-list 158 deny tcp 101.202.8.0 0.0.7.255 any eq ftp
access-list 158 permit ip any any
Can you see why access lists 128, 138, 148 and 158 give equivalent results?
Q19. Given the statements:
interface ethernet 4
ip access-group 199
access-list 199 permit ip any any
access-list 199 deny ip 106.45.0.0 0.0.255.255 any
access-list 199 deny tcp any 44.7.12.224 0.0.0.15 eq ftp
access-list 199 deny udp 23.145.64.0 0.0.0.255 host 1.2.3.4 eq rip
What will the result be?
A19. Because the first line is a "permit ip any any", all traffic matches on the first line, and is allowed to pass. The other lines are never checked. If you spot something like this, it is generally a mistake. The "permit ip any any" line was probably intended to be at the end of the access list. The order of the lines can be crucial.
------
Q20. Design an access list that permits all IP traffic from the hosts on subnets 10.0.0.0/16 through 10.7.0.0/16, permits IP traffic from the hosts on subnets 10.9.0.0/16 through 10.15.0.0/16, and denies all other IP traffic. Place it outbound on E0 and inbound on Token Ring 2.
A20. One solution:
interface ethernet 0
ip access-group 39 out
interface token-ring 2
ip access-group 39 in
access-list 39 permit 10.0.0.0 0.0.255.255
access-list 39 permit 10.1.0.0 0.0.255.255
access-list 39 permit 10.2.0.0 0.0.255.255
access-list 39 permit 10.3.0.0 0.0.255.255
access-list 39 permit 10.4.0.0 0.0.255.255
access-list 39 permit 10.5.0.0 0.0.255.255
access-list 39 permit 10.6.0.0 0.0.255.255
access-list 39 permit 10.7.0.0 0.0.255.255
access-list 39 permit 10.9.0.0 0.0.255.255
access-list 39 permit 10.10.0.0 0.0.255.255
access-list 39 permit 10.11.0.0 0.0.255.255
access-list 39 permit 10.12.0.0 0.0.255.255
access-list 39 permit 10.13.0.0 0.0.255.255
access-list 39 permit 10.14.0.0 0.0.255.255
access-list 39 permit 10.15.0.0 0.0.255.255
That solution is kind of long, but it has the advantage of being straightforward. Another solution is:
interface ethernet 0
ip access-group 49 out
interface token-ring 2
ip access-group 49 in
access-list 49 deny 10.8.0.0 0.0.255.255
access-list 49 permit 10.0.0.0 0.15.255.255
This is concise and relatively easy to understand. Can you see why access lists 39 and 49 give equivalent results?
Q21. Design an access list that permits bi-directional ICMP traffic between subnets 1.0.96.0/20 and 2.0.1.64/27, permits bi-directional IP traffic between the hosts on subnets 131.5.0.0/16 through 131.8.0.0/16 and the hosts on network 239.5.6.0/24, and denies all other IP traffic except IGRP, which must be permitted everywhere.
A21. One solution:
access-list 150 permit icmp 1.0.96.0 0.0.15.255 2.0.1.64 0.0.0.31
access-list 150 permit icmp 2.0.1.64 0.0.0.31 1.0.96.0 0.0.15.255
access-list 150 permit ip 131.5.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 150 permit ip 131.6.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 150 permit ip 131.7.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 150 permit ip 131.8.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 150 permit ip 239.5.6.0 0.0.0.255 131.5.0.0 0.0.255.255
access-list 150 permit ip 239.5.6.0 0.0.0.255 131.6.0.0 0.0.255.255
access-list 150 permit ip 239.5.6.0 0.0.0.255 131.7.0.0 0.0.255.255
access-list 150 permit ip 239.5.6.0 0.0.0.255 131.8.0.0 0.0.255.255
access-list 150 permit igrp any any
A slightly more efficient, although less intuitive, solution:
access-list 160 permit icmp 1.0.96.0 0.0.15.255 2.0.1.64 0.0.0.31
access-list 160 permit icmp 2.0.1.64 0.0.0.31 1.0.96.0 0.0.15.255
access-list 160 permit ip 131.5.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 160 permit ip 131.6.0.0 0.1.255.255 239.5.6.0 0.0.0.255
access-list 160 permit ip 131.8.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 160 permit ip 239.5.6.0 0.0.0.255 131.5.0.0 0.0.255.255
access-list 160 permit ip 239.5.6.0 0.0.0.255 131.6.0.0 0.1.255.255
access-list 160 permit ip 239.5.6.0 0.0.0.255 131.8.0.0 0.0.255.255
access-list 160 permit igrp any any
Another possibility:
access-list 170 permit icmp 1.0.96.0 0.0.15.255 2.0.1.64 0.0.0.31
access-list 170 permit icmp 2.0.1.64 0.0.0.31 1.0.96.0 0.0.15.255
access-list 170 deny ip 131.4.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 170 permit ip 131.4.0.0 0.3.255.255 239.5.6.0 0.0.0.255
access-list 170 permit ip 131.8.0.0 0.0.255.255 239.5.6.0 0.0.0.255
access-list 170 deny ip 239.5.6.0 0.0.0.255 131.4.0.0 0.0.255.255
access-list 170 permit ip 239.5.6.0 0.0.0.255 131.4.0.0 0.3.255.255
access-list 170 permit ip 239.5.6.0 0.0.0.255 131.8.0.0 0.0.255.255
access-list 170 permit igrp any any
This seems to gain us nothing at the expense of complicating the logic. The best solution is probably the first one, which costs us a little in efficiency, but gains us much in the way of clarity. In general, it is better to be inefficient and correct than it is to be efficiently wrong.
------
Q22. The following statements are executed in the order given:
access-list 1 deny any
access-list 1 permit any
no access-list 1 deny any
access-list 2 deny 1.2.3.4
access-list 2 permit any
interface serial 3
ip access-group 2 in
ip access-group 1 in
What is the result?
A22. Remember the rule: one access list per protocol per direction per interface. Since the last IP access list to be put in force inbound on interface S3 is access list 1, that is the only IP access list in force inbound on interface S3. Also, since at this point access list 1 is empty (it was completely erased by the "no access-list 1 deny any" statement, which acted as a "no access-list 1"), it has no effect. The net result is that all IP traffic is allowed inbound via S3.
------
Q23. Design a standard IPX access list that allows traffic from network 3A6C to go to network 5BF2, and blocks all other IPX traffic. Place it in force on interface E3 in the inbound direction.
A23. One solution:
interface ethernet 3
ipx access-group 801 in
access-list 801 permit 3A6C 5BF2
------
Q24. Design an IPX access list that denies traffic in either direction between networks 543210 and ABCDEF, denies traffic between sources on network 1020304 and the host with MAC address 0000.0C12.54FB on network 4B9C2, and permits any other IPX traffic. Place it outbound on FDDI 3.
A24. One solution:
interface fddi 3
ipx access-group 821 out
access-list 821 deny 543210 abcdef
access-list 821 deny abcdef 543210
access-list 821 deny 1020304 4b9c2.0000.0C12.54fb
access-list 821 permit -1
Note that "-1" is equivalent to "FFFFFFFF", which means "all IPX networks". If you input "-1", the router will automatically translate it into "FFFFFFFF". Also, hex digits are not case-sensitive.
------
Q25. Interface S0 is connected to a slow WAN link. Keep the SAP traffic advertising file services on network 2BDEAD from crossing the link.
A25. One solution:
interface serial 0
ipx output-sap-filter 1001
access-list 1001 deny 2bdead 4
access-list 1001 permit -1
Q26. Given the statements:
interface ethernet 1
ip access-group 60 in
ip access-group 161 in
access-list 60 deny host 1.3.5.7 0.0.0.0
access-list 60 deny 10.0.0.0 0.0.0.0
access-list 60 deny 54.78.43.2 255.255.255.255
access-list 60 deny ip host 101.2.5.7 eq telnet
access-list 161 permit ip 205.6.23.6 34.67.22.3
access-list 161 permit ipx a0b1c2 -1
access-list 161 deny telnet
access-list 161 permit ip host 225.0.0.5 any
access-list 161 deny ip any any
How many errors can you find?
A26. Again, one access list (standard or extended) per protocol per direction per interface. This means that access lists 60 and 161 cannot be in inbound on Ethernet 1 at the same time. Other errors are as follows: