Access Control Lists (Acls) : Expert Reference Series of White Papers

Expert Reference Series of White Papers
Access Control Lists

(ACLs)
1-800-COURSES www.globalknowledge.com
Access Control Lists (ACLs)
Al Friebe, Global Knowledge Instructor
Introduction
In this white paper, we’ll take a look at access control lists, often referred to as access lists or ACLs (sometimes
pronounced “ackels”). In Cisco IOS, ACLs are used for many things, including but not limited to:
• Filtering data packets (firewalling)
• Controlling Telnet or SSH access to a router or switch
• Filtering routing protocols
• Specifying Quality of Service (QoS)
• Controlling encryption
• Controlling NAT (Network Address Translation)
• Controlling Dial-on-Demand
The idea of an access list is straightforward: it permits some things, and denies others. What exactly is being
“permitted” or “denied” varies according to the application of the ACL. Although access lists for other protocols
(such as IPX, AppleTalk, MAC addresses, etc.) exist, we’ll be focusing on IP access lists. In general, only routers
and multi-layer switches understand IP access lists (but some Layer-2 switches are ACL-aware to some extent).
IP Access Lists
For example, let’s say that traffic originating from a host with IP address 192.168.1.1 should be permitted to
leave the FastEthernet0/0 interface. An ACL that would accomplish this would be:
Router#configure terminal
Router(config)#access-list 1 permit 192.168.1.1
The ACL resides in the running config, and can be seen with the command show access-lists. There are vari-
ous options for this command, including show ip access-lists, show access-lists X where “X” is the ACL
identifier, etc.
The ACL created above is now resident in memory, but will not take effect until it is placed into service in some
manner. To place it outbound on the FastEthernet0/0 interface, the commands would be:
Router(config)#interface fastethernet0/0
Router(config-if)#ip access-group 1 out
Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 2

To see the access lists that are outgoing or inbound on an interface, use the command show ip interface.
Note that the ip is required (if you don’t specify the protocol, it won’t show you the ACL information). This com-
mand also has options, such as the particular interface you’re interested in, such as sh ip int f0/0.
As usual, commands can be abbreviated, so to create and apply the ACL, you could simply do:
Router#conf t
Router(config)#access-l 1 per 192.168.1.1
Router(config)#int f0/0
Router(config-if)#ip access-g 1 o
Find some shortcuts that work for you, and then use them!
In the ACL we created above, we have explicitly permitted traffic originating from the host with IP address
192.168.1.1, but what about other traffic? The default behavior of an access list is to deny all traffic that is not
referenced by the list. In other words, it’s as if there is a “deny everything else” at the bottom of the list. This is
much better than having to deny every other IP address, of which there are over four billion possibilities!
It’s commonly desired to permit and/or deny multiple hosts in a single list. What if we want to permit more
hosts? Simply add more lines to the list. This can be accomplished by going back into global config mode and
adding the lines. Building on the single line list from above, let’s add lines to ACL 1 to also permit packets from
the hosts with addresses 192.168.1.2 and 192.168.1.3.
Router#conf t
If we examine ACL 1 with show access-list, we’ll see that it now contains three lines, for 192.168.1.1, 2, and
3. It’s important to realize that because the same ACL number was used for each line, all lines belong to that ac-
cess list (ACL 1, in this case). Note that if the list is in effect on the interface while we are editing it, the changes
take effect immediately (this can be dangerous, as we’ll discuss in the future).
Let’s create another ACL, this one denying traffic from the hosts with addresses 10.1.1.1, 10.1.1.2, and 10.1.1.3,
and permitting all other addresses. Since this is a separate ACL, we’ll use access list number 2:
Router#conf t
Router(config)#access-list 2 deny 10.1.1.1
The list we’ve just created will deny traffic from the specified hosts, but what about traffic from other hosts?
Remember that ACLs deny all traffic that they don’t explicitly permit, as if there was a “deny everything else” at

the bottom. In other words, this list denies all traffic! Obviously, we need to permit traffic from the other hosts,
but it would be unreasonable to list the billions of them individually. Instead, we can use the any keyword, thus:
Router(config)#access-list 2 permit any
HINT: An ACL that contains only “deny” statements is either incomplete, or wrong!
Our ACL 2 will now deny traffic from the 10.1.1.1, 2 and 3 hosts, but permit traffic sourced from any other host.
Again, as with ACL 1, the list doesn’t actually take effect until it is placed in effect. Let’s place it inbound on
Serial 2/1.
Router(config)#int s2/1
Router(config-if)#ip access-group 2 in
As before, we can see the list with sh access-l 2, and see its application on the interface with sh ip int s2/1.
To summarize the basics of access lists, ACLs

