Extended ACLs in Depth: From Numbered ACLs to Protocol Matching

Introduction to Extended ACLs

Access Control Lists (ACLs) are a crucial component in network security and management. They control the flow of traffic in and out of network interfaces, ensuring that only authorized packets are permitted while unauthorized ones are blocked. While standard ACLs are limited to filtering traffic based solely on source IP addresses, extended ACLs provide a higher degree of precision by allowing traffic to be filtered based on various attributes, including source and destination IP addresses, protocol types, and even specific TCP or UDP ports.

Extended ACLs are particularly important in environments where specific control over network traffic is required. For example, they can be used to permit or deny traffic from particular IP subnets, block certain types of traffic such as HTTP or FTP, or restrict access to sensitive parts of a network. This granular level of control makes extended ACLs an essential tool for network administrators aiming to enhance network security and performance.

In this blog post, we will explore the configuration and application of extended ACLs, examining different methods and best practices. By the end of this guide, you will have a comprehensive understanding of extended ACLs, their advantages, and how to effectively implement them in a network environment.

Numbered ACLs with Subcommands

Numbered ACLs are a fundamental aspect of Cisco IOS configurations. Traditionally, these ACLs are configured in global configuration mode using the access-list command, followed by the ACL number and the specific permit or deny conditions. This method is straightforward but can be somewhat inflexible when it comes to editing or managing extensive ACL entries.

For example, consider a simple ACL that denies traffic from a specific IP address, 192.168.1.1, while permitting all other traffic. The configuration in global config mode would look like this:

access-list 1 deny 192.168.1.1
access-list 1 permit any


This configuration is effective but lacks the flexibility needed for more complex or evolving network environments. To address this, Cisco introduced the ability to configure numbered ACLs using named ACL config mode subcommands, offering several advantages.

In named ACL config mode, you enter a dedicated configuration sub-mode that allows for more granular control over ACL entries. This approach supports the deletion of specific entries and the insertion of new entries at specified positions, which is not possible with traditional numbered ACLs. Here’s an example of configuring the same ACL using named ACL config mode:

ip access-list standard 1
deny 192.168.1.1
permit any


Despite being configured in named ACL mode, the ACL will appear in the running configuration as if it were configured using the traditional numbered method. This hybrid approach allows network administrators to benefit from the enhanced editing capabilities of named ACLs while maintaining the simplicity of numbered ACLs.

The primary advantage of using named ACL config mode for numbered ACLs is the ability to manage individual entries more effectively. For instance, if you need to remove a specific entry, you can do so without affecting the entire ACL. Additionally, you can specify sequence numbers to insert new entries at precise locations, thus avoiding the need to recreate entire ACLs when changes are required.

By leveraging the flexibility of named ACL config mode, network administrators can maintain more organized and manageable ACLs, ensuring better control over network traffic and security policies.

Advantages of Named ACL Config Mode

Named ACL (Access Control List) config mode provides several significant advantages over the traditional numbered ACL configuration method, making it a preferred choice for network administrators.

Easier Management and Editing

One of the primary benefits of named ACL config mode is the ability to delete individual ACL entries. In traditional numbered ACLs configured from global config mode, deleting an entry typically requires removing the entire ACL and reconfiguring it from scratch. This process is not only time-consuming but also prone to errors, especially with longer ACLs. In contrast, named ACL config mode allows you to remove specific entries by using the no command followed by the sequence number. For instance, no 30 would delete the entry with sequence number 30, streamlining ACL management and reducing potential disruptions in network operations.

Inserting Entries with Sequence Numbers

Named ACL config mode also enables the insertion of new entries at specific positions within an existing ACL by manually specifying sequence numbers. This feature is invaluable for maintaining the logical order and readability of ACLs. When configuring ACLs from global config mode, new entries are appended to the end, automatically receiving a sequence number 10 higher than the last entry. This default behavior can result in a disorganized and difficult-to-read ACL. With named ACL config mode, you can use sequence numbers to insert new rules exactly where they are needed, preserving the intended order and logic of the ACL. For example, if entries exist at sequence numbers 10, 20, and 40, you can insert a new rule at sequence number 30 to place it between the existing 20 and 40 entries.

Flexibility in Configuration

Named ACL config mode offers greater flexibility in ACL configuration. Administrators can switch between configuring numbered ACLs in global config mode and named ACL config mode as needed. This dual-mode capability ensures that the most appropriate configuration method can be used for different scenarios, enhancing the overall efficiency and effectiveness of ACL management. For example, you might configure a numbered ACL in global config mode for simplicity but switch to named ACL config mode for more complex editing tasks, leveraging the benefits of both methods.

