Configuring Access Lists and Network Security

Once the router's interfaces are configured, a momment should be taken to determine if any of these interfaces connect to "secure" networks. These networks can be those that connect corporate workstations with the rest of your network or perhaps the rest of the internet. They could also be networks which house servers that provide specific services to the internet community but which you would like to protect as much as possible. A good example of such a server is a WWW server of SMTP gateway. The general public needs to be able to view your web page and send you mail but they do not need to be able to connect interractively to those servers. Other uses for access control could be in protecting parts of your corporate intra-net from other parts of your company. For example, if you have a Research and Development department, it is unlike that you'll be giving your sales staff access details on top secret projects. Likewise, you don't want your Research and Development department making some clever modifications to your accounting servers. The traditional way of protecting such servers is with access lists. Access lists filter Internet traffic and determine if a packet is permitted to pass into or out of the network. Ideas about how access lists should be designed, where they should be placed, and how physical networks should be structured to allow propper filtering without overloading network links and the routers they connect varry considerably. Some corporations choose to invest in commercial "fire wall" products while others will implement minimal access controls at all. Still others will invest in the hardware necessary to service access lists at two levels (one router that blocks access to itself and the interrior router and a second, the interrior router, that blocks access to itself, is only accessible from inside or even only from its console, and provides primary access list control. This router generally does nothing else besides filtering packets and sending them to its default router or a local host.) Which method you choose depends on your needed level of security, your budget, and the particular application for which the protection is needed. The decisions that lead to the various scenarios are beyond the scope of this document, however. This section intends to focus solely on access list design and implementation for the general case. Cisco has created two different classes of access lists within its routers. The first, the standard access list, filters only on source address. If numbered access lists are being used (IOS 11.1 and earlier did not support named access lists), than these lists would be numbered from 1 to 99. The second type of access list, the extended access list, is numberes from 100 to 199 and is capable of filtering based on source address, destination address, protocol, protocol port number, and a myriad of other features not necessarily applicable to general IP traffic. Once an access list is created, it must be tied to an interface in order to be used. The interface configuration considers a filter list to be an "access group". The access group can be applied either inbound or outbound with respect to the interface. For example:

 Interface Serial0
  ip access-group 101 in
  ip access-group 6 out

This group of commands specifies that traffic coming into Serial0 must be processed through extended access list number 101 and that outbound traffic must pass through standard access list 10 before leaving the interface. Standard access lists are configured by specifying a list number, wether a match on this entry will result in traffic being permitted or denied, and the host or network which is being filtered and the mask associated with it (if it is a network or subnet).

 access-list 10 permit 234.5.6.12
 access-list 10 deny 5.10.10.32 0.0.0.31
 access-list 10 permit 5.10.0.0 0.0.255.255
 access-list 10 permit 123.234.0.0 0.0.0.255

The above example creates access list 10 and configured 4 entries. The first line permit all traffic with a source IP address of 234.5.6.12. Note that when a host IP address is listed, no mask needs to be associated with it. The second line denies all traffic from the subnet 5.10.10.32/27. One thing to observe about access lists is that instead of netmasks, they use what Cisco calls "wildcard masks." These masks function very similarly to netmasks with one important difference. Network masks operate from left to right. Wildcard masks operate from right to left. Therefore, when looking at the above configuration line, what the wildcard mask is matching is the 32 addresses that begin at 5.10.10.32. (Since zero is a valid mask, it counts as one address. Hence 31 is used in the mask instead of 32.) The remaining two lines permit traffic from 5.10.10.0.0/16 and 123.234.0.0/24 respectively. On first glance, a newcommer to access lists might think that the only thing getting denied to this network is the second line and that the permit lines are unnecessary. Access lists, though, are designed to be selectively permissive, not to selectively deny traffic. As a result, an implicit deny exists at the end of this access list. (More propperly, anything that does not explicitly match an entry in the access list is dropped.) There are a couple of other important things to consider when creating access lists. First, order is extremely important. Since access lists function through "short circuit" processing (bail out when a match is found), those entries that are most likely to match traffic should be listed first. IP access list processing is very processor intensive. By listing frequent matches first, processor utilization is kept to a minimum. Note also lines 2 and 3 of the above example. They state, collectively, that all traffic from 5.10.0.0/16 is to be permitted EXCEPT for those hosts in 5.10.10.32/27. If line 2 (the deny statement) were listed AFTER line 3, than the denial would have no effect. The traffic would be permitted as a result of line 3 and those hosts you intended to block would be allowed access. When you create access lists, you should review them very carefully to be certain that no mis-ordering has occured. The second thing to watch for when creating access lists is the fact that changes to a cisco router take effect immediately upon entry. It is a fact that most access lists are not the stagnant, unchanging creatures we would like them to be. From time to time, they will require modification. Modifying an access list means deleting the existing list and recreating it with the appropriate changes. When an interface is configured to refference an access list that does not exist, the traffic will, by default, be permitted through. However, when you create that access list, the implicit denial at the end can result in your configuration session being filtered out. As a matter of policy, it is good practice to remove the refference to the access list from the interface before modifying the access list. (via "no ip access-group 123" or whatever access list you intend to refference.) Building extended access lists is somewhat more complicated and requires a few more steps. Since extended access lists filter based on both the source and destination IP address, two parts to each entry are needed. The following is a brief example of an extended access list for IP.

 access-list 101 permit tcp any any established
 access-list 101 permit tcp any 204.34.5.25 host eq 80
 access-list 101 permit ip 203.45.34.0 0.0.0.255 204.34.5.0 0.0.0.255
 access-list 101 permit tcp 203.44.32.0 0.0.0.31 204.34.5.0 0.0.0.255 eq telnet
 access-list 101 permit tcp any 204.34.5.10 eq smtp

This access list allows all TCP connections with the established flag, allows any user to get to the host 204.34.5.25, tcp port 80 (which is the http port), all IP protocols from 203.45.34.0/24 to reach any host within the 204.34.5.0 class C, all hosts within 203.44.32.0/27 can telnet into any host on the 204.34.5.0, and allows all hosts to connect to the smtp port on host 204.34.5.10. A few notes about this access list. The first line is important. It allows all packets which have had the TCP established flag set. This means two things. First, all outbound connections will be able to have the return traffic pass back through the access list. This is important. Since outbound tcp connections come from random ports above 1024, it is not possible to filter explicitly for outbound connections. The established field takes care of that. Second, an inbound TCP connection only needs to have the first packet pass beyond this point in the access list. Once the connection has been opened, the remaining traffic will have the established flag set and will not have to again pass through the entire access list. The second line also demonstrates that when a source or destination is used, the wildcard mask can be replaced with the word "host" to indicate this. It also gives an example of filtering based on a destination port. The third line matches all IP protocols (TCP, UDP, ICMP, etc. Everything that gets encapsulated in an IP packet.) The source and destination network number and wildcard mask pairs function the same as in standard access lists. The fourth line shows that, on well known services, the port number can be replaced with the name of the service. There is one last important thing to consider when creating access lists however. Many services depend on other services in order to function. For example, you can't just permit telnet connections without permitting DNS packets to get through as well. You often won't be able to telnet out unless telnet ident requests can come back into your network. If you wish to synchronize the clocks on your computer systems to other systems, you likely need to permit NTP packets (both TCP and UDP) to pass through. For this reason, carefull consideration is needed when creating access lists. It is all too easy to overlook one or two key services when creating lists. As network administrators gain experience with access controls, these omissions become more rare, but they still occur with annoying frequency. Access lists should be tested throroughly once they are in place. Both to be certain that necessary traffic is permitted through the list as well as to be certain that unwanted traffic does not.