• Are created in global config mode
• End with an implicit “deny any” (which can be overridden)
• Must be placed into service somewhere to have any effect
Thus, the commands

Router#conf t
Router(config)#interface g1/2
will create an ACL 3 (denying traffic from hosts 172.16.1, 2 and 3, while permitting all other traffic), and place it
in service on the GigEthernet1/2 interface in the outbound direction.
Wildcard Mask (WCM)

An ACL placed inbound on a router interface will control the traffic that’s allowed to enter the router via that
interface. You would think, therefore, that an ACL placed outbound on a router interface (such as ACL 3 above)
would likewise control the traffic that’s allowed to leave the router via that interface. This is also true, except
for traffic that was generated by the router itself. In other words, an outbound ACL will affect only traffic at-
tempting to transit the router, not traffic originated by the router.

Let’s look at another example. In this case, we’d like to use ACL 4 inbound on the Serial 1/1 interface to permit
traffic from all hosts on the 192.168.1.0 network, and deny all other traffic. We could start as before:
Router#conf t
But wait, the Class C network 192.168.1.0 covers 254 hosts (192.168.1.1 through 192.168.1.254), which would
require 254 lines in the ACL. Obviously listing each host address one by one is a non-scalable solution (and
imagine what would happen with a Class B or a Class A network). What we need is a system to shorten the list.
Such a system exists, and it makes use of a wildcard mask. The rules for IPv4 wildcard masks are simple.
• Wildcard masks are 32 bits long (just like IPv4 addresses).
• A 0 bit in a WCM means match the corresponding address bit.
• A 1 bit in a WCM means ignore the corresponding address bit.
• WCMs are represented in dotted-decimal (just like IPv4 addresses).
• WCMs follow addresses.
Okay, let’s use a WCM to solve our example. What we want is to match the first three octets (the “192.168.1”
part), and ignore the fourth octet. Thus, we could match the entire 192.168.1.0 network like this:
Router(config)#access-list 4 permit 192.168.1.0 0.0.0.255
How does it work? In ACL 4, you see that there is an address (192.168.1.0), followed by a wildcard mask
(0.0.0.255). The first octet of the dotted-decimal WCM is a 0, which represents eight binary 0s. Since a 0 in a
WCM means match, these eight 0s in the WCM mean match the first octet of the address (the “192” part).
Likewise, the second and third octets of the WCM are also 0s, meaning that the second and third octets of
the address (168 and 1, respectively) must be matched exactly. Finally, the fourth octet of the WCM is a 255,
which is all 1s in binary. Since a 1 means ignore, the ACL ignores the entire last octet of the address, meaning
that it could have any value (0 through 255). Since this covers the range of legal host addresses on network
192.168.1.0, it meets the requirements stated above.
The only thing left to do is to place the ACL in service on the interface.
Router(config)#int serial 1/1
Router(config-if)#ip access-group 4 in
Those of us who are particularly “geeky,” might have noticed that the permit statement above not only per-
mits the range of legal hosts, it also permits the reserved addresses of 192.168.1.0 and 192.168.1.255 (the net-
work and broadcast addresses). Since those addresses will never be assigned to hosts, this isn’t an operational
problem. And one more thing, you’ll recall that the default subnet mask for a Class C network is 255.255.255.0.
If we simply flip the bits of the subnet mask (0s become 1s, 1s become 0s), we’d have 0.0.0.255, which is the
wildcard mask we want. More on this later!

Note that we can also represent the permit any at the end of ACL 3 as:
While this is syntactically correct, if you type it into a router, IOS will display it as permit any (which is easier
to read), so that’s the way you might as well enter it.
Now that we have a neat method of representing large blocks of addresses, let’s write and apply an ACL that
will deny packets sent from hosts with private addresses, and permit packets from hosts with public address-
es. The first question, then, is what are the private and public addresses?
Per RFC 1918, the private address ranges are:

