Access control lists (ACLs) are rule sets applied to routers, firewalls, and switches to permit or deny network traffic based on source addresses, destination addresses, protocols, and ports. This content covers ACL types, processing logic, configuration guidelines, and interface placement.
ACLs have a lot of purposes, and they can be put on a lot of devices. You could put one on your firewall, or your router, or even on your layer 2 switches. A layer 2 switch is not going to block traffic that's going through it to these different devices — they're layer 2, it's operating on layer 2 — but we could use it to block access to the management port on it, or the VTY ports, and we'll actually be covering that. We can also use ACLs to define what's going to go through a VPN on our firewall. We could use it on a router for packet shaping and policing, or we could use it as control to our different networks, where we want to block or allow certain traffic to different devices on the network.
So ACLs have a lot of different purposes. We're going to primarily cover one during this course, and that is to block traffic going through these devices. We're going to be using a router, and we're going to be setting up an ACL on the router that's going to stop certain traffic that's going into the router or going out of the router.
An access control list is a list, so then the question is, a list of what? It's a list of access control entries, or a list of access control statements — it goes by many different names. So what is an access control entry? All of these combined is an access control list, and to be specific it's an access control list for number 42. They are made up of these access control entries, so each one of these is an ACE, or access control entry. This is an ACL, and that's an ACE.
Well, what are these entries doing? Each one of these entries is either going to deny traffic or permit traffic. In this particular case we've got an access control list, and it's access control list 42. The first entry denies host 10.1.1.5, so it's going to stop traffic from this source right here. Then it's going to permit anything from the 10.1.1.0 network, and it's got a wildcard mask here, so it says anything else from that network it's actually going to permit.
As I mentioned earlier, there are many applications, whether we're defining what traffic is going to go through a tunnel or a VPN, or whether we're shaping or policing traffic. It has a lot of different purposes, but for this purpose right here we're just going to say the purpose is permitting or blocking traffic across this network.
We're going to be implementing ACLs for a few reasons. One of them is security: we want to secure certain networks, we want to secure certain traffic, and so we want to put an access control list in for security purposes. Another reason is that we want to put ACLs in to limit certain traffic.
Here is a network right here, and let's say this is a web server. We want port 80 and 443 to be open to this web server right here, so perhaps we're putting an ACL on this for security purposes, so that way people can get to port 80 and 443 but aren't able to get to other resources on this network that we don't want them to get to. So that is one of the reasons we put it on this device right here, for security purposes.
We would put it on this device right here because maybe we want to stop traffic from ever going across our network to this other network. As an example, maybe I want to have access to this port 80 and 443, and I don't want to have access to the other devices on this network, so I created an ACL for that. Rather than putting it on this device for security, I could put it on this device over here to stop the traffic so it doesn't go across and utilize these resources across the rest of the network — maybe these are slow connections and I really need to limit how much bandwidth is going across there. So that's where I'd put the ACL, on this other side.
There's a major division in the type of ACLs that are out there. There are standard ACLs and there are extended ACLs, and both can exist on the same device. So what is the difference between a standard ACL and an extended ACL?
Let's talk about a standard ACL first. The first thing we see is that it's just specifying an IP address or a network. One of these specifies a host and one of them specifies a network, so each access control entry only specifies one address essentially. It could be a network address or it could be a host address and so on, but it only specifies one, and this is the source address. So it specifies the source address.
Another thing that it does not specify: we see nothing around the port numbers. So it's only filtering based off of layer 3 IP information.
How else can we tell besides this that this is a standard access list? Well, the number gives it away as well. We know that standard access lists will be 1 through 99 and 1300. So if you see these numbers right here for the access control list, then we know that it's a standard list and we're only referencing the source IP address.
Compare that now to an extended list, where we see both a source and a destination. We see a source here and a destination. The "any" just means everything, and the "host" specifies a specific host, so we don't need to have the wildcard mask if we put a host in there. Then the destination here is a network, that's right there. So that's one of the things that we see: we have both a source and a destination, and we also include the port that's being allowed. In this case right here it's port 80 that's being allowed. This is the protocol that's being allowed, so you can see it could be TCP, it could be UDP — it's permitting or denying certain protocols and certain ports for those protocols.
One other thing that we see here, similar to a standard list, is the 180 right there, and that's because an extended list would be 100 through. One other thing too, which we're going to get into in a second, is that it could be named or numbered, so we'll talk about that as well. That is going to be one of the big differences here between standard and extended. We're going to cover more on both standard and extended, and where we may use both standard and extended.
As I mentioned, there are also ACL numbers, and we saw that the numbering is different for a standard versus an extended. But we also have numbered versus named. A numbered ACL is just like what we saw: each ACL statement specifies what access list it's a part of, and so that's how it knows that it's part of an access list.
It's a little different when it comes to a name. You're going to type in the access list, and since it's not a number you have to say whether it's standard or extended, and then you give it a name. Once you give it a name, then you are in the mode to edit that access list, and the way you're going to edit the access list then is to put your deny and permit statements in there just like that. So it behaves a little differently, and when we get into our demos we'll actually demo them separately.
It's very important to understand how ACLs get processed. If you don't understand how ACLs get processed, you can very easily create an ACL that's not going to function the way you think, either opening up a security hole into your network or stopping people so that they can't get into your network.
Let's say it's coming from a router perspective. We could put an ACL on what's coming in on the port, or on what's going out on a port. In this example right here it's coming in on a port, so it's going to come in on a port, and what the router is going to do is take a look at the packet and take a look at the source IP address. These are all standard, so it's just taking a look at this source IP address in this case right here. If it was an extended list then it would be the source and the destination, but since this is just a standard it's taking a look at the source, and it's going to compare that against this list.
So 10.1.10.23 is the source address of this packet that's coming in. What it will do is take a look at each one of these in sequence order. It's going to take a look at the first one and it says, is 10.1.10.23 the same as 10.1.10.13? No, it's not, so it's not going to process it using that one. Then it's going to take a look at the next one, and that with a wildcard mask is 0.0.0.255, and in this case it says, well, yes, it is part of this network right here. So I am going to take this action right here, and this action says it's going to be permitted. So now this packet is going to be sent through the rest of the device and get processed like it would, or just like any other packet that's going through the device. The rest of this access list is not used in this example right here.
One of the questions you may have is, what's going to happen if it goes all the way through the list and it doesn't match anything? In that example, what it's going to do is deny it. There is what's called an implicit deny any at the end of an access control list. Implicit means that it's not stated, it's not overt, it's not something that you're going to see show up in the access control list. And it's a deny, so it's going to drop the traffic. And it's any, so it matches up against everything. So there is an implicit deny any that will drop all other traffic if it doesn't match any of the entries.
I know I've mentioned this before, but making sure that your ACLs are correct is going to be really important for your network. The problem is, the wrong ACL can block traffic that should be getting to certain destinations, causing a lot of headaches to your end user and causing a lot of problems on your network. And vice versa — an open network. Putting the wrong statements in the wrong order, or on the wrong interface, just nulls that ACL and can cause a lot of security risks on your network. So make sure that you get your ACL creation correct.
How do we do that? First of all, there should be some sort of policies that back up what you're trying to do with an ACL. A policy is something that states how you're conducting business, how you are configuring these things. You should have policies that talk about what security you are trying to implement and how things should be implemented. So a good ACL starts out with a good policy and how a good policy is set up.
From there you can use something like a text editor to start typing out all of yours. What I would usually do is bring up something like Notepad — you've seen me do this in demos, where I typed out all of what I want to apply. I'm going to do the same thing when it comes to ACLs. I'm going to put all of the ACLs on a Notepad, get it all typed out, make sure to go over it multiple times, and probably have somebody else check it out to make sure that it is correct and it's going to do what you want it to do. You have to determine ahead of time, go through this process to determine ahead of time, what you're trying to accomplish with it.
There's also a remark command, and we will get more into the remark command, but you can actually document within the running configuration as you're creating the ACL. You can actually document what each of the statements do. We'll talk more about the remark command, but that is a good command to use to document.
If at all possible, have some sort of test network that you're testing these out on before you're actually putting it into production, so that way you know that it's going to function as you desire once you put it into production.
Also make sure that, once you've created the ACL and you've actually put the ACL on the router, it's actually not going to do anything once you first initially put it on the router. That is not until you apply it to an interface. So once the ACL is created, we actually have to apply it to an interface, and we apply an ACL to the interface in a direction, and that is per protocol.
What do I mean by that? Let's use this router as an example right here. It has three different interfaces on it. There's the interface right there, and it's per direction, so on this interface we could have an ACL that's filtering the traffic coming into it, and we can also have an ACL filtering the traffic that's going out of it. Same thing with this interface right here, filtering the traffic coming in and filtering the traffic coming out, and same thing with this interface right here. So so far we can have up to six — we've got per interface, per direction.
We also have to have per protocol. An example of that would be IPv4 and IPv6. So for each one of these I could have IPv4 and IPv6 for this interface right here, same thing for this interface right here and this interface right here. Since we could do that for each of the directions, now I've got to take six multiplied by two: I can have 12 different access control lists all working at the same time on this router right here. So one access control list per interface, per direction, per protocol.
There is one little gotcha with it, and that is that this does not apply for traffic coming from the device itself. What do I mean by that? Let's say I have ACLs that are blocking all of the SSH traffic going out of these interfaces right here. If I'm originating an SSH session from this router to another router, it will still be allowed, because it's originating from the device itself. So just realize that it excludes the traffic coming from the device itself.
A lot of times your ACLs will actually line up, whereas you stop the traffic early and you put it where you really want to have your control over security. In this network right here, a lot of what we're trying to block is traffic from the outside to the inside, and so the ACL would go on this interface and it would be for the traffic that's coming into that router. So that's where we would place that ACL. It also happens to be a very secure place to put it, because that's where I want to control access to the rest of the network. So a lot of what you would place in this particular network would go right here, on this interface.
Access controls are actually really fun to work with, and we're going to get a chance to get into those demos soon. With the access control list, they're a list — a list of access control entries or access control statements. So you have this list right here, and there are both standard lists and extended lists. The standard list just has the source IP address, versus an extended, where you can specify the port, you can specify the protocol, you can specify both the source and destination IP address, so you get a lot more granular with that.
We talked about the process and what your router is going to do: it's going to go line by line and try to match that packet up with each of the lines. Once it finds a match, then it's going to take that action, which is going to be a permit or deny, and it's not going to do any more processing of the ACL after that.
Then we talked about the creation guidelines, and how you need to go through and make sure your access control lists line up with your policies, make sure you type it out, make sure you have somebody look it over, and you apply it to the right port. Make sure you're putting it on the right port.
Now we're going to take a little deeper dive into a standard access list, and we're going to then get to play around with some of these statements and see how it actually works.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →