Cisco IOS Access Lists

( 1 )

Overview

Cisco routers are used widely both on the Internet and in corporate intranets. At the same time, the Cisco Internet Operating System (IOS) has grown to be very large and complex, and Cisco documentation fills several volumes.Cisco IOS Access Lists focuses on a critical aspect of the Cisco IOS—access lists. Access lists are central to the task of securing routers and networks, and administrators cannot implement access control policies or traffic routing policies without them. Access lists are used to specify both...

See more details below
Paperback
$40.84
BN.com price
(Save 9%)$44.99 List Price
Other sellers (Paperback)
  • All (20) from $3.04   
  • New (8) from $23.69   
  • Used (12) from $3.02   
Sending request ...

Overview

Cisco routers are used widely both on the Internet and in corporate intranets. At the same time, the Cisco Internet Operating System (IOS) has grown to be very large and complex, and Cisco documentation fills several volumes.Cisco IOS Access Lists focuses on a critical aspect of the Cisco IOS—access lists. Access lists are central to the task of securing routers and networks, and administrators cannot implement access control policies or traffic routing policies without them. Access lists are used to specify both the targets of network policies and the policies themselves. They specify packet filtering for firewalls all over the Internet.Cisco IOS Access Lists covers three critical areas:

  • Intranets. The book serves as an introduction and a reference for network engineers implementing routing policies within intranet networking.
  • Firewalls. The book is a supplement and companion reference to books such as Brent Chapman's Building Internet Firewalls. Packet filtering is an integral part of many firewall architectures, andCisco IOS Access Lists describes common packet filtering tasks and provides a "bag of tricks" for firewall implementers.
  • The Internet. This book is also a guide to the complicated world of route maps. Route maps are an arcane BGP construct necessary to make high level routing work on the Internet.
Cisco IOS Access Lists differs from other Cisco router titles in that it focuses on practical instructions for setting router access policies. The details of interfaces and routing protocol settings are not discussed.

This guide focuses on access lists that are critical to network and Internet security. Access lists are a main part of the Cisco IOS that are used to control access, route traffic and specify packet filtering for firewalls.

Read More Show Less

Product Details

  • ISBN-13: 9781565923850
  • Publisher: O'Reilly Media, Incorporated
  • Publication date: 6/27/2001
  • Edition number: 1
  • Pages: 274
  • Product dimensions: 7.04 (w) x 9.20 (h) x 0.70 (d)

Meet the Author

Jeff Sedayao is a network engineer with Intel Online Services, the web and application hosting division of Intel Corporation. From 1987 through 1999, he architected and maintained Intel's Internet connectivity, starting with a simple 2400-bps email link through CSNET and ending up with multiple sites connecting to the Internet with multiple ISPs at multi-megabit speeds. He has always been fascinated with policy and policy implementation, ranging from using Cisco IOS access lists for routing and firewall policies to sendmail configurations and address space design. As part of Intel Online Services, his main interests include network usage and performance issues, DNS and email implementation, and addressing and routing policy.

Read More Show Less

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...

Read More Show Less

Table of Contents

Preface;
Organization;
Audience;
Conventions used in this book;
We’d like to hear from you;
Acknowledgments;
Chapter 1: Network Policies and Cisco Access Lists;
1.1 Policy sets;
1.2 The policy toolkit;
Chapter 2: Access List Basics;
2.1 Standard access lists;
2.2 Extended access lists;
2.3 More on matching;
2.4 Building and maintaining access lists;
2.5 Named access lists;
Chapter 3: Implementing Security Policies;
3.1 Router resource control;
3.2 Packet filtering and firewalls;
3.3 Alternatives to access lists;
Chapter 4: Implementing Routing Policies;
4.1 Fundamentals of route filtering;
4.2 Implementing routing modularity;
4.3 Implementing route preferences;
4.4 Alternatives to access lists;
Chapter 5: Debugging Access Lists;
5.1 Router resource access control lists;
5.2 Packet-filtering access control lists;
5.3 Route-filtering access control lists;
Chapter 6: Route Maps;
6.1 Other access list types;
6.2 Generic route map format;
6.3 Interior routing protocols and policy routing;
6.4 BGP;
6.5 Debugging route maps and BGP;
Chapter 7: Case Studies;
7.1 A WAN case study;
7.2 A firewall case study;
7.3 An Internet routing case study;
Extended Access List Protocols and Qualifiers;
Binary and Mask Tables;
Common Application Ports;
Colophon;

Read More Show Less

Customer Reviews

Average Rating 3
( 1 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(1)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted April 22, 2003

    Good book on Access Lists options

    But unfortunately has far too many errors to give it a perfect rating...

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)