From the course: CompTIA Network+ (N10-009) Cert Prep
Switch port protection
From the course: CompTIA Network+ (N10-009) Cert Prep
Switch port protection
- One of the interesting things about teaching for a CompTIA certification is that even though CompTIA is vendor-neutral, there are certain situations where vendors start to show their head. And this is a great example of this. In this particular episode, switch port protection, we're going to be talking about switch ports. Now, switch port is a CompTIA term. Basically, you have two types of ports in this world. There are ports that connect to switches. Now these are not going to have IP addresses or anything like that, or we have ports that connect to network cards. So a network card could, for example, be the ports in a router. Routers have IP addresses. Our individual systems have IP addresses. My little camera, when I plug it in with its RJ45, has an IP address. But switches don't have IP addresses. They don't support layer three directly. So to differentiate a regular port from a port that's in one of our switches, Cisco coined the term switch port, so with that in mind, I want to talk a little bit about how we can protect all of these little ports on our switches. A situation is like this. If I'm going to be connecting switches together, what I don't want to create is I don't want to make a connection between these. That would make what we call a bridging loop. And these are bad things. Now, there is a protocol called the Spanning Tree Protocol, which is built into pretty much all managed switches, which will detect these types of things happening. And if it's detected, it will automatically turn off one of the ports somewhere to get the loop to stop. And if you look at this diagram, I could unplug any one of these ports and I would still have a good connection on all the switches. I just can't have a loop. Now, STP's been around for a long time and it works pretty much automatically, and it works great. However, over the last few years, there have been security issues that have come up that have required us to kick up our protection when it comes to our switch ports. Now, when you're setting up STP, and by the way, you don't set up anything, this is all done automatically. This is, let me grab my eraser. This actually bothers me to even have that loop drawn there. I'm going to get rid of that. Let's make this pretty again. There we go. Now I'm happy. So when you start plugging switches together, they will automatically, using the STP, will begin to negotiate certain things that are very important, and one of those is going to become the root bridge. But Mike, it's a switch. Yeah, I know it's a multiport switch. The term we use is root bridge. If you want to call it the root switch in your own head, go for it. But we use the term root bridge. And what will happen is these guys will then begin to negotiate how far away they are from the root. And that's great. It's a beautiful part of the protocol. However, some evil person got clever and came up with a way where they could just plug in their own switch and then all of a sudden say, "Oh, I'm the root." And it would cause havoc. To counter this, we come up with the concept of a root guard. The root guard's pretty simple. All it does is it memorizes the MAC address for the decided route. And if anybody else ever comes in unauthorized, it simply turns off any connection to the bad guy. That works great. But then there's other issues that come into play. For example, most of the ports on our switches are designed to connect to individual computers. Only of a few of our ports connect to other switches. However, it's relatively easy for someone, often not evil, they're just not thinking, to unplug an individual system and plug in a switch. This can be a potential security disaster. So what Cisco invented is something called BPDU guard. All this means is that when this guy's initially configured, we will turn him on to say, "Look, the only thing you're ever going to connect to is another computer." So the moment we try to plug in a switch, this switch is going to start sending out what are known as BPDUs, which are basically the negotiation of STP for Cisco devices. And the moment that happens, this port right here completely disables itself. I mean, it disables itself so much that the only way to turn this port back on is for an administrator to manually go into the switch configuration and turn it back on. They do this on purpose because there should never be a switch plugged into this port. Only another computer should be plugged in. And it's because of BPDU guard. Cisco invented this methodology, which is actually quite popular. The last one I want to talk about that goes way beyond STP, but does a great job for protecting our switch ports is DHCP snooping. DHCP snooping is pretty straightforward. We should only have one DHCP server in any broadcast domain, and that's fantastic. However, it's easy enough to accidentally or on purpose plug another DHCP server in there. In fact, let me put DHCP up here so there's no question mark. DHCP snooping is a very simple process where you configure the switches to say you are directly connected to a DHCP server. So I will go into this switch and I will say port seven, in this particular case, I can read it, you can't, is directly connected to a DHCP server. That way if somebody were to come along and try to plug another DHCP server over here, the system would automatically know that there is a rogue DHCP server and begin shutting off ports. It's a pretty powerful tool and a really great way to get around DHCP servers. So remember, when it comes to Spanning Tree Protocol, we've gone way beyond the basics. Looking for things like root guard, BPDU guard, and DHCP snooping, are standard equipment on any good switch today.
Contents
-
-
-
-
-
-
-
-
-
-
-
-
-
Switch management8m 49s
-
Introduction to VLANs10m 7s
-
InterVLAN routing2m 56s
-
Configuring switching technologies7m 25s
-
Trunking7m 39s
-
Cisco commands9m 2s
-
Switch port protection6m 28s
-
Port mirroring3m 19s
-
IDS vs. IPS4m 15s
-
Proxy servers12m 31s
-
Load balancing8m 19s
-
Device placement scenarios12m 37s
-
-
-
-
-
-
-
-
-