Resequencing ACLs

Resequencing ACLs is a powerful method to reorganize and optimize the sequence numbers of ACL entries, enhancing both readability and manageability. This functionality is especially crucial when the initial configuration of an ACL lacks sufficient spacing between sequence numbers, making future modifications challenging.

The Importance of Resequencing

In scenarios where ACL entries are numbered consecutively (e.g., 1, 2, 3, 4), inserting new rules becomes problematic. The lack of gaps between sequence numbers leaves no room for additional entries, forcing administrators to delete and recreate the entire ACL to make changes. Resequencing addresses this issue by renumbering existing entries, providing adequate spacing for future modifications.

The Resequencing Command

The resequencing command in Cisco IOS is ip access-list resequence. This command allows administrators to specify the starting sequence number and the increment value for subsequent entries. For example, the command ip access-list resequence 1 10 10 would start the resequencing from entry 1, assigning it a sequence number of 10, and then incrementing by 10 for each following entry. This methodical renumbering ensures that ample space is available between sequence numbers, facilitating future insertions and deletions.

Practical Example

Consider an ACL with entries initially sequenced as 1, 2, 3, 4, and 5. Such a tight sequence leaves no room for additional entries. By applying the resequencing command ip access-list resequence 1 10 10, the sequence numbers are adjusted to 10, 20, 30, 40, and 50. This adjustment not only organizes the ACL more logically but also creates space for new rules to be inserted at intermediate sequence numbers (e.g., 15, 25, 35).

Consistent Application Across ACL Types

The resequencing functionality is applicable to both numbered and named ACLs, as well as to standard and extended ACLs. This versatility ensures that administrators can maintain organized and easily editable ACLs regardless of their specific use case. Whether dealing with a simple standard ACL or a complex extended ACL, the resequencing command provides a consistent and effective solution for ACL management.

Matching Based on Protocol

Extended Access Control Lists (ACLs) offer the capability to filter network traffic with a high degree of precision, a significant advantage over standard ACLs. One of the critical features of extended ACLs is their ability to match packets based on various protocols. Understanding how to leverage protocol matching effectively can significantly enhance network security and performance.

Protocol Numbers vs. Protocol Names

When configuring extended ACLs, you can match traffic based on the protocol encapsulated within the IP header. Protocols can be identified either by their protocol numbers or by their names. The protocol number is a field within the IPv4 header that specifies the protocol used in the data portion of the IP datagram.

For example:

• Protocol Numbers:
  • ICMP: 1
  • TCP: 6
  • UDP: 17
  • EIGRP: 88
  • OSPF: 89
• Protocol Names:
  • ICMP
  • TCP
  • UDP
  • EIGRP
  • OSPF

Most network engineers prefer using protocol names as they are easier to remember. However, it is beneficial to be familiar with protocol numbers as they might appear in various networking scenarios and exams, including the CCNA.

Example of Protocol-Based Matching

To demonstrate protocol-based matching, let’s consider a scenario where you need to block ICMP traffic, commonly used for ping operations. The command to achieve this in extended ACL configuration mode is as follows:

deny icmp any any


In this command:

• deny specifies that packets matching the criteria should be denied.
• icmp indicates the protocol to match.
• any any specifies that packets from any source to any destination should be matched.

This entry will block all ICMP packets from passing through the interface where this ACL is applied.

Common Protocols and Their Uses

• TCP (Transmission Control Protocol):
  • Ensures reliable, ordered, and error-checked delivery of data.
  • Used by applications such as HTTP, HTTPS, FTP, and SSH.
• UDP (User Datagram Protocol):
  • Provides a connectionless datagram service.
  • Used by applications such as DNS, TFTP, and VoIP.
• ICMP (Internet Control Message Protocol):
  • Used for diagnostic and error messages.
  • Commonly used by tools like ping and traceroute.
• EIGRP (Enhanced Interior Gateway Routing Protocol):
  • An advanced distance-vector routing protocol.
  • Used for exchanging routing information within an autonomous system.
• OSPF (Open Shortest Path First):
  • A link-state routing protocol.
  • Used for routing within an IP network, especially in large or complex networks.

Practical Configuration Example

Consider a network where you need to prevent TCP traffic from a specific subnet (192.168.10.0/24) to a web server (10.1.1.1) on port 80. The extended ACL entry for this would be:

deny tcp 192.168.10.0 0.0.0.255 host 10.1.1.1 eq 80


Breaking down the command:

• deny tcp specifies the protocol to match (TCP) and the action to take (deny).
• 192.168.10.0 0.0.0.255 specifies the source subnet and wildcard mask.
• host 10.1.1.1 specifies the exact destination IP address.
• eq 80 specifies the destination port number (HTTP).