• Class A – 10.0.0.0/8
• Class B – 172.16.0.0/12
• Class C – 192.168.0.0/16
Everything else in the Class A, B, and C ranges is public. Thus, we need an ACL that denies the above-listed
address ranges, and permits everything else. Let’s use ACL 5, and place it on Serial 0/0.123 (a Frame Relay
subinterface) outbound. We’ll take it one line at a time. First, let’s handle network 10.0.0.0, a Class A network.
Since we’re interested in matching the network portion (the first octet), and ignoring the host portion (the last 3
octets), the wildcard mask should be 0.255.255.255. Thus, the first line in ACL 5 is:
Router(config)#access-list 5 deny 10.0.0.0 0.255.255.255
Next, we’ll look at the second line, which involves the Class B address space 172.16.0.0/12. Note that the mask
here is a /12, not the default Class B mask of /16. As you may recall from route summarization, moving 4 bits
to the left (from 16 to 12) results in a block of 16 (24) networks. Therefore, this address space encompasses the
172.16.0.0 through 172.31.0.0 networks. We could list these 16 networks individually, thus:
(12 more lines for 18 through 29 go here)
Note that the wildcard mask on each line is 0.0.255.255 because we care about the first two octets (the net-
work portion) but not about the last two (the host portion).
There is, however, a more elegant way. In fact, we can cover the Class B private networks in one line. Since the
mask on the Class B address space is a /12, it means that we only care about the first 12 bits of the address
space, and can ignore the last 20 (remember, there are a total of 32 bits in an address). Since a 0 in a WCM
means match the corresponding address bit, and a 1 means ignore, the WCM in binary would be twelve 0s,
followed by twenty 1s, thus:

00000000.00001111.11111111.11111111
This can be represented in dotted-decimal as 0.15.255.255, which is the format we want for a wildcard mask.
Another method for determining the WCM is to note that a /12 (the mask specified with the address space) is
255.240.0.0, and if we simply flip the bits, we get 0.15.255.255, which is exactly the WCM we need. An easy
way to flip the bits is to just subtract each octet of a mask (255.240.0.0) from 255:
• First octet: 255 – 255 = 0
• Second octet: 255 – 240 = 15
• Third octet: 255 – 0 = 255
• Fourth octet: 255 – 0 = 255
Since the address space begins with 172.16.0.0, and the WCM is 0.15.255.255, the second line of the ACL
should be:
Next, we need to take care of the Class C address space. Notice that the mask specified is a /16. Since the
default mask for a Class C is /24, and /16 is 8 bits to the left of that, this represents a block of 256 (28) Class C
networks (those starting with 192.168). Similar to what we did with the Class B block, we can just flip the bits
of the summary mask (/16, or 255.255.0.0) to get 0.0.255.255, which is the wildcard mask we need (match the
first 2 octets of 192.168, and ignore the last 2). Since the address space starts with 192.168.0.0, the third line of
ACL 5 should be:
What we have at this point is an ACL that denies the private address space, but what about the public ad-
dresses? Remember that ACLs act as if they have a deny any at the bottom. We want to permit everything that
wasn’t denied, so we need to finish the ACL with a permit any line:
Altogether then, the list is:

Now, of course, we have to invoke it on the interface:

Router(config)#interface s0/0.123
Router(config-subif)#ip access-group 5 out

Keyword Host ACL
As our first example, we’ll write an ACL 6 that permits packets sourced by the host with IP address
192.168.100.123, thus:
We could also do this using a wildcard mask (WCM).

Remember that a 0 in a wildcard mask bit position specifies a match in that bit of the address. Thus, a mask of
all 0s in dotted-decimal (which represents 32 binary 0s) means match all bits of the address exactly. If you omit
the wildcard mask (as in the first example), a WCM of all 0s is assumed, thus the two versions of ACL 6 are func-
tionally equivalent.
Interestingly enough, we can also write this ACL line a third way, by using the keyword host:
Router(config)#access-list 6 permit host 192.168.100.123
Note that when using this method, the keyword host is placed before the address, and that no wildcard mask
is used. Thus there are three functionally equivalent methods for specifying a single host address in an ACL, and
the router doesn’t care which one you use.
• Specify the address, without a WCM
• Specify the address, followed by a WCM of all zeros
• Precede the address by the keyword host, with no WCM used
In a standard ACL (the type we’ve examined so far), I generally use the first option, because it’s brief, concise,
and specific (in other words, easy to type and read). The second option gains us nothing, so I never use it. The
third option is also commonly used.
ACL for vty Lines

