Configuring IP Filtering via Access Lists

Since the first time that multiple systems were connected to form a network, there has been a need to restrict access to some systems or portions of a network for security, privacy, and other reasons. By using the packet-filtering facilities of the Cisco IOS software, a network administrator can restrict access to certain systems, network segments, ranges of addresses, and services based on a variety of criteria. The capability to restrict access is increasingly important as a company's network begins to connect to other outside networks, such as partner companies and the Internet.

The packet-filtering capabilities of the IOS software IP access lists allow for restricting packet flow based on the following criteria:

• Source IP address

• Source and destination IP address

• IP protocol types, including TCP, UDP, and ICMP

• Source and destination TCP protocol services, such as sendmail and Telnet

• Source and destination UDP protocol services, such as bootp and NetBIOS datagram

• ICMP protocol services, such as ICMP echo and ICMP port unreachable

The preceding list is by no means exhaustive. The flexibility of the IP access list gives the network administrator broad discretion in what is filtered and how the filters are applied.

The key to understanding IP access lists in IOS software is that the packet filtering task is broken into two distinct steps. First, the filtering criteria is defined through the use of the access-list and ip access-list commands. Second, the filtering criteria is applied to the desired interfaces. We've already considered one method of applying access list filtering ”in conjunction with the distribute-list command for filtering routing information. In the next sections, we focus on using access lists in conjunction with the ip access- group command. Let's first consider how to establish the filtering criteria.

Defining the Access List

The filtering criteria are defined in a list of permit and deny statements called an access list. Each line in the access list is evaluated in sequence against the IP addresses and other information in a data packet until a match occurs. As soon as a match occurs, the list is exited. This process makes access lists highly order-dependent.

When originally developed, the IOS software had just one command for creating access lists, the access-list command. By using this command and a number from a relevant range of numbers , the network administrator can specify the network protocol for which the list is created. For example, the number range 1 to 99 denotes a standard IP access list, and the range 900 to 999 denotes an IPX packet filter. (IPX access lists are discussed in Chapter 6, "IPX Basics." )

Citing the need for more flexibility and even greater numbers of access lists, the IOS software designers created versions of the access-list command for IP and IPX that allow for named access lists. That is, the new commands can use an arbitrary string of characters rather than just a number to identify the access list. The command for creating a named IP access list is ip access-list . (There is also an ipx access-list command for named IPX lists.)

Whether numbered or named, IP access lists fall into one of two categories, standard or extended. A standard IP access list evaluates only the source IP address of a packet, while an extended access list can evaluate the source and destination IP addresses, the IP protocol type, and the source and destination transport layer ports.

Use the IOS global configuration command access-list to establish a numbered access list. As noted earlier, the access-list command takes as a parameter a list number. Standard IP access lists are established by a number in the range from 1 to 99. Extended IP access lists are denoted by a number in the range from 100 to 199. Following the list number on each line of the access list is the keyword permit or deny , followed by the IP address, wildcard mask, protocol, and the protocol port number that is filtered. The following is an example of a numbered, standard IP access list on the ZIP SF-1 router that denies packets with a source IP address of 131.108.101.99 but permits all others on the 131.108.101.0/24 network:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  access-list 1 deny 131.108.101.99  SF-1(config)#  access-list 1 permit 131.108.101.0 0.0.0.255  SF-1(config)#  ^Z  

As mentioned previously, the order of the lines in an access list determines how the filter operates. Reversing the order of the access list statements in the previous example would completely alter the functionality of the access list. The following is how the access list would look if we performed such a reversal:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  access-list 1 permit 131.108.101.0 0.0.0.255  SF-1(config)#  access-list 1 deny 131.108.101.99  SF-1(config)#  ^Z  

Now, if a packet with IP address 131.108.101.99 is compared to this access list, it matches the first statement and then exits the list. The deny statement of the list is never evaluated for 131.108.101.99.

Tip

Access lists make use of a concept known as the wildcard or don't care mask. Although it looks similar to a network mask, the wildcard mask is different in that bit positions set to 1 match any value. A wildcard mask of 0.0.0.255 matches any number in the range from 0 to 255 that appears in the fourth octet of an IP address. A wildcard mask of 0.0.3.255 matches any IP address with a 0, 1, 2, or 3 in the third octet and any number in the fourth octet based on binary computation. Wildcard masks enable the network administrator to specify ranges of addresses that fall along bit boundaries of binary numbers.

The following is an example of a numbered extended IP access list on the ZIP SF-1 router that permits only packets from the TCP Simple Mail Transfer Protocol (SMTP) and the UDP domain name service (DNS) protocol to reach IP address 131.108.101.99. Note that the keyword any can replace the network address 0.0.0.0 with the wildcard mask 255.255.255.255:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  access-list 100 permit tcp any host 131.108.101.99 eq smtp  SF-1(config)#  access-list 100 permit udp any host 131.108.101.99 eq domain  SF-1(config)#  access-list 100 deny ip any any log  SF-1(config)#  ^Z  

Tip

All access lists have an implicit deny at the end of the list. This means that any packet failing to match the filtering criteria of one of the lines of the access list is denied . For better troubleshooting and administrative control of network security, we recommend that you put an explicit deny at the end of the access list with the optional keyword log . This action causes all packets that fail to match the list to have the violation logged to the console or, if syslogging is enabled, to the syslog server. (Logging is discussed in more detail in Chapter 7.) The optional keyword log may also be applied to any line of the access list for which the administrator wants to have logging information recorded.

Thus far, the examples we've considered have been of numbered access lists. As noted earlier, named access lists enable the administrator to use arbitrary character strings to reference the IP access lists. For example, you can name access lists in ways that are easy to remember and relevant to the filtering task at hand.

Named IP access lists are created with the ip access-list configuration command. The command takes as parameters the keyword extended or standard to denote the type of named access list being created and the actual name of the access list.

The ip access-list command causes the IOS software configuration to switch to the access list configuration submode. After the access list configuration is in submode, only the permit and deny statements, along with the network address and other filtering criteria, need to be supplied. The access list name need not be repeated for each line of the list. Let's review the preceding standard access list example, using a named access list instead of a numbered access list:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  ip access-list  standard sorrycharlie  SF-1(config-std-nacl)#  deny 131.108.101.99  SF-1(config-std-nacl)#  permit 131.108.101.0 0.0.0.255  SF-1(config)#  ^Z  

The following is the previous extended access list example, rewritten using named access lists:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  ip access-list extended out-of-luck  SF-1(config-ext-nacl)#  permit tcp any host 131.108.101.99 eq smtp  SF-1(config-ext-nacl)#  permit udp any host 131.108.101.99 eq domain  SF-1(config-ext-nacl)#  deny ip any any log  SF-1(config-ext-nacl)#  ^Z  

Whether numbered or named, one of the challenges of managing access lists is recalling why certain hosts , networks, or services have been permitted or denied access. Over time, different network administrators may be responsible for maintaining the access lists on various devices throughout the network, and the reasons for certain access list entries may have been long forgotten.

In earlier versions of the IOS software, the only way to document information about access lists (or any configuration command) was to add comments to a copy of the startup configuration file that was stored on a server. Unfortunately, these comments are ignored when the configuration file is loaded into the router's memory, so there is no documentation actually in the NVRAM or running memory.

More recent versions of the IOS software have introduced the capability to add comments to both numbered and named access list commands. Adding comments to numbered access lists is achieved by using the keyword remark in place of the permit or deny keyword following the IOS global configuration command access-list and the list number. Remarks may be placed anywhere within the access list, and each can be up to 100 characters long. The following is an example of adding remarks to the numbered IP extended access list previously defined on the ZIP SF-1 router:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  access-list 100 remark Allow smtp mail to John's machine per Jane  SF-1(config)#  access-list 100 permit tcp any host 131.108.101.99 eq smtp  SF-1(config)#  access-list 100 remark Allow DNS queries to John's machine per Jane  SF-1(config)#  access-list 100 permit udp any host 131.108.101.99 eq domain  SF-1(config)#  access-list 100 remark Nothing else gets through and gets logged  SF-1(config)#  access-list 100 deny ip any any log  SF-1(config)#  ^Z  

For adding comments to named access lists, the IP access list configuration submode command remark is used. Similar to the permit and deny statements used in this submode, the remark command is used after entering the access list configuration submode using the ip access-list command followed by the list name. As with numbered access list remarks, named access list remarks can appear anywhere within the list, and each can be up to 100 characters long. The following is an example of adding remarks to the named IP extended access list previously defined on the ZIP SF-1 router:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  ip access-list extended out-of-luck  SF-1(config-ext-nacl)#  remark Allow smtp mail to John's machine per Jane  SF-1(config-ext-nacl)#  permit tcp any host 131.108.101.99 eq smtp  SF-1(config-ext-nacl)#  remark Allow DNS queries to John's machine per Jane  SF-1(config-ext-nacl)#  permit udp any host 131.108.101.99 eq domain  SF-1(config-ext-nacl)#  remark Nothing else gets through and gets logged  SF-1(config-ext-nacl)#  deny ip any any log  SF-1(config-ext-nacl)#  ^Z  

