Willkommen bei RUCKUS Networks, einem Teil des weltweit führenden Portfolios an Netzwerklösungen von CommScope. Mehr erfahren.
A network engineer that specializes in route switch will say that their job is tougher because of needing to secure the “entire” network. A network engineer that specializes in wireless will say their job is tougher since radio waves travel everywhere.
Who is right? Neither.
The answer to the question is that both jobs are simply different sides of the same coin.
Wired networks consist of printers, desk phones, and a myriad of other terrible devices we never want to see on a wired corporate network, but the organization wants to deploy anyway. On that same network, you also have data centers and servers that live at the heart of the network and possibly the heart of the entire organization. Allowing all these devices to be accessible but also limiting who and what has access to these critical servers and the information they contain, is a challenge.
All of this, and we haven’t even introduced desktops and our everyday users to the mix yet.
And lest we forget, it isn’t like securing wireless networks is a cakewalk either; but we will get to that aspect all in good time.
For now, we are going to focus on some basic steps and best practices that we can take care of to make sure that our wired network is as cleaned up as we can get it so when the advanced steps of deploying NAC (Network Access Control) and other cool features like that come around we at least have a good idea of what exactly we are trying to secure.
Physical location isn’t as easy as it sounds
The first item on our list is about the physical location of our switches, and by extension, the location of the wall jacks that connect to our switches.
While it sounds basic, it’s not uncommon for larger organizations to not know exactly where all of their switches happen to live. Yes, it actually happens. If we don’t know where all of the network devices are, or even how many we have, it makes it really hard to ensure that physical access to those devices is controlled. You can use tools like RUCKUS Cloud™ or a SmartZone™ controller to manage your network, automatically generating an inventory for you. Using other tools like a spreadsheet to keep an inventory of active network devices on the network, while a not great way to do it, at least gives the organization a starting point in their battle of what is active on the network. Whichever you choose, an accurate list of assets by location is a must-have for a secure network.
Once the locations are known, make sure that these devices are physically secured. And no, hanging them in a bathroom above “the facilities” in the bathroom[1] isn’t secure.
Physically, on a switch, there can be a couple of points of weakness that might not seem like a weakness until a well-versed hacker gains physical access to your devices. Some of these things might not even appear to be useful until you start thinking through the various uses that each connection on a switch might offer. In addition to all of the ports we normally think of, for today I want to focus on the ports that aren’t used by the typical device or traffic flow.
Pictured below is a typical switch.
Image 1 RUCKUS ICX 7150-24F Switch
OK, so I understand that this is a Single Form-factor Pluggable (SFP) switch, but it is a great picture that highlights what I want to talk about.
For a network engineer that needs to support these devices, the majority of these ports are seen just as the working parts of the switch; we are going to cover these in a different post. For now, I want to focus on the ports that aren’t used in the daily operation of this switch. But, instead of thinking about them as a network engineer that just walked into a closet to fix something (like adding the management VLAN to the uplink ports after you misconfigured the switch from your desk), think about this switch from the perspective of someone who is looking to do something nefarious once gaining access to this device.
Like, for instance, what about those console ports? There are two here; an RJ45 that requires a “special” console cable (that any attacker worth their salt will have on them) and a USB-C console port. These are two ports of access that we might want to limit attackers from accessing.
There is also a standard USB-A port on here. How comfortable would you be with an attacker being able to plug their own flash drive into this and then reboot the switch by simply pulling the power cable? Maybe a little, but not enough to sleep soundly while you are on-call? (Note that the correct answer should be “very uncomfortable!”)
Then, there is an RJ45 management port. Yes, this should be logically locked down, same as the console ports, but are you certain that is configured on all of your switches?
Finally, there’s the factory reset button. While not very useful (at least not to me, but it could be useful to the wrong person with a crazy enough imagination), factory resetting a switch can cause all kinds of problems for an organization. If the switch is offline or unable to forward traffic due to a reset, then so, too, are security cameras, VoIP phones, Wi-Fi®, and other physical security devices running over that device.
So, to summarize, you should limit physical access to the cabinets with the switches and lock down any console ports within the switch operating system. This is an example of physical and logical security measures meant to back each other up. Defense in layers. We will get to the configurations part of this defense in a later post.
Jacks can be secured as well
Any access port on a switch, whether it is on the switch itself or a wall jack that is cabled back to the switch, will always pose the biggest challenge to security. While a standard switch can be just a single device, or even multiple switches in the same room, it’s still a pretty centralized space to secure. However, two 48-port switches in a single room can mean 96 connected wall jacks, and I am going to guess they aren’t all going to be in the same room.
This means 96 possible points of entry into the network and tracking so many locations can be daunting for any organization.
A simple method that doesn’t require additional hardware is to just unplug any unused wall jack from the switch. Without that physical extension of the switch to the cable, there isn’t anything for an attacker to connect to. And, if you need it again, you haven’t pulled the cable; you just connect the cable back up to the switch and the jack goes live again.
The downside to this approach is this means time spent to disconnect that jumper when the wall jack is no longer needed, and then, when it is needed again, the time to go back and ensure that the correct wall jack is connected to the correct port on the switch. Depending on the risk acceptance of your organization, this may or may not be an option.
Another way to secure these unused ports is to simply add a “locking” cap to the wall jack or switchport itself.
Image 2 CommScope RJ45 Port Blocker
While not a foolproof or 100% secure method, sometimes all it takes is something simple and basic, like a plastic RJ45 Port Blocker from CommScope to foil an attacker and protect your network.
The downside to this approach is if you thought it was hard to find where all of your switches in your network are located, wall jacks are much harder to find!
Final Thoughts
While there are many other types of physical access controls that can be put in place, this isn’t meant to be a comprehensive list of things you have to do. Instead, this is meant to make you think about the importance of physical security and develop a plan that is right for you and your organization. If what you take from this is a better appreciation, and thought process, about securing physical access to your wired network and ports, then we are one step closer to cleaning up the stuff that can impact the security of our networks.
Make sure to join me in the next installment where I will cover some tips on logical configurations you can take to help keep your wired networks secure.
-----
[1] File this under things I write that I wish wasn’t a true story, but it has happened—and more than once.