Logically Securing a Wired Network

In a previous post, I covered some steps that organizations can take to help secure their wired networks simply by securing the physical access to their network gear. It might seem like an insignificant step, but the number of hacker stories that start off with “So, I glanced over and there was an open port (USB, Network, whatever) and I plugged into it and it was live” is significant enough that it warrants paying attention to that step.

Now, I am going to cover some logical steps that can be taken to help secure your wired network from a logical perspective. While the best practice includes a Network Access Control (NAC) solution, NAC’s have a tendency to be pricey if you have a lot of ports to manage; they can also be labor intensive to feed and support. Smaller organizations may not have the time and expertise to institute a NAC solution. Larger organizations, who are able to staff with the expertise to operate a NAC, might find the cost and effort to be just too much to take on.

This isn’t to say that you shouldn’t use a NAC or look into it! By all means, EVERY organization should be using a NAC solution. However, for most people reading this, we all know that best practices often suffer when met with real-world requirements and day-to-day operations. There’s no shame here, just an effort to offer other solutions or options to secure what you have with the tools available to you.

Console Ports

In the previous post, I talked about how any attacker worth their salt will have a console cable in their bag of tricks. So, counting on your “special console cable” that none of your friends have laying around to keep the console ports on your network devices secure is a bad idea. Logically, in the gold configuration for all the switches in your organization, include the command enable aaa console in that configuration script. This simple command ensures that the console port(s) are included in the rest of the Authentication, Authorization, and Accounting (AAA) services of the switch. Once AAA is enabled on console ports, if an attacker does gain access to the network gear and plugs in their console cable, they will be asked to authenticate credentials to access the hardware instead of having a free ride into your network.

Again, not the most sophisticated of defenses, but if the attacker doesn’t have the credentials, this single roadblock could slow them down enough that they either move on, trip up and trigger an alert, or spend so much time they get caught.

While it sounds funny, catching a breach in the act is actually a good thing. While we never like to have our networks compromised, if it happens it’s really good to know exactly when it happened and who was responsible. Catching someone in the act answers a lot of questions that will be asked later.
Using Confined VLANs

We all know that we should be using VLANs. These Virtual Local Area Networks help segment the network to cut down on broadcast domains and separate traffic. There are multiple ways this can be accomplished (ACLs, firewalls) that I won’t cover here, but there is a trick that engineers can do to trip up attackers by using the basic IEEE VLAN standard of instituting a confined VLAN into your network.

A confined VLAN is simply a VLAN ID that is designated to be sacrificed to the Information Security (InfoSec) Gods. This can be any valid VLAN ID, it just needs to be designated and known throughout the networking team. Once the ID has been identified, the crucial element to this confined VLAN is that the ID should NEVER appear on the uplinks of the switch. The VLAN is applied to any and all ports that are UNUSED on the switch.

Confined VLAN Configuration

These ports should be unplugged from the cable running to the wall jack, and also administratively disabled, but in case these steps are missed (because no one told anyone the port wasn’t in use) assigning this confined VLAN to the port means that even if an attacker gains access to the port, either by a wall jack or being in the room, plugging into these unused ports won’t allow them to leave the switch. With no DHCP and no ability to leave the switch, they are confined to the switch.

A side benefit to using this confined VLAN is it can quickly signal to the network team unused ports by simply looking at the VLAN assignment. If that confined VLAN (888 in the example above) is assigned to a port, they know that the port isn’t configured for use. If it is enabled, that’s an issue to investigate. If it shows a connection, again it signals an issue that needs to be investigated.

Least Privileged

The concept of least privileged is again a security configuration that resides within most enterprise hardware but isn’t utilized enough. While not as colorful and flashy as Next Generation Firewalls and Deep Packet Inspection, the concept of least privilege is the idea that not everyone needs super user access to the network configurations, and they don’t need them all of the time. Least privilege also involves policies and procedures that users follow to use the least amount of access needed to get a task done, and only “upgrade” access as-needed for more sensitive tasks.

When setting a user’s access to a device, or a group of devices, set up a unique user accountthat only has the access level that person needs. Using a generic super admin credentials as the only credentials to the network means that if that password is compromised, the attackers now have full access to the network. All of the other cool security features don’t matter if attackers can just change the configurations to their own liking.