Now, let’s put our ACL to work. This time, though, instead of using it to control user data flowing through a
router’s interfaces, we’ll use it to enforce security on a router (or an IOS-based switch). To do this, instead of
placing the ACL in service by using the ip access-group command on an interface, we’ll use the access-class
command on the vty (virtual terminal) lines, like this:
Router(config)#line vty 0 4
Router(config-line)#access-class 6 in
Remember that inbound Telnet sessions are via the vty lines. What the above commands do is place ACL 6 in use
inbound on the vty lines, which has the effect of constraining inbound Telnet traffic to hosts permitted by ACL 6
(in this case, the host with address 192.168.100.123 only). Note that this ACL only affects Telnet traffic targeted
to this router. It has no effect on traffic flowing through the router.

Of course, you can also build more sophisticated ACLs using wildcard masks, and use them to control vty access.
An example would be:
ACL 7 would permit any public address to Telnet to this router, but block attempts at Telnet from any private ad-
dress. Note that we are placing the ACL inbound on the vty lines, which controls Telnet access to the router. If
you place the ACL in service outbound on the vty lines, it will affect the router’s being used as the middleman
in a string of Telnet sessions. For example, let’s say that R1 wants to Telnet to R2. The ability of R1 to do this is
controlled by R2’s inbound vty ACL. If there is no inbound vty ACL on R2, then any host can freely Telnet into R2
(assuming that R2’s vty password is known, of course).
Now, assuming that R1 has used Telnet to access R2, the ability of R1 to then Telnet onward from R2 to another
host would be controlled by R2’s outbound vty ACL. If there is no outbound vty ACL on R2, then R1 could
freely Telnet to any other host via R2 (assuming that the target host’s Telnet password is known).
Note that when the ACL is used inbound on the vty lines, the ACL specifies source addresses (from which hosts
are inbound Telnet into our router allowed). When the ACL is used outbound on the vty lines, the ACL specifies
destination addresses (to which hosts are outbound Telnet sessions allowed). The latter is an unusual usage of a
standard IP ACL, which normally specifies source addresses only.
Okay, now it’s Quiz Time: Let’s suppose that the following commands are placed on our router. What effect do
they have?
Router(config-line)#access-class 9 out
Since ACL 8 is placed inbound on the vty lines, it controls which hosts can Telnet into our router. In this case,
only the host with address 172.16.1.1 will succeed (don’t forget about the implicit “deny any” at the bottom of
the ACL). Now, assuming that it has established a Telnet session with our router, to where could it Telnet from
our router? That’s controlled by ACL 9, which is in effect outbound on the vty lines. Because of ACL 9, if host
172.16.1.1 accesses our router by Telnet, it can only start Telnet sessions with host 10.1.2.3 while using our
router as the middleman (again, don’t forget the “implicit deny” at the end).

Note that host 172.16.1.1 (or any other host) can still Telnet through our router to anywhere. The ACLs placed
on our router’s vty lines are only controlling Telnet sessions for which our router is an endpoint. In other words,
the access-class statements on the vty lines have absolutely no effect on data passing through our router,
but only on Telnet sessions terminating at (or starting from) our router (or switch).
In addition to controlling Telnet access (TCP port 23), access-class statements on vty lines also affect SSH ses-
sions (SSH is the encrypted version of Telnet, and it uses TCP port 22). Finally, remember that ACLs can be used
to control Telnet or SSH access to and from IOS-based switches, as well.
So why use access-class on the vty lines?

• It allows you to easily control Telnet and/or SSH sessions to a router or switch.
• It covers all of the data interfaces (and a large switch could have hundreds of data interfaces).
• It affects only Telnet and SSH traffic targeting our router or switch, not traffic traversing our router or
switch.
• It uses standard ACLs, which are easier to write than extended ACLs.
That makes the vty access-class statement a slick solution. Let’s move on; there’s still a lot more to do with
access-lists.
Additional Tips and Tricks for Standard IP ACLs

