Types of Access Lists

Many types of ACLs can be configured in Cisco IOS. The following lists are the most commonly known and used:

• Standard ACLs

• Extended ACLs

• IP named ACLs

• Lock and key (Dynamic ACLs)

• Reflexive ACLs

• Established ACLs

• Time-based ACLs using time ranges

• Distributed time-based ACLs

• Turbo ACLs

• Receive ACLs

• Infrastructure protection ACLs

• Transit ACLs

• Classification ACLs

• Debugging traffic using ACLs

Standard ACLs

Standard ACLs are the oldest and one of the most basic types of ACLs. Standard ACLs inspect traffic by comparing the source address of the IP packets to the addresses configured in the ACL. A standard ACL can be defined to permit or deny specific source IP addresses only.

The command syntax format to define a numbered standard ACL is the following:

access-list access-list-number {deny | permit} source [source-wildcard] [log]

					  

The keyword log causes an informational logging message when the packet matches the access-list statement. For all matched packets, a message is sent to the console, the buffer, or to a syslog server. The message includes the ACL number, a notification of whether the packet was permitted or denied, the source address, and the number of packets.

In all Cisco IOS Software releases, the standard access-list-number can be anything from 1 to 99 or the expanded range 1300 to 1999, as shown in Table 2-6. Example 2-2 shows a standard numbered ACL allowing access to hosts on the two specified networks. The wildcard bits apply to the host portions of the network addresses. Traffic from any host with a source address that does not match the ACL criteria will be dropped because of the implicit deny.

Example 2-2. Standard Numbered ACL Example

Router(config)# access-list 1 permit 192.16.1.0 0.0.0.255 Router(config)# access-list 1 permit 139.65.0.0 0.0.255.255 (Note: implicit deny)

After the ACL is defined, it must be applied to the interface (inbound or outbound direction).

Router(config)# interface <interface-name>
Router(config-if)# ip access-group {access-list-number|name} {in|out}

The following is another example showing the use of a standard ACL to block all traffic except that from source 10.1.1.0/24. Note that the example has one permit statement followed by an implicit deny, which will block all other traffic.

Router(config)# access-list 1 permit 10.1.1.0 0.0.0.255

Router(config)# interface Serial0
Router(config-if)# ip access-group 1 in

Extended ACLs

Extended ACLs are used to filter more-specific traffic based on the source address, the destination address, and specific protocols, ports, and flags. A sample command syntax format for various types of extended ACLs for each protocol is shown in the list that follows:

• To define an extended IP ACL:

  Code View:

  access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny |
   permit} protocol source source-wildcard destination destination-wildcard
   [precedence precedence] [tos tos] [log | log-input] [time-range time-range-name]
   [fragments]
  
  					  

• To define an extended TCP ACL:

  Code View:

  access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny |
   permit} tcp source source-wildcard [operator [port]] destination destination-
   wildcard [operator [port]] [established] [precedence precedence] [tos tos] [log
   | log-input] [time-range time-range-name] [fragments]
  
  					  

• To define an extended User Datagram Protocol (UDP) ACL:

  Code View:

  access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny |
   permit} udp source source-wildcard [operator [port]] destination destination-
   wildcard [operator [port]] [precedence precedence] [tos tos] [log | log-input]
   [time-range time-range-name] [fragments]
  
  					  

• To define an extended Internet Control Message Protocol (ICMP) ACL:

  Code View:

  access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny |
   permit} icmp source source-wildcard destination destination-wildcard [icmp-type
   [icmp-code] | icmp-message] [precedence precedence] [tos tos] [log | log-input]
   [time-range time-range-name] [fragments]
  
  					  

• To define an extended Internet Group Management Protocol (IGMP) ACL:

  Code View:

  access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny |
   permit} igmp source source-wildcard destination destination-wildcard [igmp-
   type] [precedence precedence] [tos tos] [log | log-input] [time-range time-
   range-name] [fragments]
  
  					  

In all Cisco IOS Software releases, the access-list-number for extended access lists can be 101 to 199 or the expanded numbers 2000 to 2699, as shown in Table 2-6.

The following example permits Simple Mail Transfer Protocol (SMTP) (e-mail) traffic to host 172.16.1.1, Domain Name System (DNS) traffic, and ICMP echo and echo reply packets sourced from all hosts:

