Better Security through Access-List Management

Better Security
through Access-List
Management
1-800-COURSES
www.globalknowledge.com
Expert Reference Series of White Papers
Introduction
Security is becoming more and more common in every environment, regardless how big or small the network
happens to be. Anytime we think of security, the first thing that comes to our minds is the implementation of
firewalls. What if firewalls are not available in your network? What if your firewalls are only meant for connec-
tivity from the outside world? Or, better yet, what if firewalls are controlled by different groups in your
organization, and you want to do something to protect your network internally between departments and/or
maybe your budget doesn’t allow you to get firew
alls. Can you get somewhat similar functionality with your
existing routers?
The answer is yes
. You can get limited security with the access-list on your routers. However, access-lists on
routers are in no way replacements for firewalls.
The abilities of access-list have evolved a lot since they were introduced in the early versions of Cisco IOS.
What you can and cannot do with access-list will vary between IOS releases. With the IOS Firewall Feature set
you can do more than what will be discussed in this whitepaper. This paper gives you the basics of access-list
with implementations examples as covered in the CCNA certifications. These CCNA focused access-lists are for
TCP/IP protocol only even though access-lists can control other protocols like IPX/SPX, and Appletalk.
Typically
, when you think of access-list you think about permitting or denying certain type of traffic. You think
of protecting your network from being hacked. Well, that’s not the only use for access-list. access-lists have
many other purposes. For example, with an access-list, you can trigger your ISDN calls – to mark what interest-
ing traffic will trigger the call. With access-lists, you can mark traffic from specific source and/or destination
addresses and prioritize that traffic over other traffic.
With access-lists
,

you can allow or disallow certain routes
to be added in your routing table and various other things that are beyond the scope of this whitepaper.
Categories of Access-Lists
There are two main categories of access-lists, Standard and Extended. Some folks might argue that the two
types of access-lists are named and numbered.
But remember that both named and numbered lists could be
either standard or extended. (We will give you numbered examples in this whitepaper.) What do we mean by
standard or extended type of access-list? Standard and Extended access-lists allow different type of control.
Standard Access-Lists vs. Extended Access-Lists
Standard Access-List: With standard access-lists you can check the source IP address of the packet, mean-
ing, you can check to see if the source address happens to be a specific IP address (or IP subnet), then you can
permit or deny that packet.
Raj Tolani, Global Knowledge Networking Instructor
Better Security through Access-List
Management
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 2
E
xtended Access-List
:
With extended access-list, there are many things that can be checked. Besides source
L3 addresses, you can check for destination L3 addresses, source/destination port number, or source/destina-
tion protocol number. You can also check to see if the Acknowledge (ACK) bit on TCP connections is set or not.
Wow, that’s a lot of control, giving us more items than we can cover in this whitepaper.
Named Access-Lists
Standard Access Lists are in the range from 1- 99. Extended access-lists are in the range from 100-199. That
would mean that you can only have 99 standard access-lists or 100 extended access-lists on any given router.
If you really wanted more than 99 standard access-lists or more than 100 extended access-list, you can use
Named access-list.

With named access-list, you can classify it to be standard or extended, and then you will follow the same rules
(meaning standard named access-list can check for source address only and extended named access-list can
check for all those other things mentioned earlier). Later on, with the newer IOS versions, you get expanded
ranges for both standard and extended access-lists, giving you the ability to have many more access-lists. The
expanded range for standard access-list is 1300-1999 and for extended it is 2000-2699.
Wildcard Mask
With both standard and extended access-lists you could use something called wildcard mask. Let us under-
stand the wildcard mask first, before we go into the details of the implementations of standard or extended
access-list. The wild card mask functions in reverse manner to a subnet mask.
A wildcard mask is used to mark-specific bit patterns in an address
. Since we are now talking about bits (i.e.,
binary), then we need to know that there are two possibilities – 0 and 1. The binary 0 is used to represent a
match and a binary 1 is used to represent a “don’t care” condition. So,
0 means must match
1 means don’t care
The syntax for the standard access-list is:
Router(config)# access-list access-list-number
{permit | deny} {test conditions}
Let’s take a standard list example. Let’s start with a statement saying that the HR manager should be permit-
ted to access the network. Pretend that the address is 131.107.2.14 for the HR manager.
The command to accomplish this access-list condition would look like
Router(config)#access-list 1 permit 131.107.2.14
Note: This line is configured at the global configuration mode in your router. To get to the global configuration
mode, you need to take the following steps:
Router>enable
Router#config t
Router(config)#
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 3