This command will block any TCP traffic from the 192.168.10.0/24 subnet to the web server at 10.1.1.1 on port 80.

Matching Based on Source/Destination IP

Another powerful feature of extended ACLs is the ability to match traffic based on source and destination IP addresses. This feature allows network administrators to control traffic flow with fine granularity, enhancing network security and performance.

Using Wildcard Masks and Host Keywords

In extended ACLs, matching IP addresses involves specifying the source and destination addresses along with their corresponding wildcard masks. A wildcard mask is used to determine which bits of an IP address should be checked for a match.

For example, to match a specific host, you can use the host keyword followed by the IP address:

host 192.168.1.1


Alternatively, to match an entire subnet, you use the subnet address followed by the appropriate wildcard mask:

192.168.1.0 0.0.0.255


In this case, 192.168.1.0 is the subnet address, and 0.0.0.255 is the wildcard mask indicating that only the last octet can vary.

Examples of Source and Destination IP Matching

1. Denying Traffic from a Specific Host to a Network: To deny traffic from a host (192.168.1.10) to an entire network (10.0.0.0/24):
   deny ip host 192.168.1.10 10.0.0.0 0.0.0.255

2. Permitting Traffic Between Two Subnets: To permit traffic between two subnets (192.168.1.0/24 and 172.16.0.0/16):
   permit ip 192.168.1.0 0.0.0.255 172.16.0.0 0.0.255.255

3. Denying Traffic from One Subnet to Another: To deny traffic from the subnet 192.168.2.0/24 to the subnet 10.0.1.0/24:
   deny ip 192.168.2.0 0.0.0.255 10.0.1.0 0.0.0.255


Practical Configuration Example

Suppose you need to block all traffic from a network (192.168.3.0/24) to a specific server (10.2.2.2). The configuration would be:

deny ip 192.168.3.0 0.0.0.255 host 10.2.2.2


Breaking down the command:

• deny ip specifies the action (deny) and the protocol (IP, which includes all protocols).
• 192.168.3.0 0.0.0.255 specifies the source network and wildcard mask.
• host 10.2.2.2 specifies the exact destination IP address.

This command ensures that any traffic from the 192.168.3.0/24 network destined for the server at 10.2.2.2 is blocked.

Extended ACL Entry Practice

Extended ACLs offer network administrators the flexibility to enforce granular control over network traffic by specifying multiple parameters such as protocol, source IP, destination IP, and port numbers. Practicing the configuration of extended ACL entries is crucial for mastering this aspect of network management. Here, we will go through a few practical exercises to help you understand how to construct these ACL entries effectively.

Exercise 1: Permit All Traffic

The first exercise is straightforward: writing an extended ACL entry that permits all types of traffic from any source to any destination. This is often used as a default statement to ensure that, after specific restrictions are applied, the remaining traffic is allowed.

permit ip any any


Explanation:

• permit: This keyword allows traffic.
• ip: Indicates that all IP traffic, regardless of the protocol, is matched.
• any any: Specifies that traffic from any source to any destination is permitted.

Exercise 2: Deny UDP Traffic from a Specific Source

Next, let's deny all UDP traffic originating from the network 10.0.0.0/16 to a specific host 192.168.1.1/32.

deny udp 10.0.0.0 0.0.255.255 host 192.168.1.1


Explanation:

• deny: This keyword blocks traffic.
• udp: Matches UDP traffic specifically.
• 10.0.0.0 0.0.255.255: This defines the source network 10.0.0.0/16 using a wildcard mask 0.0.255.255.
• host 192.168.1.1: Specifies the exact destination host 192.168.1.1.

Exercise 3: Deny ICMP Traffic from a Specific Host

Let's create an entry to deny ICMP traffic, typically used for ping operations, from the host 172.16.1.1/32 to the subnet 192.168.0.0/24.

deny icmp host 172.16.1.1 192.168.0.0 0.0.0.255


Explanation:

• deny: Blocks the specified traffic.
• icmp: Matches ICMP traffic, commonly used for pings.
• host 172.16.1.1: Specifies the source as a single host 172.16.1.1.
• 192.168.0.0 0.0.0.255: Defines the destination network 192.168.0.0/24 with the corresponding wildcard mask.

Practical Exercise Summary

These exercises help reinforce how to write ACL entries to control network traffic precisely. Understanding how to permit or deny traffic based on different parameters is critical for effective network management. By practicing these configurations, you'll gain confidence in applying ACLs to real-world scenarios.

Matching TCP/UDP Port Numbers