This time we’ll look at additional tips and tricks when using standard IP ACLs. Let’s suppose that we’re given
ACL 10 (the lines have been labeled A through E to facilitate the upcoming discussion):
A. access-list 10 permit 10.1.2.3
B. access-list 10 deny 10.1.2.0 0.0.0.255
C. access-list 10 permit 10.1.0.0 0.0.255.255
D. access-list 10 deny 10.0.0.0 0.255.255.255
E. access-list 10 permit any
Based on ACL 10, what will happen to packets that are sourced from the following addresses?
1) 10.1.2.4
2) 172.16.1.1
3) 10.1.3.3
4) 10.1.2.3
5) 10.2.2.3
Here are the results:

• Packet #1: Denied by line B
• Packet #2: Permitted by line E

• Packet #3: Permitted by line C
• Packet #4: Permitted by line A
• Packet #5: Denied by line D
Why is packet #1 denied, although it matches some permits in ACL 10? Remember, access lists are “top-down,
first-match.” Since line B is the top-most match for packet #1, the packet is denied. Because of this, the order of
the lines in an ACL can be critical. For example, let’s say that we swap lines B and C in ACL 10, to obtain ACL 11:
• (A) access-list 11 permit 10.1.2.3
• (B) access-list 11 permit 10.1.0.0 0.0.255.255
• (C) access-list 11 deny 10.1.2.0 0.0.0.255
• (D) access-list 11 deny 10.0.0.0 0.255.255.255
• (E) access-list 11 permit any
Now what happens to packet #1? Unlike ACL 10, with ACL 11 packet #1 is permitted (by line B). In fact, any
10.1.0.0/16 address will be permitted by line B, and will never make it to line C. For that reason, ACL 11, al-
though syntactically correct, is logically inconsistent. The old programmer’s rule of “Garbage in, garbage out”
applies to ACLs as well.
ACL Editing
The ACL editing capabilities depend on the IOS version. Under older IOS (early 12 and before), all you could do
with a numbered ACL was:
• Add lines to the bottom (append)
• Delete the entire ACL
What you couldn’t do was add lines anywhere other than at the bottom, or delete individual lines. If you wanted
to do more extensive editing, you had to delete the list, and then recreate it. With current IOS (12.4), you can
add lines wherever you like or to the bottom, and delete individual lines as well as the entire ACL.
You access the enhanced editing capabilities via sequence numbers that IOS automatically adds to the lines. You
can see the sequence numbers with show access-list. For example, given ACL 11 above, we would see:
Router#show access-list
Standard IP access list 11
10 permit 10.1.2.3
20 permit 10.1.0.0, wildcard bits 0.0.255.255
30 deny 10.1.2.0, wildcard bits 0.0.0.255
40 deny 10.0.0.0, wildcard bits 0.255.255.255
50 permit any

Using the per-line sequence numbers, you can make the changes you desire.
Named ACLs
Another enhanced capability, named ACLs, was introduced with IOS 12. Let’s take a look at creating a named
standard ACL.
Router#conf t
Router(config)# ip access-list standard Block_RFC1918
Router(config-std-nacl)#
Note that the prompt now reads config-std-nacl, meaning that we’re configuring a standard named ACL (with
the case-sensitive name “Block_RFC1918”). Now let’s add some lines to the list:
Router(config-std-nacl)#deny 10.0.0.0 0.255.255.255
Router(config-std-nacl)#deny 172.16.0 0.15.255.255
Router(config-std-nacl)#deny 192.168.0.0 0.0.255.255
Router(config-std-nacl)#permit any
You might recognize this as a list that denies the RFC 1918 private addresses, and permits the public addresses.
Like numbered ACLs, a named ACL must be placed in service to have any effect, and that’s done exactly as it is
for a numbered list. For example, to control the data flowing outbound through FastEthernet0/0:
Router(config)#interface fa0/0
Router(config-if)#ip access-group Block_RFC1918 out
You can also use a named standard ACL to control Telnet and/or SSH access:
Router(config-line)#ip access-group Block_RFC1918
As with the numbered ACLs, named ACLs are assigned per-line sequence numbers that facilitate editing. You can
also use the named ACL editor to create and edit numbered ACLs. Just use the number of the ACL as the name:
Router(config)# ip access-list standard 12
Router(config-std-nacl)#
One more thing - with both named and numbered ACLs, you can add remarks. You add a remark to a numbered
ACL like this:
Router(config)#access-list 13 remark This is my workstation