Router(config)# access-list 101 permit tcp any host 172.16.1.1 eq smtp
Router(config)# access-list 101 permit tcp any any eq domain
Router(config)# access-list 101 permit udp any any eq domain
Router(config)# access-list 101 permit icmp any any echo
Router(config)# access-list 101 permit icmp any any echo-reply

Router(config)# interface Serial0
Router(config-if)# ip access-group 101 in

IP Named ACLs

Cisco IOS Software also added the capability to use a name in the ACL. This allows standard and extended ACLs to be given names instead of numbers. All other parameters remain the same. This is an additional feature added to the normal ACL convention. The command syntax format you use to define a named ACL is the following:

Router(config)# ip access-list {standard | extended} access-list-name
 (Followed by permit/deny criteria statements)

Example 2-3 shows the configuration of a standard named ACL called myacl that allows all traffic sourced from network 192.16.1.0/24 and host 172.65.1.1.

Example 2-3. Standard Named ACL Example

ip access-list standard myacl permit 192.16.1.0 0.0.0.255 permit host 172.65.1.1 (Note: implicit deny)

Example 2-4 shows configuration of an extended named ACL called myacl that allows SMTP connections to host 172.16.1.1 and DNS packets and all ICMP packets.

Example 2-4. Extended Named ACL Example

ip access-list extended myacl permit tcp any host 172.16.1.1 eq smtp permit tcp any any eq domain permit udp any any eq domain permit icmp any any (Note: implicit deny)

Lock and Key (Dynamic ACLs)

Lock and key (also known as Dynamic ACL) allows you to set up a dynamic access that will allow per-user access control to a particular source/destination using an authentication mechanism. The lock-and-key feature depends on the following items: the Telnet protocol, an authentication process, and an extended ACL.

The following process elaborates the operation of lock-and-key access.

Follow the steps shown to configure lock-and-key access. Note this example uses local router authentication.

Configure a local username for authentication:

username test password test123

Under the vty lines, configure login local; this will trigger the authentication process.

line vty 0 4
 login local

To automatically invoke the access-enable command and set the timeout parameter, configure a username by using one of the following methods:

username test autocommand access-enable host timeout 10

line vty 0 4
  login local
  autocommand access-enable host timeout 10

Then configure an extended ACL that is applied when a user (any user) logs in to the router and the access-enable command is invoked. The maximum absolute time for this "hole" in the filter is set to 15 minutes; 15 (minutes) is the absolute timeout, and 10 (minutes) is the idle timeout. After 15 minutes, the dynamic entry is removed, regardless of the usage and whether anyone is connected. Limit the networks to which the user needs access by configuring the source or destination address and/or protocol/port details. The following example allows the user to connect to the SMTP server 192.168.1.1 after a successful authentication.

access-list 102 dynamic myacl timeout 15 permit tcp any host 192.168.1.1 eq smtp

					  

The ACL should explicitly ensure that the capability for the host to telnet into the router is allowed, as shown in the example that follows. The IP address used in this example is the Ethernet IP address of the router where the user would telnet to authenticate and open the dynamic hole.

access-list 102 permit tcp any host 172.16.1.2 eq telnet

Apply this ACL to the interface on which the user is connected:

interface Ethernet0
 ip address 172.16.1.2 255.255.255.0
 ip access-group 102 in

The ACL will show as follows after a user has successfully authenticated, and a dynamic entry will be populated in the extended ACL with the source address of the host. In the sample output that follows, the user host address is 172.16.1.5, and the user is allowed to connect to the SMTP server at 192.168.1.1. All other traffic from this host is blocked.

Router# show access-lists
Extended IP access list 102
    10 Dynamic myacl permit tcp any host 172.16.1.1 eq smtp
      permit ip host 172.16.1.5 permit tcp any host 192.168.1.1 eq smtp (time left
        160)
    20 permit tcp any host 172.16.1.2 eq telnet (104 matches)

					  

The dynamic entry is appended in the ACL for every user who passes authentication, based on the source IP address.

Reflexive ACLs

Reflexive ACLs allow IP packets to be filtered based on upper-layer session information. Reflexive ACLs are generally used to allow outbound traffic and to limit inbound traffic in response to sessions originating inside the router. A reflexive ACL is similar to the Context-Based Access Control (CBAC), which will be discussed in Chapter 5.

