CCNA Prep: Advanced IP Access Control Lists
Access Control Lists (ACLs) are one of the most used tools by network engineers. It is used to protect both the data and control plane and has many other applications like VPNs, policy routing, redistributing routes, NAT and Quality of Service (QoS). After reading this article you will know the different types of ACLs, where to implement them and how to calculate the Wild Card mask (WC). If you are preparing for the CCNA or CCNA security test, this is knowledge that is integral to your overall proficiency at the CCNA level.
What is an access-list?
The access-list is a packet filter that matches on different fields in a packet. Most commonly, ACLs will match on layer 3 and layer 4 in the OSI model, which is IP and TCP/UDP.
Access lists consists of permit and deny statements and are always processed in a top down order. As soon as there is a match, the action is taken and the ACL stops looking for a match. Until the access list has been applied to an interface, there is no filtering taking place.
Access lists can be applied inbound or outbound on an interface. There can only be one ACL per direction per interface. Many CCNA candidates will be confused on how to decide the direction of the ACL. To do this correctly, imagine that you are sitting inside the router and watching the packets flow through it. This picture describes packet flow when host A is sending traffic to host B and while transiting two routers.
Host A sends traffic to its gateway which is then received inbound. As the packet leaves the router, it leaves outbound on the interface leading to the second router. The second router receives the packet inbound and then delivers it outbound on the interface connected to Host B.
Types of ACLs
Cisco devices support two types of ACLs: standard access lists and extended access lists. The standard ACLs can only filter based on the source IP of the packet, but an extended ACL can match on both source and destination IP. Access lists are configured with a number or a name, but configuring it with a name is the newer way of doing it and it supports more features. Both ways will be shown here as you might still see both syntaxes used.
As mentioned above, the standard ACL can only match on the source IP. It also can’t filter based on port numbers so it is quite a blunt tool, but still, it has its uses. The standard ACL should be placed as close to the destination as possible because if traffic is filtered close to the source, then traffic to all destinations could potentially be filtered. To show how to use the standard ACL, take a look at the topology below.
There is a HR server in the 10.10.10.0/24 subnet and only employees in the HR department should be able to access it. The employees in the sales department must not be able to reach it. We create a standard ACL that will permit the 10.0.1.0/27 network and deny everything else. Routing has already been set up so we start by confirming reachability.
When working with access lists, something called wildcards are used. The wildcard is sometimes called an inverse mask. The wildcard is similar to a network mask but without the requirement to be contiguous. The wildcard checks the bits in the IP address and if the wildcard is set to 0 it means “check.” If it is set to 1, it means “don’t care.” So to calculate the wildcard, we start by converting 10.0.1.0 to binary.
0000 1010 0000 00000000 0001 00000000
Because we have a /27 network mask, it means that 27 bits are used for the network and 5 bits are used for the host. We want to match this with the wildcard so the first 27 bits are set to 0 and the last 5 bits are set to 1.
0000 00000000000000000000 0001 1111
Then this is converted back to dotted decimal which gives us 0.0.0.31. As we get more comfortable with wildcards, there are shortcuts we can use. If we take 255 and subtract the value in the fourth octet (224), we get the value 31 which we calculated above.
Where should we apply the ACL? We should place it close to the destination, so the best place for it is inbound F1/0 on the HR server.
Standard ACLs are numbered from 1 to 99. The only options we have are permit, deny and remark. The remark is used to make a comment about an access list rule. Now we create the ACL and apply it. Access lists are applied with the IP access-group command.
If the ACL is working, then pings from HR should go through but the ones from Sales should now be blocked.
As expected, the ping from HR succeeded but the one from Sales did not go through. The U in the output means that ICMP unreachables were received. These can be seen if we enable debug ipicmp on the Sales router.
Another way of verifying is using the show ip access-lists command which shows the counters for the ACL. There should be hits on the permit statement.
There are hits both on the permit and the deny statement, which is expected. Before taking a look at extended ACLs, the syntax with named ACLs is shown.
The advantage of using a named ACL is that we can easily recognize what the function of an ACL is by its name. It also supports sequence numbers so that it’s easy to insert statements later if we need to.
The extended ACL is far more usable in most cases as it can filter based on source and destination IP, ports, and even options in the IP header. Extended access-lists use the numbers 100-199 and also the named syntax. Go for the named ACL whenever you can because it’s the newer syntax and most features now support named ACLs.
The basic syntax of an extended ACL is like this:
ip access-list extended HR
permit<PROTOCOL><SOURCE NETWORK><WILDCARD><PORT><DESTINATION NETWORK><WILDCARD><PORT>
Matching on the ports is optional. Usually, matching on ports will be done to destination or source only. Generally we won’t know which port the client connects from because these ports are ephemeral and selected by the operating system. The extended access list can also match a range of ports, or ports that are greater than or less than a port number.
Now it’s time to create an extended ACL. The topology is still the same.
With extended ACLs we can be much more granular. We will create an ACL based on the following requirements:
- Only HR may access the HR server (10.10.10.10) at port 80 (HTTP).
- ICMP to 10.10.10.10 is not allowed.
- Only Sales are allowed to access HR server at port 443 (HTTPS).
Something I didn’t mention earlier is that at the end of every access list there is an implicit deny. As soon as a permit statement has been entered into an ACL, there is an “invisible” deny at the end that will block everything not previously permitted.
What happens if we apply an empty ACL to an interface? Then everything is permitted. The easiest way to create this ACL is to put the permit statements first and then leave the filtering to the implicit deny. In some cases we might have to mix permits and denies depending on what kind of filtering the ACL has to do.
As you can see, we can filter based on protocols like ICMP, TCP, UDP and OSPF. When we configure extended ACLs, the first part is which source is allowed. The first line allows traffic from 10.0.1.0/27. Extended ACLs can match on both source and destination ports. We don’t know what the source port will be from the client side since it is chosen by the operating system; we only know that the destination port will be port 80.
Always verify that the ACL is working as expected. How can we see if an ACL is applied to an interface? Show ip interface will show us that:
We start testing from the HR router. ICMP should not be allowed, and traffic to 443 should also be blocked but traffic to port 80 should go through. Sending traffic from a router is a good way of testing ACLs. This is how you do it:
This is the expected result. With the telnet command from the router, we can simulate sending traffic to port 80 although the payload is still Telnet.
We must test from the Sales router as well. ICMP should be blocked and traffic to port 80 should not go through but connecting to port 443 should be working.
This is also working as expected. The extended ACL is very powerful compared to the standard one. In the next section, we look at how we can edit ACLs.
Editing access lists
Sometimes we need to edit access lists that are already in place. How do we do that? Every access-list has sequence numbers that can be seen with show ip access-lists. Remember that access lists are always processed in a top down order according to the sequence numbers. Using the same ACL as in the previous example, we will insert a statement at the top to allow ICMP from the HR router.
First we must check what the current sequence numbers are:
The current sequence numbers are 10 and 20 and there is an implicit deny at the end that can’t be seen. We will insert a statement at sequence number 5 that allows ICMP from the HR network.
The syntax is simple. Just enter the ACL by typing ip access-list extended HR, then enter a number before the permit or deny statement. This number must be unique because duplicate entries are not allowed. Now we confirm that the ACL has been edited, but remember that any changes will have effect immediately after entering the commands.
The ping is now going through. What can we do if we run out of sequence numbers? There could be a case where you have sequence number 1, 2 , 3 , 4, 5 and you want to put something at sequence number 3. In this case, we can re-sequence the ACL and put more space between the sequence numbers.
We currently have statements 5, 10 and 20. Let’s make it so that the first statement is 10 and then there is a gap of 20 between every sequence number. The syntax is ip access-list re-sequence <ACL_NAME><STARTING_NR><STEP>.
As you can see, the ACL now starts at sequence 10 and then increments by 20.
Access-lists are good for filtering and they also have a logging function. This can be useful if you want to see which traffic is getting blocked. Care must be taken though because enabling logging could affect the performance of the CPU depending on which router model it’s applied to.
To enable logging, add the log keyword to the end of an ACL statement:
These logging messages can then be sent to a syslog server by configuring logging trap.
Protecting terminal lines
Cisco routers and switches have something called Virtual Teletype (VTY). The device can be accessed remotely via VTY through the use of Telnet or SSH. It is important to protect the VTY so that that only users coming from approved subnets may login.
Let’s create a standard ACL allowing only the Sales network to login to the HRserv router:
Now remote login to the device should only be allowed from the Sales router. As always, we verify:
Now the telnet from the HR router should fail.
The VTY is now protected from non-approved subnets.
This article has shown how to use access lists. Access lists are widely used in networking and has many applications. After reading this, you should be able to configure standard and extended access lists and protect the VTY from non-approved subnets. Understanding access-lists is an important part of the CCNA and CCNA security curriculum.