Access Control List Operation

Access Control List Operation

Understanding the uses of access control lists (ACL) enables you to determine how to implement them on your Cisco network. ACLs can provide an important network security feature and filter packets on inbound and outbound router interfaces. This section describes some of the applications for ACLs on Cisco networks, identifies the different types of ACLs that can be implemented, and explains how Cisco IOS Software processes ACLs.

Understanding ACLs

To be able to configure and implement ACLs, you need to understand the capacity in which they are used. Cisco devices use ACLs in two primary functions: classification and filtering. The following explains each of these functions:

• Classification: Routers also use ACLs to identify particular traffic. After an ACL has identified and classified traffic, you can configure the router with instructions on how to handle that traffic. For example, you can use an ACL to identify the executive subnet as the traffic source and then give that traffic priority over other types of traffic on a congested WAN link.
• Filtering: As the number of router connections to outside networks increase and the use of the Internet increases, access control presents new challenges. Network administrators face the dilemma of how to deny unwanted traffic while allowing appropriate access. For example, you can use an ACL as a filter to keep the rest of your network from accessing sensitive data on the finance subnet.

Through classification and filtering, ACLs provide a powerful toolset in Cisco IOS. Consider the network diagram in Figure 6-1. Using ACLs, administrators have the tools to block traffic from the Internet, provide controlled access to manage Cisco IOS devices, and provide address translation for private addresses such as the 172.16.0.0 network.

Figure 6-1 ACLs Provide Control

Filtering is the function of ACLs that people identify most readily. ACLs offer an important tool for controlling traffic on the network. Packet filtering helps control packet movement through the network. Figure 6-2 shows an example of ACLs filtering traffic transmission in and out of a physical interface or to the Telnet session of a Cisco IOS device.

Figure 6-2 ACL Filtering

Cisco provides ACLs to permit or deny the following:

• The crossing of packets to or from specified router interfaces and traffic going through the router
• Telnet traffic into or out of the router vty ports for router administration
  By default, all IP traffic is permitted in and out of all the router interfaces.

When the router discards packets, some protocols return a special packet to notify the sender that the destination is unreachable. For the IP protocol, an ACL discard results in a “Destination unreachable (U.U.U.)” response to a ping and an “Administratively prohibited (!A * !A)” response to a traceroute.
IP ACLs can classify and differentiate traffic. Classification enables you to assign special handling for traffic that is defined in an ACL, such as the following:

• Identify the type of traffic to be encrypted across a virtual private network (VPN) connection.
• Identify the routes that are to be redistributed from one routing protocol to another.
• Use with route filtering to identify which routes are to be included in the routing updates between routers.
• Use with policy-based routing to identify the type of traffic that is to be routed across a designated link.
• Use with Network Address Translation (NAT) to identify which addresses are to be translated.
• Use with quality of service (QoS) to identify which packets should be scheduled in a given queue during times of congestion.

Figure 6-3 shows some examples of using ACLs for traffic classification, such as which traffic to encrypt across the VPN, which routes should be redistributed between Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP), and which addresses to translate using NAT.

Figure 6-3 ACLs Identify Traffic

ACL Operation

ACLs express the set of rules that give added control for packets that enter inbound interfaces, packets that relay through the router, and packets that exit outbound interfaces of the router. ACLs do not act on packets that originate from the router. Instead, ACLs are statements that specify conditions of how the router handles the traffic flow through specified interfaces. ACLs operate in two ways:

• Inbound ACLs: Incoming packets are processed before they are routed to an outbound interface. An inbound ACL is efficient because it saves the overhead of routing lookups if the packet will be discarded after it is denied by the filtering tests. If the packet is permitted by the tests, it is processed for routing.
• Outbound ACLs: Incoming packets are routed to the outbound interface and then processed through the outbound ACL. Figure 6-4 shows an example of an outbound ACL.

Figure 6-4 Outbound ACL Operation

When a packet enters an interface, the router checks the routing table to see if the packet is routable. If the packet is not routable, it is dropped.
Next, the router checks to see whether the destination interface is grouped to an ACL. If the destination interface is not grouped to an ACL, the packet can be sent to the output buffer. Examples of outbound ACL operations are as follows:

• If the outbound interface is S0, which has not been grouped to an outbound ACL, the packet is sent to S0 directly.
• If the outbound interface is S1, which has been grouped to an outbound ACL, the packet is not sent out on S1 until it is tested by the combination of ACL statements that are associated with that interface. Based on the ACL tests, the packet is permitted or denied. For outbound lists, “to permit” means to send the packet to the output buffer, and “to deny” means to discard the packet.

With an inbound ACL, when a packet enters an interface, the router checks to see whether the source interface is grouped to an ACL. If the source interface is not grouped to an ACL, the router checks the routing table to see if the packet is routable. If the packet is not routable, the router drops the packet. Examples of inbound ACL operations are as follows:

• If the inbound interface is S0, which has not been grouped to an inbound ACL, the packet is processed normally, and the router checks to see whether the packet is routable.
• If the inbound interface is S1, which has been grouped to an inbound ACL, the packet is not processed, and the routing table is not consulted until it is tested by the combination of ACL statements that are associated with that interface. Based on the ACL tests, the packet is permitted or denied.

For inbound lists, “to permit” means to continue to process the packet after receiving it on an inbound interface, and “to deny” means to discard the packet.

ACL statements operate in sequential, logical order. They evaluate packets from the top down, one statement at a time. If a packet header and an ACL statement match, the rest of the statements in the list are skipped, and the packet is permitted or denied as determined by the matched statement. If a packet header does not match an ACL statement, the packet is tested against the next statement in the list. This matching process continues until the end of the list is reached. Figure 6-5 shows the logical flow of statement evaluation.

Figure 6-5 ACL Evaluation

A final implied statement covers all packets for which conditions did not test true. This final test condition matches all other packets and results in a “deny” instruction. Instead of proceeding into or out of an interface, the router drops all of these remaining packets. This final statement is often referred to as the “implicit deny any statement.” Because of this statement, an ACL should have at least one permit statement in it; otherwise, the ACL blocks all traffic. This implicit deny all will not show up in the router configuration. In many of the examples in this text, it will be added as a reminder. You can apply an ACL to multiple interfaces. However, only one ACL can exist per protocol, per direction, and per interface.

Types of ACLs

IPv4 ACLs come in various types. These differing ACLs are used depending on the functionality required. The types of ACLs can be classified as follows:

• Standard ACLs: Standard IP ACLs check the source addresses of packets that can be routed. The result either permits or denies the output for an entire protocol suite, based on the source network, subnet, or host IP address.
• Extended ACLs: Extended IP ACLs check both the source and destination packet addresses. They can also check for specific protocols, port numbers, and other parameters, which allow administrators more flexibility and control. You can use two methods to identify standard and extended ACLs:
• Numbered ACLs use a number for identification.
• Named ACLs use a descriptive name or number for identification.

ACL Identification

When you create numbered ACLs, you enter an ACL number as the first argument of the global ACL statement. The test conditions for an ACL vary depending on whether the number identifies a standard or extended ACL.

You can create many ACLs for a protocol. Select a different ACL number for each new ACL within a given protocol. However, you can apply only one ACL per protocol, per direction, and per interface.

Specifying an ACL number from 1 to 99 or 1300 to 1999 instructs the router to accept numbered standard IPv4 ACL statements. Specifying an ACL number from 100 to 199 or 2000 to 2699 instructs the router to accept numbered extended IPv4 ACL statements.

Table 6-1 lists the different ACL number ranges for each protocol.

Table 6-1 Protocol ACL Numbers

As of Cisco IOS Software Release 12.0, IPv4 ACLs have been expanded. The table shows that standard IPv4 ACLS have been expanded to include the numbers 1300 to 1999, and the extended IPv4 ACLs have been expanded to include the numbers 2000 to 2699.

The named ACL feature enables you to identify IP standard and extended ACLs with an alphanumeric string (name) instead of the numeric representations. Named IP ACLs give you more flexibility in working with the ACL entries.
IP access list entry sequence numbering has several benefits:

• You can edit the order of ACL statements.
• You can remove individual statements from an ACL.

Where additions are placed in an ACL depends on whether you use sequence numbers. There is no support for sequence numbering in software versions earlier than Cisco IOS Software Release 12.3; therefore, all the ACL additions for earlier software versions are placed at the end of the ACL.

IP access list entry sequence numbering is a new edition to Cisco IOS Software that enables you to use sequence numbers to easily add, remove, or reorder statements in an IP ACL. With Cisco IOS Software Release 12.3 and later, additions can be placed anywhere in the ACL based on the sequence number.

Earlier than Cisco IOS Software Release 12.3, only named ACLs enable the removal of individual statements from an ACL using the following command:
no {deny | permit} protocol source source-wildcard destination destination-wildcard The protocol source source-wildcard destination destination-wildcard parameters match the line you are trying to remove. With numbered ACLs, you would have to remove the whole list and recreate it with the desired statements. With Cisco IOS Software Release 12.3 and later, you can also use the no sequence-number command to delete a specific access list entry. Well-designed and well-implemented ACLs add an important security component to your network. Follow these general principles to ensure that the ACLs you create have the intended results:

• Based on the test conditions, choose a standard or extended, numbered, or named ACL.
• Only one ACL per protocol, per direction, and per interface is allowed. Multiple ACLs are permitted per interface, but each must be for a different protocol or different direction.
• Your ACL should be organized to enable processing from the top down. Organize your ACL so that the more specific references to a network or subnet appear before ones that are more general. Place conditions that occur more frequently before conditions that occur less frequently.
• Your ACL contains an implicit deny any statement at the end:
  • Unless you end your ACL with an explicit permit any statement, by default, the ACL denies all traffic that fails to match any of the ACL lines.
  • Every ACL should have at least one permit statement. Otherwise, all traffic is denied.
• You should create the ACL before applying it to an interface. With most versions of Cisco IOS Software, an interface that has an empty ACL applied to it permits all traffic.
• Depending on how you apply the ACL, the ACL filters traffic either going through the router or going to and from the router, such as traffic to or from the vty lines.
• You should typically place extended ACLs as close as possible to the source of the traffic that you want to deny. Because standard ACLs do not specify destination addresses, you must put the standard ACL as close as possible to the destination of the traffic you want to deny so the source can reach intermediary networks.

Additional Types of ACLs

Standard and extended ACLs can become the basis for other types of ACLs that provide additional functionality. These other types of ACLs include the following:

• Dynamic ACLs (lock-and-key)
• Reflexive ACLs
• Time-based ACLs

Dynamic ACLs

Dynamic ACLs depend on Telnet connectivity, authentication (local or remote), and extended ACLs. Lock-and-key configuration starts with the application of an extended ACL to block traffic through the router. Users who want to traverse the router are blocked by the extended ACL until they use Telnet to connect to the router and are authenticated. The Telnet connection is then dropped, and a single-entry dynamic ACL is added to the extended ACL. This permits traffic for a particular period; idle and absolute timeouts are possible. Figure 6-6 shows an example of dynamic access lists.

Figure 6-6 Dynamic ACL

Some common reasons to use dynamic ACLs are as follows:

• Use dynamic ACLs when you want a specific remote user or group of remote users to access a host within your network, connecting from their remote hosts via the Internet. Lock-andkey authenticates the user and permits limited access through your firewall router for a host or subnet for a finite period.
• Use dynamic ACLs when you want a subset of hosts on a local network to access a host on a remote network that is protected by a firewall. With lock-and-key, you can enable access to the remote host only for the desired set of local hosts. Lock-and-key requires the users to authenticate through a TACACS+ server, or other security server, before it allows their hosts to access the remote hosts.

Dynamic ACLs have the following security benefits over standard and static extended ACLs:

• Use of a challenge mechanism to authenticate individual users
• Simpler management in large internetworks
• In many cases, reduction of the amount of router processing that is required for ACLs
• Reduction of the opportunity for network break-ins by network hackers
• Creation of dynamic user access through a firewall, without compromising other configured security restrictions

Although the entire configuration for a dynamic ACL is outside the scope of this course, the following example shows the steps that are required to configure a dynamic ACL. The goal of a dynamic ACL is to provide a means for some users on a network to have access through the router without knowing exactly what devices they will be connecting from. This type of list requires the end user to log in to the router from the device to set up a temporary access list to permit the traffic. The following configuration creates a login name and password for authentication. The idle timeout is set to 10 minutes.

RouterX(config)#username test password test
RouterX(config)#username test autocommand access- enable host timeout 1 0

The following configuration enables users to open a Telnet connection to the router that is to be authenticated and blocks all other traffic:

RouterX(config)#access- list 1 01 permit tcp any host 1 0. 1 . 1 . 1 eq telnet
RouterX(config)#interface Ethernet0/0
RouterX(config-if)#ip address 1 0. 1 . 1 . 1 255. 255. 255. 0
RouterX(config-if)#ip access- group 1 01 in

The following configuration creates the dynamic ACL that will be automatically applied to the existing access-list 101. The absolute timeout is set to 15 minutes.

RouterX(config)#access- list 1 01 dynamic testlist timeout 1 5 permit ip 1 0. 1 . 1 . 0
0. 0. 0. 255 1 72. 1 6. 1 . 0 0. 0. 0. 255

The following configuration forces users to authenticate when they open a Telnet connection to the router:

RouterX(config)#line vty 0 4
RouterX(config-line)#login local