Similarly, to add a remark to a named ACL, you would do:
Router(config)# ip access-list standard Permit_Me
Router(config-std-nacl)#remark This is my workstation
Router(config-std-nacl)#permit 10.1.2.3
You can have multiple remarks within a numbered or named ACL. Note that while the remarks don’t appear
with show access-list, they do appear with show run and show start.
Differences between Standard and Extended ACLs

Having discussed general ACL rules and syntax, let’s now turn to the differences between standard and extend-
ed ACLs. As you might recall, numbered ACLs fall into several ranges.
• 1 – 99: Standard IP
• 100 – 199: Extended IP
• 1300 – 1999: Standard IP (expanded range)
• 2000 – 2699: Extended IP (expanded range)
• Other ranges for other protocols
Originally, the ranges for standard and extended IP ACLs were 1-99 and 100-199, respectively, but now that
ACLs are used for so many things, a hundred or so of each might not be enough. For this reason, the expanded
ranges were introduced. There are now a total of 699 standard, and 700 extended numbered IP ACLs available.
So, aside from the different numerical ranges involved, what are the differences between a standard and an ex-
tended ACL? In addition to filtering by source address (which is all that a standard IP ACL can do), an extended
IP ACL allows us to filter based on:
• Destination address
• Transport layer protocols
• Port numbers
• Other options
To see what this means, let’s look at an example of an extended IP ACL.

access-list 101 permit tcp host 1.2.3.4 host 5.6.7.8 eq tel-
net
ACL 101 permits only Telnet traffic (TCP port 23) originating from source 1.2.3.4 and targeting host 5.6.7.8, and
denies all other traffic (the implicit “deny any” also applies to extended ACLs). Note that the source address is
given first (along with either the keyword host or a wildcard mask), followed by the destination address (also
with either the keyword host or a WCM). You could also write ACL 101 using wildcard masks, like this:

access-list 101 permit tcp 1.2.3.4 0.0.0.0 5.6.7.8 0.0.0.0
eq telnet
The two choices are functionally equivalent, but for most humans the WCM format is harder to read than that
using keyword host, so I personally avoid the “0.0.0.0” WCM. Note that, unlike a standard ACL, when specify-
ing an address in an extended ACL, either the keyword host or a wildcard mask must be used. Attempting to
write ACL 101 like this would result in a syntax error:
access-list 101 permit tcp 1.2.3.4 5.6.7.8 eq telnet
Here’s another example of a syntactically correct extended IP ACL.

access-list 102 deny udp 172.16.0.0 0.0.255.255 192.168.1.0
0.0.0.255 eq tftp
access-list 102 permit ip any any
ACL 102 denies TFTP traffic (and only TFTP traffic) from any host on the 172.16.0.0 network going to any host
on the 192.168.1.0 network, and permits everything else. Note that a permit any in an extended ACL must
specify the protocol (ip, meaning anything in the IP suite), and both the source and destination addresses (any
any).
Using Port Numbers

By the way, in our extended ACLs we’ve been using keywords for the common port numbers (Telnet = 23, TFTP
= 69, etc), but you can also use the port numbers, which means that ACL 102 could also be written like this:
0.0.0.255 eq 69
To get a list of the keywords for commonly used ports, you can use the question mark, like this (note the space
in between the WCM and the “?”):
0.0.0.255 eq ?
Also, in addition to eq (equal-to), you can also specify gt (greater-than), lt (less-than), and other options. You
can also use the question mark to view these.
Let’s say that we want to permit traffic only to hosts on network 10.0.0.0, while denying everything else. Here’s
a possible solution.
access-list 103 permit ip any 10.0.0.0 0.255.255.255