Another benefit of unique credentials is, if needed, audit logs are much easier to read and decipher. If everyone uses the same generic credentials of admin/password then audit logs can’t point to who accessed the devices. Unique credentials like jpalmer/jimlikescookies mean that the audit log will show it was Jim that accessed the switch and made changes. If those credentials aren’t allowed to make configuration changes (least privileged) then changes can’t be made, or even to show the elevated credentials needed to make those changes.

Finally, unique credentials mean that when Jim leaves the company, only his credentials need to be removed from the network, not everyone (because of something like a common, admin username and password). While this is easier done using a centralized AAA server to authenticate against, it’s still something that can be done even without that central authentication server.

Forcing users to elevate their privileges, when needed, and using a separate unique passphrase can be a small delay for authorized users that they might complain about. But those two steps can be a stone wall for an attacker even if they gain access to the network.

Remember, it can be the smallest obstacle that thwarts an attack; we want to make sure we have enough of them that the attackers give up and move on.

Link Error Disabling

The last logical configuration that I want to cover is probably my favorite. Attackers generally try to be stealthy as they make their way into the network so their plan can’t be stopped until it’s too late. As such, they generally don’t like to unplug any active device in case there is alerting on the network for devices that go down. Also, since some devices, like Wi-Fi® access points, are in public areas and these devices can infrequently go down and up on their own, it becomes difficult to tell if something went offline innocently or due to malicious intent. So, just checking for down/up devices is not enough.

Due to their accessibility, attackers view Wi-Fi APs as a front door to the network that is wide open, and as such, favor attacking them. There are steps that can be taken to secure these using things like MAC learning or NAC, but NAC can be expensive and the MAC address is usually printed on the device. RUCKUS Networks ICX® switches have a command that can be used, free of charge, to help protect against anyone trying to use these APs as a wide-open front door to the network.

link-error-disable toggle-threshold sampling-time-in-sec wait-time-in-sec

Applied per port, either one at a time or to a range of ports, this command looks imposing but is fairly simple in use. For a network device that is identified as a potential target (say an AP in a lobby that is open to the public and the wall jack is accessible), the configuration would look something like this:

device(config)# interface ethernet 1/1/1
device(config-if-e10000-1/1/1)# link-error-disable 1 1 0

What this sample configuration is telling the switch is if port 1 of the switch goes down one time (the green 1) over the time span of one second (the orange 1) then the port will error disable (turn itself off) and NEVER turn back on (the red 0). These parameters can be adjusted as needed, like only disabling for a few seconds or even hours, and how many times the port would need to go down over the course of a few seconds (10 times in 5 minutes as an example). But for areas that have been identified as being vulnerable, keeping the port permanently disabled, until manually reset, allows for the organization to dispatch a tech to physically inspect the hardware to make sure that it wasn’t tampered with.

Is it time consuming? YES!

Is it service impacting? YES!

Is it an inconvenience? YES!

Is it more time consuming, service impacting, and inconvenient than a full network breach with all the organization’s data stolen and operating systems encrypted, waiting on a ransom to unencrypt it? NO!

These alerts can be tied into other platforms that can even send messages and emails letting administrators know exactly when this event happened, which is a critical piece of information for any investigation.

Final Thoughts

There are enough logical configurations and products available to secure your networks to fill a thousand page book. The goal here wasn’t to cover all of them, just to highlight a few that can be implemented without being cost prohibitive.

Don’t get me wrong, you are still going to want to go and spend some money on your IT security and take other steps to secure your network, but these steps that I outlined might be the one piece in the InfoSec playbook that protects your network and thwarts an attack before it can happen. Honestly, the odds are about the same or better that these simple steps will prevent an attack as opposed to a million-dollar security investment stopping a 0-Day attack.

Remember, we need to make sure we focus on the small things to secure our networks as well as the bigger, complicated, and high-profile attacks we read about. Attackers won’t risk exposing a super-secret exploit if they can use a simple, open back door.

Join me in the next installment where I will start talking about wireless security. If you can believe it, wireless security can actually be easier to implement and control than wired security!