IOS Access Control Lists Made Easy

IOS Access Control Lists Made Easy

Abstract

This paper is for readers with any level of ACL experience, providing novices with appreciation and understanding of what goes into the definition of an ACL and giving experts additional insight.

Sample

Introduction

It is assumed that different readers will have different levels of experience with Access Control Lists (ACLs). Some will have no experience. Others will have dabbled with ACLs in lab environments.

Still others will have extensive real-world experience with the implementation of ACLs. The goal of this white paper is to be interesting to readers with any level of ACL experience. The ACL novice should gain an appreciation and understanding of what goes into the definition of an ACL. And hopefully the ACL expert can also gain an insight or two from the material.

What Is an ACL?

Try to define an ACL using just two words.

Did you come up with "packet filter"? This is the most common response, and for good reason. It is intuitive because it is indeed a two-word definition and it describes a very common use for ACLs. The problem with this definition is that ACLs can be used for many objectives other than filtering packets. For example, ACLs can be used to define which queue a packet will enter when using custom queuing or priority queuing. In either of these cases, packets aren't filtered. They are simply sent to the front, middle, or end of the line depending on certain criteria. Another example is to use ACLs to define interesting traffic for a dial-on-demand link. When applied this way, the ACL defines traffic that is important enough to have the router pick up the phone and incur toll charges. Once the phone call is connected, all traffic is allowed across the link, not just interesting traffic. If you want only interesting traffic to cross the link, you must also apply the ACL to the interface. A third use for an ACL is to reference the ACL within a crypto map where it defines interesting traffic for an IPSec tunnel. When the crypto map is assigned to the interface, non-interesting traffic may still be allowed through the interface, it just won't be encrypted before it is forwarded. There are dozens of different ways of applying ACLs on an IOS Router.

The two-word definition of an ACL that I will suggest is "packet classifier". To expand that definition, an ACL contains a list of entries defining matching criteria. One packet at a time, the packet characteristics are compared to the list of ACL entries in sequence. The classification associated with the first ACL entry that matches the packet's characteristics will determine the classification of the packet. ACLs use the terms "permit" and "deny" to describe the two possible classes. Unfortunately, this terminology helps to promote the "packet filter" perception. Don't think of permit and deny as to permit or deny the packet passage through the router. Instead think of it as to permit or deny the packet entry into a certain classification. For example, to permit or deny this packet entry into the class of packets that belong in the high-priority queue.

What Types of ACLs Do IOS Routers Support?

IOS routers support many types of ACLs. There are ACLs that examine layer 2 criteria, such as MAC address and LSAP values. There are ACLs that examine various layer 3 protocols, such as IPX, AppleTalk, DECnet, and vines. There are ACLs that examine IPv6 criteria. But this white paper will focus on what is most commonly used today: ACLs that examine IP (v4) criteria.

IP ACLs are generally broken down into standard IP ACLs and extended IP ACLs. Whether or not an ACL is a standard or extended IP ACL, it can be defined either by a number or a name. If you choose to define by a number, the range that the number is in is important. Originally, standard IP ACLs used numbers between 1 and 99, while extended IP ACLs used numbers between 100 and 199. These ranges were extended to also include 1300 to 1999 for standard IP ACLs and 2000 to 2699 for extended IP ACLs.

Standard IP ACLs use exactly one criterion on which to match: the source IP address of the packet. Often this is exactly what is appropriate to use. For example, you can use the access class statement to reference an ACL to limit access to VTY lines. In this case, you are interested in only the source IP address. You know the destination IP address is one of the router's own IP addresses, the protocol is TCP and destination port is 23 for telnet. (Actually, in this example it might also be TCP port 22 if you have configured SSH support). Another example for the use of standard IP ACLs is when they are referenced on the definition of an SNMP community string. Again, only the source IP address is of interest, as we know the destination IP address is one of the router's own IP addresses and the protocol is UDP with destination port 161 (SNMP).

Related Courses

SNAF - Securing Networks with ASA Fundamentals
SNRS - Securing Networks with Cisco Routers & Switches v3.0
BECSN - Building Enhanced Cisco Security Networks v2.0

Download Now

Date: 4/28/2009

Author: Kurt Patzer

Format: PDF

Pages: 14

 

  • White Paper Rating