Protected Ports Explained

If you've ever had a cubicle neighbor or officemate who snooped and poked their nose in everyone else's business, you know sometimes, you don't want the entire office knowing what everyone's working on. There are times 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's doing. Fortunately, keeping a port's communications secret and secure from its neighbors is quite a bit easier than keeping someone's desk secret and secure from their cubicle neighbor.

In this post, we're going to explain what protected ports are, how they prevent different ports on the same switch from seeing traffic being generated by neighbors, and how to configure and verify protected ports on your switches.

What Are Protected Ports?

Quick Definition: A protected port is a port on a switch that is configured not to forward any traffic to any other port that's also a 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's traffic is unaffected to ports that are not also protected.

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 Would You Want 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 isn't going to any others you don't want it to go to. Let's take a moment to imagine a hypothetical network topology. With it, we can walk through choosing and configuring protected ports.

This network topology is going to be pretty 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.

Now, for our purposes, both of these ports are in VLAN 123. That means they're in the same broadcast domain. As a result of that, they're also in the same subnet. What we've been asked to do in this circumstance is 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 with each other.

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 a number of 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, what we'll be doing to implement protected ports is go to the interface connection for both Port 2 and Port 4, and tell each interface that they're protected ports. As a result, they won't be able to communicate with each other. 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 with one another.

Now, obviously, it's likely that there's 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 that fact that we wouldn't configure the router port as a protected port. A key to understanding protected ports is to remember 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: protected sender and non-protected sender. Along the side: protected recipient and non-protected recipient. Where they intersect is "Communication" or "No communication". Two non-protected are going to 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 have an understanding of what protected ports are doing on a switch, let's look at the steps for actually 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're going to change configurations, it's a good idea to start with a baseline. So to start, let's do a couple 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, and so we'll run a connectivity check from the console of our Kali box:

ifconfig eth0

In 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/4

Next 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/4

Remember, in our hypothetical network, 0/4 is where the PC is, 0/2 is where the attacker KALI Linux box is. We'll specify that those ports are going to be access ports:

switchport mode access

We'll also put them into VLAN 123:

switchport access vlan 123

With 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 binding

That'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 own virtualized network will likely be different, but it can be helpful to walk one step at a time.

The last thing to confirm would be 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.4

A 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, 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/4
switchport protected
exit

And 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 switchport

This 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.4

The 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.1

The 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.

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.