Applying the Access List

After the filtering criteria of the access list is defined, it must be applied to one or more interfaces so that packets can be filtered. The access list may be applied in either an inbound or an outbound direction on the interface. When packets travel in the inbound direction, they come into the router from the interface. When they travel in the outbound direction, they leave the router and then go onto the interface. The access list is applied via the IOS interface configuration subcommand ip access-group . The command takes as a parameter the keyword in or out . If no parameter is provided, the out keyword is presumed . The following example applies the standard access list 1, defined previously, on the Fast Ethernet interface of the ZIP router SF-1. This configuration prevents packets originating from the address 131.108.101.99 from reaching destinations beyond the Fast Ethernet interface:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  interface fastethernet 0  SF-1(config-if)#  ip access-group 1 out  SF-1(config-if)#  ^Z  

The following is an example of applying the previously defined access list, out-of-luck, on the Fast Ethernet interface of the ZIP SF-1 router. This configuration prevents packets originating from any address from exiting the router, with the exception of those packets traveling to the host 131.108.101.99 for SMTP and DNS services:

 SF-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-1(config)#  interface fastethernet 0  SF-1(config-if)#  ip access-group out-of-luck out  SF-1(config-if)#  ^Z  

After access lists are configured, they can be viewed and verified by using the IOS EXEC commands show access-lists and show ip access-lists . The former command shows all access lists defined on the router, while the latter shows only IP access lists defined on the router (whether numbered or named). Each command can take as a parameter a specific numbered or named access list and can display only the contents of that list. If no parameter is supplied, all lists are displayed. The following output of the show access-lists command for the ZIP SF-1 router shows that the previously defined access lists have been applied to the router:

 SF-1#  show access-lists  Standard IP access list 1    deny 131.108.101.99  (50 matches)    permit 131.108.101.0 0.0.0.255  (576 matches) Standard IP access list sorrycharlie    deny 131.108.101.99    permit 131.108.101.0 0.0.0.255 Extended IP access list 100    permit tcp any host 131.108.101.99 eq smtp    permit udp any host 131.108.101.99 eq domain    deny ip any any log Extended IP access list out-of-luck    permit tcp any host 131.108.101.99 eq smtp  (987 matches)    permit udp any host 131.108.101.99 eq domain  (10987 matches)    deny ip any any log  (453245 matches) SF-1# 

As seen in the output, the show access-lists and show ip access-lists commands count the number of times that each line of an access list has been matched and display the count in parentheses. This information can be useful in determining which lines of an access list are serving a useful purpose. It can also aid in troubleshooting, revealing possible access list misconfigurations. For example, if the counter for permitting UDP domain packets in the out-of-luck list does not increase and there are reports of domain name service outages from users, it is clear that domain packets are not passing the access list. Further evidence might be an increase in the counter for the last line of the out-of-luck list that is registering the number of packets that fail the access list.

The match counters on the commands show access-lists and show ip access-lists can be reset by the IOS EXEC command clear ip access-list counters . This command takes an optional parameter of an IP access list number or name for which to clear the match counters. If no parameter is specified, all match counters on all IP access lists are cleared.

The following is an example of clearing the match counters for the named IP access list out-of-luck on the ZIP SF-1 router:

 SF-1#  clear ip access-list counters out-of-luck  SF-1# 

Determining where access lists are utilized is a bit tricky. When they are applied as packet filters with the ip access-group command, output from the show ip interfaces command indicates which access lists have been applied to which interfaces. When access lists are applied as route filters with the distribute-list command, output from the show ip protocols command indicates the inbound or outbound application of the filters to specific routing protocols. This discussion of commands for viewing and verifying access lists is by no means exhaustive, because access lists function as the enabler for many of the filtering features within the IOS software. Each specific application of access lists has corresponding verification commands.

The IP packet-filtering capabilities of the Cisco IOS software provide very powerful tools for limiting access to resources both inside and outside an entity's network. However, designing a firewall protection scheme is a complex and important task. Entire books are devoted to providing adequate security for the network. We recommend that you refer to such texts for more information on protecting your network resources (see the "References" section at the end of this chapter). Additionally, as of this writing, Cisco Systems maintains an excellent case study entitled Increasing Security on IP Networks on CCO athttp://www.cisco. com/univercd/cc/td/doc/cisintwk/ics/cs003.htm.