ACL 103 applies to any protocol in the IP suite (due to the ip keyword), from any source (keyword any), going
to any destination on the 10.0.0.0 network (note the WCM). Since no port or other option information was
specified, the ACL applies to all ports and options.
Options
Speaking of options, let’s look at a few of those. ICMP has many different options, one of them being echo used
by the ping application. Here’s an ACL that will specifically deny pings, while permitting all other traffic:
access-list 104 remark This ACL stops pings
access-list 104 deny icmp any any echo
If you really wanted to nail things down, you could deny not only pings (ICMP echoes), but also their replies
(ICMP echo replies), like this:
access-list 105 remark This ACL stops pings and replies
access-list 105 deny icmp any any echo
access-list 105 deny icmp any any echo-reply
As with standard IP ACLs, you can create named extended IP ACLs. For example, you could create a named ACL
equivalent to ACL 105 like this:
Router#conf t
Router(config)#ip access-list ext stop_ping
Router(config-ext-nacl)#This ACL stops pings and replies
Router(config-ext-nacl)#deny icmp any any echo
Router(config-ext-nacl)#deny icmp any any echo-reply
Router(config-ext-nacl)#permit ip any any
Finally, you put an extended IP ACL in service the same way you do a standard IP ACL. For example, to put ACL
105 in effect outbound on the GigEthernet2/1 interface, you would do:
Router#conf t
Router(config)#int g2/1
Likewise, to place ACL stop_ping in force inbound on the Serial 1/2 interface:
Router#conf t
Router(config)#int s1/2
Router(config-if)#ip access-group stop_ping in

Remember, ACL names are case-sensitive, and the underscore is not the same as the dash (hyphen). You need to
place an ACL in service using exactly the same name as that used to create it.
Packet Filtering
We can use extended IP ACLs to filter packets based on source address, destination address, transport layer
protocols, and other options, as follows:
access-list 106 permit tcp host 1.2.3.4 host 5.6.7.8 eq tel-
net
For a packet to be permitted by ACL 106, the following must be true:

• The transport layer protocol is TCP
• The source address is 1.2.3.4
• The destination address is 5.6.7.8
• The destination port is Telnet (port 23)
Why is it the destination port, and not the source port? It’s because the port specification (eq telnet) follows
the destination address (5.6.7.8). In ACL 106, since the source port is unspecified, it could be anything. What if
instead we had written the ACL like this:
access-list 107 permit tcp host 1.2.3.4 eq telnet host
5.6.7.8
For a packet to be permitted by ACL 107, the following must be true:

• The transport layer protocol is TCP.
• The source address is 1.2.3.4.
• The source port is Telnet (port 23).
• The destination address is 5.6.7.8.
Thus, using an extended IP ACL gives us directional control that we don’t have with a standard IP ACL. Let’s look
at an example:
access-list 108 deny tcp host 1.2.3.4 host 5.6.7.8 eq telnet
Assuming that ACL 108 is placed in service correctly, it will prevent host 1.2.3.4 from opening a Telnet session to
host 5.6.7.8. This is because when host 1.2.3.4 (the Telnet client) sends the TCP syn to host 5.6.7.8 (the Telnet
server), the addresses match the deny line, as does the destination port of 23 (Telnet) and the transport layer
protocol (TCP). Thus, the syn packet is denied, and the TCP session is never established.

Will ACL 108 also prevent host 5.6.7.8 from opening a Telnet session to host 1.2.3.4? Remember that for most
applications, client ports are chosen randomly in the range of 1024 and above. Let’s say that when host 5.6.7.8’s
Telnet client process starts, the IP stack in 5.6.7.8 assigns that process a port number of 2000. Now, when
5.6.7.8 sends a TCP syn to host 1.2.3.4 (the Telnet server), even though the destination port of 23 (the server)
matches that specified by the deny line of ACL 108, as does the transport protocol (TCP), the source and desti-
nation addresses do not match (the addresses are reversed). Since the packet does not match the deny line, it’s
permitted by the “permit” line. Thus 5.6.7.8 receives the syn packet, and the first phase of the TCP three-way
handshake is successful.
Next, the Telnet server (1.2.3.4) will reply to the client (5.6.7.8) with a syn ack (the second phase of the TCP
three-way handshake). For this packet, the addresses do match those specified by the deny line of ACL 108, as
does the transport protocol (TCP), but the destination port doesn’t. Remember, the server (1.2.3.4), using port
23 (which would be the source port), is replying to the client (5.6.7.8), at port 2000 (the destination port). Since
2000 is not the destination port specified by the deny line of ACL 108, the packet does not match the deny line,
and is permitted by the permit line. Thus, the syn ack makes it to 5.6.7.8.
When 5.6.7.8 then sends 1.2.3.4 an ack (to complete the three-way handshake), this packet is permitted as well,
and the Telnet session has been successfully established. Thus, an extended IP ACL gives us directional control,
which is both good and bad. It’s good, because it gives us more flexibility, but it’s bad because to deny traffic in
both directions, we have to explicitly deny the traffic in both directions. In other words, to block Telnet bi-direc-
tionally between 1.2.3.4 and 5.6.7.8, but permit everything else, we could do this:
access-list 109 deny tcp host 1.2.3.4 eq telnet host 5.6.7.8
When blocking particular protocols, be careful to permit everything you intend to permit. What does ACL 110
permit?
access-list 110 permit tcp any any
ACL 110 permits any TCP traffic that isn’t Telnet, but it doesn’t permit TFTP or VoIP (which use UDP) or ping
(which uses ICMP). If you mean to permit ip (the entire protocol suite), then that’s what you have to say. And
remember that in addition to specifying an exact port (eq), you can also use lt, gt, or a range (less-than,
greater-than, or a range or ports numbers, respectively).
Similarly, what if we want to block pings (ICMP echoes) from host 1.2.3.4 to the 10.0.0 network? We could do:
access-list 111 deny icmp host 1.2.3.4 10.0.0.0
0.255.255.255 echo