Extended ACLs provide the ability to match traffic based not only on IP addresses and protocols but also on specific TCP and UDP port numbers. This feature is invaluable for creating precise and granular traffic filters. Let’s explore how to match TCP and UDP port numbers in ACL entries and review some practical examples.

Specifying Source and Destination Ports

When configuring an extended ACL, you can specify source and destination port numbers to filter traffic based on applications. This is particularly useful for allowing or blocking specific services such as HTTP, HTTPS, FTP, and more.

Matching Source Port Numbers

To match a specific TCP or UDP source port, you use the eq (equal) keyword followed by the port number. Here’s an example of how to deny traffic from a source port 80, which is commonly used by HTTP.

deny tcp any any eq 80


Explanation:

• deny: Blocks the specified traffic.
• tcp: Indicates that the rule applies to TCP traffic.
• any any: Specifies any source IP and any destination IP.
• eq 80: Matches traffic with a source port equal to 80.

Matching Destination Port Numbers

Similarly, to match traffic based on the destination port, you specify the port number after the destination IP address. For example, to permit traffic destined for port 443 (HTTPS):

permit tcp any host 192.168.1.1 eq 443


Explanation:

• permit: Allows the specified traffic.
• tcp: Applies to TCP traffic.
• any: Any source IP address.
• host 192.168.1.1: Specifies the destination host IP.
• eq 443: Matches traffic with a destination port equal to 443.

Other Port Matching Options

Extended ACLs offer additional options to match ports beyond the eq keyword. These include:

• gt (greater than): Matches ports greater than a specified number.
• lt (less than): Matches ports less than a specified number.
• neq (not equal): Matches ports not equal to a specified number.
• range: Matches ports within a specified range.

Examples:

1. Match Ports Greater Than a Specific Port: Explanation: Denies UDP traffic with source ports greater than 1023.
   deny udp any any gt 1023

2. Match Ports Less Than a Specific Port: Explanation: Permits TCP traffic with source ports less than 1024.
   permit tcp any any lt 1024

3. Match Ports Within a Range: Explanation: Permits TCP traffic with source ports in the range of 20 to 21 (commonly used for FTP).
   permit tcp any any range 20 21

4. Match Ports Not Equal to a Specific Port: Explanation: Denies TCP traffic with source ports not equal to 23 (commonly used for Telnet).
   deny tcp any any neq 23


Practical Example of Port Matching

Let’s configure an extended ACL entry to permit HTTP traffic from any source to a specific destination server 10.0.0.1/32, while denying all other TCP traffic to that server.

access-list 101 permit tcp any host 10.0.0.1 eq 80
access-list 101 deny tcp any host 10.0.0.1


Explanation:

• The first line permits TCP traffic to port 80 (HTTP) on the destination server 10.0.0.1.
• The second line denies all other TCP traffic to the same destination.

Extended ACL Entry Practice

Extended ACLs (Access Control Lists) provide a powerful tool for controlling network traffic. To master their use, it's crucial to practice writing and interpreting ACL entries. This section presents several practice scenarios designed to reinforce your understanding of extended ACL syntax and functionality.

Practice Scenario 1: Allow HTTPS Traffic

Requirement: Allow traffic from the network 10.0.0.0/16 to access the server at 2.2.2.2/32 using HTTPS.

Solution:

permit tcp 10.0.0.0 0.0.255.255 host 2.2.2.2 eq 443


Explanation:

• permit tcp: This indicates that the rule permits traffic using the TCP protocol.
• 10.0.0.0 0.0.255.255: This is the source network address and its corresponding wildcard mask, specifying the entire 10.0.0.0/16 subnet.
• host 2.2.2.2: This specifies the exact destination IP address.
• eq 443: This matches traffic destined for port 443, which is used by HTTPS.

Practice Scenario 2: Deny UDP Traffic from Specific Ports

Requirement: Prevent all hosts from using source UDP port numbers from 20000 to 30000 to access the server at 3.3.3.3/32.

Solution:

deny udp any range 20000 30000 host 3.3.3.3


Explanation:

• deny udp: This denies traffic using the UDP protocol.
• any: This matches any source IP address.
• range 20000 30000: This specifies the range of source port numbers to match.
• host 3.3.3.3: This specifies the exact destination IP address.

Practice Scenario 3: Allow Specific TCP Traffic

Requirement: Allow hosts in the network 172.16.1.0/24 using a TCP source port greater than 9999 to access all TCP ports on server 4.4.4.4/32 except port 23.

Solution:

permit tcp 172.16.1.0 0.0.0.255 gt 9999 host 4.4.4.4 neq 23


Explanation:

