We have many security protections that can be applied to our switch and router interfaces. In this video, you’ll learn about broadcast storm control, loop protection, DHCP snooping, MAC filtering, and more.
In this video, we’re going to talk about port security. We’re talking about physical interfaces on a switch or router. We’re not talking about TCP or UDP ports in this particular usage of the word port. So when you think of port security for this video, think of it as that physical connection you’re making to a switch or router.
The goal with port security is to maintain uptime and availability of the communication across the network. We want to limit the overall traffic on the network. There may be certain traffic types that need to be controlled as they’re going across the network, and we certainly want to remove any unwanted network traffic from those connections.
But of course, there are many different types of devices that we would have on our network, and many different protocols and applications that are using those networks. So we will use different techniques to be able to provide security at the port level.
One challenge we have on our networks is with broadcasts. Broadcasts are packets that are sent from one device that are addressed to everybody else who happens to be on the network.
When that information is sent out, every single device on the network has to examine the information that’s inside of that packet. If there are many broadcasts traversing the network, this could cause everyone to stop and evaluate what is inside of those packets, and it would use unnecessary bandwidth on the network as well.
Fortunately, broadcasts have a limited scope. They can only traverse the networks that are connected in a single broadcast domain. When we talk about using a VLAN on our network, that VLAN is a broadcast domain. And any broadcast sent to that VLAN will only be sent to other devices that are on that same VLAN.
With IP version 4 it’s very common to see broadcasts being sent over the network. Protocols such as routing updates and ARP requests commonly use broadcasts to be able to communicate to other devices on the network.
Unfortunately, broadcasts can also be malicious traffic, or unwanted traffic, as well. So we need to have some way to manage and control the good broadcast traffic from the bad broadcast traffic.
If you’ve done any work with IPv6, one of the things you’ll notice is that there’s no broadcasts. One of the things we did when we implemented IPv6 was focus on multicast, rather than broadcasts, which are much easier to manage.
Many of our managed switches can be used to control broadcasts. There’s functionality within the software of the switch itself that allows us to limit the number of broadcasts that can be sent in any particular second. Some of these switches can even provide control of multicast, and unicast as well, giving the administrator of the network a tight level of control over what type of traffic is sent on the network.
There might also be a way to limit broadcast by a certain finite value. For example, you might want to limit 100 broadcasts per second, or 1,000 broadcasts per second. But you can also have the switch monitor the amount of broadcasts, and if it increases by a large percentage in a short period of time, you can have those broadcasts removed from the network as well.
One challenge we have with our layer 2 networks is there’s no mechanism built into layer 2 communication that is able to recognize and remove loops from the network. This makes it very easy for us to accidentally bring down the network by simply connecting two networks to each other into a loop configuration.
It’s surprising how easy it is to do this, especially if you’re moving around a lot of cables inside of a wiring closet and you accidentally plug the wrong cable into the wrong interface. Fortunately, there is a standard for preventing loops on switch networks that is from the IEEE. It’s the standard called the 802.1D standard that was created by Radia Perlman to prevent loops on any type of switch network.
The standard is called Spanning Tree Protocol, or STP. And it’s a very common way to implement loop control on layer 2 networks. I have a design for a layer 2 network here. You can see there are a number of bridges, or switches, on this network, five of them, and they’re connecting many different networks together.
You can see in this design that there’s many opportunities to create loops. For example, if you’re on Network M, you could communicate through Bridge 6, then network B, then Bridge 21, then network J, back to Bridge 1, and finally, back to Network M. And the process can go around, and around, and around, unless you’re using Spanning Tree Protocol.
In this example, Spanning Tree is enabled. And anywhere you see BP, which is a blocked port, that is a port that has been administratively disabled because of Spanning Tree, to prevent loops on the network. This means that Network M could not loop all the way through the network because they would be blocked at this interface on Bridge 21.
Spanning Tree is also good at finding problems that occur, and working around those problems. For example, if Network M wanted to communicate to Network Y, it would hop through Bridge 6, then Network A, then Bridge 5, and then finally down to Network Y.
But what if there was an outage on the network? What if a cable was disconnected, or a switch happened to go bad? In that case, we would lose the connectivity that we had between Bridge 6 and Network A, and now we would no longer be able to follow that path between Network M and Network Y.
Fortunately, Spanning Tree is constantly monitoring itself for situations like this, and it will put the network into a convergence mode, where it will begin examining what interfaces are available, and what interface are not available based on this particular outage.
In this example, it is found that there are some interfaces that it’s able to change, and it’s able to remove the block that was on Bridge 11, allowing Network M to use a different path to communicate to Network Y. Now Network M would communicate through Bridge 1, Network J, Bridge 21, Network C, and Bridge 11, to finally talk to Network Y.
So it was able to work around the problem, still maintain communication to that network, but also prevent any type of loops, thanks to Spanning Tree Protocol.
One of the challenges with initial implementations of Spanning Tree is when you first connect to the network, it might take 20 to 30 seconds before Spanning Tree understands exactly what path it should use to be able to communicate on the network. Since we’re plugging in a single device, there should never be a situation where our single device would create a loop. But Spanning Tree doesn’t know that. So it has to perform the same checks every time we plug into the network.
Instead of having this delay when individual devices connect, we can configure the switch and let it know that the only thing that would be plugging in to that physical interface on the switch, is somebody’s end station, and you don’t have to go through the listening and learning process that Spanning Tree would normally use.
Instead, you can plug the device in and instantly start communicating on the network. On Cisco switches, this capability is called PortFast.
The problem, of course, is that someone could plug into that connection with another switch, and then there would be a loop created over that connection. To be able to combine the speed of having PortFast, and the security of Spanning Tree, we can configure BPDU guard on the switch.
BPDU stands for Bridge Protocol Data Unit, and it’s the primary protocol used by the Spanning Tree Protocol. With BPDU guard, the switch is constantly watching the communication coming from these interfaces. And if at the interface ever sends a BPDU frame, then it recognizes that there could be a switch on the other side of this communication. PortFast would no longer apply, and it would disable that interface before there was an opportunity for a loop to occur.
Another challenge we have on switches is that someone could plug in a DHCP server that was not authorized to be on the network, thereby creating either a denial of service situation, or a potential security issue. Fortunately, switches have software inside of them that can also look for these types of problems.
This is called DHCP snooping, for Dynamic Host Configuration Protocol. The switch would be configured with a series of trusted interfaces that may have routers, switches, and other DHCP servers on it, but it would have other interfaces that are not trusted. These might have other computers, and of course, DHCP servers that would not be authorized to be on the network.
The switch is constantly monitoring the conversations that are occurring over these interfaces. And if the DHCP protocol appears, and it’s coming from one of the untrusted interfaces on that switch, the switch can filter out that DHCP conversation, and not allow it to be sent to any of the other devices on the network.
Another type of control technology used on our switches, routers, and other devices, is MAC filtering. This stands for Media Access Control, and it’s referring to the physical interface that is on our ethernet cards. MAC filtering allows the administrator of this device to either allow or disallow traffic based on the Mac address that’s communicating through the network.
This means that you could configure your switch to allow communication for all of the devices that are on the inside of your network. But if someone comes in with their own device and plugs in, that device would not be able to communicate across those network links.
One of the challenges with MAC filtering is there’s no security mechanism at Layer 2 that can obscure or encrypt these Mac addresses. That means that anyone could connect to the network, they could listen, and collect a list of all of the MAC addresses that are allowed on the network, and then simply change their MAC address to match one of the MAC addresses that’s allowed.
This obviously is not a very strong security mechanism, which means that MAC filtering is really more of an administrative tool. We often refer to MAC filtering as security through obscurity, because if you know the mechanism that’s being used to provide this filtering, it’s very easy to circumvent the security controls.