Access List Overview

ACLs are a multipurpose configuration tool on your router. Typically, ACLs are seen as a filtering tool, filtering traffic as it comes into or leaves your router. This enables you to implement detailed security policies. ACLs are known mostly for their security features, but ACLs support all of the following types of actions:

• Filtering traffic entering an interface

• Filtering traffic exiting an interface

• Controlling access to the router's VTY lines (this is discussed briefly in Chapter 3, "Accessing a Router")

• Controlling what routing updates a router advertises to or receives from neighboring routers

• Triggering dial-on-demand routing (DDR) phone calls with analog or ISDN

• Classifying traffic for dealing with congestion, such as congestion avoidance, congestion management, and queuing functions

• Restricting the output from debug commands based on addressing or protocol information

As you can see from this list, ACLs can perform many different types of functions. This book, however, focuses on how you can use ACLs as a security filtering solution. As you will see later in this chapter and throughout the book, Cisco supports many different kinds of ACLs with different kinds of capabilities. Your task is to choose the best ACL solution, based on your policies, to implement a filtering solution.

ACLs and Filtering

ACLs are a grouping of commands that enable you to control traffic as it comes into or exits an interface. When ACLs are filtering traffic, they commonly are also referred to as filters. Decisions that you can apply to traffic include permitting or dropping traffic based on conditions (rules) that you define on your router. Conditions can look for matches on the contents of a packet, including the following:

• Source or destination address

• Layer 2 protocol information, such as the type Ethernet frame

• Layer 3 protocols, such as IP, IPX, and AppleTalk

• Layer 3 protocol information, such as IP, ICMP, OSPF, TCP, UDP, and others within the TCP/IP protocol suite

• Layer 4 protocol information, such as TCP and UDP port numbers

Typically, ACLs filter Layers 3 and 4 information, but as you can see from the previous list, you also can use them to filter Layer 2 information. When I discuss reflexive ACLs in Chapter 8, "Reflexive Access Lists," and Context-based Access Control (CBAC) in Chapter 9, "Context-Based Access Control," you will see that ACLs can also keep track of Layer 5 information, or session information, and higher.

ACLs can provide a base level of security for traffic flowing through your network. It is important to point out that, by default, your router does not filter any traffic; you must configure and apply ACLs for your router to filter traffic as it flows through the router. ACLs commonly are used to prevent different devices from accessing a specific service, a specific device, or a part of a network.

Simple ACL Example

The network in Figure 6-1 serves as an example to show the usefulness of filtering with ACLs. In this example, there are two routers: an internal router and a perimeter/firewall router.

Figure 6-1. Filtering Example

[View full size image]

The perimeter/firewall router is using these policies:

• For traffic originating from the Internet, only traffic destined for the web server (its IP address and TCP port 80) is allowed. All other Internet traffic coming into this router is dropped.

• For internal traffic being forwarded to the Internet, only the returning traffic is allowed. (This can be accomplished with stateful firewall filtering, which is discussed in Chapter 2, "Introduction to Firewalls"; Chapter 8, "Reflexive Access Lists"; and Chapter 9, "Context-Based Access Control.")

The internal router is using these filtering policies:

• Only traffic from the accounting users is allowed to reach the accounting server.

• All other traffic between other segments is allowed.

With the filtering policies defined for the two routers in Figure 6-1, ACLs are used to implement and enforce them.

Types of ACLs

ACLs can be used in any situation to control traffic between devices, services, networks, or a combination of these. As shown in Figure 6-1, you can use ACLs to implement a firewall solution on a router, or you can use them to restrict internal usage of resources, such as an accounting server. Actually, it is very common to see a perimeter router with ACLs on it restricting the type of traffic allowed into the network. In Figure 6-1, the perimeter router is allowing only web traffic destined for the internal web server, as well as any returning traffic that internal users initiated.

You can use many types of ACLs to implement filtering solutions. Each is meant to accomplish a specific function, and each has its own advantages and disadvantages. Some types of ACLs are meant for firewall solutions; others are not. The following types of IP ACLs are discussed in this book:

• Standard IP ACLs? This type of ACL can filter only Layer 3 information. These ACLs are used to filter packets based on the source address in the packet header. Chapter 7, "Basic Access Lists," covers standard IP ACLs. Standard ACLs commonly are used to restrict VTY access to a Cisco router.

• Extended IP ACLs? This type of ACL can filter Layers 3 and 4 information. These ACLs are used to filter packets based on the source and destination IP address, the IP protocol (such as ICMP, IP, OSPF, TCP, UDP, and others), and protocol information (such as ICMP message types or TCP or UDP port numbers). Chapter 7 covers extended IP ACLs. Extended ACLs commonly are used to filter traffic, especially traffic as it enters your network.

• Turbo ACLs? This is an ACL feature that enables you to compile standard and extended ACLs, making them more efficient for the router to process and resulting in quicker lookup times. Chapter 7, "Basic Access Lists," covers turbo ACLs.