Reflexive ACLs have an important restriction—that is, they can be used only in conjunction with an extended-named IP ACL. They cannot be defined with a numbered or standard-named IP ACL, or with any other non-IP protocol ACLs. Reflexive ACLs can be used in combination with other standard and static extended ACLs.

With the extended ACL in Example 2-5, all ICMP traffic statically and all TCP traffic originating from source 10.0.0.0/24 going to destination 172.16.1.0/24 through the reflexive router is permitted on the return path through the use of a dynamic mechanism in the inbound ACL. In essence, the reflexive process permits only the return traffic that has been initiated from inside. (All other traffic is denied.)

Example 2-5. Reflexive ACL Example

interface Ethernet0 ip address 172.16.1.2 255.255.255.0 ip access-group inbound_acl in ip access-group outbound_acl out ! ip access-list extended inbound_acl permit icmp any any evaluate tcp_reflect ! ip access-list extended outbound_acl permit icmp any any permit tcp 10.0.0.0 0.0.0.255 172.16.1.0 0.0.0.255 reflect tcp_reflect

The context binding the outbound_acl ACL called tcp_reflect is linked with the evaluate tcp_reflect reference in the inbound_acl ACL. Hence, traffic originating from 10.0.0.0/24 to destination 172.16.1.0/24 will be permitted, and it will return when it hits the inbound_acl.

Established ACLs

The established keyword in a TCP extended ACL validates that a packet belongs to an existing connection from an ongoing TCP session initiated earlier and checks whether the TCP datagram has the acknowledgment (ACK) or reset (RST) bit set. This mechanism allows only internal networks to initiate a TCP session outbound through the device. Any TCP connections originated from the external network inbound are dropped.

The configuration in Example 2-6 for Figure 2-5 shows TCP traffic sourced from Network A (10.2.2.0/24) destined to Network B (10.1.1.0/24) being permitted, while denying TCP traffic from Network B destined to Network A.

ACL 101 in Example 2-6 permits all inbound TCP packets to pass through the router interface Ethernet1 only when the TCP datagram has the acknowledged (ACK) or the reset (RST) bit set, validating an established TCP session originated from inside. When a host from Network B (10.1.1.0/24) initiates a TCP connection by sending the first TCP packet in the three-way handshake with the SYN bit set, it will be denied, and the TCP session will not succeed. Any TCP sessions initiated from Network A (10.2.2.0/24) destined to Network B (10.1.1.0/24) will be allowed because they will have the ACK/RST bit set for all the returning packets. Any datagram with an ACK/RST bit not set will be dropped.

Example 2-6. Established ACL Example

interface Ethernet1 ip address 10.1.1.2 255.255.255.0 ip access-group 101 in ! access-list 101 permit tcp any any established

Time-Based ACLs Using Time Ranges

Time-based ACLs are similar to the extended ACLs in function; they provide the additional feature of controlling access based on the time. The time range relies on the router's system clock. However, this feature works best with Network Time Protocol (NTP) synchronization. IP and IPX numbered or named extended ACLs are the only functions that can use time ranges.

To configure time-based ACLs, a time range is created that defines specific times of the day and week. The time range is identified by a name and then referenced within the extended ACL allowing control when the permit or deny statements in the ACL are in effect. Both named and numbered ACLs can reference a time range.

Router(config)# time-range time-range-name

Router(config-time-range)# absolute [start time date] [end time date]

Router(config-time-range)# periodic days-of-the-week hh:mm to [days-of-the-
 week] hh:mm

Router(config)# access-list number {permit | deny} source destination time-
 range name_of_time_range

Router(config)# interface {interface-name}
Router(config-if)# ip access-group {access-list-number|name} {in | out}

Example 2-7 shows that all IP traffic is being permitted through the network on weekdays (Monday through Friday) during normal business hours.

Example 2-7. Time-Based ACL Example

interface Ethernet0 ip address 172.16.1.2 255.255.255.0 ip access-group 101 in access-list 101 permit ip any any time-range mytime time-range mytime periodic weekdays 9:00 to 17:00

Distributed Time-Based ACLs