W
e are using the number 1 in this example (remember that the range for standard access-list is 1-99); we
could have picked any number in that standard access-list range. There is no higher or lower priority for higher
or lower numbers. In our example, we used the number 1, which means all conditions we are going to do
should be grouped under the number 1.
Some students would look at that first line of code and argue that in their organization, the syntax would be
something like
Router(config)#access-list 1 permit 131.107.2.14 0.0.0.0
This is just an alternative way of accomplishing the same thing. The last four zeros are our wildcard mask bits,
which are just stating that we need to exactly match that particular IP for HR manager (really there are 32
zeros in the wildcard mask because, in each octet, there are 8 bits, so we really have 32 zeros, if you think in
binary).
Another w
ay of saying the same thing would be
Router(config)#access-list 1 permit host 131.107.2.14
This line is using the keyword host, which also means to exactly match the IP following the host keyword. The
keyword host is used before the IP address and the wildcard mask numbers are used after the IP address (just
what the syntax requires in the IOS).
So far we have seen three ways of saying the same things.
Option 1:
Router(config)#access-list 1 permit 131.107.2.14
Option 2:
Router(config)#access-list 1 permit 131.107.2.14 0.0.0.0
Option 3:
Router(config)#access-list 1 permit host 131.107.2.14
In plain English, we have stated that we want to allow the packet FROM 131.107.2.14. What we are allowing
here and from what interfaces will be clear soon. But, how do you know at this point that this is the source
address of 131.107.2.14 and not the destination address of 131.107.2.14? Remember
,
we said that the stan

-
dard access-list can only check for the source address and,
since the number 1 falls in the range of standard
access-list, we can only check for the source address of the packet.
It doesn’t matter which line you pick; they are all correct. Some might argue that option 1 is less typing so it’s
better. Others will argue that option 3 is better since it clearly states that this is for a host, which might make
it easier for some of us to remember later on when you look at your access-lists
.
Continuing this example in
this whitepaper I’ll use the syntax from option 1 since it’
s less typing
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 4
L
et’s say the next requirement we have is that the rest of the HR department should not be allowed to access
the network. To accomplish this, we will have to deny the rest of the folks on the 131.107.2.0 subnet.
Here it goes:
Router(config)#access-list 1 deny 131.107.2.0 0.0.0.255
Remember that 1 in binary means any. And 255 is nothing but 8 contiguous 1s. So, this statement is saying
deny 131.107.2.<Anything>.
Now you might wonder if that isn’t going to deny the HR manager? The HR manager is also on the
131.107.2.0 subnets. Well, you can be at ease because the HR manager will NOT be denied, since we already
allowed the HR manager in the beginning of the access-list. In the world of access-lists, we have the rule of
top-down processing and, since our first line allowed the HR manager, we don’t have to worry about acciden-
tally denying him/her.
So far our conditions look like
Router(config)#access-list 1 permit 131.107.2.14
Router(config)#access-list 1 deny 131.107.2.0 0.0.0.255
You might wonder if second line shouldn’t be access-list 2? No

, because the number 1 is nothing but a
GROUPING of conditions, and remember, we mentioned that these statements in the GROUP are going to be
read top-down so the order is important. Some books even recommend that you should think of what you
want to accomplish in the access-list in English on a regular piece of paper before you start keying in the com-
mands.
Let’s say that the rest of the company network should be allowed and the non-company networks should not
be allowed. To make this happen the next command would be
Router(config)#access-list 1 permit 131.107.0.0 0.0.255.255
Again, using the same rules for Wildcard Mask, we are matching the first two octets (131.107) and ignoring
the last two octets (0.0 in the third and forth octet). This is like saying access-list 1 permit 131.107.<any-
thing>.<anything>.
So, are we done? Well, yes, but what about that last condition that said that the non-company networks
should not be allowed? Well, we are saved here because at the end of every access-list there is always an
“IMPLICIT DENY ANY”. You can’t see this when you type the commands to see the access-lists, but it exists.
T
he complete access-list looks lik
e this
Router(config)#access-list 1 permit 131.107.2.14
Router(config)#access-list 1 deny 131.107.2.0 0.0.0.255
Router(config)#access-list 1 permit 131.107.0.0 0.0.255.255
Copyright ©2007 Global Knowledge T
raining LLC. All rights reserved.
Page 5