Mastering Access Control Lists
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In order to achieve success at the Cisco Certified Network Associate (CCNA) level and beyond, you must master Access Control Lists (ACLs). There is simply no doubt about this. Part of the reason is that we find we must use ACLs for so many functions these days on our Cisco devices, devices like Routers, Switches, and Firewalls.
When most CCNA candidates think about ACLs, they immediately think about filtering traffic with these powerful structures. Perhaps permitting one form of traffic from the Internet into their private network, but blocking other forms of traffic. But filtering is only one of the many uses these structures have for Cisco network engineers now. We end up using these structures for classification of traffic for many, many different purposes in the Cisco Internetwork Operating System (IOS). For example, perhaps we need to define what addresses will be translated with Network Address Translation (NAT), or perhaps we desire to highlight some traffic for transmission over a Virtual Private Network (VPN). Yes, you guessed it, it is Access Control Lists to the rescue.
Types of Lists
While there are many types of access lists for various protocols, this article will focus on IP Access Control Lists. It probably comes as no surprise to our readers that these are the most popular form of ACLs used today. This is because IP is quickly becoming a ubiquitous protocol in our modern networks.
When it comes to our IP ACLs, the first distinction we need to be aware of is between a named ACL and a numbered ACL. When ACL technology was first invented, it was a numbered structure only. The number that is used to identify the ACL educates the Cisco IOS about what type of ACL it is. For example, an ACL with a number of 10 indicates the ACL is an IP type, and it also indicates that it is a standard ACL.
This leads us to our next distinction of different types of ACLs. With IP access lists, there are standard versus extended ACLs. A standard ACL is only able to distinguish traffic based on the source IP address field in the packet. An extended ACL, however, is able to distinguish traffic based on the exact IP protocol type, the source address, the destination address, even the source and destination port information. Extended ACLs certainly enhance the flexibility of use and the granularity of these lists, but their power is not always needed. In fact, when all we care about is the source IP address in a packet, the standard ACL remains the logical choice.
Here is an example of a numbered ACL:
R1(config)#access-list 10 permit 10.10.0.0 0.0.255.255 R1(config)#access-list 10 permit 10.20.0.0 0.0.255.255
Notice this ACL consists of two entries. Traffic matching the 10.10.X.X network or the 10.20.X.X network is permitted by this list. Notice the Wildcard Masks that are used to distinguish which portion of the address to match. I like to call Wildcard Masks Inverse Masks. This helps me to remember that they work exactly opposite of how Subnet Masks work. In the Inverse Mask, a zero bit setting indicates we want to match, while the one bit setting indicates “we don’t care.”
Note that numbered ACLs from 1-99 are for standard IP, while numbers from 100-199 are for extended IP lists. There are other “expanded” number ranges set aside, but these should be enough for the average job. And let’s face it...if we run out, we can always use named ACLs.
Here is an example of a named, standard ACL:
R1(config)#ip access-list standard AL_EXAMPLE R1(config-std-nacl)#permit 10.30.0.0 0.0.255.255 R1(config-std-nacl)#permit 10.40.0.0 0.0.255.255
Notice how the name is beneficial to communicate the purpose of the ACL. Notice also how we had to specify that it is a standard IP list we are creating since there is no number used to communicate that information.
Here is an example of a numbered, extended ACL:
R1(config)#access-list 102 deny icmp any any echo R1(config)#access-list 102 permit ip any any
Notice how this list allows us to deny very specific traffic[md]in this case[md]an echo packet used by the PING utility. Notice also how access lists allow us to use the shortcut keyword any to represent 0.0.0.0 255.255.255.255.
The Implicit Deny All
One of the critical aspects of any ACL that we must remember is that the Access List ends with an implicit DENY ALL statement. Implicit means that we cannot see this Access Control Entry (ACE) when we look at the ACL. We cannot see it[md]but it is there, providing a DENY ACL treatment to any traffic that makes its way down the entire ACL without a matching statement.
Often times engineers will want to know how many packets hit the implicit deny all at the end of a list. Because of this need, they create an explicit deny all entry to conclude the ACL. Here is an example:
R1(config)#access-list 103 permit ip 10.10.10.0 0.0.0.255 10.20.20.0 0.0.0.255 R1(config)#access-list 103 deny ip any any
The Importance of Order
The order of statements is critical in your ACLs. This is because there is a rigid top-down processing that occurs, and once there is a match for the traffic, no more processing occurs for this packet. As a result, always remember to place your more specific entries earlier in your ACLs. Here is an example:
R1(config)#ip access-list standard AL_ORDERISIMPORTANT R1(config-std-nacl)#permit 10.50.50.1 0.0.0.0 R1(config-std-nacl)#deny 10.0.0.0 0.255.255.255 R1(config-std-nacl)#permit any
Notice in this example, we must place the permit for the specific host (10.50.50.1) before the more general denying of all traffic in the 10.X.X.X network. If we did not do this, the traffic would be denied before hitting any other permit entry.
Assigning ACLs as Filters
It always tends to strike students by surprise that on an interface, only one ACL per protocol, per direction is permitted. So if you have a Fa0/0 interface and you want to filter inbound IP traffic using an ACL, you can only have one of them. This means that your ACLs can get really long and really complex pretty quickly. You should always plan on saving them in some type of data store outside of the actual Cisco device as a backup, and to give yourself an easy editing location.
What syntax is used to actually assign an ACL filter? Here is an example:
R1(config-if)#ip access-group AL_EXAMPLE in
Notice that we are in interface configuration mode and we use the command ip access-group {name | number} {in | out}.
If you want to filter traffic on the Virtual Terminal Lines into the device, the command to assign the ACL is a bit different, the command is as follows:
R1(config-line)#access-class 100 in
Be sure to practice with the concepts presented in this article to ensure your mastery of these important Cisco IOS constructs.