Distributed time-based ACLs were introduced primarily for the high-end routers. Distributed time-based ACLs were designed to be implemented on the VPN-enabled Cisco 7500 series routers. As discussed earlier, time-based ACLs were not initially supported on the line cards in the Cisco 7500 series. If an interface on a 7500 line card was configured with a time-based ACL, the packets switched into the interface were not "distributed switched" through the line card. Instead, they were forwarded to the route processor for processing and therefore did not take advantage of the distributed switching capability. The distributed time-based ACLs feature allows packets destined for an interface that are configured with time-based ACLs to be "distributed-switched" through the line card.

Distributed time-based ACLs leverage the performance benefits of distributed switching and the flexibility provided by time-based ACLs. The software clock must remain synchronized between the Route Processor (RP) and the line card for the distributed time-based ACL to function properly.

Configuring Distributed Time-Based ACLs

Because this feature is enabled automatically when the normal time-range ACL is configured on a line card interface, there is no command syntax to enable this feature. The command syntax is the same as for the time-based ACL. The function is only a software code integration in the IOS; no additional commands are required. Use the following commands to monitor the status and display statistics for the Interprocessor Communication (IPC) messages between the RP and line card:

clear time-range ipc

Used to clear the time-range IPC message statistics and counters between the RP and the line card.

debug time-range ipc

Used to enable debugging output for monitoring the time-range IPC messages between the RP and the line card.

show time-range ipc

Used to display the statistics about the time-range IPC messages between the RP and the line card.

Turbo ACLs

Traditional ACLs are searched sequentially (top-down) to find matching criteria. As the ACLs grow, a significant amount of time and memory can be consumed for lookups when packets are being processed. This adds a variable latency to the packet forwarding and results in performance issues. The Turbo ACL feature is designed to process ACLs more efficiently to improve router performance. This feature is available on high-end platforms such as the Cisco 7200 and 7500 series routers and the Cisco 12000 series Gigabit Switch Routers (GSR).

The Turbo ACLs feature compiles the ACLs into a group of lookup tables while maintaining the first match requirements. Packet headers are used to access these tables in a small, fixed number of lookups, independent of the existing number of ACL entries. This tremendously improves the performance and saves ACLs lookup cycles.

To enable the Turbo ACL feature, use the access-list compiled command from the global configuration mode to compile all ACLs. This command should be applied after the normal ACLs have been configured and are ready to be compiled.

The Turbo ACL feature is disabled by default. When Turbo ACL is not enabled, the normal ACL processing is enabled, with no occurrence of ACL acceleration.

Use the show access-list and the show access-list compiled commands to verify that the Turbo ACL feature has taken effect and ACLs have been compiled for acceleration. The ACLs will be flagged as (Compiled), indicating they are operating as an accelerated ACL.

Receive ACLs (rACL)

Cisco 12000 series Gigabit Switch Routers (GSR) and 7500 platforms support Receive ACL (rACL) to increase security and thereby protect the router from unnecessary and potentially nefarious traffic. High volumes of data sent to the GRP can be overwhelming, resulting in an effective denial-of-service (DoS) attack. GSRs need to be protected against such scenarios, which may result from DoS attacks directed at the GRP of the router. There are few techniques available to alleviate DoS, such as rate-limiting traffic destined to the GRP from the line cards. Unfortunately, this approach comes with a trade-off and some limitations. The rate limiting for normal-priority traffic destined to the GRP does not guarantee protection to high-priority traffic, such as routing protocol data in the event of an attack channeled via several line cards.

Receive ACL can be configured using the following global configuration command and distributed to each line card in the router. Standard and extended ACL numbers are supported for rACL.

ip receive access-list <access-list-number>

Infrastructure Protection ACLs (iACL)

Infrastructure ACL (iACL) is a conceptual view, and no special configuration is required. It is mainly used to minimize the risk of direct infrastructure attacks by explicitly permitting only authorized traffic to the infrastructure equipment (such as the routers, switches, and firewalls). This technique secures network devices by denying access from valid external sources to all infrastructure device addresses that do not require direct access. When configuring an iACL, be careful to ensure that that iACL allows all transit traffic traversing the router and maintaining an uninterrupted packet flow, thereby complying with basic RFCs such as RFC 1918, RFC 3330, and RFC 2827 ingress filtering and anti-spoofing guidelines.