• Timed IP ACLs? This is an extended IP ACL that can filter on Layers 3 and 4 information. Unlike normal extended IP ACLs, timed ACLs can be activated based on the time of day, day of the week, or day of the month. They can be set up to filter on a recurring time period or just a single time period. Chapter 7 covers timed IP ACLs.

• Reflexive IP ACLs? This type of ACL can filter on Layers 3, 4, and 5 information. Some people think that reflexive ACLs implement a stateful firewall function; they do not, as you will see in Chapter 8, "Reflexive Access Lists," but they come very close. I like to refer to them as the "poor-man's firewall."

• Context-based Access Control (CBAC) ACLs? This type of ACL can filter on Layer 3 through Layer 7 information. This is Cisco's stateful firewall function in its Cisco IOS. Chapter 9, "Context-Based Access Control," covers CBAC ACLs.

• Lock-and-key ACLs? This type of ACL filters on Layer 3 and sometimes Layer 4 information. These ACLs implement double-authentication, in which, when connecting through PPP, the user authenticates first through PAP or CHAP and then at the application layer before the router allows the connection. Chapter 13, "Lock-and-Key Access Lists," covers lock-and-key ACLs. As you will see there, lock-and-key ACLs can be used to restrict any type of access to your network.

Processing ACLs

ACL statements have two components: a condition and an action. A condition is used to match on packet contents. When a match is found for a condition, an action is taken: permit or deny the packet. Even though this sounds simple, ACLs are one of the most complex features of the Cisco IOS: Take care when you configure and activate them. A misconfigured ACL can inadvertently block traffic or open a huge security hole. The following sections cover the ACL process in more depth.

Conditions

A condition is basically a set of rules that define what to look for in a packet's contents to determine whether the packet matches. A condition can be something as simple as looking for a match on the source address in the packet, or something as complicated as looking for a match in a source address, destination address, protocol type, and protocol information.

Only one condition can be listed in each ACL statement; however, you can group ACL statements to form a single list or policy. The statements are grouped by a common number or name.

Matches on Conditions

The Cisco IOS can take two basic actions when a condition in an ACL statement matches the contents in a compared packet:

• Permit

• Deny

When there is a match in an ACL statement, no further statements are processed.

Also, there is an invisible statement at the end of every ACL, called the implicit deny statement. The purpose of this statement is to drop packets; if a packet was compared to every statement in the list and a match was not found, the packet is dropped. Therefore, it is only common sense to have at least one permit action in your ACL. If you have only deny actions, the Cisco IOS either will match on one of these statements and drop the packet, or it will use the implicit deny statement to drop the packet.

ACL Flowchart

To help understand how the Cisco IOS processes an ACL, examine the flowcharts shown in Figures 6-2 and 6-3. Figure 6-2 shows an example in which an ACL is applied inbound on an interface. In this example, when a packet is received on an interface, the Cisco IOS first determines whether an ACL is applied on the interface. If it is not, the Cisco IOS normally routes the packet. If it is, the Cisco IOS processes the ACL. It starts with the first statement and compares the packet contents with the condition. If there is no match, the Cisco IOS goes to the next statement in the list. If there is a match, it executes the action: permit or deny. If the Cisco IOS goes through the entire ACL and does not find a match, it drops the packet.

Figure 6-2. Inbound ACL Flowchart

[View full size image]

Figure 6-3. Outbound ACL Flowchart

With an outbound ACL, the process is similar, as shown in Figure 6-3. When the Cisco IOS receives a packet, it first routes the packet to the outbound interface. The Cisco IOS then checks to see whether there is an outbound ACL on the interface. If not, the Cisco IOS queues up the packet to be sent out the interface. Otherwise, the packet is processed by comparing it to the ACL entries, as described previously.

Statement Order in ACLs

The order in which ACL statements are placed is very important. By default, when you add an ACL statement to the list, it is added at the bottom, or end, of the list. Until Cisco IOS 12.2(14)S and 12.3(2)T, you could not easily insert an ACL statement into the middle of an existing ACL grouping, nor could you delete a specific ACL statement (with the exception of named ACLs).

The order of the statements is important because the Cisco IOS processes the list from the top down. Starting with the first ACL statement, the Cisco IOS compares the packet contents with the condition. If there is no match, the router proceeds to the next statement, and so on and so forth. If the Cisco IOS does not find a match on any statements, the Cisco IOS drops the packet (implicit deny).

Look at a simple example in which statement ordering can create problems. In the example network shown in Figure 6-4, a router is separating two segments: One segment has users, and one segment has file servers. The goal in filtering traffic is to allow all users to reach the web server, but to allow only the Accounting user to the accounting server.

Figure 6-4. Simple ACL Ordering Problems

These ACL filtering rules are configured on the router (in this order):

Given the order of these rules, there is a problem. Because the statements are processed from the top down, when regular User A tries to access the accounting server, he is permitted based on a match of the first statement. In this example, everyone can access all servers on the server segment. Instead, the ACL should read as follows:

In this example, the regular users are denied access to the accounting server but still are allowed access to other servers on the segment.

