ISSATitle | Article
Article The Author
Global Voice of Information Security
Living with Access Lists
By Jeffrey Monaco
The access control list has been with us since the early days of networking. This article is
about living with them and managing them on a day-to-day basis.
T
he access control list (ACL) has been with us since
the early days of networking. ACLs secure many of
the world’s networks. You find them in routers, fire-
walls, load-balancers and other internetworking devices.
They are ubiquitous. If you do a quick search on Google, you
will find hundreds or thousands of links describing the syn-
tax and methods for writing ACLs and making them do what
you want.
This article is not about writing ACLs but about living with
them and managing them on a day-to-day basis. The goal
is improving the quality of network security, taking it to a
higher level. The following are just a few results of improving
a network’s ACLs:
• Provide an audit trail for your security organization
• Enhance the security and availability of your network
by reducing or eliminating mistakes
• Recover from mistakes, when they do occur, quicker
and easier
• Demonstrate a mature and concerned attitude toward
your work and your employer
ACLs do more than just protect your networks. They also
play an important role in traffic management. For example,
they control routing decisions in policy-based routing, mark
traffic for quality-of-service processing, control routing up-
dates, and control route redistribution between routing pro-
tocols. Proper handling of ACLs will improve your networks
in many ways and allow you to follow the golden rule:
Always be able to dig yourself out of a hole faster than you dug
yourself into it.
The examples that follow are simple in order to illustrate
methodologies, but be assured they represent real-world situ-
ations.
Use named ACLs wherever possible
In the early days of the IOS, ACLs were always based on num-
bers. A certain numeric range indicated a certain type of
ACL. For example, ACLs from 1 to 99 indicate “standard”
 The examples shown in this treatise are oriented toward a Cisco™ environment.
