Home |
Access Control Lists Overview |
10 Things to know about ACLs |
Adding Remarks
Anatomy of ACLs |
Demystifying ACLs |
ACL Wildcards
ACL PowerPoint 1 |
ACL PowerPoint 2 |
Cisco ACL paper
Access Control Lists (ACL) - A Tutorial with Questions and their Answers
Access lists are essentially lists of conditions that control access. They’re powerful tools that control access both to and from network segments. They can filter unwanted packets and be used to implement security policies. With the right combination of access lists, network managers will be armed with the power to enforce nearly any access policy they can invent.The IP and IPX access lists work similarly - they’re both packet filters that packets are compared with, categorized by, and acted upon. Once the lists are built, they can be applied to either inbound or outbound traffic on any interface. Applying an access list will then cause the router to analyze every packet crossing that interface in the specified direction and take action accordingly.
What They're All About
The access list is a group of statements. Each statement defines a pattern that would be found in an IP packet. As each packet comes through an interface with an associated access list, the list is scanned from top to bottom--in the exact order that it was entered--for a pattern that matches the incoming packet. A permit or deny rule associated with the pattern determines that packet's fate. You also can use a mask, which is like a wild card, to determine how much of an IP source or destination address to apply to the pattern match. The pattern statement also can include a TCP, UDP, Telnet, ftp, or other port numbers.
Access list statements are entered one line at a time, and the list is scanned for a match in that same order. If you must make a change, you have to re-enter the entire list. Also, keep in mind that once you associate the list with an interface, any packet not processed by the list is dropped by default.
Once the access list is entered, you must associate it with the interface on the router where you want to apply the filtering. You can apply the list to incoming packets, (an "in" access list) or outgoing packets (an "out" access list). Think of yourself inside the router and you are filtering packets coming in to you or going out from you through the affected interface or port. In most cases, either list will work. For out access lists, you need to set up the filter only on the one outgoing interface rather than on the individual incoming interfaces. This improves performance because only the network you are protecting will force a lookup on the access list.
-
There are a few important rules a packet must follow when it’s being compared with an access list:
It’s always compared with each line of the access list in sequential order, i.e., it’ll always start with line 1, then go to line 2, then line 3, and so on.
-
It’s compared with lines of the access list only until a match is made. Once the packet matches
a line of the access list, it’s acted upon, and no further comparisons take place.
-
There is an implicit “deny” at the end of each access list - this means that
if a packet doesn’t match up to any lines in the access list, it’ll be discarded.
There are two types of access lists used with IP and IPX:
Standard access lists
These use only the source IP address in an IP packet to filter the network. This basically permits or denies an entire suite of protocols. IPX standards can filter on both source and destination IPX address.
Extended access lists
These check for both source and destination IP address, protocol field in the Network layer header, and port number at the Transport layer header. IPX extended access lists use source and destination IPX addresses, Network layer protocol fields, and socket numbers in the Transport layer header.
Once you create an access list, you apply it to an interface with either an inbound or outbound list.
Inbound access lists
Packets are processed through the access list before being routed to the outbound interface.
Outbound access lists
Packets are routed to the outbound interface and then processed through the access list. There are also some access list guidelines that should be followed when creating and implementing access lists on a router:
- You can only assign one access list per interface, per protocol, or per direction. This means that if you are creating IP access lists, you can only have one inbound access list and one outbound access list per interface.
- Organize your access lists so that the more specific tests are at the top of the access list.
- Anytime a new list is added to the access list, it will be placed at the bottom of the list.
- You cannot remove one line from an access list. If you try to do this, you will remove the entire list. It is best to copy the access list to a text editor before trying to edit the list. The only exception is when using named access lists.
- Unless your access list ends with a permit any command, all packets will be discarded if they do not meet any of the lists’ tests. Every list should have at least one permit statement, or you might as well shut the interface down.
- Create access lists and then apply them to an interface. Any access list applied to an interface without an access list present will not filter traffic.
- Access lists are designed to filter traffic going through the router. They will not filter traffic originated from the router.
- Place IP standard access lists as close to the destination as possible.
- Place IP extended access lists as close to the source as possible.
Standard IP access lists filter the network by using the source IP address in an IP packet.
You create a standard IP access list by using the access list numbers 1–99.
Here is an example of the access list numbers that you can use to filter your network.
The different protocols that you can use with access lists depends on your IOS version.
| RouterA(config)#access-list ? | |
| <1-99> | IP standard access list |
| <100-199> | IP extended access list |
| <200-299> | Protocol type-code access list |
| <300-399> | DECnet access list |
| <400-499> | XNS standard access list |
| <500-599> | XNS extended access list |
| <600-699> | Appletalk access list |
| <700-799> | 48-bit MAC address access list |
| <800-899> | IPX standard access list |
| <900-999> | IPX extended access list |
| <1000-1099> | IPX SAP access list |
| <1100-1199> | Extended 48-bit MAC address access list |
| <1200-1299> | IPX summary address access list |
By using the access list numbers between 1–99, you tell the router that you want to create a standard IP access list.
| RouterA(config)#access-list 10 ? | |
| deny | Specify packets to reject permit Specify packets to forward |
After you choose the access list number, you need to decide if you are creating a permit or deny list. For this example, you will create a deny statement:
| RouterA(config)#access-list 10 deny ? | |
| Hostname or A.B.C.D | Address to match |
| any | Any source host |
| host | A single host address |
The next step requires a more detailed explanation. There are three options available. You can use the any command to permit or deny any host or network, you can use an IP address to specify or match a specific network or IP host, or you can use the host command to specify a specific host only.
Here is an example of using the host command:
| RouterA(config)#access-list 10 deny host 172.16.30.2 |
This tells the list to deny any packets from host 172.16.30.2. The default command is host. In other words, if you type access-list 10 deny 172.16.30.2, the router assumes you mean host 172.16.30.2.
However, there is another way to specify a specific host: you can use wildcards. In fact, to specify a network or a subnet, you have no option but to use wildcards in the access list.
Extended IP Access Lists
In the standard IP access list example, notice how you had to block the whole subnet from getting to the finance department. What if you wanted them to gain access to only a certain server on the Finance LAN, but not to other network services, for obvious security reasons? With a standard IP access list, you can’t allow users to get to one network service and not another. However, extended IP access lists allow you to do this. Extended IP access lists allow you to choose your IP source and Destination address as well as the protocol and port number, which identify the upper-layer protocol or application. By using extended IP access lists, you can effectively allow users access to a physical LAN and stop them from using certain services.
Here is an example of an extended IP access list. The first command shows the access list numbers available. You’ll use the extended access list range from 100 to 199.
At this point, you need to decide what type of list entry you are making. For this example, you’ll choose a deny list entry.
| RouterA(config)#access-list 110 ? | |
| deny | Specify packet |
| dynamic | Specify a DYNAMIC list of PERMITs or DENYs |
| permit | Specify packets to forward |
Once you choose the access list type, you must choose a Network layer protocol field entry. It is important to understand that if you want to filter the network by Application layer, you must choose an entry here that allows you to go up through the OSI model. For example, to filter by Telnet or FTP, you must choose TCP here. If you were to choose IP, you would never leave the Network layer, and you would not be allowed to filter by upper-layer applications.
| RouterA(config)#access-list 110 deny ? | |
| <0-255> | An IP protocol number |
| eigrp | Cisco's EIGRP routing protocol |
| gre | Cisco's GRE tunneling |
| icmp | Internet Control Message Protocol |
| igmp | Internet Gateway Message Protocol |
| igrp | Cisco's IGRP routing protocol |
| ip | Any Internet Protocol |
| ipinip | IP in IP tunneling |
| nos | KA9Q NOS compatible IP over IP tunneling |
| ospf | OSPF routing protocol |
| tcp | Transmission Control Protocol |
| udp | User Datagram Protocol |
Once you choose to go up to the Application layer through TCP, you will be prompted for the source IP address of the host or network. You can choose the any command to allow any source address.
| RouterA(config)#access-list 110 deny tcp ? | |
| A.B.C.D | Source address |
| any | Any source host |
| host | A single source host |
After the source address is selected, the destination address is chosen.
| RouterA(config)#access-list 110 deny tcp any ? | |
| A.B.C.D | Destination address |
| any | Any destination host |
| eq | Match only packets on a given port number |
| gt | Match only packets with a greater port number |
| host | A single destination host |
| lt | Match only packets with a lower port number |
| neq | Match only packets not on a given port number |
| range | Match only packets in the range of port numbers |
In the example below, any source IP address that has a destination IP address of 172.16.30.2 has been denied.
| RouterA(config)#access-list 110 deny tcp any host 172.16.30.2 ? | |
| script | Match only packets on a given port number |
| eq | Match only packets on a given port number |
| established | Match established connections |
| fragments | Check fragments |
| gt | Match only packets with a greater port number |
| log | Log matches against this entry |
| log-input | Log matches against this entry, including input interface |
| script | script |
| neq | Match only packets not on a given port number |
| precedence | Match packets with given precedence value |
| range | Match only packets in the range of port numbers |
| tos | Match packets with given TOS value |
Now, you can press Enter here and leave the access list as is. However, you can be even more specific: once you have the host addresses in place, you can specify the type of service you are denying. The following help screen gives you the options. You can choose a port number or use the application or even the program name.
| RouterA(config)#access-list 110 deny tcp any host 172.16.30.2 eq ? | |
| <0-65535> | Port number |
| bgp | Border Gateway Protocol (179) |
| chargen | Character generator (19) |
| cmd | Remote commands (rcmd,514) |
| daytime | Daytime (13) |
| discard | Discard (9) |
| domain | Domain Name Service (53) |
| echo | Echo (7) |
| exec | Exec (rsh,512) |
| finger | Finger (79) |
| ftp File | Transfer Protocol (21) |
| gopher | Gopher (70) |
| hostname | NIC hostname server (101) |
| ident | Ident Protocol (113) |
| irc | Internet Relay Chat (194) |
| klogin | Kerberos login (543) |
| kshell | Kerberos shell (544) |
| login | Login (rlogin,513) |
| lpd | Printer service (515) |
| nntp | Network News Transport Protocol (119) |
| pop2 | Post Office Protocol v2 (109) |
| pop3 | Post Office Protocol v3 (110) |
| smtp | Simple Mail Transport Protocol (25) |
| sunrpc | Sun Remote Procedure Call (111) |
| syslog | Syslog (514) |
| tacacs | TAC Access Control System (49) |
| talk | Talk (517) |
| telnet | Telnet (23) |
| time | Time (37) |
| uucp | Unix-to-Unix Copy Program (540) |
| whois | Nicname (43) |
| www | World Wide Web HTTP,80) |
Monitoring IP Access Lists
It is important to be able to verify the configuration on a router. The following commands can be used to verify the configuration:
- show access-list Displays all access lists and their parameters configured on the router. This command does not show you which interface the list is set on.
- show access-list 110 Shows only the parameters for the access list 110. This command does not show you the interface the list is set on.
- show ip access-list Shows only the IP access lists configured on the router.
- show ip interface Shows which interfaces have access lists set.
- show running-config Shows the access lists and which interfaces have access lists set.
This is one we always seem to get in the classroom:
Given the IP address: 200.8.7.0 (Network Address) with a wildcard mask of 0.0.0.254.
The last octet is 1111 1110, so we are going to ignore everything except the last bit.
If we say:
permit tcp 200.8.7.0 0.0.0.254, then we are saying that we have to match that last bit.
For odd numbers, the last bit will always be turned on.
This would permit; explicitly deny even and allows odd
If we wanted to use the same IP address to do the opposite:
permit all odd and deny all even, we could use the deny statement:
deny tcp 200.8.7.0 0.0.0.254
This would explicitly deny odd and allow even.
Below are some exercises to assist in learning about ACLs.
Remember:
A "0" bit in a wildcard mask means match the corresponding bit in the address.
A "1" bit in a wildcard mask means ignore the corresponding bit in the address.
The IP address of the source or destination is a bit reference for the wildcard mask.
Access Control Lists - Questions with Answers
Click HERE to download a Word document of the Questions with Answers
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:
access-list 60 deny host 1.3.5.7 0.0.0.0
Don't use both the keyword "host" and the "0.0.0.0" mask.
access-list 60 deny 10.0.0.0 0.0.0.0
It's not likely that "10.0.0.0" is a host address.
access-list 60 deny 54.78.43.2 255.255.255.255
The mask was probably intended to be "0.0.0.0", i.e. "host".
access-list 60 deny ip host 101.2.5.7 eq telnet
We can't deny specific protocols with a standard access list.
Also, since there is no "permit" statement in access list 60, it denies all IP traffic.
access-list 161 permit ip 205.6.23.6 34.67.22.3
Missing addressing information, the "host" keyword should probably appear before each address.
access-list 161 permit ipx a0b1c2 -1
We can't specify any IPX information in an IP access list.
access-list 161 deny telnet
Missing addressing and protocol (TCP) information.
access-list 161 permit ip host 225.0.0.5 any
The address "225.0.0.5" is a multicast address. A multicast or broadcast address can never be a legal
source address.
While this statement is redundant (because it is implicit at the end of every IP access list), some people do
include it for the sake of clarity. Therefore, it is not an "error
---------------------
Q27. Keep all SAP advertisements received via interface To2 from the NetWare servers named "SUZY" and "CHIPSTER" from being entered into the SAP table.
A27. One solution:
interface token-ring 2
ipx input-sap-filter 1095
access-list 1095 deny -1 0 SUZY
access-list 1095 deny -1 0 CHIPSTER
access-list 1095 permit -1
A SAP type of "0" means all services. Don't forget to take advantage of the "?" for help when configuring routers!
---------------------
Q28. Stop the SAP advertisements for service type 47 on any network from leaving via interface S2, permit all other SAP traffic to leave via S2, and allow only UDP traffic from hosts on IP subnet 201.2.6.0/24 to enter via S5.
A28. One solution:
interface serial 5
ip access-group 134 in
ipx output-sap-filter 1099
access-list 134 permit udp 201.2.6.0 0.0.0.255 any
access-list 1099 deny -1 47
access-list 1099 permit -1
Filtering multiple protocols requires multiple access lists, and also appropriate statements to place them in force in the required direction(s).
---------------------
Q29. Given the statements:
interface ethernet 4
appletalk access-group 606
access-list 606 deny cable-range 200-205
access-list 606 deny within 303-305
access-list 606 permit other-access
What will the result be?
A29. This configuration denies outbound traffic from cable range 200-205 and from networks 303-305 from leaving via interface Ethernet 4, but permits traffic from other networks to leave via Ethernet 4.