• permit tcp: This permits traffic using the TCP protocol.
• 172.16.1.0 0.0.0.255: This specifies the source network address and its corresponding wildcard mask.
• gt 9999: This matches source port numbers greater than 9999.
• host 4.4.4.4: This specifies the exact destination IP address.
• neq 23: This matches all destination ports except port 23.

These practice scenarios illustrate how to configure extended ACL entries for specific requirements. By practicing these configurations, you can gain confidence in creating effective ACLs for various networking scenarios.

Extended ACL Example

To consolidate our understanding of extended ACLs, let's apply them to a practical network scenario. We'll configure and apply extended ACLs to fulfill specific network security requirements.

Network Scenario:

Consider a network with the following requirements:

1. Hosts in the network 192.168.1.0/24 cannot use HTTPS to access the server at 10.0.1.100.
2. Hosts in the network 192.168.2.0/24 cannot access the network 10.0.2.0/24.
3. Hosts in the networks 192.168.1.0/24 and 192.168.2.0/24 cannot ping the networks 10.0.1.0/24 and 10.0.2.0/24.

Configuration Steps:

1. Deny HTTPS Traffic:

• Requirement: Hosts in 192.168.1.0/24 cannot use HTTPS to access 10.0.1.100.
• ACL Entry:

ip access-list extended DENY_HTTPS
deny tcp 192.168.1.0 0.0.0.255 host 10.0.1.100 eq 443
permit ip any any


• Explanation: This ACL denies TCP traffic from 192.168.1.0/24 to 10.0.1.100 on port 443 (HTTPS) and permits all other traffic.

2. Deny Access to Specific Network:

• Requirement: Hosts in 192.168.2.0/24 cannot access 10.0.2.0/24.
• ACL Entry:

ip access-list extended DENY_ACCESS
deny ip 192.168.2.0 0.0.0.255 10.0.2.0 0.0.0.255
permit ip any any


• Explanation: This ACL denies all IP traffic from 192.168.2.0/24 to 10.0.2.0/24 and permits all other traffic.

3. Deny ICMP (Ping) Traffic:

• Requirement: Hosts in 192.168.1.0/24 and 192.168.2.0/24 cannot ping 10.0.1.0/24 and 10.0.2.0/24.
• ACL Entry:

ip access-list extended DENY_PING
deny icmp 192.168.1.0 0.0.0.255 10.0.1.0 0.0.0.255
deny icmp 192.168.1.0 0.0.0.255 10.0.2.0 0.0.0.255
deny icmp 192.168.2.0 0.0.0.255 10.0.1.0 0.0.0.255
permit ip any any


• Explanation: This ACL denies ICMP traffic (pings) from 192.168.1.0/24 and 192.168.2.0/24 to 10.0.1.0/24 and 10.0.2.0/24 and permits all other traffic.

Applying ACLs to Interfaces:

Extended ACLs should be applied as close to the source of the traffic as possible. This minimizes unnecessary processing of packets that will ultimately be denied.

• DENY_HTTPS: Apply inbound on R1’s G0/1 interface.

interface G0/1
ip access-group DENY_HTTPS in


• DENY_ACCESS: Apply inbound on R1’s G0/2 interface.

interface G0/2
ip access-group DENY_ACCESS in


• DENY_PING: Apply outbound on R1’s G0/0 interface.

interface G0/0
ip access-group DENY_PING out


Verification:

To verify the ACLs, use the show access-lists and show ip interface commands. These commands display the ACLs applied to interfaces and their current configurations.

Example:

show access-lists
show ip interface G0/1
show ip interface G0/2
show ip interface G0/0

These commands will show detailed information about the ACLs applied and their statuses.

Conclusion

Access Control Lists (ACLs) are fundamental tools in network security, allowing for precise control of traffic flow. Extended ACLs enhance this control by filtering traffic based on various attributes such as source and destination IP addresses, protocols, and port numbers. This granularity is particularly beneficial for environments requiring specific traffic management, such as permitting or denying traffic from particular IP subnets or restricting access to sensitive network areas.

The configuration and application of extended ACLs involve defining specific rules using commands that specify the traffic type and action (permit or deny). Techniques such as using wildcard masks and sequence numbers enhance the flexibility and manageability of ACLs. Named ACL config mode offers advantages in editing and organizing ACL entries, making it easier to manage complex configurations.

Practicing ACL configurations through real-world scenarios helps in mastering the use of extended ACLs. Examples include permitting or denying traffic based on IP addresses and port numbers, ensuring network security and performance. Applying ACLs to the appropriate network interfaces and verifying their effectiveness are crucial steps in maintaining a secure network environment.

By understanding and implementing extended ACLs, network administrators can significantly improve the security and efficiency of their networks.