ACL Fundamentals
ACLs provide packet filtering for routers and firewalls to protect internal networks from the outside world. ACLs filter network traffic in both directions by controlling whether to forward or block packets at the router interfaces based on the criteria that you specify within the ACLs. ACL criteria could be the source address of the traffic, the destination address of the traffic, the upper-layer protocol, or other information. Be aware, however, that sophisticated users (hackers) can sometimes successfully evade or fool basic ACLs because not only is authentication not required, but mainly because of the inability of an ACL to track the state of a connection.
ACLs provide a basic level of security for accessing your network. If you do not configure ACLs on your router, all packets passing through the router could get to all parts of your network. You can use ACLs on a router that is positioned between two parts of your network to control traffic entering or exiting a specific part of your internal network. An ACL on the router allows one host to access a part of your network and prevents another host from accessing the same area. The ACL shown in Figure 3-12 allows Host A to access the Human Resources network but prevents Host B from accessing the Human Resources network.
To provide the security benefits of ACLs, you should, at a minimum, configure ACLs at the perimeter of your networks. This configuration provides a basic buffer from the outside network, or from a less-controlled area of your own network, into a more sensitive area of your network. On these network edge routers, you should configure ACLs for each network protocol that is configured on the router interfaces.
You can use ACLs to mitigate many threats:
-
IP address spoofing (inbound)
-
IP address spoofing (outbound)
-
DoS TCP SYN attacks (blocking external attacks)
-
DoS TCP SYN attacks (using TCP intercept)
-
DoS Smurf attacks
-
Filtering ICMP messages (inbound)
-
Filtering ICMP messages (outbound)
-
Filtering traceroute
Cisco routers use ACLs as packet filters to decide which packets can access a router service or cross an interface. Packets that are allowed across an interface are permitted packets. Packets that are not allowed across an interface are denied packets.
An ACL enforces one or more corporate security policies. For example, a corporate security policy might only allow packets using source addresses from within the trusted network to access the Internet. Once this policy is written, you can develop an ACL that includes certain statements that, when applied to a router interface, can implement this policy.
Cisco router security depends strongly on well-written ACLs to restrict access to router network services and to filter packets as they traverse the router.
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 itself. Instead, ACLs are statements that specify conditions of how the router handles the traffic flow through specified interfaces.
ACLs operate in two ways:
-
Inbound: 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 then processed for routing.
-
Outbound: Packets arriving on the inside interface are routed to the outbound interface, and then they are processed through the outbound ACL.
Figure 3-13 shows an example of an outbound ACL. When a packet enters an interface, the router checks the routing table to see whether 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 operation 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 whether the packet is routable. If the packet is not routable, the router drops the packet. Figure 3-14 shows an example of an inbound ACL.
Examples of inbound ACL operation are as follows:
-
If the inbound interface is E0, which has not been grouped to an inbound ACL, the packet is processed normally and the router checks to determine whether the packet is routable.
-
If the inbound interface is E1, which has been grouped to an inbound ACL, the packet is not processed and the routing table is not consulted until the packet is tested by the ACL that is associated with that interface. Based on the ACL tests, the packet is permitted or denied.
For inbound lists, permit means to continue to process the packet after receiving it on an inbound interface, and deny means to discard the packet.
| Note | If encryption is used, the inbound ACL is checked first to see whether the encryption traffic is permitted. If permitted, the traffic is then decrypted and again compared to the ACL. |
ACL statements operate in a sequential, logical order, as shown in Figure 3-15. 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.
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.
Types of IP ACLs
Cisco routers support two types of IP ACLs:
-
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 allows administrators more flexibility and control.
The two general methods you can use to create ACLs are as follows:
Before Cisco IOS Software Release 11.2, you had to assign a number to each ACL as you created it. Since then, either a number or a name can identify Cisco ACLs and the protocols that they filter.
Using numbered ACLs is an effective method on smaller networks with more homogeneously defined traffic. Because each ACL type is limited to an assigned range of numbers, it is easy to determine the type of ACL that you are using.
Specifying an ACL number from 1 to 99 or 1300 to 1999 instructs the router to accept numbered standard IP Version 4 (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.
The named ACL feature allows you to identify IP standard and extended ACLs with an alphanumeric string (name) rather than the numeric representations. Named IP ACLs provide you more flexibility in working with the ACL entries.
| Tip | The number of the ACL determines which protocol it is filtering. 1 to 99 and 1300 to 1999 define standard IP ACLs. 100 to 199 and 2000 to 2699 define extended IP ACLs. Named ACLs have been available since Cisco IOS Software Releases 11.2. Names contain alphanumeric characters. Names cannot contain spaces or punctuation and must begin with an alphabetic character. Named ACLs enable you to add or delete entries within the ACL. |
There are several benefits to IP access list entry sequence numbering:
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. This means that should you deny a protocol, for example, but then decide to add a permit statement for a specific host who needs to use that protocol, this new permit statement would be placed below the deny statement stipulating that all traffic for that application be denied. With older versions, it is a question of first match, not necessarily best match.
IP access list entry sequence numbering is a new edition to Cisco IOS Software that allows you to use sequence numbers to easily add, remove, or reorder statements in an IP ACL. With Cisco IOS Release 12.3 and later, you can place additions anywhere in the ACL based on the sequence number, providing that you use an unused sequence number. You might need to resequence your access list if you need to create unused sequence numbers.
Earlier than Cisco IOS Release 12.3, only named ACLs allow the removal of individual statements from an ACL using the no{deny | permit} protocol source source-wildcard destination destination-wildcard command, where 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 re-create 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 with consideration for its top-down process. 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.
-
If you apply an ACL to an interface, the ACL filters traffic going through the router, but does not filter traffic that the router generates. You can apply ACLs on the router in other ways that will affect the traffic that the router generates, such as using the access-class command to control the traffic in and out of vty ports, which will be discussed later.
-
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 for the source to reach intermediary networks.
| Note | ACLs that are applied to an interface do not filter traffic that is generated by the router. |
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:
| Note | A wildcard mask is sometimes referred to as an inverse mask. Be aware, however, that you should use regular subnet masks if you are configuring ACLs on a PIX and ASA. |
Figure 3-16 illustrates how wildcard bits are used to check the corresponding address bits.
By carefully setting wildcard masks, you can permit or deny tests with one ACL statement. You can select a single IP address or any IP address.
Example: Wildcard Masking Process for IP Subnets
In Figure 3-17, 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.
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.
First, 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, shown in bold, 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, shown in gray, 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 any other subnets.
In Figure 3-17, 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.
So, suppose that you want to block all IP traffic from the range of subnets of Figure 3-17, the access list could be this:
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.
Example: Wildcard Masking Process with a Single IP Address
In Figure 3-18, 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. The command syntax using the abbreviation host is as follows:
And this is the same as entering the following:
Should you enter the full host mask of 0.0.0.0, the router will convert the command for the host abbreviation automatically.
Example: Wildcard Masking Process with a Match Any IP Address
In Figure 3-19, 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. The command syntax using the keyword any is as follows:
And this is the same as entering the following:
| Tip | As a matter of fact, you can enter any valid host IP address, followed by the wildcard mask of 255.255.255.255 and the router will convert your entry to the keyword any, as demonstrated by the following test: |
Using ACLs to Control Traffic
To configure numbered standard IPv4 ACLs on a Cisco router, you must create a standard IPv4 ACL and activate an ACL on an interface. The access-list command creates an entry in a standard IPv4 traffic filter list.
The following is the syntax for the access-list command:
To create an access list, use 1 to 99 for the access-list-number parameter. The first entry is assigned a sequence number of 10, and successive entries are incremented by 10. The default wildcard mask is 0.0.0.0 (only standard ACL). The remark argument lets you add a description to the ACL.
| Caution | The no access-list access-list-number command removes the entire ACL. |
The log option of the access-list command causes an informational logging message about the packet that matches the ACL entry to be sent to the console.
| Tip | You control the level of messages that are logged to the console using the logging console command. You can also have the messages kept in buffer with the logging buffered command. The number of system error and debugging messages in the system logging buffer is determined by the configured size of the syslog buffer. This size of the syslog buffer is also set using the logging buffered command. |
The logging message includes the ACL number, whether the packet was permitted or denied, the source address, and the number of packets. The message is generated for the first packet that matches, and then at five-minute intervals, including the number of packets permitted or denied in the previous five-minute interval.
The ip access-group command links an existing ACL to an interface. Only one ACL per protocol, per direction, and per interface is allowed. The syntax for this command is as follows:
| Note | To remove an IP ACL from an interface, first enter the no ip access-group command on the interface; then enter the global no access-list command to remove the entire ACL. |
Table 3-2 provides an example of the steps required to configure and apply a numbered standard ACL on a router.
Table 3-2: Numbered Standard ACL Configuration Procedure
Open table as spreadsheet | Step | Action | Notes |
| 1. | Use the access-list global configuration command to create an entry in a standard IPv4 ACL: | Enter the global no access-list access-list-number command to remove the entire ACL. |
| | | The example statement matches any address that starts with 172.16.x.x. |
| | | Use the remark option to add a description to your ACL. |
| 2. | Use the interface configuration command to select an interface to which to apply the ACL: | After you enter the interface command, the command-line interface (CLI) prompt changes from (config)# to (config-if)#. |
| 3. | Use the ip access-group interface configuration command to activate the existing ACL on an interface: | To remove an IP ACL from an interface, enter the no ip access-group access-list-number command on the interface. |
| | | This example activates the standard IPv4 ACL 1 on the interface as an outbound filter. |
Example: Numbered Standard IPv4 ACL: Deny a Specific Subnet
Table 3-3 describes the command syntax that is presented in Example 3-1 for the network topology shown in Figure 3-20.
Table 3-3: Numbered Standard IPv4 ACL Example
Open table as spreadsheet | access-list Command Parameters | Description |
| 1 | ACL number that indicates this ACL is a standard list. |
| deny | Indicates that traffic that matches the selected parameters is not forwarded. |
| 172.16.4.0 | IP address of the source subnet. |
| 0.0.0.255 | Wildcard mask; 0s indicate positions that must match, 1s indicate “don’t care” positions. |
| | The mask with 0s in the first three octets indicates those positions must match; the 255 in the last octet indicates a “don’t care” condition. |
| permit | Indicates that traffic that matches the selected parameters is forwarded. |
| any | Abbreviation for the IP address of the source. The abbreviation any indicates a source address of 0.0.0.0 and a wildcard mask of 255.255.255.255; all source addresses will match. |
vty Access
To control traffic into and out of the router (not through the router), you protect the router virtual ports. A virtual port (or virtual terminal line) is commonly referred to as vty. By default, there are five such virtual terminal lines, numbered vty 0 through vty 4. You can configure Cisco IOS Software images to support more than five vty ports.
Restricting vty access is primarily a technique for increasing network security and defining which addresses are allowed Telnet access to the router EXEC process.
The command used to filter Telnet traffic is as follows:
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 IP ACL statements to control vty access.
In Example 3-2, you are permitting any device on network 192.168.1.0 0.0.0.255 to establish a virtual terminal session with the router. Of course, the user must know the appropriate passwords to enter user mode and privileged mode. In Example 3-2, we can only assume that the protocol used to exchange with the router is Telnet; however, other protocol can be filtered by the access-class command, such as Secure Shell (SSH).
Numbered Extended IPv4 ACL
Use extended IPv4 ACLs, which are named or numbered 100 to 199 and 2000 to 2699, to provide more precise traffic-filtering control, because extended IPv4 ACLs check for the source and destination IPv4 address. In addition, with an extended ACL statement, you can specify the protocol and optional TCP or UDP application to filter traffic more precisely. To specify an application, you can configure either the port number or name of a well-known application.
Table 3-4 shows some well-known port numbers of IP protocols that you can use with extended access lists.
Table 3-4: Well-Known Port Numbers and IP Protocols
Open table as spreadsheet | Well-Known Port Number (Decimal) | IP Protocol |
| 20 (TCP) | FTP data |
| 21 (TCP) | FTP control |
| 23 (TCP) | Telnet |
| 25 (TCP) | SMTP |
| 53 (TCP/UDP) | DNS |
| 69 (UDP) | TFTP |
| 80 (TCP) | HTTP |
To configure numbered extended IPv4 ACLs on a Cisco router, create an extended IPv4 ACL and activate that ACL on an interface. Use the access-list command to create an entry to express a condition statement in a complex filter. Table 3-5 explains the syntax of the command for configuring a numbered extended ACL shown here:
Table 3-5: Command Parameters for a Numbered Extended ACL
Open table as spreadsheet | access-list Command Parameters | Description |
| access-list-number | This parameter identifies the list using a number in the ranges of 100 to 199 or 2000 to 2699. |
| permit | deny | This parameter indicates whether this entry allows or blocks the specified address. |
| protocol | The protocol parameter can be IP, TCP, UDP, ICMP, GRE, or IGRP. |
| source and destination | These parameters identify the source and destination IP addresses. |
| source-wildcard and destination-wildcard | In the wildcard mask, 0s indicate positions that must match, 1s indicate “don’t care” positions. |
| operator [port | app_name] | The operator can be lt (less than), gt (greater than), eq (equal), neq (not equal). The port number referenced can be either the source port or the destination port, depending on where in the ACL the port number is configured. As an alternative to the port number, well-known application names can be used (for example, telnet, ftp, smtp). |
| established | This option is for inbound TCP only. It allows TCP traffic to pass if the packet is a response to an outbound initiated session. This type of traffic has the acknowledgment (ACK) bits set. (See Example 3-4.) |
| log | This option sends a logging message to the console. |
| Note | The syntax of the access-list command that is presented in Table 3-5 is representative of the TCP protocol form. Not all parameters and options are given. For the complete syntax of all forms of the command, refer to the appropriate Cisco IOS Software documentation available at Cisco.com. |
To link an existing extended ACL to an interface, use the following command:
Only one ACL per protocol, per direction, and per interface is allowed.
Table 3-6 describes the parameters of the ip access-group command.
Table 3-6: ip access-group Command Parameters
Open table as spreadsheet | Parameter | Description |
| access-list-number | Indicates the number of the ACL that is to be linked to an interface |
| in | out | Selects whether the ACL is applied as an input or output filter; out is default |
Example 3-3 shows the configuration for denying FTP access from subnet 172.16.4.0/24 to subnet 172.16.3.0/24, for the network depicted in Figure 3-21. All other traffic is allowed. By applying the ACL to the E0 interface in an outbound direction, traffic is dropped just before it would be transmitted out the E0 interface.
Example 3-3: Numbered Extended IPv4 ACL Example
r1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21
r1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 20
r1(config)# access-list 101 permit ip any any
(implicit deny all)
(access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255)
r1(config)# interface ethernet 0
r1(config-if)# ip access-group 101 out
In Example 3-4, the established parameter of the extended ACL allows responses to traffic that originate from the mail host, 200.1.1.2, to return inbound on the serial 0 interface. 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. Without the established parameter in the ACL statement, the mail host could only receive SMTP traffic but not send it.
| Caution | ACLs using the keyword established are not a substitute of stateful firewall. The ACL only checks whether the established flag bit is turned on in the TCP header, without reference to other prior transmission. In other words, as long as the established bit is turned on and the other filtering criteria mentioned in the ACL entry are valid, the router will execute the action. It will not check to determine whether a proper TCP three-way handshake was done. It is therefore easy to fool the router using a packet-crafting tool. |
Example 3-4: Using the established Keyword
Router(config)# access-list 102 permit tcp any host 200.1.1.2 established
Router(config)# access-list 102 permit tcp any host 200.1.1.2 eq smtp
Router(config)# interface serial 0
Router(config-if)# ip access-group 102 in
Displaying ACLs
When you finish the ACL configuration, use the show commands to verify the configuration. Use the show access-lists command to display the contents of all ACLs, as shown in Example 3-5. By entering the ACL name or number as an option for this command, you can display a specific ACL. To display the contents of only the IP ACLs, use the show ip access-list command.
No comments:
Post a Comment