Note that although ACL 111 will prevent host 1.2.3.4 from successfully pinging hosts on the 10.0.0.0 network,
it will permit network 10.0.0.0 hosts to ping host 1.2.3.4. To block pings in both directions, you could also deny
ICMP echo replies, like this:
0.255.255.255 echo
0.255.255.255 echo-reply
What other options are available with extended IP ACLs? As you might recall, both standard and extended IP
ACLs now count the number of matches on each line, and this can be viewed with show access-lists. This al-
lows you to monitor who is doing what, or, in the case of a deny, who is attempting to do what.
With extended IP ACLs, you can go one step further, and have the ACL display console messages when matches
occur. This is accomplished by appending the keyword log to lines of the ACL, like this:
log
log
Note that in ACL 113, we didn’t add the log option to the permit, because we aren’t interested in the non-Telnet
traffic, and don’t want to see messages regarding that.
There are many other things that can be done with extended IP ACLs. Consult the Cisco docs for examples, and
don’t forget to use the “?” to check for available keywords and options with your particular version of IOS.
Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge.
Check out the following Global Knowledge courses:
ICND1 – Interconnecting Cisco Network Devices 1
ICND2 – Interconnecting Cisco Network Devices 2
CCNA Boot Camp
For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a
sales representative.
Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use. Our
expert instructors draw upon their experiences to help you understand key concepts and how to apply them to

your specific work situation. Choose from our more than 700 courses, delivered through Classrooms, e-Learning,
and On-site sessions, to meet your IT and management training needs.
About the Author

Al Friebe is a Cisco Certified Systems Instructor (CCSI) who has been teaching networking classes since 1995. In
the past, he has served as Global Knowledge’s Course Director for BGP and BSCI, and he is the author of Global
Knowledge’s current ICND2 labs. His previous experience includes instructor duty in the U.S. Navy’s Nuclear
Power School, radiochemistry, software engineering, and network management. His certifications include CCDA,
CCDP, CCNA, CCNP, A+ and others.

Access Control Lists (Acls) : Expert Reference Series of White Papers

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Access Control Lists (Acls) : Expert Reference Series of White Papers

Transféré par

Droits d'auteur :

Formats disponibles

Expert Reference Series of White Papers

Access Control Lists

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 2

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 3

To summarize the basics of access lists, ACLs

Thus, the commands

Wildcard Mask (WCM)

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 4

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 5

Per RFC 1918, the private address ranges are:

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 6

Altogether then, the list is:

Now, of course, we have to invoke it on the interface:

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 7

We could also do this using a wildcard mask (WCM).

ACL for vty Lines

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 8

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 9

So why use access-class on the vty lines?

Additional Tips and Tricks for Standard IP ACLs

Here are the results:

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 10

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 11

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 12

Differences between Standard and Extended ACLs

To see what this means, let’s look at an example of an extended IP ACL.

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 13

Here’s another example of a syntactically correct extended IP ACL.

Using Port Numbers

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 14

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 15

For a packet to be permitted by ACL 106, the following must be true:

For a packet to be permitted by ACL 107, the following must be true:

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 16

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 17

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 18

About the Author

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 19

Vous aimerez peut-être aussi

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 2

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 3

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 4

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 5

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 6

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 7

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 8

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 9

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 10

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 11

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 12

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 13

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 14

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 15

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 16

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 17

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 18

Copyright ©2009 Global Knowledge Training LLC. All rights reserved. 19