After you have done these configurations, when the user at 10.1.1.2 successfully makes a Telnet connection to 10.1.1.1, the dynamic ACL is applied. The connection is then dropped, and the user can access the 172.16.1.x network.

Reflexive ACLs

Reflexive ACLs allow IP packets to be filtered based on upper-layer session information such as TCP port numbers. They are generally used to allow outbound traffic and limit inbound traffic in response to sessions that originate from a network inside the router. Reflexive ACLs contain only temporary entries. These entries are automatically created when a new IP session begins, for example, with an outbound packet, and the entries are automatically removed when the session ends. Reflexive ACLs are not applied directly to an interface but are “nested” in an extended named IP ACL that is applied to the interface.

Reflexive ACLs provide a truer form of session filtering than an extended ACL that uses the established parameter. Reflexive ACLs are much harder to spoof because more filter criteria must match before a packet is permitted through; for example, source and destination addresses and port numbers, not just acknowledgment (ACK) and reset (RST) bits, are checked. Figure 6-7 illustrates how the reflexive access list operates.

Figure 6-7 Reflexive Access Lists

Reflexive ACLs are an important part of securing your network against network hackers and can be included in a firewall defense. Reflexive ACLs provide a level of security against spoofing and certain denial of service (DoS) attacks. Reflexive ACLs are simple to use and, compared to basic ACLs, provide greater control over which packets enter your network.

Although the entire configuration for reflexive ACLs is outside the scope of this course, the following example shows the steps that are required to configure a reflexive ACL. The example is of a reflexive ACL that permits Internet Control Message Protocol (ICMP) outbound and inbound traffic, while it permits only TCP traffic that has initiated from inside. All other traffic is denied.

The following configuration causes the router to keep track of traffic that was initiated from inside:

RouterX(config)#ip access- list extended outboundfilters
RouterX(config-ext-nacl)#permit icmp 1 0. 1 . 1 . 0 0. 0. 0. 255 1 72. 1 6. 1 . 0 0. 0. 0. 255
RouterX(config-ext-nacl)#permit tcp 1 0. 1 . 1 . 0 0. 0. 0. 255 1 72. 1 6. 1 . 0 0. 0. 0. 255 reflect
tcptraffic

The next configuration creates an inbound policy that requires the router to check incoming traffic to see whether it was initiated from inside and ties the reflexive ACL part of the outboundfilters ACL, called tcptraffic, to the inboundfilters ACL:

RouterX(config)#ip access- list extended inboundfilters
Router(config-ext-nacl)#permit icmp 1 72. 1 6. 1 . 0 0. 0. 0. 255 1 0. 1 . 1 . 0 0. 0. 0. 255 evaluate tcptraffic

The configuration in Example 6-1 applies to both an inbound and an outbound ACL to the interface.

Example 6-1 Applying Inbound and Outbound ACLs to an Interface

RouterX(config)#interface Ethernet0/1
RouterX(config-if)#ip address 1 72. 1 6. 1 . 2 255. 255. 255. 0
RouterX(config-if)#ip access- group inboundfilters in
RouterX(config-if)#ip access- group outboundfilters out

Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs or with other protocol ACLs.

Time-Based ACLs

Time-based ACLs are similar to extended ACLs in function, but they allow for access control based on time. To implement time-based ACLs, you create a time range that defines specific times of the day and week. The time range is identified by a name and then referenced by a function. Therefore, the time restrictions are imposed on the function itself. For example, in Figure 6-8, a user is blocked from transmitting HTTP traffic after 7:00 p.m.

Figure 6-8 Timed Access Lists

Time-based ACLs have many benefits:

• The network administrator has more control over permitting or denying a user access to resources. These resources could be an application, identified by an IP address and mask pair and a port number; policy routing; or an on-demand link, identified as interesting traffic to the dialer.
• Network administrators can set time-based security policies such as the following:
  • Perimeter security using the Cisco IOS Firewall feature set or ACLs
  • Data confidentiality with Cisco Encryption Technology or IP security (IPsec)
• Policy-based routing and queuing functions are enhanced.
• When provider access rates vary by time of day, it is possible to automatically reroute traffic cost effectively.
• Service providers can dynamically change a committed access rate (CAR) configuration to support the QoS service-level agreements (SLA) that are negotiated for certain times of day.
• Network administrators can control logging messages. ACL entries can log traffic at certain times of the day but not constantly. Therefore, administrators can simply deny access without analyzing the many logs that are generated during peak hours.

Although the entire configuration for time-based ACLs is outside the scope of this course, the following example shows the steps that are required to configure a time-based ACL. In the example, a Telnet connection is permitted from the inside network to the outside network on Monday, Wednesday, and Friday during business hours. The following configuration defines the time range to implement the ACL and names it:

