If you manage switches, then you’ll need to understand the best way to secure your switched infrastructure. In this video, you’ll learn about Spanning Tree Protocol, BPDU guard, root guard, and more.
<< Previous Video: Mitigation Techniques Next: Network Segmentation >>
At the MAC address level, there’s no calendars or any other way to tell if a frame has been seen before by a particular device. That means if you create a connection between two switches, and then you create another connection between those same two switches, you will have created a loop. And that loop will cause traffic to constantly be sent back and forth between those two switches until you’re able to sever that loop. As more traffic is added to the network, more traffic will begin to loop throughout the network, and very quickly you’ll find the network is brought to its knees. This is a very easy way to bring down anyone’s network.
Fortunately, it’s easy to resolve if you happen to know where the loop is. But on today’s complex networks, it may be difficult to know exactly where the loop happens to be and it may take some time until you’re able to find out where that is and disconnect it. Fortunately, we have a standard method to prevent any loops on a switch network. This method is the IEEE standard 802.1D. It’s the spanning tree protocol. It was created in 1990 by Radia Perlman, and now it’s used on all switching devices that you might find.
Here’s an example of a network that has many switches connected to each other. We have a bridge one, bridge six, bridge 21, bridge five, and bridge 11. They’re all separate switches. And you can see they have multiple interfaces between these. These also have different designations.
Anything that has an RP is a root port. That’s because one of these switches is designated as the root switch or the root bridge. And on any of the other switches, the interfaces that are closest to the root are called the root port. All of the other enabled interfaces on these switches are assigned designated ports and you can see those are in green. And spanning tree will designate an interface as a blocked port, if enabling that port was to cause a loop on the network.
For example, if the folks on Network Y wanted to talk to Network C, you can see that there’s a blocked port going through bridge 11. So they would have to traverse this network and move all the way through the bridge, up through the network, and back down again to talk to anyone on Network C. If that blocked port wasn’t in place, then you can easily see that information would continue to loop around the network until you were able to resolve that loop. Of course, no network is perfect and occasionally problems might occur.
Let’s say, for example, that a particular connection happens to have a problem and suddenly Network A is not able to communicate through bridge six. This means that anyone on Network Y would not be able to communicate outside of that connection over to Network C. Fortunately, spanning tree will recognize when any changes occur with the network infrastructure and it will examine and determine that it needs to make a change to these configurations. It will modify and remove that blocked port configuration and now Network Y can work around this problem by now communicating directly to Network C.
One of the challenges with spanning tree is that it may take some time for this network convergence to occur. Spanning tree has to examine all of the traffic that’s going by, and then finally make a decision on what ports need to forward traffic and what ports need to be blocked. On the older, original spanning tree protocol, this could take 20 to 30 seconds from the time someone connects to the network to the time they’re ever able to send any traffic to that network.
On some switches, you have the option to bypass that entire process. This is called BPDU guard. On Cisco switches it’s called PortFast. And it’s a way to bypass that listening and learning state so that devices can immediately begin communicating on the network.
BPDU is the Bridge Protocol Data Unit. It’s the protocol that spanning tree uses to communicate between all of the different switches. An end device, like a laptop or desktop computer, will never send BPDU frames. These are only sent between switches that are participating in spanning tree.
So instead of having these end stations participate in the entire convergence process, the switch will simply allow the device access to the network. But if that switch happens to see a BPDU frame from that end station, it will shut down that interface. BPDU frames don’t normally come from these end devices, and if a BPDU frame happens to occur on an interface, that means there must be a switch on the other side and there could potentially be a loop. So to prevent that from happening, the interface is completely disabled. You would obviously only enable this BPDU guard on interfaces that you knew would only be used by end station devices.
Another way to protect your switch interfaces is to enable root guard. On any spanning tree network, one of those switches is going to be the root switch, or the root bridge. And you can manually determine what that root bridge might be by setting a root bridge priority to 0 in the configuration of the switch. But if any other device also happens to have a root bridge priority of 0, it’s going to choose the one that has the lowest MAC address.
Root guard is a feature that you’ll find in Cisco switches that allows you to administratively set which particular bridge is going to be the root bridge. This means if someone does connect another switch that’s configured with a root bridge priority of 0 and has a lower MAC address, it still would not be able to become the root bridge. So if you have administratively defined which switch is going to be the root and you’ve configured route guard, if that switch happens to receive a higher priority spanning tree protocol BPDU on that interface, it will turn that interface into listening status.
You’ll see a message show up as root inconsistent and that it is listening. This is effectively going to disable any traffic from coming inbound from that interface. This may also create connectivity problems for anyone else that happens to be on that link, but it also prevents someone else from taking over the root status on that network.
Flood guard is a way that you, as the network administrator, can limit the number of devices that can communicate through any particular switch interface. For example, if one device is connected to an interface on a switch, you may set the flood guard to only limit this one MAC address. You could even specify the exact MAC address inside the configuration of the switch. If you were to disconnect that user’s network connection and plug it into your own device the switch would recognize that a new MAC address was communicating across the network and it would maintain the list of all of the different MAC addresses that it had seen on a particular interface.
The default for flood guard is to then disable that interface so that no one can communicate over that connection from that point forward. You would then need to provide some additional investigation to determine why flood guard happened to activate on that particular interface and that may have allowed you to stop a security breach from occurring on that interface. This feature also prevents somebody from performing a denial of service by flooding the network with a number of different MAC addresses in order to overflow the switches index of addresses. By using flood guard, you can address a number of different security concerns.
One way to cause problems on a network is to install and launch your own rogue DHCP server that then starts handing out IP addresses that are completely different than what you would normally have on your official DHCP server. To be able to prevent this, we can enable DHCP snooping on your switch. This means your switch effectively becomes a DHCP firewall. This allows you to configure certain interfaces on your switch as trusted interfaces, and you would put your DHCP server, or router, or any other device that would act as a DHCP server, on that particular interface.
You would then define other interfaces on your switch as untrusted interfaces. This allows your switch to now begin watching for DHCP conversations and it will begin adding a list of trusted devices to an internal table of the switch. If your switch happens to see static IP addresses, rogue DHCP server responses, or other invalid traffic, it can filter that information from those untrusted interfaces.