DEMO: ACL Example

This is the network that we've been building, and this is mostly what I would do if I was in the real world. I've already implemented stuff into this network that I would do and have done in my networks. This time what I want to do is show you what ACLs I would create to protect this network right here. I'm not going to do the whole network, I'm just going to show you what I would implement for this site right here.

One thing that we've done is we've set up VLANs so that we can create security. For instance, this demo Pi 3 is on .30, this demo Pi 2 is on .20, this demo Pi 1 is on .10, and each one of these VLANs is a different type of network. VLAN 10 is designed to be my admin network, things that I will manage other devices through. VLAN 20 is supposed to be my server network, where I'm going to put all my servers. VLANs 30, 40 and 50 are my user networks. VLAN 150 is my phone network. I've got this all split out very logically, and as I said with the VLAN chapters, one reason why I do that is so that way I can implement security. Here's where we're going to implement the security: we're going to do it with access control lists.

Start with the policy

The first thing that I mentioned when you are establishing your access control list is that it comes down to the policy. You need to have a policy on how your network is going to operate. That's what I have right here, my policies on how I'm going to manage the network when it comes to this headquarter site over here on the left hand side of this network.

First of all, traffic exiting a network should be implicitly allowed. So from demo laptop it is going to be allowed to exit and go to the rest of the world. Not all networks are set up that way. I've definitely encountered networks where they block all traffic unless they explicitly allow it. It's a much more secure way of operating your network, and the advantage of that is if something gets compromised within your network it's not going to be sending out traffic to the outside world. What you have to do then is, if you are part of the organization, a user, and they needed access to something specific, a certain port or some site that's out there that has an IP and a port, you would have to relay that to your IT team or your networking team and they would have to allow that traffic to get out. It can be a big pain, a big headache, it can be really problematic, and it could cause troubleshooting problems. Generally speaking I don't like my networks to operate that way, and a lot of networks won't operate that way. Most networks operate where it just allows all traffic to exit but blocks certain traffic trying to enter. It can be done, and in a really secure network — if you're dealing with a bank network or a military network or something that needs to be really secure — you would want that implemented. For this purpose we're not going to set that up.

The next policy I have is that traffic entering a network should explicitly be blocked unless it were specifically allowed. That's just saying that things can't come back into this network unless we specifically allow it.

All return traffic to all networks should be explicitly allowed, so anything originating from the internal network going out and making a request, that traffic should be able to get replied to. That's pretty standard.

Ping is always allowed. I just want to troubleshoot, I want to be able to make sure that I can troubleshoot all of this network, so ping is always going to be allowed.

All vty lines should be locked down to only accept traffic from the VLAN 10 network. That's my administration network, that's the network that I can get into all of the other networks from, so we could lock down those vty lines so that only the admin network has access.

The admin network has access to all other networks, since that's the admin access network. The server network has access to all others except for the admin. So there's a hierarchy here: the admin access network has access to everything, and the server network has access to everything except for the admin network.

The server network blocks traffic except traffic specifically allowed, so you're not going to allow traffic back into the server network unless you open up certain ports. The server network allows admin network access — that's essentially been said already. But the server network can allow access to a specific resource by IP and port service, and all other services must be blocked. This is just saying that you're going to have servers in your network and you're going to want to allow access to those services, so this is allowing access to those servers' services by the IP and port. You have to specify the IP and port to be able to have access to it.

User networks block traffic except to those resources specifically allowed. Mainly our user networks shouldn't really have much in the way of resources on them that need to be accessed from other networks. Even things like our printers, we probably want local on that network, and we don't want other people from other VLANs to access that. For instance, maybe you have your sales network and they have a specific printer that's dedicated towards the sales network, and you don't want your other users from other departments to be able to access that. You may or may not want that, and this just allows for certain exceptions to that.

From policy to remarks

We've got our policy set up — that's step one, set up our policies. The next thing is, I like to have kind of an intermediate step, and that is: what is the effect? Well, VLAN 10, this is what we're going to allow and this is what we're going to deny. This would essentially become our remarks for our VLAN, so in our ACLs we have the remark statements, and this would essentially become the remark statement. You outline all of that. The one ACL that I don't have outlined here is for those vty lines, so we would want to do that separately and set up the vty lines.

Turning the policy into commands

Next what I'm going to do is take these and then figure out what the commands are for each one of these.

I am going to allow established traffic, so allow TCP any any established. That makes sense. Allow ping, so I'm going to allow ICMP any any. And allow 10.1.10.21, so I'm allowing any traffic to get to this 10.1.10.21 — that is my Pi. So any TCP traffic can come back to this demo Pi.

Then I need to apply it to the interface, so I'm going to apply it to interface VLAN 10, IP access group and then the ACL, and it's out. Remember, these are switch virtual interfaces, so think of an interface: it's coming out of the interface into the network, versus if it were originating from the network then it would be coming into that interface. But this is going out to that network.

Next I have the IP access list extended VLAN 20, and it has the same established, it has the same ping, and it adds access from the admin network — remember, we want all admin network to be able to access everything else — so it allows the admin access to VLAN 20. It also allows from this 10.2.0.0. This is from the other side, this is the server network over here, and it's allowing access in, because we actually have a server network over here. And then it allows port 22, so SSH access into this host, which is the demo Pi right here.

I will skip all of this because it is all the same, except it adds the local server network, so this local server network can get into VLAN 30. It also allows TCP traffic port 80 to 10.1.30.23, and I did that because this demo Pi has a website on it, so I wanted to allow access to that. For the most part the rest of these are pretty much the same, so I'm not going to cover all the rest of them.

That is then the commands. At this point what I could do is jump onto that device — so I'll minimize this and jump onto this device — get into global configuration mode, and then start copying these and pasting them in to do the configuration.

Testing

Then the most important part is testing: both testing to make sure that what you want to happen, to allow, will be allowed, and the traffic you want to deny will be denied. Testing is an important part of all of this because you don't want any security holes and you don't want to hinder certain traffic. Because of the amount of commands that are in here and how many VLANs are involved, there's going to be extensive testing with this, so don't overlook the time that it would take to test all this out to make sure it works correctly.

What we essentially have developed by doing this is that each one of these VLANs has a heightened level of security. Those that are in the exec network, those that are in the sales network, and those who are in the operations network have security between each of those networks. So now somebody who's in sales can't just start hacking things — they can't get into things. We have put these ACLs on each one of our VLANs to create security between our networks, between our VLANs. That's how I would set up my network if I were setting this particular network up.