ACLs

An ACL is a sequential list of permit or deny statements that apply to addresses or upper-layer protocols. ACLs provide a powerful way to control traffic into and out of your network. You can configure ACLs for all routed network protocols. The most important reason to configure ACLs is to provide security for your network. ACLs enable you to control traffic into and out of your network. This control can be as simple as permitting or denying network hosts or addresses. However, ACLs can also be configured to control network traffic based on the TCP port being used

 

Packet Filtering

Packet filtering, sometimes called static packet filtering, controls access to a network by analyzing the incoming and outgoing packets and passing or halting them based on stated criteria. A router acts as a packet filter when it forwards or denies packets according to filtering rules. When a packet arrives at the packet-filtering router, the router extracts certain information from the packet header and makes decisions according to the filter rules as to whether the packet can pass through or be discarded. As a Layer 3 device, a packet-filtering router uses rules to determine whether to permit or deny traffic based on source and destination IP addresses, source port and destination port, and the protocol of the packet. The ACL can extract the following information from the packet header, test it against its rules, and make "allow" or "deny" decisions based on:

• Source IP address
• Destination IP address
• ICMP message type

The ACL can also extract upper layer information and test it against its rules. Upper layer information includes:

• TCP/UDP source port
• TCP/UDP destination port

What's an ACL?

An ACL is a router configuration script that controls whether a router permits or denies packets to pass based on criteria found in the packet header. As each packet comes through an interface with an associated ACL, the ACL is checked from top to bottom, one line at a time, looking for a pattern matching the incoming packet. The ACL enforces one or more corporate security policies by applying a permit or deny rule to determine the fate of the packet. By default, a router does not have any ACLs configured and therefore does not filter traffic. Traffic that enters the router is routed according to the routing table.

The Three Ps

A general rule for applying ACLs on a router can be recalled by remembering the three Ps. You can configure one ACL per protocol, per direction, per interface:

• One ACL per protocol-To control traffic flow on an interface, an ACL must be defined for each protocol enabled on the interface.
• One ACL per direction-ACLs control traffic in one direction at a time on an interface. Two separate ACLs must be created to control inbound and outbound traffic. 
• One ACL per interface-ACLs control traffic for an interface

ACLs perform the following tasks:

• Limit network traffic to increase network performance
• Provide traffic flow control. ACLs can restrict the delivery of routing updates.
• Provide a basic level of security for network access.
• Decide which types of traffic to forward or block at the router interfaces
• Control which areas a client can access on a network. 
• Screen hosts to permit or deny access to network services.

 How ACLs Work

ACLs define 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 itself.

ACLs are configured either to apply to inbound traffic or to apply to outbound traffic.

• Inbound ACLs-Incoming packets are processed before they are routed to the outbound interface. An inbound ACL is efficient because it saves the overhead of routing lookups if the packet is discarded. If the packet is permitted by the tests, it is then processed for routing.

• Outbound ACLs-Incoming packets are routed to the outbound interface, and then they are processed through the outbound ACL

ACL statements operate in sequential order. They evaluate packets against the ACL, from the top down, one statement at a time. 

The Implied "Deny All Traffic" Criteria Statement

At the end of every access list is an implied "deny all traffic" criteria statement. It is also sometimes referred to as the "implicit deny any" statement. Therefore, if a packet does not match any of the ACL entries, it is automatically blocked. The implied "deny all traffic" is the default behavior of ACLs and cannot be changed.

Types of Cisco ACLs

There are two types of Cisco ACLs, standard and extended.

Standard ACLs

Standard ACLs allow you to permit or deny traffic from source IP addresses. The destination of the packet and the ports involved do not matter. The example allows all traffic from network 192.168.30.0/24 network. Because of the implied "deny any" at the end, all other traffic is blocked with this ACL. Standard ACLs are created in global configuration mode.

Extended ACLs

Extended ACLs filter IP packets based on several attributes, for example, protocol type, source and destination IP address, destination IP address, source TCP or UDP ports, destination TCP or UDP ports, and optional protocol type information for finer granularity of control. In the figure, ACL 103 permits traffic originating from any address on the 192.168.30.0/24 network to any destination host port 80 (HTTP). Extended ACLs are created in global configuration mode.

Numbering and Naming ACLs

Using numbered ACLs is an effective method for determining the ACL type on smaller networks with more homogeneously defined traffic. However, a number does not inform you of the purpose of the ACL. This course focuses only on IP ACLs. For example, numbers 600 to 699 are used by AppleTalk, and numbers 800 to 899 are used by IPX.

Where to Place ACLs

Where you place ACLs can reduce unnecessary traffic. For example, traffic that will be denied at a remote destination should not use network resources along the route to that destination.

Every ACL should be placed where it has the greatest impact on efficiency. The basic rules are:

• Locate extended ACLs as close as possible to the source of the traffic denied. This way, undesirable traffic is filtered without crossing the network infrastructure.
• Because standard ACLs do not specify destination addresses, place them as close to the destination as possible.

In the figure, the administrator wants to prevent traffic originating in the 192.168.10.0/24 network from getting to the 192.168.30.0/24 network. An ACL on the outbound interface of R1 denies R1 the ability to send traffic to other places as well. The solution is to place a standard ACL on the inbound interface of R3 to stop all traffic from the source address192.168.10.0/24. A standard ACL meets the needs because it is only concerned with source IP addresses.

Consider that administrators can only place ACLs on devices that they control. Therefore, placement must be determined in the context of where the control of the network administrator extends. In this figure, the administrator of the 192.168.10.0/24 and 192.168.11.0/24 networks (referred to as Ten and Eleven, respectively, in this example) wants to deny Telnet and FTP traffic from Eleven to the 192.168.30.0/24 network (Thirty, in this example). At the same time, other traffic must be permitted to leave Ten.

There are several ways to do this. An extended ACL on R3 blocking Telnet and FTP from Eleven would accomplish the task, but the administrator does not control R3. That solution also still allows unwanted traffic to cross the entire network, only to be blocked at the destination. This affects overall network efficiency.

One solution is to use an outbound extended ACL that specifies both source and destination addresses (Eleven and Thirty, respectively), and says, "Telnet and FTP traffic from Eleven is not allowed to go to Thirty." Place this extended ACL on the outbound S0/0/0 port of R1.

A disadvantage of this solution is that traffic from Ten would also be subject to some processing by the ACL, even though Telnet and FTP traffic is allowed.

The better solution is to move closer to the source and place an extended ACL on the inbound Fa0/2 interface of R1. This ensures that packets from Eleven do not enter R1, and subsequently cannot cross over into Ten, or even enter R2 or R3. Traffic with other destination addresses and ports is still permitted through R1.

Configuring Standard ACLs

To configure numbered standard ACLs on a Cisco router, you must first create the standard ACL and then activate the ACL on an interface.

The access-list global configuration command defines a standard ACL with a number in the range of 1 to 99. Cisco IOS Software Release 12.0.1 extended these numbers by allowing 1300 to 1999 to provide a maximum of 799 possible standard ACLs. These additional numbers are referred to as expanded IP ACLs.

The full syntax of the standard ACL command is as follows:

Router(config)#access-list access-list-number [deny | permit | remark] source [source-wildcard] [log]

The full syntax of the standard ACL command to filter a specific host is as follows:

Router(config)#access-list access-list-number [deny | permit] source [log]

 
For example, to create a numbered ACL designated 10 that would permit network 192.168.10.0 /24, you would enter:

R1(config)#access-list 10 permit 192.168.10.0 0.0.0.255

The no form of this command removes a standard ACL. The command show access-list displays the current ACLs configured on router R1. To remove the ACL, the global configuration no access-list command is used.

When an ACL is revisited at a later time, it may no longer as obvious as it once was. The remark keyword is used for documentation and makes access lists a great deal easier to understand. Each remark is limited to 100 characters.

Wildcard Masking

ACLs statements include masks, also called wildcard masks. A wildcard mask is a string of binary digits telling the router which parts of the subnet number to look at. Although wildcard masks have no functional relationship with subnet masks, they do provide a similar function. The mask determines how much of an IP source or destination address to apply to the address match. The numbers 1 and 0 in the mask identify how to treat the corresponding IP address bits.

Wildcard masks and subnet masks are both 32 bits long and use binary 1s and 0s. Subnet masks use binary 1s and 0s to identify the network, subnet, and host portion of an IP address. Wildcard masks use binary 1s and 0s to filter individual or groups of IP addresses to permit or deny access to resources based on an IP address. By carefully setting wildcard masks, you can permit or deny a single or several IP addresses. Wildcard masks use the following rules to match binary 1s and 0s:

• Wildcard mask bit 0 - Match the corresponding bit value in the address
• Wildcard mask bit 1 - Ignore the corresponding bit value in the address

Note: Wildcard masks are often referred to as an inverse mask. The reason is that, unlike a subnet mask in which binary 1 is equal to a match and binary 0 is not a match, the reverse is true. 

Working with decimal representations of binary wildcard mask bits can be tedious. To simplify this task, the keywords host and any help identify the most common uses of wildcard masking. These keywords eliminate entering wildcard masks when identifying a specific host or network. They also make it easier to read an ACL by providing visual clues as to the source or destination of the criteria.

• The host option substitutes for the 0.0.0.0 mask. This mask states that all IP address bits must match or only one host is matched.
• The any option substitutes for the IP address and 255.255.255.255 mask. This mask says to ignore the entire IP address or to accept any addresses.

Applying Standard ACLs to Interface

After a standard ACL is configured, it is linked to an interface using the ip access-group command:

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

To remove an ACL from an interface, first enter the no ip access-group command on the interface, and then enter the global no access-list command to remove the entire ACL.

This ACL allows only traffic from source network 192.168.10.0 to be forwarded out on S0/0/0. Traffic from networks other than 192.168.10.0 is blocked.

The first line identifies the ACL as access list 1. It permits traffic that matches the selected parameters. In this case, the IP address and wildcard mask identifying the source network is 192.168.10.0 0.0.0.255. Recall that there is an unseen implicit deny all statement that is equivalent to adding the line access-list 1 deny 0.0.0.0 255.255.255.255.

The ip access-group 1 out interface configuration command links and ties ACL 1 to the Serial 0/0/0 interface as an outbound filter.

Therefore, ACL 1 only permits hosts from the 192.168.10.0 /24 network to exit router R1. It denies any other network including the 192.168.11.0 network.

This ACL replaces the previous example, but also blocks traffic from a specific address. The first command deletes the previous version of ACL 1. The next ACL statement, denies the PC1 host located at 192.168.10.10. Every other host on the 192.168.10.0 /24 network is permitted. Again the implicit deny statement matches every other network.

The ACL is again reapplied to interface S0/0/0 in an outbound direction.

This ACL replaces the previous example but still blocks traffic from the host PC1. It also permits all other LAN traffic to exit from router R1.

The first two commands are the same as the previous example. The first command deletes the previous version of ACL 1 and the next ACL statement denies the PC1 host located at 192.168.10.10.

The third line is new and permits all hosts from the 192.168.x.x /16 networks. This now means that all hosts from the 192.168.10.0 /24 network still match but now the hosts from the 192.168.11.0 network also match.

The ACL is again reapplied to interface S0/0/0 in an outbound direction. Therefore, both LANs attached to router R1 may exit the S0/0/0 interface with the exception of the PC1 host.

Using an ACL to Control VTY Access

Restricting VTY access is a technique that allows you to define which IP addresses are allowed Telnet access to the router EXEC process. You can control which administrative workstation or network manages your router with an ACL and an access-class statement to your VTY lines. You can also use this technique with SSH to further improve administrative access security.

The access-class command in line configuration mode restricts incoming and outgoing connections between a particular VTY (into a Cisco device) and the addresses in an access list.

Standard and extended access lists apply to packets that travel through a router. They are not designed to block packets that originate within the router. An outbound Telnet extended ACL does not prevent router-initiated Telnet sessions, by default.

Filtering Telnet traffic is typically considered an extended IP ACL function because it filters a higher level protocol. However, because you are using the access-class command to filter incoming or outgoing Telnet sessions by source address and apply filtering to VTY lines, you can use standard ACL statements to control VTY access.

The command syntax of the access-class command is:

access-class access-list-number {in [vrf-also] | out}

The parameter in restricts incoming connections between a particular Cisco device and the addresses in the access list, while the parameter out restricts outgoing connections between a particular Cisco device and the addresses in the access list.

An example allowing VTY 0 and 4 is shown in the figure. For example, the ACL in the figure is configured to permit networks 192.168.10.0 and 192.168.11.0 access to VTYs 0 - 4. All other networks are denied access to the VTYs.

Editing Numbered ACLs

When configuring an ACL, the statements are added in the order that they are entered at the end of the ACL. However, there is no built-in editing feature that allows you to edit a change in an ACL. You cannot selectively insert or delete lines. It is strongly recommended that any ACL be constructed in a text editor such as Microsoft Notepad.

You can use the remark keyword to include comments (remarks) about entries in any IP standard or extended ACL. The remarks make the ACL easier for you to understand and scan. Each remark line is limited to 100 characters.

The remark can go before or after a permit or deny statement. You should be consistent about where you put the remark so that it is clear which remark describes which permit or deny statement. For an entry in a named ACL, use the remark configuration command. To remove the remark, use the no form of this command.

Creating Standard Named ACLs

Naming an ACL makes it easier to understand its function. For example, an ACL to deny FTP could be called NO_FTP. When you identify your ACL with a name instead of with a number, the configuration mode and command syntax are slightly different.

The figure shows the steps to create a standard named ACL.

In the figure, the screen output shows the commands used to configure a standard named ACL on router R1, interface Fa0/0 that denies host 192.168.11.10 access to the 192.168.10.0 network.

When you finish an ACL configuration, use Cisco IOS show access-lists command:

Editing Named ACLs

Named ACLs have a big advantage over numbered ACLs in that they are easier to edit. Starting with Cisco IOS Software Release 12.3, named IP ACLs allow you to delete individual entries in a specific ACL. You can use sequence numbers to insert statements anywhere in the named ACL. If you are using an earlier Cisco IOS software version, you can add statements only at the bottom of the named ACL. Because you can delete individual entries, you can modify your ACL without having to delete and then reconfigure the entire ACL.

 

Extended ACLs

For more precise traffic-filtering control, you can use extended ACLs numbered 100 to 199 and 2000 to 2699 providing a total of 800 possible extended ACLs. Extended ACLs can also be named.  Like standard ACLs, extended ACLs check the source packet addresses, but they also check the destination address, protocols and port numbers (or services).

The figure shows some examples of how an administrator specifies a TCP or UDP port number by placing it at the end of the extended ACL statement. Logical operations can be used, such as equal (eq), not equal (neq), greater than (gt), and less than (lt).

Configuring Extended ACLs

The procedural steps for configuring extended ACLs are the same as for standard ACLs, you first create the extended ACL and then activate it on an interface.

The figure shows an example of how you might create an extended ACL specific to your network needs. In this example, the network administrator needs to restrict Internet access to allow only website browsing. ACL 103 applies to traffic leaving the 192.168.10.0 network, and ACL 104 to traffic coming into the network.

ACL 103 accomplishes the first part of the requirement. It allows traffic coming from any address on the 192.168.10.0 network to go to any destination, subject to the limitation that traffic goes to ports 80 (HTTP) and 443 (HTTPS) only.

The nature of HTTP requires that traffic flow back into the network, but the network administrator wants to restrict that traffic to HTTP exchanges from requested websites. The security solution must deny any other traffic coming into the network. ACL 104 does that by blocking all incoming traffic, except for the established connections. HTTP establishes connections starting with the original request and then through the exchange of ACK, FIN, and SYN messages.