Now look at a more complicated filtering problem by examining the network shown in Figure 6-5. The administrator must configure these policies, in no important order:

• Allow all access to the web server.

• Restrict access to the development server.

• Restrict access to the accounting server.

• Restrict access to the database server.

Figure 6-5. Complex ACL Ordering Problems

In this example, the administrator configured the following ACL rules in the specified order:

In this example, there is a configuration problem. For example, based on the previous rules and processing of the ACL from the top down, regular Users A, B, and C can access any resource because the first statement allows them to do so. Now switch the first two statements and see the results of this action:

This example fixes some of the access problems, but regular Users A, B, and C can still access the accounting server. Here is how the ACL should be structured and ordered:

As you can see in this example, the structure and ordering of the statements become more complicated because many policy variables come into play. The previous example is not the only way to accomplish the ordering of the list, but it does satisfy the requirements.

ACL Rules and Restrictions

Given the complexity that ACLs can create when implementing your security policies, you should be aware of these general rules, guidelines, and restrictions when creating your grouping of ACL statements:

• ACL statements are grouped by either a name or a number.

• Each ACL statement can have only one set of conditions and one action (permit or deny). If you need multiple conditions or multiple actions, you must create multiple ACL statements.

• If a match is not found in the condition of a statement, the next ACL statement in the list is processed.

• When a match is found on a statement in an ACL group, no further statements are processed.

• If all the statements in the list are processed and no match is found, the invisible implicit deny statement denies the packet.

• Given the implicit deny at the end of the grouping of ACL statements, you should have at least one permit action; otherwise, all packets will be denied.

• When filtering, if the Cisco IOS drops a packet, it generates an ICMP administratively prohibited message.

• Order of statements is important. The most restrictive statements should be at the top of the list, and the least restrictive should be at the bottom.

• An empty ACL grouping permits all packets. An empty ACL grouping is an ACL that has been activated on a router but that does not contain any statements. For the implicit deny statement to take effect, there must be at least one permit or deny statement in the ACL.

• You are allowed to apply one ACL per interface, per protocol, per direction. For example, you cannot have two IP ACLs applied inbound on an interface, but you can have an IP ACL applied inbound and outbound, or an IP and IPX ACL applied inbound.

• Inbound ACLs are processed before a packet is routed to another interface (see Figure 6-2).

• Outbound ACLs are processed after a packet is routed to the interface but before the packet exits the interface (see Figure 6-3).

• When an ACL is applied to an interface, which affects traffic flowing through the interface, the ACL does not filter traffic that the router itself generates. For example, if an outbound ACL is on a interface that blocks ICMP traffic, it will not filter pings that the router generates.

From this list, you can see that the processing of ACLs, as well as the configuration and management of them, is not a simple process. Care must be taken in the setup, implementation, maintenance, and troubleshooting of them. Therefore, you must be familiar with the previous bullets if you want to implement your security policies with the fewest problems and headaches.

Placement of ACLs

One of the questions that students commonly ask in my classes is where to configure ACLs?on what router or routers and on which interface or interfaces? The classic answer to this question is that it depends on your specific situation. However, two guidelines can help you with your decision:

• ACLs that filter only on the source address in a packet should be placed as close to the destination (that you are filtering) as possible.

• ACLs that filter on both the source and destination address in a packet, as well as other things, should be placed as close to the source as possible.

To demonstrate where ACLs should be placed, consider the network shown in Figure 6-6.

Figure 6-6. Placement of ACLs

In the first situation, assume that the network administrator is using ACLs that filter only on the source addresses in packets. In this example, User A is allowed to access all resources except the development server. Here is the ACL rule for User A:

The question is, on which router should the ACL be placed, and on which interface? Given the two placement rules just mentioned, the ACL should be placed as close to the destination as possible: on Router C's E0 interface in the outbound direction.

Now look at some other options with this example. If you placed it on Router A's E0 interface in the inbound direction, this definitely would stop the user from accessing the development server. However, because this ACL looks at the source address when matching the condition (it does not look at the destination), this filter would also prevent this user from accessing any other resource. If you put this ACL on Router C's E1 interface in the inbound direction, the user would be able to access the e-mail and file servers (as desired), but that user would be prevented from accessing the needed resources on the web server.

However, ACLs that filter only on source addresses in packets have two limitations:

• Even with the ACL applied outbound on E0 on Router C, any traffic from User A would be prohibited from accessing anything on this segment, including the development server.

• Traffic must go all the way to the destination. It is dropped just before reaching the destination. This is inefficient use of bandwidth.

In the second example, the network administrator is using ACLs that can filter on both source and destination addresses in packets. In this example, User A is allowed to access all resources except the development server. The question is, on which router should the ACL be placed, and on which interface? The answer is as close to the source as possible: Router A's E0 interface in the inbound direction. This solution solves the previous two problems. With this type of ACL, you can be specific about what resources are being accessed. In this example, you easily can set up this filtering policy to deny User A from accessing the development server and to grant access to all other services throughout the network.

Copyright eTutorials.org 2008-2023. All rights reserved.