I’ve made several posts about switches, how they function, and the amazing features they possess, but now it’s time to talk about their security. Let’s start with switching loops.
Switching Loops and STP/RSTP
In some cases, a network can develop a “switching loop,” sometimes called a “bridging loop.” In networks with a lot of switches, administering and configuring these switches can be difficult and, in some instances, network techs can incorrectly connect two switches together or connect two ports together on the same switch with one Ethernet cable. If this happens, the effect is similar to a broadcast storm where the switch continuously sends and re-sends unicast traffic back-and-forth. In a way, it looks as if the network is being flooded, similar to a DoS attack. As a result of the chaos on the network, a switching loop can effectively disable a network and the switch, resulting in a downgrade in network performance and bandwidth.
Fortunately, switching loops aren’t a huge cause for concern on modern networks because most of the switches we use are running an IEEE standard called 802.1D, or “Spanning Tree Protocol (STP).” Switches weren’t built with the intelligence of knowing whether they are in a loop or not. Accordingly, we have put the intelligence on the switch ourselves. When detected, STP will break the loop on-the-fly. The newest predecessor of STP is “Rapid STP,” or simply “RSTP” for short. This new standard is called IEEE 802.1w and it’s much quicker than STP in its ability to fix switching loops. If STP can fix a switching loop in 50 seconds, RSTP can fix a switching loop in only 6 seconds. Apart from being super quick, RSTP is reverse-compatible with STP-capable switches, making life for switch administrators much easier.
When packets start circling back and forth in a switching loop, the network infrastructure will eventually be overwhelmed. STP and RSTP work by enabling all your switches to communicate with each other. One of your switches, however, must be designated as the “root switch,” which acts as the central switch. Every other switch on the network is somehow connected to the root switch via a “root port.” Each of these switches are subordinate to the root switch and they have a root port that connects back to the root switch. Ports that connect subordinate switches together are called “designated” ports. On most networks, we are “trunking” switches together in order for different subnets to communicate with each other. If STP or RSTP detects a switching loop or a failed connection in the link between two switches, it will open or close designated ports to open a new path.
Telecommunications Rooms: Keep Your Switches Locked Up
Network switches should never sit in the work area where the workstations reside. Your switches should be out-of-site from every-day people in your company or business and locked up in a closet or room that is designated as the telecommunications room. It’s also called the “Intermediate Distribution Frame (IDF).” The telecommunications room is where all the cabling from the workstations meet. The cables run from each individual workstation, into the wall, up through the ceiling, and into the telecommunications room. This room should be locked and only accessible by you and other network techs to prevent unauthorized people from (un)intentionally tampering with your equipment.
Disable Unused Ports
This is perhaps the most basic thing a network or security administrator can do to protect their switch. In the console interface, you can disable unused physical ports on the switch. This will prevent attackers from plugging their computer into a physical port and accessing the network and its resources; however, it doesn’t stop the attacker from unplugging a computer-already-in-use and using that same patch cable to connect to the switch. In that case, you’ll need additional security. Keep reading on…
MAC Address Filtering
If you know all the MAC addresses that should be connecting to your switch, then you can enable MAC address filtering, which ties a specific MAC address to a specific physical port on the switch. This is a form of “white-listing,” which gives the switch a list of approved MAC addresses. Should the switch detect a MAC address not on the approved list, it will deny that device access to the network. You could also deny previously seen and unknown MAC addresses by “black-listing” them on the switch. If the switch detects a black-listed MAC address, it too gets denied access. In the past, MAC address filtering was just white-listing and black-listing. However, MAC address filtering didn’t stop attackers from “spoofing” their MAC address. In a MAC address spoofing attack, an attacker changes the source MAC address of his machine, either to fool the switch into thinking the machine is an approved MAC address or for another malicious reason.
Fortunately, Cisco switches are capable of preventing MAC address spoofing. A physical port on a Cisco switch can be secured with the command (config-if) switchport port-security mac-address xxxx.xxxx.xxxx where the x’s is the approved source MAC address for that specific port. If an attacker’s machine sends a frame with a source MAC address other than that assigned MAC address to the securely configured port, the switch will block or shut down the port. This prevents MAC flooding and spoofing attacks.
Duplicate MAC Address Checking
“Duplicate MAC address checking” is another way to prevent spoofing attacks. When duplicate MAC address checking is enabled, the switch will alert when it sees two identical MAC addresses coming from two different physical ports on the switch. If the switch notices this behavior, it is indicative of a MAC address spoofing attack. If that is the case, the switch will disable the port where it detects the new, identical MAC address.
Unicast Flood Protection
A switch floods an incoming frame on all active ports (like a hub) if it cannot find a corresponding entry in its MAC address table or if the MAC address table has become full. This is a normal behavior of a switch and it’s one of the first things the switch does when it’s first installed onto the network. Attackers take advantage of this normal function by flooding the switch with spoofed MAC addresses frames. This is called a “unicast flood attack.”
With all the new MAC addresses entering the switch, the MAC address table quickly becomes full. The switch then starts over and empties its MAC address table to learn the MAC addresses of the devices connected to it again. The unicast flood protection feature allows an administrator to set a limit on the number of unicast floods. When flood protection detects unknown unicast floods exceeding the predefined limit, it sends an alert and shuts down the port that is generating the floods.
IEEE 802.1x
802.1x, otherwise known as “Port-based Network Access Control (PNAC),” is a port-based authentication protocol and it provides much stronger port security than simply disabling unused ports on a switch. It requires users or devices to authenticate when they connect to the switch, or a specific physical port, and can be implemented in both wired and wireless networks. It secures the authentication process prior to a client gaining access to a network, and blocks network access if the client cannot authenticate with the correct username and password.
As I covered in a previous post, you can implement 802.1x using a Remote Authentication Dial-In User Service (RADIUS) server and one or more Network Access Servers (NASs). 802.1x supports Extensible Authentication Protocol (EAP) and can be implemented to require authentication using multiple methods, including digital certificates. If you have the money, you can invest in a full Public-Key Infrastructure (PKI) and have digital certificates on both the servers and the clients.
One of the things I don’t like about RADIUS and 802.1x is the terminology because it switches between RADIUS implementations and 802.1x implementations. (When you study these two topics, you’ll know what I mean).
VLAN Hopping Protection: Switch Spoofing and Double-Tagging Attacks
I recently wrote a post about how we use our switches to create “Virtual Local Area Networks,” or “VLANs.” It’s very useful and limits the administrative work required for managing switches, but they also need protection. If you’re unfamiliar with how VLANs work, you should do a quick read-through.
If your workstation is connected to a switch, you usually only have access to your own VLAN on that switch, unless there is a router. Accessing different VLANs doesn’t usually happen. This is good security practice because we usually restrict users to specific VLANs to prevent them from accessing things they aren’t allowed to have access to. But, it is possible for someone to “hop” from one VLAN to another. This is called “VLAN hopping” and there are two primary methods attackers use to do this.
The first VLAN hopping method is called “switch spoofing.” An attacker can take advantage of an automatic configuration capability inside a switch, which automatically determines what’s connecting to an individual port. The switch determines whether it’s an access port that has a workstation connected to it, or it may determine that what’s being connected is a trunk interface and it configures itself automatically for that particular trunk interface. If you recall, trunks are used for connecting switches together. On most switches, this auto-negotiation of these port types uses a Cisco protocol called “Dynamic Trunking Protocol (DTP)” and either 802.1Q or ISL along with it. This process has no security associated with it; literally no authentication required. You simply send a trunk negotiation to that interface and the switch just assumes that you happen to be a trunked interface.
Once the attacker has sent this spoofed trunk negotiation and has now been configured as a trunked interface, he can then send trunked information across those configured VLANs. Essentially, if an attacker can trick a switch into believing it needs to trunk, it can become a member of all VLANs. For this reason alone, switch administrators should disable any automated trunk negotiation (DTP) on switches that do not need to trunk and you should determine whether each interface on a switch happens to be an access port or a trunked port.
The second VLAN hopping method is called “double-tagging” and there is an example shown above. If you remember from my VLAN post, we can extend VLANs by trunking two switches together. If one VLAN needs to access another VLAN on another switch, we use 802.1Q or ISL to tag the Ethernet frame with a VLAN tag and sends it to the correct VLAN on another switch. When the switch receives this frame, it strips off the VLAN tag and sends the frame to the destination access port.
However, we can also send information between switches that is normal network traffic without any of these VLAN tags. This is called the “native VLAN.” By using this native VLAN, and an additional VLAN tag, you can hop from one VLAN to another. To perform this double-tagging, you have to hop through multiple switches. That’s where those tags are being removed. The attacker does this by connecting to an interface on the native VLAN and adds not one, but two VLAN tags to his Ethernet frame. The first tag is the native VLAN tag and the second is the victim’s VLAN tag, which shouldn’t be there. The first switch will remove the native VLAN tag and, within that frame, there will be the second “fake” tag inside of it. This is not something that’s commonly done. This second, fake tag is seen by the second switch down the line, which then, of course, forwards that message to the appropriate VLAN and victim device.
With double-tagging, the attacker is now able to hop to another VLAN that was never originally assigned to him. The challenge with double tagging, since there’s spoofing going on, is that there’s no way for that traffic to come BACK to the attacker. It’s a one-way-trip, essentially, making it pointless. But, if you are trying to initiate a DoS, then double-tagging might be a useful mechanism. To prevent double-tagging, you can by keep the native VLAN of the trunk ports different from the user VLANs.
Winding Up on Switches
Switches evolved from hubs, which were never designed with security in mind. But, with a lot of suggestions from switch administrators, cybersecurity professionals, and lessons learned, modern switches can be pretty advanced hardware with a lot of nifty tools. I feel as if I’ve barely touched the surface so far.
References
Gibson, D. (2017). CompTIA SECURITY+ Get Certified Get Ahead SY0401 Study Guide. Virginia Beach, VA: YCDA, LLC
Meyers, M. (2015). All in One CompTIA Network+ Certification Exam N10-006. McGraw-Hill Education: New York, NY.
The Cybersecurity Man 