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
Figure 7-1. Restricting VTY Access
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
ospf? OSPF routing protocol
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.
Name | Port Number | Description |
|---|---|---|
bgp | 179 | Border Gateway Protocol |
chargen | 19 | Character generator |
cmd | 514 | Remote commands (rcmd) |
daytime | 13 | Daytime |
discard | 9 | Discard |
domain | 53 | Domain Name System zone transfers |
echo | 7 | Echo |
exec | 512 | Remote commands/shell (rsh) |
finger | 79 | Finger |
ftp | 21 | File Transfer Protocol control channel |
ftp-data | 20 | FTP data channel |
gopher | 70 | Gopher |
hostname | 101 | NIC host name server |
ident | 113 | Ident protocol |
irc | 194 | Internet Relay Chat |
klogin | 543 | Kerberos login |
kshell | 544 | Kerberos shell |
login | 513 | Remote login (rlogin) |
lpd | 515 | Remote printing |
nntp | 119 | Network News Transport Protocol |
pim-auto-rp | 496 | PIM Auto Rendezvous Point |
pop2 | 109 | Post Office Protocol v2 |
pop3 | 110 | Post Office Protocol v3 |
smtp | 25 | Simple Mail Transport Protocol |
sunrpc | 111 | Sun remote-procedure call |
syslog | 514 | Logging to a syslog server |
tacacs | 49 | TAC access control system server connection |
talk | 517 | Talk |
telnet | 23 | Telnet |
time | 37 | Time |
uucp | 540 | UNIX-to-UNIX copy program |
whois | 43 | Nickname |
www | 80 | World Wide Web (HTTP) |
0 to 65,535 | Valid port numbers |
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.
Name | Port Number | Description |
|---|---|---|
biff | 512 | Biff mail notification and comsat |
bootpc | 68 | BootP client |
bootps | 67 | BootP server |
discard | 9 | Discard |
dnsix | 195 | DNSIX security protocol auditing |
domain | 53 | DNS queries and replies |
echo | 7 | Echo |
isakmp | 500 | Internet Security Association and Key Management Protocol |
mobile-ip | 434 | Mobile IP registration |
nameserver | 42 | IEN116 name service, which is now obsolete |
netbios-dgm | 138 | NetBIOS datagram service |
netbios-nm | 137 | NetBIOS name service |
netbios-ss | 139 | NetBIOS session service |
non500-isakmp | 4500 | ISAKMP on nonstandard port |
ntp | 123 | Network Time Protocol |
pim-auto-rp | 496 | PIM Auto Rendezvous Point |
rip | 520 | Routing Information Protocol |
snmp | 161 | Simple Network Management Protocol |
snmptrap | 162 | SNMP traps |
sunrpc | 111 | Sun remote-procedure calls |
syslog | 514 | Remote logging of messages |
tacacs | 49 | TAC Access Control System |
talk | 517 | Talk |
tftp | 69 | Trivial File Transfer Protocol |
time | 37 | Time |
who | 513 | Remote who service (rwho) |
xdmcp | 177 | X Display Manager Control Protocol |
0 to 65,535 | Valid port numbers |
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.
