Quick Definition: A protected port is a network port that does not forward traffic to other protected ports on the same switch, even if they belong to the same VLAN. Activating this feature protects networks by limiting hacker access in the case of a cyberattack.
If you've ever had an officemate who poked their nose in everyone else's business, you know that sometimes, you don't want the entire office to know what everyone's working on. Sometimes, it's better if different people's work is kept private and confidential.
Maybe they're working on proprietary code. Or they're beginning some experiments in a market where a competitor has the upper hand. There's often good reason for security and secrecy, even between team members and people in the same office.
The same can be said of bits and packets in a network. When you have many different users and devices connected to your switches and routers, there are plenty of occasions when you don't want any old port to be able to listen in on what another port is doing.
Fortunately, keeping a port's communications secret and secure is quite a bit easier than keeping someone's desk secret and secure from their cubicle neighbor.
This post explains protected ports, how they prevent different ports on the same switch from seeing traffic generated by neighbors, and how to configure and verify protected ports on your switches. This concept is covered on the Network+ exam, so make sure you've got a solid understanding of how they work.
What are Protected Ports?
A protected port is a port configuration that prevents the port from forwarding traffic to any other protected port. No traffic at Layer 2 can be forwarded between ports on the same switch if both are configured as protected ports. Unicast, broadcast or multicast traffic is all blocked between ports that are protected. A protected port can send traffic to unprotected ports.
An Overview of Protected Ports [VIDEO]
In this video, Keith Barker covers protected ports. This includes what they are used for, how to implement them and how to verify that they are properly functioning. He explains how the feature, which is also known as Private VLAN Edge, is a great technique to prevent two or more ports on a switch from having direct access to each other.
When Do You Use Protected Ports?
Any time you have ports you want to prevent from passing traffic to other ports on the same switch, you need protected ports. Protected ports help ensure that traffic from one port doesn't go to any others you don't want it to.
Let's imagine a hypothetical network topology. Using it, we can walk through choosing and configuring protected ports.
This network topology is likely to be limited. We're just going to have one switch on it. For our purposes, we won't imagine many active ports. Let's say that on Port #2, we have a malicious host. In this case, it's running BackTrack or Kali or some other penetration testing tool. Further, it's come to our attention that this attacker is starting to attack a PC that's connected to Port #4.
For our purposes, both of these ports are in VLAN 123. That means they're in the same broadcast domain, which means they're also in the same subnet. In this circ*mstance, we've been asked to isolate the attacker on Port #2 from the PC on Port #4. We shouldn't change anything else about their configurations except that they can't communicate directly.
Now, if you found yourself in a similar situation in real life, you'd have a few different options. Depending on the switch, you could approach the problem in several different ways. For example, you could use Port-Based Access Control Lists or even private VLANs. But the simplest method to isolate Port 2 and Port 4 so they can't talk directly to each other is a feature called Protected Ports.
As a feature or technique, protected ports are also often called Private VLAN Edge or PVLAN Edge. Implementing protected ports is a particularly good technique if and when you need a simple solution for preventing two or more ports on a given switch from having direct access to each other.
How Protected Ports Work
The underlying idea of protected ports is very easy: a protected port can't communicate nor be communicated with by any other protected port. But it doesn't affect broadcast to or from non-protected ports.
In practice, we'll implement protected ports by going to the interface connection for both Port 2 and Port 4 and telling each interface they're protected ports. As a result, they won't be able to communicate. If we had a larger network topology, one that included 40 ports, and we configured each one as a protected port, those 40 ports wouldn't be able to communicate.
Now, obviously, there’s likely a default gateway configured for the subnet we're dealing with. We'll leave that router port alone. The reason for that should be pretty obvious: if we configured the attacker, the PC and the router all on protected ports, none of them would be able to communicate with each other at all.
But it's important that we not gloss over the fact that we wouldn't configure the router port as a protected port. A key to understanding protected ports is remembering that one protected port on a switch does nothing. A protected port is allowed to communicate with a non-protected port. That means that by leaving the port that goes to the router as a normal port — a non-protected port — we ensure that devices on the subnet will be able to communicate with the router.
You could imagine a simple chart with two rows and two columns. Along the top are protected sender and non-protected sender. Along the side are protected recipients and non-protected recipients. Where they intersect is "Communication" or "No communication". Two non-protected ports will have successful communications. One protected and one non-protected are going to have successful communications. It's only when we have two protected ports that we get stopped.
How to Prepare for Implementing Protected Ports
Now that we understand what protected ports are doing on a switch let's look at the steps for configuring and implementing protected ports on a switch. While we'll explain each step and command along the way, we recommend that you work on an actual network or a virtualized network.
Any time you change configurations, it's a good idea to start with a baseline. So, to start, let's perform a couple of checks on our network to verify connectivity before we implement protected ports. In our hypothetical network, we obviously have control of every device on each port, so we'll run a connectivity check from the console of our Kali box:
ifconfig eth0In our case, this shows us that our attacker device's IP address is 10.123.0.3.
You may not need to clear your ports of settings, but because we're trying to demonstrate only how to implement protected ports, we're going to clear the ports we'll be using. You don't have to, but to default both Port 2 and 4, you can go to the console for the switch.
To make sure everything starts from the same place, type:
default int range gig 0/2 , gig 0/4Next, we're going to configure those two interfaces. Still, on the console for the switch itself, we're going to use the interface range command. That way, we can type each command once, and it'll apply both to gig 0/2 and 0/4:
int range gig 0/2 , gig 0/4Remember, in our hypothetical network, 0/4 is where the PC is, and 0/2 is where the attacker KALI Linux box is. We'll specify that those ports are going to be access ports:
switchport mode accessWe'll also put them into VLAN 123:
switchport access vlan 123With all this done, we can be sure that we've started from a clean slate and a good starting point. We're now sure that both ports are in the same broadcast domain and the same VLAN. We also want to verify that both have an IP address in the same subnet. In our topology, we happen to be using a router as a DHCP server, and so on that DHCP server, we type:
show ip dhcp bindingThat'll simply show the IP addresses that it's handed out. In our case, we see two addresses that stand out: 10.123.0.3 is the Kali Linux box, gig 2/0 on the switch. And the second address, 10.123.0.4, is the IP address that's been assigned to the PC that's sitting on port #4 of that switch. Your IP addresses on your virtualized network will likely differ, but taking one step at a time can be helpful.
Finally, we want to confirm that the port we're trying to prevent from communicating can actually communicate with other ports on the same switch. To do that, head to the console for the Kali Linux box and ping from ourselves at .3 over to .4:
ping -c 5 10.123.0.4A funny sidenote: While working through this on our own, it was at this point that we hit an unexpected snag. It demonstrates exactly why it's a good idea to test connectivity before implementing security. When we ran our ping from the Kali Linux box, the PC at 10.123.0.4 had gone into sleep mode. We got a false negative when we ran our ping. If we had never tested that connection and then went on to configure the protected ports incorrectly, we could've gotten a false positive because the computer was asleep. We might never have known the security wasn't enabled properly.
So, we woke the computer up, tried again, and got a positive result. Just goes to show the value of being careful.
How to Implement Protected Ports
Now that we know our setup is primed and ready, our next step is to actually implement protected ports. We're going to implement protected ports on the switch for Ports 2 and 4. That'll prevent the Kali Linux box – on Port 2 – from being able to directly communicate with the PC on Port 4. To do that, go back to your switch's console, and type:
int range gig 0/2 , gig 0/4switchport protectedexitAnd that's all there is to enabling protected ports. With the command "switchport protected," those two ports are now protected ports.
How to Verify Protected Ports
Now that you've implemented protected ports, you'll want to verify that they are both incapable of communicating with one another. One way of verifying that is with a show command. This will require going through a fairly long readout, but in the switch's console, type:
do show int g 0/2 switchportThis gives a lot of information about that port, but down at the bottom, about three lines from the bottom of that output there's an important line. "Protected: true." We already know that any two protected ports will not be able to directly communicate with each other, so these ports should not be able to communicate with one another.
Another way to verify the protected ports are working is to go back to the Kali Linux box. We did that ping from Port 2 earlier to check that we could see Port 4. The same ping should no longer work. So type:
ping -c 5 10.123.0.4The switch is no longer allowing traffic between port 2 and port 4, so all those pings from the Kali Linux box going over to the PC should fail.
Now, on the other hand, let's change the ping slightly and alter the ping to head to the default gateway address:
ping -c 5 10.123.0.1The default gateway is not on a protected port, and the ping to that device should work. If your network is like ours, you should see the five pings successfully make their way to the default gateway.
Protected Ports vs. Port Security: What's the Difference?
In the context of CompTIA Network+ certification, protected ports and port security are two different concepts related to network security, specifically within switch management. Here's a breakdown of each term:
Protected Ports
The primary goal of protected ports is to enhance security by limiting the potential for certain types of network attacks and unauthorized communications within the same VLAN. This is useful in environments like hosting services or shared infrastructure where you want to prevent devices from interfering or communicating with each other, adding an extra layer of security.
Protected ports:
Isolate devices within the same VLAN
Prevents direct communication between isolated ports
Are used mainly for enhancing security within a shared environment
Port Security
Port security is a broader term and a feature found on managed switches that involves controlling and monitoring the devices that can connect to a switch port. Port security limits the number of MAC addresses that can be learned on a single port, which helps prevent unauthorized devices from connecting to the network. This mitigates risks like MAC flooding, which can disrupt network operations
Port security:
Controls which devices can connect to a port
Limits the number of MAC addresses per port
Protects against unauthorized access and MAC flooding attacks
Can take actions like shutting down the port or logging violations upon detecting unauthorized devices
In essence, while both features aim to enhance network security, protected ports focus on isolating communication within a VLAN, whereas port security is about controlling device access and preventing unauthorized connections on switch ports.
Wrapping Up
Setting up protected ports is one of the simplest ways you can help reduce security threats on your network. Finding and potentially exploiting non-protected ports is one thing discussed in CBT Nuggets' training on penetration testing.
Want to learn more about networking? Consider our Network+ Training!