Because they are armed with a number of techniques and solutions that safeguard networks from both accidental and malicious risks, you should seriously consider using infrastructure protection ACLs for deployment at all network ingress points.

Transit ACLs

Transit ACLS are similar to infrastructure protection ACLs in two ways: transit ACLS give you a conceptual view, and they do not require special configuration. Transit ACLs represent one of the many ways to increase network security by explicitly allowing legitimate traffic into the network. For most network environments, filtering should be applied to control inbound traffic into the network and to block any unauthorized attempt at the edge of the network. Service provider networks, for example, often control traffic entering or exiting customer networks by using edge or transit filtering. This protects unwanted traffic from one customer to another because unwanted traffic is dropped at the service provider edge.

A transit ACL is developed using the following guidelines:

• Using antispoofing protection based on best practices from the following three RFCs:
  
  

  - RFC 1918—Private address space not routable on the Internet
  
  

  - RFC 3330—Special use addresses that might require filtering
  
  

  - RFC 2827—Antispoofing guidelines
  
  

• Explicitly permitting return traffic for all connections originating from the internal network to the Internet
  
  
• Explicitly permitting externally sourced traffic that is originating from the external network destined to the protected internal network
  
  
• Explicitly using a deny statement toward the end of the ACL
  
  

Visit the Cisco documentation URL shown in the Tip that follows for an example of transit ACL.

Classification ACLs

Another common type of ACL is the classification, also commonly known as characterization ACL. It is initially composed with all permit statements for the various protocols, ports, flags, and so on that could be sent to any of these three destinations: an infrastructure device, a public server in the protected zone, or any other device in the network. In some cases, a classification ACL can also have any source and the destination IP address using the keyword any in the ACL. This type of ACL is useful in classifying and categorizing a denial-of-service (DoS) attack and identifying the type of traffic and its source. Logging can be used to develop a list of source addresses that match the protocol permit statements. A last line permitting ip any any is required to permit all other traffic flow.

Example 2-8 shows a sample ACL that characterizes a suspected DoS attack. The first line checks for possible ICMP Smurf attacks. The second line checks for any sort of TCP SYN attack. The third, fourth, and fifth lines check for any sort of fragment attack. Finally, the last four lines check for general protocol types. This ACL is a very basic generic example and can be configured for virtually any protocol, ports, flags, and so on in a classification ACL.

Example 2-8. Example of DoS Characterization ACL

access-list 101 permit icmp any any eq echo access-list 101 permit tcp any any syn access-list 101 permit tcp any any fragment access-list 101 permit udp any any fragment access-list 101 permit ip any any fragment access-list 101 permit tcp any any access-list 101 permit udp any any access-list 101 permit icmp any any access-list 101 permit ip any any

After applying this ACL on the suspected ingress interface, enter the show access-list command repeatedly and check for the line that shows the highest hit counts, indicating the possible cause of the attack. Continue to tune this ACL to further narrow down the type of traffic until a closer match is found. This is a very useful technique to implement under a DoS attack, particularly when you are unsure what type of DoS attack is underway.

Debugging Traffic Using ACLs

ACLs can be used to debug traffic on a router. Running debugs on a router is resource consuming and could potentially use almost all system resources, such as memory and processing power. Excessive debugging under high load conditions may cause unexpected interruptions or in some cases cause the device to crash. Therefore, debugging commands need to be used with extreme caution. Before enabling debugging, inspect the CPU load by using the show processes cpu command and verify that sufficient CPU is available before running the debugs.

One way of reducing the impact of the debug command on a device is to use an ACL to selectively define the traffic criteria that needs to be examined. This concept does not do any packet filtering; it is used only for controlled monitoring. Example 2-9 shows a configuration that enables debugging only for packets between the hosts 10.1.1.1 and 192.168.1.1 using the debug ip packet [detail] <ACL-number> command.

Example 2-9. Debugging Traffic Using ACL Example

Router(config)# access-list 101 permit ip host 10.1.1.1 host 192.168.1.1 Router(config)# access-list 101 permit ip host 192.168.1.1 host 10.1.1.1 Router(config)# end Router# debug ip packet detail 101 IP packet debugging is on (detailed) for access list 101