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.