Notice that the example uses the established parameter.

This parameter allows responses to traffic that originates from the 192.168.10.0 /24 network to return inbound on the s0/0/0. A match occurs if the TCP datagram has the ACK or reset (RST) bits set, which indicates that the packet belongs to an existing connection. With the established parameter, the router will allow only the established traffic to come back in and block all other traffic.

Applying Extended ACLs to Interface

Let us learn how to configure an extended access list by building on the previous example. Recall that we want to allow users to browse both insecure and secure websites. First consider whether the traffic you want to filter is going in or out. Trying to access websites on the Internet is traffic going out. Receiving e-mails from the Internet is traffic coming into the business. However, when considering how to apply an ACL to an interface, in and out take on different meanings depending on the point of view.

In the example in the figure, R1 has two interfaces. It has a serial port, S0/0/0, and a Fast Ethernet port, Fa0/0. The Internet traffic coming in is going in the S0/0/0 interface, but is going out the Fa0/0 interface to reach PC1. The example applies the ACL to the serial interface in both directions.

This is an example of denying FTP traffic from subnet 192.168.11.0 going to subnet 192.168.10.0, but permitting all other traffic. Note the use of wildcard masks. Remember that FTP requires ports 20 and 21, therefore you need to specify both eq 20 and eq 21 to deny FTP.

With extended ACLs, you can choose to use port numbers as in the example, or to call out a well-known port by name.

This example denies Telnet traffic from 192.168.11.0, but allows all other IP traffic from any other source to any destination inbound on Fa0/1. Note the use of the any keywords, meaning from anywhere going to anywhere.

Creating Named Extended ACLs

You can create named extended ACLs in essentially the same way you created named standard ACLs. The commands to create a named ACL are different for standard and extended ACLs.

To remove a named extended ACL, use the no ip access-list extended name global configuration command.

Types of Complex ACLs

Standard and extended ACLs can become the basis for complex ACLs that provide additional functionality. The table in the figure summarizes the three categories of complex ACLs.

Dynamic ACLs

Lock-and-key is a traffic filtering security feature that uses dynamic ACLs, which are sometimes referred to as lock-and-key ACLs. Lock-and-key is available for IP traffic only. Dynamic ACLs are dependent on Telnet connectivity, authentication (local or remote), and extended ACLs.

Dynamic ACL 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 that exists. This permits traffic for a particular period; idle and absolute timeouts are possible.

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

• Use of a challenge mechanism to authenticate individual users.
• Simplified 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.

 

 Reflexive ACLs

Reflexive ACLs force the reply traffic from the destination of a known recent outbound packet to go to the source of that outbound packet. This adds greater control to what traffic you allow into your network and increases the capabilities of extended access lists.

Network administrators use reflexive ACLs to allow IP traffic for sessions originating from their network while denying IP traffic for sessions originating outside the network. These ACLs allow the router to manage session traffic dynamically. The router examines the outbound traffic and when it sees a new connection, it adds an entry to a temporary ACL to allow replies back in. 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 provide a truer form of session filtering than an extended ACL that uses the established parameter introduced earlier. Although similar in concept to the established parameter, reflexive ACLs also work for UDP and ICMP, which have no ACK or RST bits. The established option also does not work with applications that dynamically alter the source port for the session traffic. The permit established statement only checks ACK and RST bits, not source and destination address.

Reflexive ACLs are not applied directly to an interface but are "nested" within an extended named IP ACL that is applied to the interface.

Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named ACLs or with other protocol ACLs. Reflexive ACLs have the following benefits:

• Help secure your network against network hackers and can be included in a firewall defense.
• Provide a level of security against spoofing and certain DoS attacks.
• Simple to use and, compared to basic ACLs, provide greater control over which packets enter your network.

 

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. You identify the time range with a name and then refer to it by a function. The time restrictions are imposed on the function itself.

Time-based ACLs have many benefits, such as:

• Offers the network administrator more control over permitting or denying access to resources.
• Allows network administrators to control logging messages. ACL entries can log traffic at certain times of the day, but not constantly.