Read an Excerpt
Chapter 5: Debugging Access Lists
In this chapter:
Router resource access control lists
Packet-filtering access control lists
Route-filtering access control lists
Once you've formatted access lists and used them to implement policies, how do you know if your access lists are correct? How can you find problems with them? We'll look at these questions in this chapter, first verifying that your access lists are working correctly in the areas of router resource control, packet filtering, and route filtering. More generally, I will talk about how access lists can go wrong and what are the typical failure modes of access lists. Finally, we'll look at some tips and tricks for debugging access lists in detail.
Router resource access control lists
In this section, I discuss how to debug router resource access lists. The first part describes how to check them for correctness since it doesn't make sense to debug a list that is configured properly. The second part discusses what generally happens when access lists go wrong, and the last part goes over specifically how to debug router resource access lists.
Checking for correctness
In Chapter 3 we configured the router to control resources such as Telnet and time services. The approach to verifying if these access lists function correctly is very basic: test if access works correctly for those who are permitted, and test if access does not work for those who are not permitted. Let's look at one of our early examples of router resource policies and look at how we can test it. In the first example in Chapter 2, we had a policy like the following:
Only the hosts at IP addresses 192.168.30.1 and 192.168.33.5 may telnet into the router
The access list that defines the policy set for this policy is:
access-list 1 permit 192.168.30.1
access-list 1 permit 192.168.33.5
We use the policy set as follows:
line vty 0 4
access-class 1 in
In order to verify that the access list actually implements the policy, we need to check that what we defined in the policy set matches what is in the policy definition. There are two ways to do this. The first is by inspection: we manually check whether the access list matches our policy. While this method can work for small access lists, it becomes much more difficult as access lists grow in size and really isn't a particularly reliable way to verify that an access list is correct. The second way is to test whether access lists actually function as desired. In this instance, we would attempt to telnet to the router from the hosts at 192.168.30.1 and 192.168.33.5. If we succeed in getting a prompt from the router, we know that the access list is allowing the correct host to connect to the router.
We should also make sure that forbidden hosts do not have access. If for some reason we forgot to apply an access list (not putting in the access-class statement, for example), the default policy set permits everything, giving us the same results as the test we did earlier. When we telnet to the router from the host at 192.168.3.59, the router should refuse the connection and not provide a login prompt. In general, the following algorithm is useful for verifying a policy against the access lists you implemented:
Make sure what hosts that are permitted have access to the resource
Make sure that the hosts that are not permitted do not have access to the resource
You will not always be able to completely test all cases (as access lists grow, you will not be able to test every entry), but being reasonably sure that the above two conditions are true is how to verify correctness.
Manual tests of masks
Testing for both what is permitted and what is denied is particularly useful when you use masks in a policy. Let's look at the following policy and its implementation:
Only the hosts at IP addresses 192.168.30.4 through 192.168.30.7 and IP address 192.168.33.5 may telnet into the router
We define the appropriate policy set and apply it as follows:
access-list 1 permit 192.168.30.4 0.0.0.3
access-list 1 permit 192.168.33.5
! line definition
line vty 0 4
access-class 1 in
Notice that the first access list entry has a mask, as we covered in Chapter 2. When you use a mask like this, in addition to testing that the hosts in the mask range have access to the resource being controlled, make sure that the hosts just outside of the mask range (hosts at IP addresses 192.168.30.3 and 192.168.30.8) do not. What happens if you specify a mask that is too large, as in the following list?
access-list 1 permit 192.168.30.4 0.0.0.7
access-list 1 permit 192.168.33.5
Testing only the permitted hosts will miss the fact that you also included hosts 192.168.30.1, 192.168.30.2, and 192.168.30.3 in the policy set. Testing the hosts just outside the range permitted by the mask catches this problem.
When access lists don't work
I have talked about making sure that access lists are functioning properly by implementing the policies that you intend. But what happens if your access lists do not function as expected? This section describes how an access list can do other than what you intend and how you can use the various tools available on a Cisco router to find where you made a mistake. I will first go over ways that access lists can go wrong. After that, I will cover how to debug router resource access lists, extended access lists, and router filtering access lists.
There are typically a number of ways access lists can go wrong. First, they can be applied incorrectly, meaning that you have either applied the wrong access list to a router resource, interface, or distribute list; applied the correct access list but with the wrong directionality (inbound instead of outbound or the reverse); or forgotten to apply one altogether. This should be the first thing you check.
If you are applying an access list correctly, and your policy is still not being implemented properly, then one of two things is happening. Either something you want to include into a policy set was excluded, or something you want excluded from a policy set was included. In the first case, you need to check whether some statement in the access list is excluding the IP addresses or packet types that you want in the policy set. (If you are certain that nothing is excluding the items desired, then the only other explanation is that you have forgotten to include it.) In the second case, you have included something in your policy set that you do not want, so to fix your access list, you need to find the permissive entry. These are the fundamental problems that can occur, and when I talk about debugging specific kinds of access lists in the following sections, I go over how to find bad or missing access list entries.
There is one final category of access list problems that you may encounter. If you are implementing security policies and routing policies, you have to be careful about their interaction. For instance, if an application does not work through an extended access list, it doesn't always mean there's a problem with the access lists; it could be a communication problem between the two systems you are routing. If you encounter what seems to be a routing problem with routing, there could be packet filtering that is disrupting route advertisements. I will also talk about this category of problems in later sections on debugging.
Debugging router resource access lists
If you find that your router resource access lists are not working, typically one of two things is happening. Either something that needs access to a router resource does not have access, or something that should not have access to the resource does. I'll go over each case and what to look for when trying to find what the problem is.
If a host or router that should have access cannot access a resource on a router you control, the first thing to check is whether there is network connectivity between the host in question and the router. The easiest way to do this is to use the ping command. The format of ping is the command ping followed by the name or IP address of the host you want to check on. Let's say that we want to check on connectivity to a host at 10.1.1.2, and the route to 10.1.1.2 goes through an Ethernet interface with IP address 192.168.3.2. We would use the following command, which can be executed from user EXEC mode or privileged EXEC mode:
ping 10.1.1.2
If there is a functioning route to IP address 10.1.1.2 and a route from the host 10.1.1.2 back to the router interface with IP address 192.168.3.2, we would see output like this:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
If either the transmit and return path between 10.1.1.2 and 192.168.3.2 is unavailable, the ping will not be successful:
Router1# ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
If the ping attempt is not successful, there is either a route missing at the target host for the router, a route missing at the router for the host, or some other packet filter along the path getting in the way. Let's put off a discussion of packet filtering extended access lists until the next section and assume that the problem is with a missing route. Check the routing on the host or the router. If the route is missing, and there is no default route, then you need to make sure that the route is there and again check if the resource access works. If the route is there, it implies that the problem may be with a packet filter along the way. I will talk about finding problematic packet filters in later sections.
If the ping attempt is successful, the problem is with your access list. You either excluded some IP addresses from your policy set or forgot to include an appropriate entry.
Looking at an example will illustrate this better. Let's say we have the following policy for a router:
All of the hosts with IP addresses 192.168.32.32 through 192.168.32.63 except 192.168.32.40 through 192.168.32.43 can have SNMP read access
and implement it as follows:
access-list 1 deny 192.168.40.0 0.0.0.7
access-list 1 permit 192.168.32.0 0.0.0.31
snmp community string public ro 1
We notice that host 192.168.32.44 does not have SNMP access. We can ping 192.168.32.44 from the router, so routing is not an issue. On examination, we see that the initial deny mask is too large. Access list 1 should be defined as:
access-list 1 deny 192.168.40.0 0.0.0.3
access-list 1 permit 192.168.32.0 0.0.0.31
The other way that router resource access lists can go wrong is if something that should not have permission does have permission. This means that somehow you have inadvertently allowed something in a policy set you shouldn't have, and again a previous example illustrates this well. Recall that we have a policy for a router as follows:
Only the hosts at IP addresses 192.168.30.4 through 192.168.30.7 and IP address 192.168.33.5 may telnet into the router
We define the appropriate policy set and apply it as follows:
access-list 1 permit 192.168.30.4 0.0.0.7
access-list 1 permit 192.168.33.5
! line definition
line vty 0 4
access-class 1 in
After testing, we notice that host 192.168.30.8 has Telnet access to the router. We made the mask on the first entry of access list 1 too large. Access list 1 should be:
access-list 1 permit 192.168.30.4 0.0.0.3
access-list 1 permit 192.168.33.5
Packet-filtering access control lists
Here I talk about debugging the packet filters that you implement with access control lists. Like the previous section, I first talk about how to verify that your access lists are correct, followed by a section about how to find the problems in the access lists that you find to be wrong.
Checking for correctness
One of the first things you want to do is make sure that your access lists are applied to the interfaces you intended. You or another network administrator may have removed access lists or applied other access lists in order to debug problems or temporarily enable certain functionality for a variety of reasons, such as host installations or debugging. One way to do that is to show the running configuration with the show running-confg command. If you have a large configuration, this command may take a while, and it is easy to miss the interface you want to look at when many of them are scrolling by.
Using show ip interface to display applied access lists
A better way is to use the show ip interface command. This command yields output that looks like the following...