However, many other networking equipment vendors have similar capabilities and
syntax. The concepts and methods apply to a wide range of environments.
34
ISSA Journal | June 2008
IP access lists, 100 to 199 indicate “extended” IP access lists,
and so on. This was convenient, but limiting and not very
informative. The next step in the evolution of ACLs was the
introduction of “named” access lists. It would seem obvious,
but the first rule of Good ACL Management is “Always use
named access lists.”
Old-style access lists still occur in a variety of situations. Do
not use them! A name means so much more. Over time, his-
tory teaches a few things about creating the name. Again,
these would seem obvious, but based on experience, they are
not.
Long, descriptive names are good. Short, cryptic names are
bad. Which of these two names is more meaningful:
Protect_me or
Limit_telnet_access_to_the_router_2008-03-12?
The above example also illustrates another point. Always put
a date-stamp in the access list name. Access lists, like com-
puter program code, evolve and change over time. Knowing
when an ACL was created or changed is also part of Good
ACL Management. As will be seen later, the date-stamp also
plays a role in following the golden rule.
You may consider having actual naming conventions for ACL
names. Different conventions may be used for different pur-
poses. A workable convention for interface ACLs is “direc-
tion” + “date-stamp” + “Interface.” An example is:
IB080315-serial0/0
This immediately identifies the ACL as applied inbound to se-
rial0/0, and was created on 15 March 2008. However, while
naming conventions are good, it is best not to get carried
away. Keep your naming conventions simple; do not try to
assign a meaning to every single character of the name. A
convention should be meaningful, yet easy to use.
This is an example of a named access list used for controlling
route redistribution. Its function is clearly obvious from the
name. Its date-stamp indicates when it was created.
ip access-list standard limit_routes_we_learn_
from_Peoria_2008-03-12
permit 10.10.10.0
permit 10.200.254.17
deny any
Living with Access Lists | Jeffrey Monaco
Use remarks liberally
An access list is very much like a computer program. Each
line is an instruction to be interpreted by the computer. In
this case, the computer is the router, switch, firewall, or other
security device. Just like a computer program, the lines of the
access list should be commented. Various IOS flavors now
support the capability to add comments to your code. In the
networking environment, you can use the “remark” state-
ment. The second rule of Good ACL Management is “Use
remarks in your ACLs.” While this should also be obvious,
it is clear from experience that most network and security
engineers do a poor job of documenting their ACLs.
There should be one or more remarks at the beginning of an
access list indicating the purpose of the access list, who cre-
ated it, and when it was created. Significant changes to the ac-
cess list should also be documented here. This does not have
to be a novella, but it does need to have enough information
so that other engineers working with the access list can do so
successfully. It might look like this:
ip access-list extended Control_WEP_wireless_
access_2008-03-12
remark This ACL is placed inbound on
interface fa0/1 to control
remark access from the wireless, WEP-only,
network to Internal
remark devices. JPM 2007-12-19.
<snip>
A network access list that controls traffic will generally have
several sections. It is not necessary to document every single
line of an access list, but major sections should each have
their own remark. For example:
<snip>
remark Allow telnet from selected barcode
scanners
remark to the XYZ app server. Added 2008-03-15
by jpm.
permit tcp host 10.10.10.10 host 192.168.1.1 eq
telnet
permit tcp host 10.10.10.11 host 192.168.1.1 eq
telnet
permit tcp host 10.10.10.12 host 192.168.1.1 eq
telnet
deny ip any any
At this point, one may ask why the names of the access lists
should be so descriptive when you are putting as much or
more information in the remarks. The reason is to be able
to understand the purpose of the access list when you see it
applied. Here is an example using route-redistribution where
an access list is applied. The first example is clearly more de-
scriptive than the second.
Good name
Router eigrp 100 distribute-list limit_routes_
we_learn_from_Peoria_2008-03-12 in fa0/1
<snip>
ISSA Journal | June 2008
Poor name
Router eigrp 100 distribute-list 88 in fa0/1
<snip>
Never change an active ACL on-the-fly
This rule, perhaps, will cause the most wailing and gnashing
of teeth among network and security engineers. There are a
number of ways to modify an active ACL on-the-fly. Do not
use them! The next rule of Good ACL Management is, “Al-
ways create a new ACL, and switch to it.” Why not modify an
existing ACL on-the-fly? After all, it is quick, easy, and conve-
nient. However, it also leaves no audit trail. The IOS does not
allow the addition of remarks (except in limited instances),
and the back-off mechanism is poor and clumsy. It becomes a
nightmare to back off certain parts of the changed ACL after
several iterations of changes.
Instead, create a new access list from a copy of the ACL that
requires modification. Give it a new date-stamp to make it
unique. You may then switch to it, and, more importantly,
switch back to the old one, with ease. This is the key to being
able to dig yourself out of a hole faster than you dug yourself
into it. It also allows someone else to back off to the previous
version if you are not available.
Here is how it works. Suppose you want to apply a changed
ACL on the interface shown. You have just created a new ACL
IB080315-fast0/1 to replace IB071112-fast0/1.
Existing:
interface fastethernet0/1
ip access-group IB071112-fast0/1 in
<snip>
Commands to switch to the new access list:
conf t
interface fa0/1
ip access-group IB080315-fast0/1 in
Commands to switch back to the old access list:
conf t
interface fa0/1
ip access-group IB071112-fast0/1 in
Notice the apply/back-off process remains the same, regard-
less of the number of changes between the old and new access
list. It is a quick process, and least likely to cause disruption
to a production network.
As a side benefit, having the old access list available provides
some ability to look back and see how things used to work.
Access lists that are or have been previously applied will have
“hitcounts” or “match counts.” Many times it is useful to
compare these values between the old and new access list.
Use an explicit final “deny any”
One of the first things a new network engineer learns when
studying access lists is the IOS places an implied deny any as
the last statement of any access list. It does not show up in the
output of a show access-list command, yet it is there nonethe-
35
Living with Access Lists | Jeffrey Monaco
less. This conforms to the good security practice of failing se-
cure. Experience shows it is best, however, to explicitly specify
the final deny any on ACLs.
Functionally, an explicit deny any is not necessary. Its real
value becomes obvious when it is time to analyze, debug, or
manage an access list. A show access-list command gives you
each line of the ACL and the number of times that line has
been matched. Consider the following from a sample show
access-list
Extended IP access list Control_WEP_wireless_
access_2008-03-12
10 permit tcp host 10.10.10.10 host 192.168.1.1
eq telnet (91895 matches)
20 permit tcp host 10.10.10.11 host 192.168.1.1
eq telnet (300 matches)
30 permit tcp host 10.10.10.12 host 192.168.1.1
eq telnet
40 deny ip any any (5 matches)
Versus
Extended IP access list Control_WEP_wireless_
access_2008-03-12
10 permit tcp host 10.10.10.10 host 192.168.1.1
eq telnet (91895 matches)
20 permit tcp host 10.10.10.11 host 192.168.1.1
eq telnet (300 matches)
30 permit tcp host 10.10.10.12 host 192.168.1.1
eq telnet
40 deny ip any any (1299835 matches)
Note the match count on the last line. The vast difference in
the number of denied packets may well be indicative of an
exposure or intrusion attempt. Without the final deny any,
this piece of vital information is not available.
Avoid creative masking
Masking seen in access list entries indicates which bits of the
address are important when the device is looking at an IP ad-
dress in a packet. This mask is sometimes referred to as the
wildcard bits or “wild-mask.” In a router, the mask is back-
wards from what one expects to see as a subnet mask. For
example, if the first three octets of an address are important,
you do not use 255.255.255.0 as might be expected. Rather,
the opposite is coded. In this case, the proper specification
is 0.0.0.255. (Note that in a Cisco™ PIX or ASA, masking
works as expected, and not with wildcard bits.)
Masking tells the IOS what parts of the address are impor-
tant, and what parts to ignore. Here are some examples:
ip access-list extended allow only_private_
addresses_2008-03-12
permit ip 10.0.0.0 0.255.255.255 any ! Applies
to any 10.x.x.x
permit ip 192.168.0.0 0.0.255.255 any ! Applies
to 192.168.x.x
permit ip 172.16.0.0 0.15.255.255 any ! Applies
to 172.16-31.x.x
deny ip any any
36
ISSA Journal | June 2008
The key to this is that the masking, or wildcarding, shown
above indicates how much of the leading part of the address
to look at. The rest of the address is ignored. The first line, for
instance, applies all addresses beginning with 10. The second
line applies to all addresses beginning with 192.168.
Many network engineers struggle with masking as described
above. Creative masking, described next, is an order of mag-
nitude more difficult to understand.
Creative masking is when one builds the mask to apply to the
middle part of the address, either ignoring or caring about
selected bits. Does this sound confusing? It should; it is. Here
is a simple example (and the only one typically used):
ip access-list extended control_telnet_access_
to_routers_2008-03-12
remark Allow anyone to telnet to the .1
address of our 10.10.x.x/24
remark networks. All of our 10.10 networks are
subnetted Class C.
permit ip any 10.10.0.1 0.0.255.0 eq telnet
deny ip any any
Note the wildcard bits are 0.0.255.0. To get a firm grasp on
this, it is necessary to resort to binary. When the addresses
and masking are written in binary, the logic makes sense.
This means you must be able to convert an IP address from
its dotted-decimal notation to its binary equivalent, convert
the access list wildcard specification to its binary equivalent,
and finally understand the results of the binary “or” function
as applied to the IP address and wildcard. In short, you must
be able to think in binary.
Though not often used in a production environment, vendors
think knowledge of creative masking indicates deep network
ability and put related questions on certification exams.
This leads us to the times when it is safe to use creative mask-
ing in production. Ask the following questions:
• Can you think in binary?
• Can the rest of your team think in binary?
• Can the technicians supporting your devices at 3:00
am think in binary?
If you have answered yes to the above questions, then it is safe
to use creative masking. Just bear in mind that it will make
subsequent analysis of the ACLs more difficult as well.
Finally, it is worth mentioning at this point that creative
masking is not available in Cisco’s IPv6 implementation.
Do periodic ACL analysis
The internetworking business is a rapidly changing environ-
ment. Requirements change, topologies change, servers and
services change, all at an alarming rate. Network engineers
make frequent changes to their ACLs to adjust to all of the
changes. The network engineer’s primary focus is on making
an application work and getting packets from one point to
another. Once they have a working ACL, they are often reluc-
Living with Access Lists | Jeffrey Monaco
tant to change it for fear of breaking a critical application or
service. Over time, errors and mistakes can creep into access
lists. Also, as servers and services change and evolve, access
list entries become obsolete.
The next rule of Good ACL Management is “Do periodic ACL
analysis.” For ACLs that control traffic, the security organi-
zation should do this analysis. This applies the principle of
separation of duties. For network topology access lists, those
related to route maps, QoS, and similar, someone from the
network team that does not maintain these ACLs should do
the analysis. As with security related access lists, this will ap-
ply “separation of duties” to the process.
Some of the things to look out for are services and servers
whose IP addresses have changed or been removed. Have
the old ACL entries been removed also? Does the business
no longer provide facilities on certain TCP or UDP ports,
or have the port numbers changed? Many times no one goes
back through a working access list to remove the old lines.
Pay particular attention to those ACLs that control business
partner access. Business relationships often silently expire
as contracts are not renewed. This information is not always
given to the security or networking teams.
One of the more insidious errors that sneaks into access lists
is the logic error. This most often occurs in large, extended
ACLs such as those protecting a corporate network from the
Internet. Here is a simple example to illustrate:
ip access-list extended Filter_Inbound_INET_
2008-03-20
remark This ACL is placed inbound to control
traffic we let pass
remark to our firewall. Last update JPM 2008-
03-20.
remark *** permit traffic for the ERP
application 2005-11-08
permit tcp any any range 20 25
<snip – 300 additional lines removed.
remark *** deny any inbound telnet per policy
2007-06-01
deny tcp any any eq telnet
The deny tcp any any eq telnet line will never be hit because
the previous permit statement has already permitted the traf-
fic. This condition is not just related to TCP ports. It happens
with overlapping network ranges, overriding protocols, and
even overriding QoS settings. Some of these are very diffi-
cult to find. If the ACLs are also using creative masking, the
analysis is a nightmare.
How important is this last point? At my company, we feel this
is important enough, and we do this often enough, that we
invested resources to create our own internal tool just to deal
with this case.
Tools
One of the complaints usually heard when recommending
not changing ACLs on-the-fly is that it is slow and tedious
to copy an existing ACL, change it, and reinsert it into the
configuration. This would not seem to be too difficult. How-
ISSA Journal | June 2008
ever, it turns out that not all telnet clients are the same when
it comes to using copy/paste. From experience, we know that
two open source clients, TeraTerm and PuTTY, work well.
The Microsoft™ command line client included with their
operating systems is tolerable. There are some expensive,
proprietary telnet clients that are truly painful, at least when
using default settings. When doing a lot of ACL work via
copy/paste, it will be worth your while to find a telnet client
that handles this function well. Those using a purchased tel-
net client are well-advised to work with the various settings
of the software to make the “paste” process more efficient.
As an alternative to using telnet cut/paste, tftp and ftp can be
used to apply an ACL. This is particularly useful with large
access lists.
The other tool that is useful is a context-aware editor. There
are a few available. An open source editor is Scite (sc1.exe).
While it does not know the exact syntax of an ACL, it high-
lights the IP addresses and wildcard masks, making them
stand out. ACLs are easier to read, edit, and maintain this
way.
Conclusion
To review, the rules of Good ACL Management are:
• Always use “named” access lists, and have meaning-
ful names
• Always comment your ACLs with remarks
• Always code a final deny any
• Never change an active ACL on-the-fly
• Avoid creative masking
• Do periodic analysis of your ACLs, applying separa-
tion of duties in the process
These are rules and methodologies we have learned through
experience over many years with many different clients. We
build a lot of ACLs for our clients, and we do numerous ACL
analyses as part of security audits. We believe in the process
and are sufficiently committed to have invested in the cre-
ation of tools to use internally to both analyze and create
ACLs in support of the process and related methodologies.
As network engineering and security consultants, we do not
get invited back into a company if we do a poor job – this is
something we take seriously.
About the Author
Jeffrey Monaco, CISSP, CCNA, is the CTO
of solutions4networks, a network consult-
ing company specializing in voice, data,
wireless and security. He has been working
for and with Fortune 500 customers for 25
years in design and implementation of net-
work infrastructures for mission critical applications. He may
be reached at jeff@s4nets.com.
37