Chapter 7. Basic Access Lists
Chapter 6, “Access List Introduction,” introduced you to the concept of access control lists (ACLs) and their uses. An ACL most commonly is used for traffic filtering. This chapter focuses on different types of ACLs that you can use for this purpose: standard, extended, named, and timed. I also discuss some additional features of ACLs, such as ACL remarks, compiling ACLs, and sequenced ACLs.
The second half of this chapter covers some of the common types of attacks that you will face and how to use an ACL to filter this offensive traffic. I even discuss how to block some common Internet applications, such as Instant Messenger and file-sharing programs (Kazaa and the sort), to keep your users in line with work-related instead of fun-related or illegal tasks.
Types of ACLs
Since 1993, most administrators have used two basic ACLs: standard and extended ACLs. Standard IP ACLs can filter on only the source IP address in an IP packet header, whereas an extended IP ACL can filter on the following:
• Source IP address
• Destination IP address
• TCP/IP protocol, such as IP (all TCP/IP protocols), ICMP, OSPF, TCP, UDP, and others
• TCP/IP protocol information, such as TCP and UDP port numbers, TCP code flags, and ICMP messages
Given the differences between these two types of ACLs, standard ACLs typically are used for the following configuration tasks on a router:
• Restricting access to a router through the VTY lines (Telnet and SSH)
• Restricting access to a router through HTTP or HTTPS
• Filtering routing updates
Extended ACLs, on the other hand, commonly are used to filter traffic between interfaces on the router, mainly because of their flexibility in matching on many different fields at Layers 2, 3, and 4.
As you recall from Chapter 2, “Introduction to Firewalls,” packet-filtering firewalls can filter traffic at Layers 3 and 4. The Cisco standard and extended ACLs fall under this category. In Chapter 2, I pointed out some of the limitations of packet-filtering firewalls, including these:
• They can be complex to configure.
• They cannot prevent application layer attacks.
• They are susceptible to certain types TCP/IP protocol attacks, such as spoofing.
• They do not support user authentication of connections.
• They have limited logging capabilities: They do not log actual packet contents that can be useful in determining what someone was attempting to do.
Standard and extended ACLs have the following advantages:
• They can process packets at very fast speeds.
• They easily can match on most fields in Layer 3 packets and Layer 4 segments, providing a lot of flexibility in implementing security policies.
Note
It is important to understand the use and limitations of standard and extended ACLs: They cannot prevent all kinds of attacks, but they are good at filtering out a lot of the garbage and then letting another component in your firewall system deal with application layer attacks. You will see some of these limitations in this chapter when I discuss how you can attempt to limit traffic such as that from Instant Messenger or from file-sharing programs, such as Kazaa, with the use of ACLs.
In this part of the chapter, I discuss how to use the Cisco IOS to configure standard and extended ACLs. Later in the chapter, I discuss how you can use ACLs, especially extended ACLs, to protect your network.
Standard ACLs
Originally, there was a large performance difference between standard and extended ACLs. Standard ACL information was capable of being cached in the various high-speed caches that the router supported, such as fast switching, autonomous switching, silicon switching, optimum switching, and others. Extended ACLs could be only process-switched, drastically affecting the performance of the router. Therefore, when possible, administrators attempted to use standard ACLs over extended ones, to provide the best possible performance.
Today, however, this is typically not true. With Cisco Express Forwarding (CEF), routers can cache ACL information and process traffic in hardware. However, this requires a router that supports CEF, which many routers do. Therefore, a standard ACL typically is used to restrict traffic to or from the router itself, such as through its VTY lines or routing update contents.
Numbered Standard ACLs
You can group standard ACL statements in two ways: by number or by name. This section covers how to create standard numbered ACLs; the “Named Standard ACLs” section discusses how to create named ACLs. To create a numbered standard ACL, use the following command:
Router(config)# access-list ACL_# {permit | deny}
source_IP_address [wildcard_mask] [log]
With this command, you must specify the ACL’s number, which can range from 1 to 99 or 1300 to 1999. This number is used to group statements in the same list. By default, when you enter an ACL command for the specified list, it is added at the bottom of the list. Chapter 6 discussed how to edit ACLs. In the later section “Sequenced ACLs,” I discuss how you can insert, delete, or modify entries in a specific ACL grouping.
Following the ACL number is the action to take if there is a match on the condition. You can specify only two actions: permit or deny. Following the action is the condition. With standard ACLs, you can specify only a source address and wildcard mask. The wildcard mask is optional.
Tip
If you omit the wildcard mask in a standard ACL, it defaults to 0.0.0.0—a specific match. If you want to match on all addresses, replace the source address and mask with the keyword any.
At the end of the ACL, you optionally can configure the log parameter. If you configure this parameter and the Cisco IOS compares a packet and finds a match to the statement, the router logs it to any enabled logging facility, such as the console, the router’s internal buffer, or a syslog server.
Caution
You cannot delete a specific entry in a numbered ACL unless it is sequenced first, as discussed in the later section “Sequenced ACLs.” If you try to delete a specific entry by preceding the command with the no parameter, you actually will delete the entire ACL grouping. This applies to all numbered ACLs, both standard and extended.
After you have built your ACL, activate it on your router; until you do this, the ACL will do nothing. You can activate a traffic-filtering standard ACL on your router in two basic ways. If you want to filter traffic as it comes into or leaves an interface, use the following configuration:
Router(config)# interface type [slot_#/]port_#
Router(config-if)# ip access-group ACL_#_or_ACL_name {in | out}
With the ip access-group command, you need to specify the name or number of the ACL and the direction in which the router will filter information:
• in—As traffic enters the interface of the router from the network segment
• out—As traffic leaves the interface to the network segment
If you want to restrict Telnet or SSH connections to the router, activate the ACL with the following configuration:
Router(config)# line type line_#
Router(config-if)# access-class ACL_#_or_ACL_name {in | out}
Use the access-class command to activate an ACL on a line. This command was discussed in Chapter 3, “Accessing a Router.”
Named Standard ACLs
Named ACLs were introduced in Cisco IOS 11.2. Their main advantages over numbered ACLs were these:
• They allowed an administrator to give a descriptive name to the ACL.
• They allowed an administrator to create more than 99 standard or 100 extended ACLs. This was the original limitation put on the number of ACLs that you could create.
• They allowed you to delete a specific entry in an ACL.
Today you can use other methods to do these three things besides using a named ACL. For example, you can give a description to an ACL with a remark, as discussed later in the “ACL Remarks” section. Today’s standard IP ACLs also support numbers from 1 to 99 and 1300 to 1999, allowing for almost 700 ACL groupings. Therefore, named ACLs do not have any real advantage (or disadvantage) over numbered ACLs. Named ACLs still have two main advantages: They support a descriptive name, and, with the introduction of sequenced ACLS, discussed later in the “Sequenced ACLs” section, you can insert and delete specific ACL entries.
Note
In most situations, determining whether you want to use named or numbered ACLs is personal preference. In some instances, however, you might have to use one over another, based on any ACL extensions that you might want to add. For example, reflexive ACLs, discussed in Chapter 8, “Reflexive Access Lists,” require the use of named extended ACLs. Other than implementing specific features, there is no real difference between the two types. I grew up on numbered ACLs, so I use them in most instances.
To create a named standard IP ACL, use the following configuration:
Router(config)# ip access-list standard name_of_ACL
Router(config-std-nacl)# deny {source [src_wildcard] | any} [log]
Router(config-std-nacl)# permit {source [src_wildcard] | any} [log]
Router(config-std-nacl)# exit
The first thing that you must do is specify the type of named ACL (standard) and the name of the ACL in the ip access-list command. The name actually can be a number, such as 50, but a name is more descriptive.
Executing this command takes you into a subconfiguration mode. Here you enter your permit and deny commands, which have the same basic syntax as those in the numbered standard IP access-list commands. Note that you can delete a specific entry in a named ACL by going into ACL subconfiguration mode and prefacing the command with the no parameter.
When you are done entering your ACL statements, activate the ACL on an interface with the ip access-group command, specifying the name of the ACL. This was discussed in the last section, “Numbered Standard ACLs.” If you want to filter traffic destined to the VTYs of your router, you cannot use the ip access-group command to activate the ACL on the VTYs. Instead, you need to use the access-class command, discussed in Chapter 3.
Standard ACL Examples
Now that you have a basic understanding of the syntax of commands to create standard IP ACLs, you can take a look at a couple of examples to illustrate how they are configured. In the first example, I show you how to restrict VTY access on your router using, as an example, the network shown in Figure 7-1. In this example, only the two administrator PCs should be allowed access. Example 7-1 shows the configuration.
Example 7-1 Restricting VTY Access with a Standard Numbered ACL
Router(config)# access-list 1 permit 192.168.1.10
Router(config)# access-list 1 permit 192.168.1.11
Router(config)# line vty 0 4
Router(config-line)# access-class 1 in
In this example, notice that I omitted the wildcard mask. Whenever you omit the wildcard mask for a standard IP ACL, as I mentioned in Chapter 6, it defaults to 0.0.0.0—an exact match.
Example 7-2 shows the same configuration for Figure 7-1, except that it uses a named ACL.
Example 7-2 Restricting VTY Access with a Standard Named ACL
Router(config)# ip access-list standard restrict_VTY
Router(config-std-nacl)# permit 192.168.1.10
Router(config-std-nacl)# permit 192.168.1.11
Router(config-std-nacl)# exit
Router(config)# line vty 0 4
Router(config-line)# access-class restrict_VTY in
Either of the two configuration methods—numbered or named ACLs—will work.
Extended ACLs
Extended IP ACLS are much more flexible than standard ACLs because their conditions can match on many more criteria in a packet or segment header. I have divided this section into two subsections: numbered and named extended IP ACLs. Within the numbered section, I discuss some common types of extended IP ACLs, such as TCP, UDP, and fragmented packets.
Numbered Extended ACLs
Numbered extended IP ACLs were introduced in Cisco IOS 10.0. Here is the basic syntax of creating a numbered extended ACL statement:
Router(config)# access-list ACL_# {deny | permit} protocol_name_or_#
source_IP_address source_wildcard_mask destination_IP_address
destination_wildcard [protocol_options] [precedence precedence] [dscp value]
[tos tos] [log | log-input] [fragments] [established]
To build an extended IP ACL statement, use the access-list command. The first parameter that you need to specify is the ACL number, which groups the ACL statements. IP extended ACLs can have numbers from 100 to 199 and 2000 to 2699. Following this is the name or number of the TCP/IP protocol. Here is a list of protocol names supported by the Cisco IOS:
• ahp—Authentication Header Protocol
• eigrp—The Cisco EIGRP routing protocol
• esp—Encapsulation Security Payload
• gre—Cisco GRE tunneling
• icmp—Internet Control Message Protocol
• igmp—Internet Gateway Message Protocol
• ip—Any Internet Protocol
• ipinip—IP in IP tunneling
• nos—KA9Q NOS–compatible IP over IP tunneling
• pcp—Payload Compression Protocol
• pim—Protocol Independent Multicast
• tcp—Transmission Control Protocol
• udp—User Datagram Protocol
If the name of the protocol that you want to filter is not listed, you can enter the number; protocol numbers range from 0 to 255.
Tip
To match on any IP protocol, use the ip protocol keyword.
Following the protocol name or number is the source and destination addressing information. Unlike standard IP ACLs, with extended IP ACLs, you must specify both the source and destination addresses, as well as their corresponding wildcard masks.
Tip
In an extended IP ACL, if the wildcard mask for an address is 0.0.0.0 (exact match), the router converts it to this syntax: host IP_address. Either syntax is valid; just remember that the router performs this conversion automatically.
The rest of the information is optional. For a specific protocol, such as TCP, UDP, ICMP, and others, protocol options can be supplied to refine the condition further, assuming that the protocol supports options. I discuss these options for TCP, UDP, and ICMP in the following subsections.
The precedence parameter (optional) enables you to filter on a specific precedence level, ranging from 0 to 7. This field in the IP packet header typically is used to classify traffic for Quality of Service (QoS) and queuing purposes. Here is a list of names that you can use for the level instead of specifying a number:
• critical (0)
• flash (1)
• flash-override (2)
• immediate (3)
• internet (4)
• network (5)
• priority (6)
• routine (7)
The dscp parameter (optional) enables you to filter on the Differentiated Services Code Points (DSCPs) value in an IP packet header. DSCP is used to implement QoS by prioritizing traffic. You can specify either a value from 0 to 63 or the DSCP code name.
The tos parameter (optional) enables you to filter on the Type of Service field in the IP packet header. This IP option sometimes is used to implement QoS. This can be a number from 1 to 15 or the name of the service:
• max-reliability
• max-throughput
• min-delay
• min-monetary-cost
• normal
The optional log parameter causes the Cisco IOS to log a match on the condition to whatever logging facility has been enabled (console, internal buffer, and/or syslog server). The information logged includes the following:
• The action: permit or deny
• The protocol, such as TCP, UDP, or ICMP
• The source and destination addresses
• For TCP and UDP, the source and destination port numbers
• For ICMP, the message types
Log messages are generated on the first packet match and then on 5-minute intervals after that on packet matches. This is to ensure that a Denial of Service (DoS) attack does not overrun the router’s logging function. You can change the update interval with the ip access-list log-update command, as covered later in the “Logging Updates” section.
Caution
Enabling the log (or log-input) parameter on a router disables CEF switching, seriously impacting the performance of your router. When logging is enabled, packets are either process- or fast-switched. Therefore, use this only if you are under a network attack and are trying to determine the culprit. In this instance, enable logging for the period for which you need to gather the appropriate information, and then disable logging.
The optional log-input command includes the input interface of the received packet and the Layer 2 source address in the packet, such as an Ethernet MAC address, a frame relay DLCI number, or a ATM VC number.
I discuss the optional established keyword in the “TCP” subsection, and I discuss the optional fragments parameter in the “Fragments and Extended ACLs” subsection.
When you are done entering your ACL statements, activate the ACL on an interface with the ip access-group command, specifying the name of the ACL. This was discussed in the “Numbered Standard ACLs” section.
TCP
You can filter TCP traffic with the following ACL statement:
Router(config)# access-list ACL_# {deny | permit} tcp
source_IP_address source_wildcard_mask [operator src_port_name_or_number]
destination_IP_address destination_wildcard [operator dest_port_name_or_number]
[log | log-input] [precedence precedence] [dscp value] [tos tos] [fragments]
[established] [ack] [fin] [psh] [rst] [syn] [urg]
For filtering TCP traffic, use the tcp keyword for the protocol parameter. This is followed by the source and destination addresses and wildcard masks. Optionally, you can match on source or destination port numbers. To match on a port number for an address, you must specify an operator and then a port name or number. Here is a list of operators that you can specify:
• eq—Must match exactly this port name or number
• lt—Must be lower than this port name or number
• gt—Must be greater than this port name or number
• neq—Must not be equal to this port name or number
• range—Must be within the specified inclusive range, where the beginning and ending port name or numbers are separated by a space, like this: 22 23.
If you specify an operator, you must follow it with a TCP port name or number. Table 7-1 lists the TCP port names supported on the router. If you do not find the name of the TCP port in Table 7-1 that you need to filter, specify the number instead. Numbers range from 0 to 65,535, where 0 represents all TCP ports.
One additional parameter that can be used with TCP connections is the established keyword. Basically, this allows return replies from established connections. This means that if you have an inbound ACL on your perimeter router, protecting you from the Internet, TCP traffic that your users send out will be allowed back in. The established keyword looks to see if the ACK, FIN, PSH, RST, SYN, or URG set TCP control flags are set. If they are, the TCP traffic is allowed in; if not, the Cisco IOS assumes that this is a new connection and does not match on this statement.
Caution
Many administrators think that using the established keyword implements a stateful firewall on a router. This cannot be further from the truth. All the established parameter does is allow any TCP segments with the appropriate control flag or flags set: If they are set, the action is executed (permit or deny). The parameter does not look to see if this is returning traffic from a connection that was initiated from inside your network. Remember that standard and extended ACLS are plain packet filters and do not maintain state information. Therefore, if you use the established keyword to allow returning traffic into your network, you are opening a large hole in your perimeter router. Hackers can take advantage of this hole by using a packet generator/scanner to sneak TCP packets into your network by hiding them as returning traffic. Hackers accomplish this by using packet-generator tools and setting the appropriate bit or bits in the TCP control field. Some packet-generator products that I use include hping, nmap, nemesis, and lcrzoex, but there are dozens out there. Some are available for Windows platforms, but most were developed for UNIX-based platforms. I highly recommend that you download and try out these tools; especially to test the packet filters that you configure on your router.
Where the established keyword looks for a specific control flag or flags in the TCP segment header, you can be more specific and filter on just a single control flag, including ack, fin, psh, rst, syn, and urg. The rest of the parameters for TCP ACL statements were discussed at the beginning of this section.
UDP
You can filter UDP traffic with the following ACL statement:
Router(config)# access-list ACL_# {deny | permit} udp
source_IP_address source_wildcard_mask [operator src_port_name_or_number]
destination_IP_address destination_wildcard [operator dest_port_name_or_number]
[log | log-input] [precedence precedence] [dscp value] [tos tos] [fragments]
For filtering UDP traffic, use the udp keyword for the protocol parameter. This is followed by the source and destination addresses and wildcard masks. Optionally, you can match on source or destination port numbers. To match on a port number for an address, you must specify an operator and then a port name or number. The operators are the same as those used by TCP, discussed in the previous section.
If you specify an operator, you must follow it with a UDP port name or number. Table 7-2 lists the UDP port names supported on the router. If you do not find the name of the UDP port in Table 7-2 that you need to filter, specify the number instead. Numbers range from 0 to 65,535, where 0 represents all UDP ports.
The one main difference between UDP and TCP is that UDP is connectionless. Thus, the established keyword and the TCP code flag parameters are not valid when configuring a UDP ACL statement.
ICMP
You can filter ICMP traffic with the following ACL statement:
Router(config)# access-list ACL_# {deny | permit} icmp
source_IP_address source_wildcard_mask
destination_IP_address destination_wildcard [ICMP_message_type_or_#]
[log | log-input] [precedence precedence] [dscp value] [tos tos] [fragments]
For filtering ICMP traffic, use the icmp keyword for the protocol parameter. This is followed by the source and destination addresses and wildcard masks. Optionally, you can match on ICMP message types. Unlike TCP and UDP, there is no operator to specify a match; instead, you just configure the specific ICMP message type. If you omit the message type, it defaults to matching on any ICMP message type. To specify a message type, configure either the name of the message or its number. Table 7-3 lists the ICMP message type names supported on the router. If you do not find the name of the ICMP message type in Table 7-3 that you need to filter, specify the number instead. Numbers range from 0 to 255, where 0 represents all ICMP messages.
Named Extended ACLs
Besides using numbers to reference extended ACLs, you can use names. Named extended ACLs were introduced in Cisco IOS 11.2. Here is the general syntax of a named extended ACL:
Router(config)# ip access-list extended ACL_name
Router(config-ext-nacl)# {deny | permit} protocol_name_or_#
source_IP_address source_wildcard_mask
destination_IP_address destination_wildcard [protocol_options]
[precedence precedence] [dscp value] [tos tos]
[log | log-input] [fragments] [established]
To create a named extended ACL, use the ip access-list extended command, followed by the name of the ACL. When you execute this command, you are taken into a subconfiguration mode where you enter your permit or deny statements. At this point, the syntax is the same as a numbered ACL, with the same options being supported.
Remember that you can delete a specific entry in a named ACL by going into ACL subconfiguration mode and prefacing the command with the no parameter.
Extended ACL Examples
To help you understand the configuration of ACLs, take a look at a couple of examples. The first example uses a router with two interfaces; the second uses a router with three interfaces.
Two-Interface Router Example
The first example uses a network with a simple setup, as shown in Figure 7-2. In this example, the router has two interfaces: ethernet0 is the internal interface, and ethernet1 is the external interface.
In Figure 7-2, the security policies are as follows:
• Allow web traffic to the internal web server
• Allow DNS queries to the internal DNS server
• Allow e-mail to be sent from Internet users to the internal e-mail server
• Allow FTP control connection from the Internet to the internal FTP server, as well as the data connection in an active, or standard, FTP connection
• Allow the internal users to access external DNS servers and web servers only
• Deny all other types of traffic
Example 7-3 shows the ACL configuration to accomplish these policies.
Example 7-3 Using an Extended ACL to Implement a Two-Interface Router Solution
Router(config)# access-list 100 permit tcp any (1)
host 200.1.1.14 eq 80
Router(config)# access-list 100 permit udp any (2)
host 200.1.1.13 eq 53
Router(config)# access-list 100 permit tcp any (3)
host 200.1.1.12 eq 25
Router(config)# access-list 100 permit tcp any eq 25
host 200.1.1.12 established
Router(config)# access-list 100 permit tcp any (4)
host 200.1.1.11 eq 21
Router(config)# access-list 100 permit tcp any (5)
host 200.1.1.11 eq 20
Router(config)# access-list 100 permit tcp any eq 80 (6)
200.1.2.0 0.0.0.255 established
Router(config)# access-list 100 permit udp any eq 53 (7)
200.1.2.0 0.0.0.255
Router(config)# access-list 100 deny ip any any (8)
Router(config)# interface ethernet1
Router(config-if)# ip access-group 100 in (9)
Take a look at this access list with reference to the numbering on the right side of Example 7-3:
1. This command allows traffic from anywhere to reach TCP port 80 of the web server (200.1.1.14).
2. This command allows traffic from anywhere to do a DNS lookup to UDP port 53 on 200.1.1.13.
3. The first command allows traffic from anywhere to send an e-mail to TCP port 25 on 200.1.1.12; the second command allows the internal e-mail server to send e-mail to external servers and get replies. Reading this statement is confusing to many users. Remember that the source, in this case, is an external e-mail server, and because the internal server initiated the connection to port 25 on the Internet e-mail server, the source port will be 25 when the Internet server responds.
4. This command allows traffic from anywhere to set up a control connection to TCP port 21 on the FTP server.
5. This command allows the Internet user to use the FTP data port, TCP 20 (set up from the server to the Internet user), if the traffic is destined to 200.1.1.11. One problem with this ACL is that, normally, the control connection is set up first from the client to the server, and then the server sets up the data connection to the client; however, this ACL allows data connections without a corresponding control connection, which represents a security risk. This can be overcome by using a stateful firewall, such as CBAC, instead of a standard packet filter.
6. Notice in this command that the source port is TCP 80. This command allows the returning traffic from external web servers to the internal users. I also added the established command to provide an extra level of protection.
7. This command allows any DNS queries sent to external servers to return to the internal users. The source port is UDP 53, which is traffic coming from (the source) external DNS servers.
8. The deny any any command is not necessary, but I always put it in to remind me of the implicit deny at the end of the list. Plus, you can see the hit count when you display the ACL with the show [ip] access-list command.
9. The ip access-group command activates the ACL inbound on the external interface—the interface connected to the Internet.
In this example, for internal users sending traffic and allowing the replies back in, a stateful firewall, such as the use of CBAC in the Cisco IOS, would be a much better solution than the one given here (Steps 5, 6, and 7). I discuss CBAC in Chapter 9, “Context-Based Access Control.”
Note
You can configure polices using an extended ACL in one of two ways. One approach is to use two ACLs on the external interface, with one applied inbound and the other applied outbound. You also could use two ACLs on the internal interface, with one applied inbound and the other applied outbound. I typically like to put as much as possible into a single ACL because it makes troubleshooting easier.
Three-Interface Router Example
The second example uses the network shown in Figure 7-3. Notice that this example is more complicated than that shown in Figure 7-2. In this example, the router has three interfaces: internal (ethernet0), external (ethernet1), and dmz (ethernet2).
In this example, I use the following policies:
• Users from the Internet can access web pages in the DMZ web server.
• Users from the Internet can send e-mail to the SMTP server in the DMZ.
• The DMZ SMTP server can forward mail to the internal server, but no other traffic can originate from this segment to the internal network.
• Internal users should be able to perform DNS queries.
• Internal users should be able to access both servers in the DMZ.
• Internal users should be able to access all TCP services in the Internet.
Example 7-4 shows the ACL configuration to accomplish these policies.
Example 7-4 Using an Extended ACL to Implement a Three-Interface Router Solution
Router(config)# access-list 100 deny ip any (1)
200.1.2.10 0.0.0.1
Router(config)# access-list 100 permit tcp any (2)
host 200.1.1.11 eq 80
Router(config)# access-list 100 permit tcp any (3)
host 200.1.1.10 eq 25
Router(config)# access-list 100 permit tcp any eq 25 (4)
host 200.1.1.10 any established
Router(config)# access-list 100 permit tcp any (5)
200.1.2.0 0.0.0.255 established
Router(config)# access-list 100 permit udp any eq 53 (6)
200.1.2.0 0.0.0.255
Router(config)# access-list 100 deny ip any any (7)
Router(config)# interface ethernet 1
Router(config-if)# ip access-group 100 in (8)
Router(config-if)# exit
Router(config)# access-list 101 deny ip any (9)
host 200.1.2.11
Router(config)# access-list 101 permit tcp any (10)
200.1.2.0 0.0.0.255 established
Router(config)# access-list 101 permit udp any eq 53 (11)
200.1.2.0 0.0.0.255
Router(config)# access-list 101 permit tcp host 200.1.1.10 (12)
host 200.1.2.10 eq 25
Router(config)# access-list 101 permit tcp host 200.1.1.10 eq 25 (13)
host 200.1.2.10 established
Router(config)# access-list 101 deny ip any any (14)
Router(config)# interface ethernet 0
Router(config-if)# ip access-group 101 out (15)
Router(config-if)# exit
In Example 7-4, I have created two ACLs. ACL 100 is used to filter traffic to the internal network, and ACL 101 is used to filter traffic from the Internet and the DMZ to the internal segment. Compared to Example 7-3, Example 7-4 is more difficult to implement; as in Example 7-3, there is more than one solution to implement your security policies. I have broken down the policies into steps, with reference to the numbering on the right side of Example 7-4:
1. All Internet traffic is denied from reaching the internal Accounting server and the e-mail server. This is necessary because of Step 5, which allows all TCP returning traffic to the internal network. This step prevents any traffic to the Accounting and e-mail server, including returning TCP traffic and DNS replies (Step 6).
2. This step allows Internet users to request web pages from the DMZ web server.
3. This step allows external users and servers to send e-mail traffic to the DMZ web server.
4. This step allows the DMZ e-mail server to get replies to e-mail that it has sent to external e-mail servers, as long as the correct TCP flag or flags are set (established keyword).
5. This statement allows any returning TCP traffic to be forwarded to the inside users who requested it (except the Accounting and internal e-mail server, which was filtered in Step 1).
6. This statement allows DNS replies to be forwarded to internal users who sent DNS queries (except the internal accounting and e-mail server, which was filtered in Step 1).
7. This statement drops all remaining traffic (not necessary because the implicit deny is enforced).
8. ACL 100 is applied inbound on the interface facing the Internet.
9. ACL 101 is used to filter traffic from the DMZ and Internet to the internal segment. This statement prevents any traffic from being sent to the Accounting server.
10. This statement allows the replies of TCP connections that internal users requested to be forwarded back to them from the Internet (except the Accounting server, which was filtered in Step 9). Even though this was done in Step 1 in ACL 100, this step is necessary to prevent DMZ traffic from accessing the Accounting server.
11. This statement allows DNS replies to be forwarded to the internal users (except the Accounting server—see Step 9).
12. This statement allows the DMZ e-mail server to forward e-mail to the internal e-mail server.
13. This statement allows the internal server to forward e-mail to the DMZ server and to allow the responses back.
14. This drops all remaining traffic (not necessary because the implicit deny is enforced).
15. This activates ACL 101 as traffic comes from either the Internet or the DMZ interfaces and exits ethernet0, the internal interface.
The biggest problem in this example and the previous one is trying to implement a secure “stateful” function using packet filters. In a large network, this is either impractical or impossible. For instance, this example allows only returning TCP traffic; UDP traffic presents a problem. However, the assumption in this example is that internal users basically are using HTTP (TCP) and DNS (UDP), which are allowed.
Tip
When you need to allow returning traffic into your network, using the established keyword, opening a specific source port, or opening a range of ports, makes you vulnerable to spoofing and DoS attacks. Therefore, I highly recommend that you use a stateful firewall function. As you will see in Chapters 8 and 9, with the Cisco IOS, you can use these two features to implement stateful features to allow returning traffic and still use extended ACLs to filter traffic originating from devices.
Therefore, use the previous examples as just that: examples in packet-filtering practice. Do not use this solution to allow returning traffic.
ACL Verification
When you have completed the configuration (access-list or ip access-list standard | extended) and activation of your ACLs (ip access-group), you are ready to verify your router’s configuration and operation. Use the following command to list your ACLs and the statements that they contain:
Router> show [protocol_name] access-list [ACL_#_or_name]
If you enter only show access-list, all ACLs from all protocols are displayed, as in Example 7-5.
Example 7-5 Using the show access-list Command
Router# show access-list
Extended IP access list 109
permit tcp 172.16.0.0 0.0.255.255 any established (189 matches)
permit udp host 172.16.1.39 any eq domain (32 matches)
permit icmp host 199.199.199.1 any (98 matches)
deny ip any any (1237 matches)
IPX sap access list 1000
deny FFFFFFFF 7
permit FFFFFFFF 0
In this example, there is an extended numbered IP ACL and an IPX SAP filter (1000). If you want to view only ACLs from a specific protocol, specify the protocol, like this: show ip access-list. You even can be more restrictive by adding the name or number of the ACL.
I want to point out two important items in Example 7-5. First, notice that at the end of each ACL statement is a list of the number of matches that the Cisco IOS found when comparing packets to the ACL. This gives you information that your ACL has been activated on your interface and is filtering traffic. Second, notice that I manually configured the deny ip any any statement at the end of the list. I configured this statement so that I could see how many packets the Cisco IOS was dropping.
Tip
Any matches on the implicit deny statement are not logged and are not recorded as a match, by default. If you want to record matches, manually configure a deny all statement at the end of the ACL. I typically use this and keep a record of the number of matches on statements daily. If I see something radically different from the average, I typically inspect it to see if there is a security issue related to the anomaly.
If you want to log dropped packets, add the log keyword to your manually configured deny statement. Remember my caution, though, about using the logging feature and the impact that it has on the router’s switching capabilities. Do this only to troubleshoot problems or to examine a security incident more closely.
To reset the counters that you see in the show access-list command, use the clear access-list counters command:
Router# clear access-list counters [ACL_#_or_name]
If you do not specify a specific ACL name or number, all counters for all ACLs are cleared.
If you want to see if an IP ACL is applied to an interface, use the show ip interfaces command:
Router> show ip interface [interface_name_and_#]
You can restrict the output of this command by specifying a particular interface. Example 7-6 shows sample output of this command.
Example 7-6 Using the show ip interface Command
Router# show ip interface fastethernet0
FastEthernet0 is up, line protocol is up
Internet address is 192.168.1.254/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 100
<--output omitted-->
As you can see in this example, an extended ACL has been applied inbound on the interface fastethernet0.
Fragments and Extended ACLs
Fragments are used when the data cannot fit into the configured payload size. Typically this occurs when packets cross over between media types that use different maximum MTUs, such as token ring to Ethernet. A large packet is broken into two or more smaller packets to meet the maximum configured MTU size. There is no real restriction on how many times fragmentation can occur because it is performed on a hop-by-hop basis. The main problem with fragmentation is that it is process intensive: An intermediate device must break up the original packet into fragments, and then the destination must reassemble them.
Fragmentation Process
As an example, assume that you create a TCP segment that is 1600-bytes long and has been forwarded to a next-hop address in an IP packet. The next-hop device does not support this MTU size on the next hop, so it fragments the original packet into two or more fragments. The first, or initial, fragment is the first part of the original segment. However, the subsequent (noninitial) fragments look different.
Note
The first fragment has a fragment-offset value of 0. Subsequent, or noninitial, fragments have a fragment offset that is greater than 0.
In this example, the first fragment contains the TCP header and part of the data. However, the second and subsequent fragments carry only the remainder of the TCP data. This presents a problem because, when the destination receives the fragments, it knows that the first one is for a specific TCP port number, but it does not know about the port number in the remaining fragments. Plus, if the fragments are received out of order, the destination has an issue with the reassembly process.
To overcome these problems, the IP headers in all these fragments are marked as fragments. The identification field in the IP header is assigned a unique identifier for the fragments of the original packet, which helps the destination determine what protocol and port this should be forwarded to. The flags field is used to mark the fragment as either the beginning or middle part of the fragment, or the last fragment in a packet. The fragment offset field is used to mark where in the reassembly process the fragment fits into the total (completed) packet.
Fragmentation and Filtering Issues
The process that fragmentation uses can pose problems with how packet-filtering devices process packets. In this example, assume that the data being fragmented is a TCP port 80 (web) connection. The first fragment lists the IP protocol (TCP) and contains the TCP header, with port 80 as the destination. The second fragment lists the IP protocol (TCP) but does not list the port number. The TCP header was in the first fragment, and the remaining TCP data is in the second fragment. With the second fragment, a packet-filtering router or firewall knows that this is a TCP fragment, but it does not know what the port number is. How should the packet-filtering firewall treat these fragments?
With a stateful firewall, this would be easier because if a stateful firewall was set up to do so, it could keep track of the identification field and allow subsequent fragments into its interface based on the receipt of the TCP 80 fragment first. However, there is no guarantee that the first fragment will be received first. In this instance, what would happen if the second fragment arrived before the first? The stateful firewall would lack information about the connection. It could buffer fragments of a packet to determine whether they were all part of the same connection, but this requires extra resources on the firewall.
The most common solution is to allow the fragments into the network. The assumption made here is that these fragments must be part of a valid connection. Unfortunately, hackers can take advantage of this assumption and create a DoS attack by flooding your network with fragments. If your packet-filtering firewall assumes that fragments are part of a valid connection, basically any fragment, whether it is or is not a true fragment, is allowed. This can be a dangerous assumption. With a brute-force approach, a hacker just floods garbage fragments into your network that cannot be reassembled. A more intelligent hacker uses fragments that are reassembled into a valid packet, which requires more resources to process.
You can use three solutions to deal with fragmentation with your Cisco IOS:
• Use packet filters.
• Use CBAC (discussed in Chapter 9, “Context-Based Access Control”).
• Use IDS shunning (discussed in Chapter 16, “Intrusion-Detection System”).
All three of these solutions have advantages and disadvantages. In the following section, I discuss how you can use extended ACLs to filter packet fragments.
Note
RFC 1858 discusses security issues related to fragments.
Filtering Fragments
You can filter fragments for packets by using the fragments keyword in your extended ACL statement. Fragment filtering requires Cisco IOS versions 12.0(11) or 12.1(2) or later.
This keyword works with both numbered and named extended ACLs. Here is the syntax for a numbered ACL:
Router(config)# access-list ACL_# {deny | permit} IP_protocol
source_IP_address source_wildcard_mask
destination_IP_address destination_wildcard [log | log-input]
[precedence precedence] [dscp value] [tos tos] fragments
When filtering fragments, noninitial fragments that match Layer 3 information in your ACL have the appropriate action taken against them: permit or deny. No Layer 4 information can be filtered, with the exception of the IP protocol, when filtering fragments in an ACL statement.
Note
By using the fragments keyword, only noninitial fragments are filtered: The first fragment of a packet, or packets that are not fragmented, will not match this condition. Also, with TCP and UDP, you cannot include Layer 4 information, such as port numbers, when using the fragments keyword. As you recall from the “Fragmentation and Filtering Issues” section, this information is not noted in noninitial fragments of a packet. Basically, only Layer 3 header information can be used in a condition. As an example, you can use the fragments keyword with ICMP and ICMP message types because ICMP is a Layer 3 protocol.
In this example, all IP fragments are dropped:
Router(config)# access-list 100 deny ip any any fragments
Router(config)# ! <rest of ACL statements in ACL 100>
When setting up a grouping of ACL statements, you should deny fragments at the top or toward the top of you list, and put your specific permit statements below them. This is especially true of internal firewalls, where you are denying specific types of access but permitting all other types.
Tip
You want to make sure that a permit statement in an ACL does not inadvertently permit fragments. Therefore, the fragment ACL statements are placed at the top of the list.
In this example, only TCP, UDP, and ICMP fragments are dropped:
Router(config)# access-list 100 deny tcp any any fragments
Router(config)# access-list 100 deny udp any any fragments
Router(config)# access-list 100 deny icmp any any fragments
Router(config)# ! <rest of ACL statements in ACL 100>
In this example, only TCP, UDP, and ICMP fragments are dropped, allowing other types of fragments into the router. Note that this is less secure than the first example. Even though TCP, UDP, and ICMP are the most common protocols that hackers use for DoS fragment attacks, other protocols, such as IGMP, have been exploited in the past.
When setting up ACL filters, if you do not specify that fragments should be filtered, certain rules apply to whether the fragments are permitted or denied. First, if you have an ACL statement with only Layer 3 information in it, such as the source and destination addresses and the IP protocol type (IP, TCP, ICMP, UDP, and so on), both nonfragmented, initial fragments and noninitial fragments can match against the configured condition.
If you have an ACL statement with both Layers 3 and 4 information, such as TCP or UDP port numbers, a different process is used:
• If the packet is a nonfragmented packet or an initial fragment from a packet and the condition matches, the action (permit or deny) is applied.
• If the packet is a noninitial fragment from a packet and the condition matches and the action is permit, the fragment is permitted. However, if the condition matches and the action is deny, the next ACL statement in the list is processed.
Caution
As you can see from this last point, the deny keyword in an ACL statement does not drop fragments; it drops only nonfragmented packets and the initial fragment in a packet. This is important to remember because the default action of ACLs is to allow fragments. Therefore, if you want to deny traffic from a specify device, you need two deny statements: one to deny nonfragmented packets and the initial packet in a fragment (not using the fragments keyword), and one to deny the noninitial fragments (using the fragments keyword). This is definitely true if you are using Cisco IOS versions earlier than 12.0(11) or 12.1(2).
Newer versions of the Cisco IOS, however, have fixed this security hole and allow the implicit deny statement to drop noninitial fragments that do not match any of the statements in the ACL grouping. In either case, I recommend following the more secure path and always specify whether fragments are permitted or denied.
Fragment Filtering Example
Take a look at a couple of examples that filter traffic to see how fragments are affected. These use the network shown in Figure 7-4.
In Example 7-7, you want to allow Internet users to access an internal FTP server, so you configure the following ACL:
Example 7-7 Configuring a Simple ACL to Allow FTP Traffic
Router(config)# access-list 100 permit tcp any host 200.1.1.10 eq 21
Router(config)# access-list 100 deny ip any any
As you recall, FTP uses two connections: 21 for control information and 20 for data. In an active FTP session, the server opens the port 20 connection. To allow the client to send traffic across the opened port 20 connection, I assume that the router is performing as a stateful firewall. If the router were not, you would need the commands in Example 7-8 before the deny statement in Example 7-7.
Example 7-8 Allowing the FTP Data Connection for Example 7-7
Router(config)# access-list 100 permit tcp any host 200.1.1.10 eq 20 established
Router(config)# access-list 100 permit tcp any host 200.1.1.10 eq 21
Router(config)# access-list 100 deny ip any any
Remember that the use of the established keyword does not implement a stateful firewall function.
In either of these two configurations, if the router was running earlier versions than Cisco IOS 12.0(11) or 12.1(2), fragments would be allowed, by default. This could be a big security risk, so I have modified the ACL as displayed in Example 7-9.
Example 7-9 Adding Fragment Filtering to Example 7-8
Router(config)# access-list 100 deny ip any any fragments
Router(config)# access-list 100 permit tcp any host 200.1.1.10 eq 20 established
Router(config)# access-list 100 permit tcp any host 200.1.1.10 eq 21
Router(config)# access-list 100 deny ip any any
In this example, you have prevented fragments from reaching any internal device (no matter what Cisco IOS version your router is running). However, you just received an e-mail from an Internet user stating that he cannot access your FTP server. After investigating the problem, you discover that it is a fragmentation issue: He is sending IP packets that are composed of fragments. To solve this problem, you probably would allow fragments to the FTP server, as displayed in Example 7-10.
Example 7-10 Allowing Fragments to the FTP Server from Example 7-9
Router(config)# access-list 100 permit tcp any host 200.1.1.10 fragments
Router(config)# access-list 100 deny ip any any fragments
Router(config)# access-list 100 permit tcp any host 200.1.1.10 eq 20 established
Router(config)# access-list 100 permit tcp any host 200.1.1.10 eq 21
Router(config)# access-list 100 deny ip any any
The first statement in Example 7-10 allows any TCP fragments to be forwarded to your FTP server, but it is denying all other types of fragments. Also, by allowing TCP fragments to your FTP server, you are opening it to TCP fragmentation DoS flood attacks.
Caution
In most networks today, fragmentation is uncommon except for IPSec connections. Therefore, if you are not using IPSec, you typically can filter fragments without any side effects. If you are filtering fragments and certain connections are failing, it might be because of fragmentation and your filtering rules. In this situation, you might have to open your filter to allow fragments. In this case, make sure that you use an IDS solution that can detect fragmentation attacks and dynamically can log into your router and configure a filtering rule to prevent the flood of fragments. Cisco calls this process shunning, and it is discussed in Chapter 16.
Timed ACLs
Timed ACLs were introduced in Cisco IOS 12.0(1)T. Timed ACLs enable you to restrict traffic based on the time of day, the day of the week, or the day of the month. Sometimes you want to open a hole in your router’s filter to allow a specific type of traffic, but you do not want to leave the hole open indefinitely. For example, you might not want your users accessing the Internet during business hours, but you might let them do so during lunch or before or after hours. Timed ACLs enable you to enforce this kind of policy.
Timed ACLs are actually an extension of numbered and named extended ACLs, and work with IP and IPX. You create your entries that are timed based and use the time-range parameter to specify the time period or periods that the ACL statement is valid. The time periods can be recurring, such as every day between 12 and 1 P.M., or absolute, occurring only once. Besides being an extension of extended ACLs, they can be used with reflexive ACLs and CBAC stateful filtering. They also can be used with VPNs to restrict access during certain time periods or to implement different QoS policies based on the time of day.
Creating Time Ranges
To create a time range, use the following commands:
Router(config)# time-range time_range_name
Router(config-time)# absolute [start_time start_date]
[end_time end_date]
Router(config-time)# periodic day_of_the_week hh:mm to
[day_of_the_week] hh:mm
When creating a time range with the time-range command, you must give the time range a unique name. The name must begin with a letter and cannot contain a space. You will use this name later to associate a specific ACL statement with this range. Executing the time-range command takes you into a subconfiguration mode where you can specify two types of ranges: one time only (absolute) and recurring (periodic).
absolute Command
The absolute command specifies a single time period for which the time range is valid; the ACL statement(s) referencing this time range is not used after this period. With the absolute command, you can specify a beginning time period, an ending time period, or both. The time is specified in 24-hour time, like this: hh:mm, where the hours range from 0 to 24 and the minutes are 0 to 59. For example, 3 P.M. would be represented as 15:00. The date is specified in this format: day month year. The day is specified as a number from 1 to 31; the month is the name of the month, such as May; and the year is a four-digit value, such as 2003. Here is an example date: 19 November 2004. The earliest date that you can reference is 00:00 1 January 1993, and the latest date that you can reference is 23:59 31 December 2035. If you omit the starting time, it defaults to the current time on the router. If you omit the ending time, it defaults to 23:59 31 December 2035. One restriction with the absolute command is that you can have only one of these commands in a single time-range configuration.
periodic Command
The periodic command specifies a recurring time period for which the time range is valid. Unlike absolute commands, you can have multiple periodic commands in the same time range. With this command, you must specify a beginning and ending time; however, the ending time can be on a different day. The first parameter that you specify is the day of the week beginning time, which is one of the following values:
• monday
• tuesday
• wednesday
• thursday
• friday
• saturday
• sunday
• daily (every day)
• weekdays (Monday through Friday)
• weekend (Saturday and Sunday)
After the day of the week is the beginning time, specified as hh:mm. This is followed by the to parameter and the ending time. If you omit the day of week parameter, it defaults to the day of week that you configured for the beginning time. Following this is the ending time, specified as hh:mm.
Activating Time Ranges
After you have created your time range or ranges, you are ready to activate them. This is done by adding the time-range parameter to the ACL statement. This is supported in both named and numbered extended ACLs. Here is the configuration for a numbered ACL:
Router(config)# access-list ACL_# {deny | permit} protocol_name_or_#
source_IP_address source_wildcard_mask
destination_IP_address destination_wildcard
[protocol_options][precedence precedence] [dscp value] [tos tos] [log | log-input]
[fragments] [established] [time-range name_of_time_range]
As you can see from this command, you need to add the time range only to the ACL statement. When you do this, the ACL statement is processed only by the Cisco IOS when the router’s time falls within the period specified by the periodic or absolute commands defined in the time-range configuration.
Using Distributed Timed ACLs
Distributed timed ACLs were introduced in Cisco IOS 12.2(2)T and are an extension to timed ACLs. One restriction with timed ACLs, however, is that they were not supported on the VIP line cards of the 7500 series of routers. If you configured a time-based ACL on one of these line cards, the Cisco IOS treated it as a normal ACL statement. In addition, if an interface was configured with a time-based ACL, packets were not distributed switched through the line card; they had to be forwarded to the Route Processor (RP) card to be processed. In other words, timed ACLs basically were broken for the 7500 series routers.
Distributed timed ACLs fix these two problems. A distributed timed ACL activated on a 7500’s interface is distributed through the line card, but the software clock between the RP and the line card must be synchronized. This process is performed through the exchange of interprocess communications (IPC) messages between the two cards. Whenever you add, delete, or modify a time range for an ACL that is associated with an interface, the RP sends an IPC message to the line card.
Tip
To ensure that your router has a reliable clock source, I recommend that you use the Network Time Protocol (NTP). I discuss this protocol in Chapter 18, “Logging Events.”
The configuration of distributed timed ACLS is done the same way with normal timed ACLs by using the time-range and the absolute and periodic commands. After you build your time range, reference it in your extended ACL with the time-range parameter.
After you have configured your timed ACLs on your 7500 router (with VIP line cards), you can verify that the timed ACLs are functioning properly with these commands:
• show time-range ipc—Use this command to verify that the clocks are synchronized between the VIP line cards and the RP. It displays statistics about the communication process.
• clear time-range ipc—Use this command to clear the time-range IPC statistics and counters and reset them to 0.
• debug time-range ipc—Use this command to display the messages shared between the RP and VIP cards.
Example of Timed ACL
To help illustrate how timed ACLs are used, take a look at an example, using the network shown in Figure 7-5. In this example, e-mail and DNS query traffic should be allowed from the Internet to the two respective DMZ servers, and vice versa. However, no other traffic should be allowed. Even users are not allowed to directly access the Internet during business hours, but management has just passed a policy that allows users to access the Internet during lunch and after hours until 7 P.M., when the office closes.
Example 7-11 displays the configuration to accomplish this.
Example 7-11 Using Timed ACLs to Implement Filtering Policies
Router(config)# time-range employee-time
Router(config-time)# periodic weekdays 12:00 to 13:00
Router(config-time)# periodic weekdays 17:00 to 19:00
Router(config-time)# exit
Router(config)# access-list 100 permit tcp any host 200.1.1.11 eq 25
Router(config)# access-list 100 permit tcp any eq 25 host 200.1.1.11 established
Router(config)# access-list 100 permit udp any host 200.1.1.12 eq 53
Router(config)# access-list 100 permit udp any eq 53 host 200.1.1.12
Router(config)# access-list 100 permit tcp any 200.1.1.0 0.0.0.255 established
time-range employee-time
Router(config)# access-list 100 deny ip any any
Router(config)# interface ethernet 1
Router(config-if)# ip access-group 100 in
Router(config-if)# exit
Router(config)# access-list 101 permit tcp host 200.1.1.11 eq 25 any
Router(config)# access-list 101 permit tcp host 200.1.1.11 any eq 25
Router(config)# access-list 101 permit udp host 200.1.1.12 eq 53 any
Router(config)# access-list 101 permit udp host 200.1.1.12 any eq 53
Router(config)# access-list 101 permit tcp 200.1.1.0 0.0.0.255 any
time-range employee-time
Router(config)# access-list 100 deny ip any any
Router(config)# interface ethernet 1
Router(config-if)# ip access-group 101 out
In this example, only e-mail and DNS traffic is allowed in and out at any time. However, employees are allowed TCP access to the Internet during lunch time and after work hours (periodic commands). Again, setting up this configuration is difficult because extended ACLs are packet filters and do not support stateful firewall functions. The first timed ACL entry (ACL 100) allows returning TCP traffic to employees’ PCs. The second timed ACL entry (ACL 101) allows the employees to access the Internet. Two ACLs are required, based on the requirements: 100 prevents traffic from entering this company’s network, and 101 prevents traffic from leaving the network.
Additional ACL Features
This section rounds out the introduction to ACLs and their configuration. This section covers five enhanced ACL features: remarks, throttling of logging updates, IP accounting, turbo ACLs, and sequenced ACLs. ACL remarks enable you to insert descriptions into your ACL statement grouping. Throttling logging information from ACL matches (with the log parameter) enables you to restrict the number of messages that the Cisco IOS generates on matches, reducing an overload on the router. IP accounting enables you to identify traffic that matches a deny statement in an ACL, providing more information about the dropped packet. Turbo ACLs allow the Cisco IOS to compile ACLs, making them more efficient and faster to process. Sequenced ACLs enable you to insert or delete a specific ACL entry in your statement grouping without having to delete the entire ACL and rebuild it. The following sections cover these enhanced features.
ACL Remarks
As of Cisco IOS 12.0(2)T, you can include remarks in your ACL statements. Before this, most administrators created a text configuration file with their ACLs, using comments to accomplish the same thing, as displayed in Example 7-12.
Example 7-12 Using Comments in Your Configuration
! This ACL is used to restrict access to the router:
access-list 1 permit 192.168.1.10
access-list 1 permit 192.168.1.11
! Activating it on the VTYs
line vty 0 4
access-class 1 in
The problem with this approach is that when this was loaded into the Cisco IOS, the Cisco IOS ignored the comments. Therefore, you always had to look back to your text file to determine what an ACL was for or what a particular statement was intended to do.
Remarks are supported with both numbered and named ACLs. Here is the syntax for entering a remark in either one:
Router(config)# access-list ACL_# remark remark
or:
Router(config)# ip access-list {standard | extended} ACL_name
Router(config-{std | ext}-nacl)# remark remark
The remark that you enter can be up to 100 characters in length. If you enter a remark that is longer than 100 characters, any extra characters automatically are truncated. When you enter a remark, it is inserted after the last ACL command that you entered. However, using sequenced ACLs, you can insert a remark or multiple remarks anywhere in your ACL statement grouping. Example 7-13 shows a simple example of an ACL that is used to restrict VTY access to a router.
Example 7-13 Using the remark Command in an ACL
Router(config)# access-list 1 remark This ACL restricts administrator
Router(config)# access-list 1 remark -----access to the router for
Router(config)# access-list 1 remark -----VTY access
Router(config)# access-list 1 remark -----
Router(config)# access-list 1 remark -----Allow Richard access
Router(config)# access-list 1 permit 192.168.1.10
Router(config)# access-list 1 remark -----Allow Natalie access
Router(config)# access-list 1 permit 192.168.1.11
As you can see from this example, it is much easier to understand what the ACL is used for and what each statement is doing.
Logging Updates
As I mentioned earlier with standard and extended ACLs, you can add the optional log parameter to a specific ACL statement(s), causing the Cisco IOS to generate a log message when a packet matches the condition in the statement. This is a very useful feature when you are trying to determine what kinds of traffic you are dropping (specifically, to see what hackers and curious individuals are attempting to send into your network).
I mentioned that logging affects the performance of your router: It no longer can use high-speed switching methods such as CEF. Another issue with the default logging function is that the Cisco IOS displays a message on the first matching packet, but it displays another message on a subsequent match only after a 5-minute interval has expired. The problem with this is that if someone is probing or attacking a particular device or part of your network, you probably will see only a small number of log messages.
As of 12.0(2)T, you can change the logging threshold. To change the threshold of logging, use the following command:
Router(config)# ip access-list log-update threshold #_of_matches
This command defines a threshold for how often a log message is generated. When you specify the value for the number of matches, the Cisco IOS generates a log message after each number of matches. For example, if you set the number of matches to 5, the Cisco IOS generates a log message on the first match, then a message after five subsequent matches, then another message after another five subsequent matches, and so on. This enables you to control how much logging your router generates.
One caveat with the configuration of this command is that, even if you configure a threshold, the Cisco IOS clears its cache of counts after a 5-minute period. As an example, assume that you set a threshold of five packets. Someone sends a packet that matches on a condition with logging enabled, so, because this is the first match, the Cisco IOS generates a message. This person sends two more packets, totaling three. Because the threshold of five has not been reached no additional messages are generated. At this point, the 5-minute period expires and the Cisco IOS clears its matching count cache, setting all counts to 0 for the ACL. The person then sends his fourth packet. From the Cisco IOS perspective, this is counted as the first packet, and it causes a logging message to be generated.
Caution
If you are under an attack, you might want to set up this threshold to gather more logging information about what is occurring. Be careful, though, of setting the logging update threshold to a very small value, such as 1. Doing this causes your Cisco IOS to generate a lot more log messages. With a massive DoS attack by a hacker, this easily could flood your router and bring it to its knees, if not crash it. Cisco recommends not setting this to 1.
IP Accounting and ACLs
The IP accounting feature has been around since Cisco IOS 10.0. Actually, IP accounting initially was intentioned to gather traffic statistics for accounting purposes. However, an option was added to it to log statistics for access violations. This feature enables you to get more information about traffic that matches a deny statement in an ACL (available in Cisco IOS 10.3).
Configuration of Accounting
To enable accounting for logging violations, configure the following:
Router(config)# interface type [slot_#/]port_#
Router(config-if)# ip accounting access-violations
When you enable IP accounting for access violations, the Cisco IOS keeps track of the source and destination address that matched the deny statement, as well as the number of packets and bytes and the ACL number or name that was matched. To view your access-violation accounting information, use the show ip accounting access-violations command.
Note
One restriction with IP accounting is that it can gather accounting information for only transit information—traffic that is not destined to the router itself or traffic that the router itself generates.
IP accounting also works with process, fast, and CEF switching, but it disables autonomous and SSE switching.
Example 7-14 shows a sample of a router filtering ICMP traffic, with accounting enabled, as well as its verification.
Example 7-14 Using IP Accounting to Log ACL Matches
Router(config)# access-list 100 deny icmp any any
Router(config)# access-list 100 permit ip any any
Router(config)# interface fastethernet0
Router(config-if)# ip address 192.168.1.254 255.255.255.0
Router(config-if)# ip access-group 100 in
Router(config-if)# ip accounting access-violations
Router(config-if)# end
Router# show ip accounting access-violations
Source Destination Packets Bytes ACL
192.168.1.100 192.168.2.253 4 240 100
Accounting data age is 9
Router#
In this example, all ICMP traffic is filtered, but everything else is permitted. Notice that IP accounting is enabled on the fastethernet0 interface. In the output of the show ip accounting access-violations command, 192.168.1.100 tried pinging a remote destination (192.168.2.253), which was filtered by the router’s ACL, and its accounting information was recorded: Four packets, totaling 240 bytes, were dropped by ACL 100.
Restriction of Accounting Information
Remember that any packet that matches a deny statement (or the implicit deny) generates or updates an accounting record when access violations are enabled. Because IP accounting can generate a large amount of information, you will want to restrict it to a reasonable amount that the router can handle. You can use three commands to restrict the amount of accounting information:
• ip accounting-list—Filters accounting information based on the addresses listed
• ip accounting-threshold—Defines the maximum number of accounting records that the router will create
• ip accounting-transits—Limits the number of transit records that the router stores
Filtering Accounting Information
To limit accounting information to just specific hosts, use the ip accounting-list command:
Router(config)# ip accounting-list IP_address wildcard_mask
With this command, enter an IP address or network number, and qualify it with a wildcard mask (this is the same wildcard mask used with standard and extended ACL statements). You must configure both of these parameters. You also can specify more than one record to capture traffic from a multitude of sources or destinations.
Restricting accounting data is useful if you know that an attack is occurring to or from a specific device. Normally, you might not know what device is creating the attack, but you easily can find out which internal device (or network or subnet) is bearing the brunt of the attack. Knowing this information, you can restrict accounting information with your device’s IP address or your internal network number. By using this command, you can focus your accounting information on just the matches on deny statements for specific devices.
Defining Thresholds
By default, the Cisco IOS stores up to 512 entries in its internal accounting database. An entry is basically a source-destination address pairing. With 512 entries, this takes up 12,928 bytes of memory. This number of address pairings is actually not very much, so you can increase this using this command:
Router(config)# ip accounting-threshold threshold_value
The threshold value is the maximum number of entries that you want the Cisco IOS to store in the accounting database. It can range from 0 to 4,294,967,295!
Caution
Be careful not to set the accounting threshold value to too large of a size. Setting this value too high can cause a router to consume all its free memory, creating buffer overflow problems and possible crashes.
Limiting Number of Transit Records
Besides limiting the number of accounting records or the devices for which accounting records are created and maintained, you can limit the number of transit records that the Cisco IOS maintains.
One problem of using the ip accounting-list command is that only devices included in the list have accounting information maintained for them. In certain instances you still want accounting information displayed for other devices, but you want to control the amount of additional accounting records that this creates in memory.
The ip accounting-transits command accomplishes this task:
Router(config)# ip accounting-transits #_of_records
With this command, the default number of transit records kept defaults to 0. Therefore, accounting information is generated only when a device listed in the ip accounting-list command matches a deny statement. As an example, you might want to keep accounting records for certain devices, but allow up to 100 other devices to generate records. To accomplish this, use this configuration:
Router(config)# ip accounting-transits 100
In this example, up to 100 additional address-pairs are kept in the accounting database besides the ones specified in the ip accounting-list command(s).
Note
Other commands for IP accounting have nothing to do with security. This section focuses only on the ones that can be used to help with security auditing and logging.
Turbo ACLs
Normally, ACLs are searched sequentially, from the first to the last entry, when trying to find a match on a condition. However, very long ACLs can slow down the search process to find a match on a condition. In addition, depending on the packet contents, one packet might match on one of the first statements in an ACL, while another might match on one of last statements in an ACL, producing a variable delay in latency that then affects delay-sensitive traffic.
Cisco developed turbo ACLs to speed up the processing of ACLs and to produce a more defined latency period during ACL processing. This feature is available only on the 7100, 7200, 7500, and 12,000 Gigabit Switch routers. Turbo ACLs are basically ACLs that are compiled into a lookup table that still maintains first-match requirements (remember, order of statements is important). The Cisco IOS uses packet headers to match against these table entries in a small number of lookups, which is independent of the number of ACLs in the original list.
Turbo ACLs provide these two advantages:
• The time to find a match is fixed, so latency is smaller and consistent. This is important with very large ACLs and mixed types of data traffic.
• For ACLs that have three or more entries, turbo ACLs reduce the CPU processing cycles required to find a match. Actually, the CPU load to find any match is fixed, no matter how many ACL statements are in the ACL list. Therefore, the larger the list is, the better the performance gain is.
Turbo ACLS have limitations, of course. For example, you cannot use timed entries or reflexive entries in ACLs (discussed in Chapter 8). In addition, when you compile an ACL, you need an additional 2 to 4 MB of memory to hold the compiled contents. The show access-list compiled command displays the memory overhead used by the compiled ACL(s).
Turbo ACLs were introduced in Cisco IOS 12.0(6)S and on the 7200 in 12.1(1)E. They have been integrated into 12.1(5)T. By default, turbo ACLS are disabled on a router that supports them. To compile your ACLs on a supported router, use this command:
Router(config)# access-list compiled
This command has no parameters; in other words, you cannot choose which ACLs are compiled and which ones are not. Instead, if an ACL can be compiled, the Cisco IOS compiles it automatically. When compiling, the Cisco IOS scans the ACL and then compiles the ACL, if the Cisco IOS can. For large and complex ACLs, it might take a few seconds (or minutes) for the compilation to complete. After an ACL is compiled, any changes that you make to the ACL automatically trigger a recompilation of the ACL. While an ACL is being compiled or recompiled, the Cisco IOS uses the uncompiled ACL to filter traffic.
After you have enabled a turbo ACL on your router, you can use the show access-list compiled command to verify its successful configuration and operation, as displayed in Example 7-15.
Example 7-15 Using the show access-lists compiled Command
Router# show access-lists compiled
Compiled ACL statistics:
4 ACLs loaded, 4 compiled tables
ACL State Tables Entries Config Fragment Redundant Memory
1 Operational 1 2 1 0 0 1Kb
100 Operational 1 15 9 7 1 1Kb
101 Operational 1 13 6 6 0 1Kb
102 Operational 1 2 1 0 0 1Kb
First level lookup tables:
Block Use Rows Columns Memory used
0 TOS/Protocol 6/16 12/16 66048
1 IP Source (MS) 10/16 12/16 66048
2 IP Source (LS) 27/32 12/16 132096
3 IP Dest (MS) 3/16 12/16 66048
4 IP Dest (LS) 9/16 12/16 66048
5 TCP/UDP Src Port 1/16 12/16 66048
6 TCP/UDP Dest Port 3/16 12/16 66048
7 TCP Flags/Fragment 3/16 12/16 66048
Router#
An ACL can be placed in five states:
• Operational—The ACL has been compiled successfully.
• Deleted—The ACL is empty (no entries).
• Unsuitable—The ACL cannot be compiled because it contains time-range, reflexive, or dynamic entries.
• Building—The ACL is currently being compiled, which might take a few seconds to complete.
• Out of memory—The router does not have enough memory to compile the ACL.
Sequenced ACLs
For years, customers have been complaining about how difficult it is to maintain ACLs: adding, modifying, or deleting statements in an ACL. I detailed how this was done using a text editor, in Chapter 6. I have been using this process for more than a decade now, and I always have found it to be a tedious, error-prone process.
Hallelujah! Cisco has implemented a feature that enables you to delete specific entries in an ACL, as well as insert entries anywhere you want within an ACL. Cisco calls this feature sequenced ACLs. This makes your ACL-editing process much simpler. Actually, sequenced ACLs are not a new ACL type: They use normal standard or extended named ACLs (numbered ACLs are not supported). This feature was introduced in Cisco IOS 12.2(14)S and has been integrated into 12.2(15)T and 12.3(2)T.
Note
Sequenced ACLs work only with named standard or extended ACLs. However, you can create a named ACL and give it a number as its name, such as ip access-list extended 100. This is common with old-school administrators who have been dealing with ACLs for years. Likewise, you can take a normal numbered ACL and treat it like a named ACL, using the ip access-list {standard | extended} command, where you reference the number in the name field.
ACLs and Sequencing
With sequenced ACLs, each ACL entry is associated with a sequence number. Sequence numbers then can be used to insert an ACL into the middle of an existing list or to delete an existing statement in the list. And if you do not like the sequence numbers that the Cisco IOS assigns to the list, you can resequence them with your own numbering scheme. This ensures that you always can insert ACL statements into a list.
Working with sequenced ACLs is a simple process. However, you need to be aware of some things when adding or deleting entries in a sequenced ACL. First, all ACL statements have sequence numbers—even if you did not assign them any. If you upgrade your Cisco IOS to one that supports sequenced ACLs, the Cisco IOS automatically assigns a sequence number to each statement. The first statement in the list is assigned a sequence number of 10, and every subsequent statement’s sequence number is 10 more than the previous one. For example, if you had three statements in your ACL, the default sequence numbers would be 10, 20, and 30. Of course, you do not have to use the standard sequencing that Cisco assigns to ACLs. For route-processor cards and line cards, any sequencing or resequencing that you do automatically is synchronized by the route processor card to all the line cards.
You can create your own sequencing process. For example, you can have ACL sequence numbers incrementing by 100 instead of 10. However, the maximum sequence number that can be assigned is 2,147,483,647. If you exceed this number, you will see the following error message:
Exceeded maximum sequence number.
If you enter an ACL statement without specifying a sequence number, the router uses the default increment of 10 when adding the statement to the end of the list. This applies to a new ACL grouping as well. If you enter an ACL command that already is in the list but that has a different sequence number, the router ignores your input. If you enter a new ACL statement, where it is a unique command in the list, but you have specified a sequence number that is already in use, you will see the following error message:
Duplicate sequence number.
In this case, the Cisco IOS aborts your command, and you need to assign a different sequence number to your statement.
Any sequence numbers that are applied to an ACL are not saved to NVRAM. Each time that the router boots up, the Cisco IOS applies the default sequencing scheme, assigning a sequence number of 10 for the first statement and incrementing sequence numbers by 10 for subsequent statements. Cisco did this to ensure backward compatibility for older Cisco IOS versions that do not support sequence numbers. Therefore, if you resequence your list to multiples of 100, this is not saved when you execute the copy running-config startup-config command.
Resequencing ACLs
Remember that you do not have to sequence a named ACL first; the Cisco IOS does this automatically by starting at 10 and incrementing each statement’s sequence number by 10 for following statements. Optionally, you can implement your own sequencing method using the following command:
Router(config)# ip access-list resequence ACL_name
starting_seq_# increment
As an example, if you want to resequence the ACL named 100, you would follow these steps. First, display the current ACL with the show access-list command, as shown in Example 7-16 (this is the same ACL that I used previously for the network in Figure 7-2).
Example 7-16 Displaying the Sequence Numbers for ACLs
Router# show access-list 100
Extended IP access list 100
10 permit tcp any host 200.1.1.14 eq www
20 permit udp any host 200.1.1.13 eq domain
30 permit tcp any host 200.1.1.12 eq smtp
40 permit tcp any eq smtp host 200.1.1.12 established
50 permit tcp any host 200.1.1.11 eq ftp
60 permit tcp any host 200.1.1.11 eq ftp-data
70 permit tcp any eq www 200.1.2.0 0.0.0.255 established
80 permit udp any eq domain 200.1.2.0 0.0.0.255
90 deny ip any any
Notice that the ACL statements use the default sequencing. In this example, I am going to change the sequence numbers to start at 1 and increment by 1. Here is the command to change the sequencing:
Router(config)# ip access-list resequence 100 1 1
To verify the configuration, redisplay the ACL as displayed in Example 7-17.
Example 7-17 Viewing Updated ACL Sequence Numbers
Router# show ip access-list 100
Extended IP access list 100
1 permit tcp any host 200.1.1.14 eq www
2 permit udp any host 200.1.1.13 eq domain
3 permit tcp any host 200.1.1.12 eq smtp
4 permit tcp any eq smtp host 200.1.1.12 established
5 permit tcp any host 200.1.1.11 eq ftp
6 permit tcp any host 200.1.1.11 eq ftp-data
7 permit tcp any eq www 200.1.2.0 0.0.0.255 established
8 permit udp any eq domain 200.1.2.0 0.0.0.255
9 deny ip any any
Notice that the sequence numbers have changed. At any given time, you can resequence the numbers in your ACL.
Deleting an Entry in a Sequenced ACL
Deleting a sequenced ACL entry is just as simple as resequencing it. If you want to delete a specific entry in the ACL, first display the entries with the show access-list command and note the sequence number to the left of the statement that you want to delete. Next, enter the subconfiguration mode for the named ACL, and then delete the command by prefacing the sequence number of the statement with the no parameter. Here is a simple breakdown:
Router# show access-list
<--output omitted-->
Router# configure terminal
Router(config)# ip access-list {standard | extended} ACL_name
Router(config-{std | ext}-nacl)# no sequence_#
As you can see from this example, deleting an entry is straightforward. To illustrate this, in Example 7-18, I delete entry number 9 from the resequencing Example 7-17.
Example 7-18 Deleting a Specific Sequenced ACL Entry
Router(config)# ip access-list extended 100
Router(config-ext-nacl)# no 9
Router(config-ext-nacl)# end
Router# show access-list 100
Extended IP access list 100
1 permit tcp any host 200.1.1.14 eq www
2 permit udp any host 200.1.1.13 eq domain
3 permit tcp any host 200.1.1.12 eq smtp
4 permit tcp any eq smtp host 200.1.1.12 established
5 permit tcp any host 200.1.1.11 eq ftp
6 permit tcp any host 200.1.1.11 eq ftp-data
7 permit tcp any eq www 200.1.2.0 0.0.0.255 established
8 permit udp any eq domain 200.1.2.0 0.0.0.255
As you can see in this example, deleting entry 9 was as simple as entering no 9.
Inserting an Entry in a Sequenced ACL
Inserting an entry in a sequenced ACL is also very simple. If you want to insert an entry in the ACL, first display the entries with the show access-list command and note the two sequence numbers of the statements where you want to insert your new ACL statement. Choose a number between these two sequence numbers; if there is no room, resequence the ACL. Next, enter the subconfiguration mode for the named ACL and then enter your sequence number for the new ACL, the action (permit or deny), and the condition. Basically, this is exactly the same as adding a normal named ACL statement, with the exception of putting the sequence number at the beginning of the line. Here is a simple breakdown:
Router# show access-list
<--output omitted-->
Router# configure terminal
Router(config)# ip access-list {standard | extended} ACL_name
Router(config-{std | ext}-nacl)# sequence_# {permit | deny} condition
As you can see from this example, inserting an entry is straightforward. To illustrate this, in Example 7-19 I add back entry number 9 from the deletion example in Example 7-18, using a sequence number of 50 for this entry.
Example 7-19 Previewing an ACL Before Inserting an ACL Statement
Router# show access-list 100
Extended IP access list 100
1 permit tcp any host 200.1.1.14 eq www
2 permit udp any host 200.1.1.13 eq domain
3 permit tcp any host 200.1.1.12 eq smtp
4 permit tcp any eq smtp host 200.1.1.12 established
5 permit tcp any host 200.1.1.11 eq ftp
6 permit tcp any host 200.1.1.11 eq ftp-data
7 permit tcp any eq www 200.1.2.0 0.0.0.255 established
8 permit udp any eq domain 200.1.2.0 0.0.0.255
As you can see from this ACL, sequence number 50 does not exist, so in Example 7-20, I add the statement that I previously deleted back into the ACL.
Example 7-20 Inserting an ACL Statement
Router(config)# ip access-list extended 100
Router(config-ext-nacl)# 50 deny ip any any
As you can see, I added my new statement with a sequence number of 50. Next, I view my ACL configuration to verify the statement’s placement within the ACL, as displayed in Example 7-21.
Example 7-21 Verifying the Statement’s Placement Within the ACL
Router# show access-list 100
Extended IP access list 100
1 permit tcp any host 200.1.1.14 eq www
2 permit udp any host 200.1.1.13 eq domain
3 permit tcp any host 200.1.1.12 eq smtp
4 permit tcp any eq smtp host 200.1.1.12 established
5 permit tcp any host 200.1.1.11 eq ftp
6 permit tcp any host 200.1.1.11 eq ftp-data
7 permit tcp any eq www 200.1.2.0 0.0.0.255 established
8 permit udp any eq domain 200.1.2.0 0.0.0.255
50 deny ip any any
In this example, my new statement is placed in the correct location.
From these last two sections, you can see that editing an ACL is a breeze when using sequence numbers. It takes the wonderful pain out of editing ACLs and reduces the number of stories that I can tell my students about stupid editing mistakes I have made using the old method.