RouterX(config)#time- range EVERYOTHERDAY
RouterX(config-time-range)#periodic Monday Wednesday Friday 8: 00 to 1 7: 00

The following configuration applies the time range to the ACL:

RouterX(config)#access- list 1 01 permit tcp 1 0. 1 . 1 . 0 0. 0. 0. 255 1 72. 1 6. 1 . 0 0. 0. 0. 255
eq telnet time- range EVERYOTHERDAY
The following configuration applies the ACL to the interface:
RouterX(config)#interface Ethernet0/0
RouterX(config-if)#ip address 1 0. 1 . 1 . 1 255. 255. 255. 0
RouterX(config-if)#ip access- group 1 01 in

The time range relies on the router system clock. The router clock can be used, but the feature works best with Network Time Protocol (NTP) synchronization.

ACL Wildcard Masking

Address filtering occurs when you use ACL address wildcard masking to identify how to check or ignore corresponding IP address bits. Wildcard masking for IP address bits uses the numbers 1 and 0 to identify how to treat the corresponding IP address bits, as follows:

• Wildcard mask bit 0: Match the corresponding bit value in the address.
• Wildcard mask bit 1: Do not check (ignore) the corresponding bit value in the address.

NOTE A wildcard mask is sometimes referred to as an inverse mask.

By carefully setting wildcard masks, you can permit or deny tests with one ACL statement. You can select a single IP address or many IP addresses. Figure 6-9 illustrates how to check corresponding address bits.

Figure 6-9 Wildcard Mask

NOTE Wildcard masking for ACLs operates differently from an IP subnet mask. A “0” in a bit position of the ACL mask indicates that the corresponding bit in the address must be matched. A “1” in a bit position of the ACL mask indicates that the corresponding bit in the address is not interesting and can be ignored.

In Figure 6-10, an administrator wants to test a range of IP subnets that is to be permitted or denied. Assume that the IP address is a Class B address (the first two octets are the network number), with 8 bits of subnetting. (The third octet is for subnets.) The administrator wants to use the IP wildcard masking bits to match subnets 172.30.16.0/24 to 172.30.31.0/24.

Figure 6-10 Masking a Range of Addresses

To use one ACL statement to match this range of subnets, use the IP address 172.30.16.0 in the ACL, which is the first subnet to be matched, followed by the required wildcard mask. The wildcard mask matches the first two octets (172.30) of the IP address using corresponding 0 bits in the first two octets of the wildcard mask.

Because there is no interest in an individual host, the wildcard mask ignores the final octet by using the corresponding 1 bit in the wildcard mask. For example, the final octet of the wildcard mask is 255 in decimal.

In the third octet, where the subnet address occurs, the wildcard mask of decimal 15, or binary 00001111, matches the high-order 4 bits of the IP address. In this case, the wildcard mask matches subnets starting with the 172.30.16.0/24 subnet. For the final (low-end) 4 bits in this octet, the wildcard mask indicates that the bits can be ignored. In these positions, the address value can be binary 0 or binary 1. Thus, the wildcard mask matches subnet 16, 17, 18, and so on up to subnet 31. The wildcard mask does not match other subnets.

In the example, the address 172.30.16.0 with the wildcard mask 0.0.15.255 matches subnets 172.30.16.0/24 to 172.30.31.0/24.

In some cases, you must use more than one ACL statement to match a range of subnets; for example, to match 10.1.4.0/24 to 10.1.8.0/24, use 10.1.4.0 0.0.3.255 and 10.1.8.0 0.0.0.255. The 0 and 1 bits in an ACL wildcard mask cause the ACL to either match or ignore the corresponding bit in the IP address. Working with decimal representations of binary wildcard mask bits can be tedious. For the most common uses of wildcard masking, you can use abbreviations. These abbreviations reduce how many numbers you are required to enter while configuring address test conditions. Figure 6-11 shows the wildcard masks used to match a specific host or to match all (any) host.

Figure 6-11 Special Case Wildcard Masks

Instead of entering 172.30.16.29 0.0.0.0, you can use the string host 172.30.16.29. Using the abbreviation host communicates the same test condition to the Cisco IOS ACL Software. Instead of entering 0.0.0.0 255.255.255.255, you can use the word any by itself as the keyword. Using the abbreviation any communicates the same test condition to the Cisco IOS ACL Software.

More Resources

• Interconnecting Cisco Network Devices (ICND2)
• CCNP Switch Exam Certification Guide