Router Access Lists
Gilbert Held Routers are designed to interconnect geographically separated networks. As such, this device also represents an entry point into a network, and has the associated security issues. Recognizing this fact, router manufacturers have added an access list capability, which is the subject of this article. An access list, also known as an access control list, represents one or more statements that perform packet filtering when executed by a router. Access lists can be configured for a variety of network protocols, such as Apple Talk, IP, IPX, DECnet, and Vines. Once an access list is created, it must be applied to an interface to take effect. In doing so, consider whether you wish to filter packets flowing into your network from an untrusted area, or packets leaving your network, or both. Rationale for Use While the primary use of access lists is to bar traffic and thereby enhance network security, there are other reasons to use this router feature. One reason is the ability to filter packets based upon the IP Type of Service (TOS) field. This allows traffic to be prioritized when entering or leaving a queue. Another reason for using access lists is to implement corporate policy concerning the use of different services on an intranet or accessible via the Internet. For example, corporate policy may be to bar all or certain employees from Web surfing. Restricting the contents of routing updates and providing a mechanism for traffic flow are other reasons for configuring access lists. However, the primary reason is to obtain a basic level of security. In this article, I primarily focus on the use of access lists to enhance network security. Examples in this article focus on Cisco access lists. However, other router vendors follow a similar methodology by which access lists are created and applied to an interface, either inbound or outbound. Although you may need to tailor examples in this article to the access list format supported by other router manufacturers, the basic concepts are applicable to most routers. This article should serve as a guide concerning the use of a router's access list as the first line of defense of a network, regardless of the manufacturer of the device. Although access lists were developed to support different protocols, I focus on the IP protocol. IP is the only protocol supported for use on the Internet and most organizations that use access lists for security do so with respect to data flowing to and from the Internet. Types of Access Lists There are two basic types of access lists supported by Cisco routers -- standard and extended. A standard access list is limited to performing filtering on source addresses. In comparison, an extended access list permits filtering based upon source address, destination address, source port, destination port, and even the setting of bits within certain fields of a packet. Here is a basic format of a standard IP access list:
access-list list # {permit | deny } source [wildcard-mask] [log]
Although you can only assign one access list to one direction on an interface, a router can support multiple access lists. The list # represents a decimal from 1 to 99 that identifies a particular access list. Additionally, because Cisco assigns numeric ranges to different types of access lists with respect to the protocols they operate on, the list # also serves to identify the protocol that will be filtered. This means that a list number from 1 to 99 identifies a standard IP access list. Note that you would specify either the keyword permit or deny in an access list statement. The use of permit enables a packet to flow through an interface when conditions specified in the access list are matched. Similarly, the use of deny sends a packet to the great bit bucket in the sky when conditions match those specified in the access list. The source entry in the standard access list format represents the IP address of a host or network from which the packet was transmitted. You can specify the source either via the use of a 32-bit IP address denoted in dotted decimal notation or you can use the keyword any to represent any IP address. The wildcard-mask functions as a reverse network address subnet mask. That is, you would place ones in the bit positions that you wish to ignore. For example, assume your organization has the IP class C network address of 198.78.46.0. When you configure your TCP/IP protocol stack you would use the subnet mask 255.255.255.0 to specify the absence of subnets. Here the trailing byte of 0's indicates a “don't care” condition and results in hosts 1 through 254 being considered as residing on the network. If you're configuring Cisco access lists, the wildcard mask uses an inverse of the subnet mask, with one bits placed in positions you wish to ignore instead of zeroes used in a subnet mask. If you wish to allow all hosts on network 198.78.46.0, the wildcard-mask would be 0.0.0.255. An example of a standard IP access list statement permitting IP packets from all hosts on the 198.78.46.0 network would be:
access-list 1 permit 198.78.46.0 0.0.0.255. Note that list number 1 is in the range 1 to 99. Thus, the list number identifies the access list as a standard IP access list. Also note that the keyword access-list is entered with a dash (-) between access and list. When you use the optional term log in the standard IP access list, it results in an informational logging message about packets that matches an access list statement being sent to the console. Logging can be an effective tool both for developing complex access lists as well as for generating information about the number of packets permitted or denied by an access list. It can be tedious to enter wildcard-masks for specific network addresses when constructing an access list with a large number of statements. Instead, you can use the keyword host to reference a specific address. Rather than entering 198.78.46.8 0.0.0.0 to reference the specific IP address of 198.78.46.8, you could enter host 198.78.46.8 as a shortcut reference. Extended Access Lists An extended access list increases the capability of router packet filtering. Through the use of an extended access list, you can filter on source and destination addresses, layer 4 ports, protocol, and even the bit settings within certain packet fields. The general format of an extended IP access list is:
accesss-list list # {permit|deny} [protocol] source source- \
wildcard [port] destination destination - wildcard [port] \
[established] [log] [other options]
Similar to a standard access list, the list number defines the type of list. To define an extended IP access list, use a list number between 100 and 199. Because IP includes ICMP, TCP, and UDP, you can create a more explicit access list statement by specifying an IP protocol. In fact, you can even specify a routing protocol in an access list. Unlike a standard access list that is restricted to filtering based on a source address for all IP traffic, you can filter based upon a particular IP protocol, source and destination address, source and destination ports, as well as use such keywords as established, log, and other options. Both source and destination ports are optional and are used when filtering on layer 4 information. You can specify a port number, the mnemonic of a port number, such as SNMP, or use the keyword RANGE to create specific ranges of port numbers. You can also use mnemonics to represent numeric operations, such as GT for “greater than”, LT for “less than”, and EQ for “equal to”. You could specify filtering based on SMTP for source or destination ports or both by substitution, either EQ 25 or EQ SMTP for source port or destination port since port number 25 represents SMTP. The keyword established is only applicable for the TCP protocol. When used in an access list statement, a match occurs if a TCP datagram has either its ACK or RST bits sets. This situation occurs when a packet flowing in one direction represents a response to a session initiated in the opposite direction. One common use of an extended IP access list with the keyword established is to only permit packets that represent a response to a session initiated via the trusted private network side of a router to enter a network from the Internet. For example, consider the following extended IP access list statement:
access-list 101 permit tcp any any established The list number of 101 identifies the access list as an extended IP access list. The protocol specified is tcp, and we will permit packets to flow from any source to any destination address if their ACK or RST bit is set, which indicates the packet is part of an established conversation. Thus, you normally need to apply the preceding statement to a serial interface connecting a router to the Internet. However, you also need to apply the access list containing the preceding statement in the inbound direction, if you want to consider restricting tcp traffic from the Internet to sessions established by hosts on your internal network or networks connected via the router to the Internet. Consider the following access list consisting of three statements:
access-list 101 permit tcp any any established access-list 101 permit ip any host 198.78.46.8 access-list 101 permit icmp any any echo-reply The first statement permits TCP datagrams that are part of an established conversation. The second statement permits IP traffic from any host to the specific host whose IP address is 198.78.46.8. Here the keyword host followed by an IP address is equivalent to an IP address followed by a wildcard-mask of 0.0.0.0. The third statement in the access list permits ICMP from any host to any host if the packet is a response to a ping request (echo-reply). Note that if you apply this access list in the inbound direction on a serial interface connecting a router to the Internet, the result will be to allow responses to pings originating from the trusted side of the router. Because an access list is based upon the premise that all is denied unless explicitly allowed, if you apply the preceding access list in the inbound direction, pings originating on the Internet destined to any host on the 198.78.46.0 network other than host 198.78.46.8 will be blocked. pings can flow to host 198.78.46.8 because the second statement permits IP traffic to include ICMP to that host. If you wanted to preclude pings to that host, you could insert a deny ICMP statement before the permit IP statement. This illustrates an important concept concerning access list processing -- the contents of packets are matched against statements in an access list in their sequence. If access list statement n permits or denies a packet then statement n+1 will not be matched against the packet. Thus, it is important to review the order by which statements are entered into an access list. New Capabilities In tandem with several relatively recent updates to the Cisco Internetwork Operating System (IOS) were improvements to the functionality and capability of access lists. Four additions to access lists include named access lists, reflexive access lists, time-based access lists, and TCP intercept. Actually, these additions represent additional capabilities added to access lists and do not literally represent new types of access lists. Named Access Lists Each type of access list has a limited range of acceptable numbers so it is theoretically possible, although highly unlikely, that you could run out of numbers when configuring an enterprise router. Perhaps a more important reason for named access lists is that a name can be more meaningful than a number. In any event, named access lists were introduced in Cisco's IOS Version 11.2. Revising our previously presented access list into a named extended IP access list called “inbound”, we would obtain the following statements:
ip access-list extended inbound permit tcp any any extended permit ip any host 198.78.46.8 permit icmp any any echo-reply One important aspect of named access lists is that they enable you to delete specific entries in the list. This is accomplished by entering a “no” version of a specific statement contained in a named access list, such as no permit ip any host 198.78.46.8 to remove the second permit statement. This action is not possible with a numbered access list. To revise a numbered access list, you must create a new list, delete the old list, and apply the new list to the appropriate interface. Reflexive Access Lists One of the limitations associated with the keyword established in an extended IP access list is that it's only applicable to TCP. To control other upper-layer protocols, such as UDP and ICMP, you must either permit all incoming traffic or define a large number of permissible source/destination host/port addresses. Besides being tedious and time consuming, the resulting access list could require more memory than available on your router. Perhaps recognizing this problem, Cisco introduced reflexive access lists in IOS Version 11.3. A reflexive access list creates a dynamic, temporary opening in an access list. The opening is triggered (or is in reflex to) when a new IP traffic session is initiated from inside your network to an external network. The temporary opening is always a “permit” list entry, and specifies the same protocol as the original outbound packet. The opening also swaps source and destination IP addresses and upper-layer port numbers, and will exist until either the session initiated on the trusted network is closed or an idle timeout value is reached. There are four general tasks associated with the creation of a reflexive access list. First, you create an extended named access list. In an IP environment, you would use this command format.
ip access-list extended name where “name” represents the name of the access list. Next, create one or more permit entries to establish reflected openings. Because a reflexive access list is applied to outbound traffic, it will result in temporary openings appearing in an inbound access list. When defining permit statements for your outbound access list, use this statement format:
permit protocol any any reflect name [timeout seconds] You can use the keyword “timeout” to assign a timeout period to each specific reflexive entry created in the inbound direction. If you don't use this option, a default timeout of 300 seconds will be used for the opening. You can also place a global timeout on all reflexive statements. To do so, use this global command:
ip reflexive-list timeout value where “value” is the global timeout value in seconds. As a third task, create an access list for inbound filtering into which dynamic reflexive entries will be added. This command concludes the operation:
evaluate name where “name” represents the name of the access list and which causes packets to be evaluated by reflexive entries. The following example illustrates the creation of a reflexive access list where the reflected openings are limited to 180 seconds of idle time. Note that the three deny statements in the extended access list named inbound are conventional statements that are not reflected. Also note that those statements are commonly referred to as anti-spoofing entries. Many times hackers use RFC 1918 private network IP addresses in an attempt to prevent network operators from identifying the source address of an attack:
! ip reflexive-list timeout 180 ! ip access-list extended outbound permit tcp any any reflect my_session permit udp any any reflect my_session permit icmp any any reflect my_session ! ip access-list extended inbound deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.31.255.255 any deny ip 192.168.0.0 0.0.255.255 any evaluate my_session Although reflexive access lists considerably extend the capability of packet filtering, they are limited to single channel connections. Applications such as ftp, which use multiple port numbers or channels, cannot be supported by reflexive access lists. However, a special release of IOS, initially referred to as the Firewall Feature Set (FFS), introduced support for dynamic openings in access lists for multi-channel applications. It is now referred to as Context Based Access Control (CBAC) in IOS Release 12.0. CBAC also adds Java blocking, denial-of-service prevention and detection, real time alerts, and audit trails. Unfortunately, CBAC is only applicable for certain platforms, and a discussion of its numerous options and configuration parameters is beyond the scope of this article. Time Based Access Lists Until IOS Version 12.0, there was no easy way for an administrator to establish different security policies based upon the time of day or date. Although an administrator could create multiple access lists and apply them at different times, doing so could be complex. With the introduction of IOS Version 12.0, time-based access lists provided the flexibility to implement different policies based on time. In the wonderful world of IP, the use of time-based access lists is a relatively easy two-step process. First, define a time range. Then, reference the time range in an access list entry. You can specify a time range by using a time-range statement like this:
time-range time-range-name where “time-range-name” is the name you assign to the time range. Once the name is assigned, you can specify a time range in one of two ways. You can use an “absolute” statement or a “periodic” statement, such as these:
absolute [start time date] [end time date] periodic days-of-the-week hh:mm to [days-of-the-week] hh:mm The “time” parameter is entered in the format hh:mm where hours (hh) are expressed in a 24-hour format. You can list the days of the week separated by spaces or use the keywords “daily” or “weekend”. After creating the time-range statement, you can reference it through the optional keyword “time-range” in a traditional access list entry. This example illustrates the creation of a time-based access list that restricts Web access to Monday through Friday from 8 am to 5 pm.
time-range allow-http Periodic weekdays 8:00 to 17:00 ! access-list 101 permit tcp any any eq 80 time-range allow-http TCP Intercept The TCP intercept feature was added in IOS Version 11.3 as a mechanism to alleviate a type of denial-of-service attack referred to as “SYN flooding”. Under TCP's three-way handshake, the first packet in a session has the SYN bit sent. The recipient of this initial packet requesting a service, such as HTTP, responds with a packet in which the SYN and ACK bits are set and waits for an ACK from the originator of the session. If the originator of the request fails to respond, the host times out the connection. However, while the host is waiting for the conclusion of the three-way handshake, the half-open connection consumes resources. Suppose an unscrupulous person modifies software to transmit tens of thousands of packets with their SYN bit set, using forged IP source addresses. This results in the attacked host never receiving a response to its request to complete each three-way handshake. Thus, its resources will be consumed as it times out each session only to be faced with a new flood of additional bogus packets with their SYN bit set. As host resources are consumed, its potential decreases to a point where little or no useful work occurs. Because of the popularity of this method of attack, TCP intercept was added as a mechanism to limit half-open connections flowing through a router. The TCP intercept feature works by intercepting and validating TCP connection requests. The feature can operate in one of two modes -- intercept or watch. When it's in intercept mode, the router intercepts inbound TCP synchronization requests and establishes a connection with the client on behalf of the server (and with the server on the behalf of the client) thereby functioning as a proxy agent. If both connections are successful the router will merge them. To prevent router resources from being fully consumed by a SYN attack, the router has aggressive thresholds and will automatically delete connections until the number of half-open connections falls below a particular threshold. Under watch mode, the router passively monitors half-open connections, and actively closes connections on the server after a configurable length of time. Enabling TCP intercept is a two-step process. First, configure either a standard or extended IP access list permitting the destination address you wish to protect. Once this is accomplished, enable TCP intercept using this statement:
ip tcp intercept list list# Because the default mode of operation of TCP intercept is the intercept mode, a third step may be required to set the mode. To do so, you can use this command:
ip tcp intercept mode {intercept | watch}
As previously mentioned, TCP intercept includes aggressive thresholds to prevent router resources from being adversely consumed by a SYN attack. There are four thresholds maintained by routers that you can adjust. Those thresholds are set using the following TCP intercept commands, with the default value indicated for each setting:
ip tcp intercept max-incomplete low number 90 ip tcp intercept max-incomplete high number 1100 ip tcp intercept one-minute low number 900 ip tcp intercept one-minute high number 1100 To illustrate the use of TCP intercept, assume you wish to protect the host 198.78.46.8. Doing so while selecting default thresholds would require these access list statements:
ip tcp intercept list 107 access-list 107 permit tcp any host 198.78.46.8 Applying Access Lists An access list is applied through the use of the access-group command. The general format of that command is:
ip access-group {list# | name } {in | out}
Note that you use a name in the access group command to reference a named access list. You also use either in or out to reference the direction with respect to the router interface that filtering occurs. Because the access group command only associates the direction of filtering to an access list number or name, use an interface command before the access group command to tie everything to an interface. For example, if you wanted to apply the extended IP access list named inbound that we previously created to a router's serial port in the inbound direction, the statements would be as follows:
interface serial 0 ip access-group inbound in ! ip access-list extended inbound permit tcp any any established permit ip any host 198.78.46.9 permit icmp any any echo-reply Configuration Principles Although access lists can be used as the first line of defense to protect a network there are several configuration principles to remember. First, Cisco access lists are evaluated sequentially, top down. As soon as a match occurs, access list processing against a packet terminates. Thus, its important to place more specific entries toward the top of an access list. Also, if you add new entries to an access list, they are added to the bottom of the list. This can cause undesirable results, and you may wish to create a new list, instead of attempting to patch an existing list. All too often, human error can result in an undesirable result. If you reference an access list that was not created in a configuration, the effect is the same as if the access list contained a permit any entry. Similarly, if you apply an access list to the wrong interface, in the incorrect direction, or make a mistake in your statements the level of protection you seek may be compromised. Thus, always review your work and then review your review.
About the AuthorGilbert Held is an award-winning author and lecturer. Gil is the author of over 40 books and 300 technical articles. Some of his recent books include Voice over Data Networks covering TCP/IP and Frame Relay and Cisco Security Architecture (co-authored with Kent Hundley), both published by McGraw Hill and Data Communications Networking Devices 4th edition and LAN Performance 3rd Edition, both published by John Wiley & Sons. Gil can be reached at: 235-8068@mcimail.com. |