There are many best-practices when hardening a network. In this video, you’ll learn about SNMP versions, port security, private VLANs, and much more.
If you’re a network administrator, then you’re probably using SNMP, or the Simple Network Management Protocol, to be able to query and receive information about the infrastructure devices that are on your network. This could be monitoring things like servers, switches, firewalls, routers, or anything else that may be connected to the network.
Unfortunately, not all versions of SNMP provide the best security. For example, SNMP version 1 and SNMP version 2 communicate over the network in the clear. There’s no encryption built into either of those SNMP versions.
If you’re using SNMP, then you should be using SNMP version 3. With version 3, we added encrypted communications, so that everything sent across the network would be private and secure. Unfortunately, not all devices support SNMP version 3. So check the documentation with your devices to see what options might be available for you.
Another useful network hardening technique is to protect your IP version 6 router advertisements. We do this by using something called Router Advertisement, or RA, guard. This particular hardening technique focuses on the router advertisements that are sent with IPv6. Router solicitations are sent by devices on the network, and if a router sees that solicitation, it will send back a router advertisement.
The security concern comes from this router advertisement. Normally, it would come from a local router that’s on your subnet. But an attacker could pretend to be a router, thereby introducing the ability to perform on-path attacks or denial of service.
Many switches have the ability to turn on router advertisement guard, where they will validate all of the router advertisements. Through the use of these RA guard policies, you can be assured that the devices on your network would only be receiving router advertisements from legitimate routers.
Another useful security technique on your switches is the use of port security. Port security prevents unauthorized users from connecting to a switch and gaining access to the rest of the network. This would be based on the source MAC address seen by a particular interface on a switch. And if that MAC address doesn’t match the configuration that you have previously configured on that switch, then you can make a decision on what you would like to do with that traffic.
For example, you would set a configuration on your switch that would configure a maximum number of source MAC addresses on a particular interface. Normally, when a person is working on the network, they would be connected using that MAC address.
But if someone else came along and disconnected that user and plugged in their own device, a new MAC address would be introduced to that interface. The switch, then, monitors how many different MAC addresses have been seen on a particular physical interface. And if that number is exceeded, you can choose to disable that interface or send an alert to the administrator.
In previous videos, we’ve discussed how ARP spoofing could be used to circumvent existing security and create on-path attacks. There is a way to prevent this in the switch by using DAI, or Dynamic ARP Inspection. This adds additional monitoring to the network and adds to the security that normally is not included with the address resolution protocol.
Dynamic ARP inspection starts with creating a map of all of the devices on your network and what their IP addresses might be. It’s able to collect this information by using something called DHCP snooping, where it examines all of the DHCP communication and begins building a chart on what IP addresses are assigned to what MAC addresses.
The switch sees all of this ARP communication and can then decide, based on the existing chart, whether a particular ARP is legitimate or not. And if that ARP request doesn’t match what’s already in the switch, the switch can discard any invalid ARP requests or responses.
On many of our modern network infrastructure devices, we have different planes of operation. The plane of the device that handles the forwarding of traffic is considered to be the data plane. Inside of the device is a management plane that allows us to configure the device. We often refer to this as the control plane. Since the control plane is responsible for the configuration and the monitoring of this device, it’s a very important plane to secure.
We need to make sure that we’re protected against denial of service or someone performing reconnaissance. We also might want to configure quality of service on our network, so that management traffic to the control plane has priority over any other types of traffic. We could also do some firewalling, so that not only are we prioritizing the management traffic, we’re also blocking any non-management traffic.
So if you know that all of your control plane traffic is going to be SSH communication, you can disable all other control plane traffic that is non-SSH. And to protect against denial of service or other types of traffic flows being sent to the management plane, you can rate limit any of the traffic that is sent directly to that management port on the switch.
If you’ve ever connected to a public Wi-Fi hotspot, you may have noticed that you have access to the internet, but you don’t have access to the other devices that might be on that same wireless network. This probably means that the network administrator for this device has configured port isolation, which limits or prevents any type of communication between the different devices on that switch or access point.
Even if all of the devices are in the same VLAN, if you’ve turned on port isolation, there’s no way to communicate between any of those devices. You might also see this at home. You’ll notice that your home network can communicate to the internet, but you’re not able to communicate to other homes in your neighborhood. Or perhaps, you’re in a hotel room and your hotel room can communicate to the internet, but you can’t communicate with any of the other devices in that hotel.
Another important best practice when you’re trying to harden a network is to administratively disable any interfaces that are not currently in use. This prevents someone from walking into a conference room or a break room, plugging into the network, and gaining access to the internal network. Many organizations take it a step further and implement network access control using 802.1X. This means that users would need valid authentication before they were ever able to communicate on that network.
Every service running on a system that needs to be accessed over the network will have an open port. Every open TCP or UDP port on this device is a potential security concern, so we want to be sure to close all unnecessary ports and only leave the TCP and UDP ports open that need access to those services.
You would, commonly, control this access with a firewall, either a next generation firewall that’s on the network or, perhaps, also a firewall built into the operating system on that server.
You also want to be sure that any unknown services or services that may have been previously installed have been either disabled or filtered from any network communication. When someone implements a new network service but they’re not quite sure which port number should be open, they may configure a security policy in a firewall to allow port 0 through port 65,535, effectively, allowing access to every port number on that device.
From a security perspective, you only want to enable the ports that are necessary for that application to work. So you may want to use a port scanner such as Nmap to see exactly what ports are open on that device and limit your access controls and firewall rules to only those ports.
If you’ve ever installed a new access point, a new switch, a new router, or any other new device to the network, you know that there is a default set of credentials that’s used for your initial login. Sometimes these usernames and passwords are “administrator” and “admin” or, simply, “admin” and “admin.” This gives a remote user administrative access to this device, allowing them to make any change they would like to the configuration of that system.
So of course, it would be important to change the password to something that would not be available to others or to create a separate account for the administrator and disable the default account on that system. If you want to see what the default authentication might be for some of your devices, you can find a number of resources on the internet, such as routerpasswords.com.
If you’re planning to change the password on one of these devices, we need to make sure the password is something that is difficult for someone else to know. You want to have what’s called a strong password, which is one that adds so much complexity that it’s not something that’s easily discovered. Your focus should be on increasing the entropy of that password. Entropy is a measure of how unpredictable a particular value might be.
So you don’t want to use single words or obvious passwords, like the name of your dog. And you want to mix uppercase, lowercase, and, perhaps, add other characters into the password. You also want to be careful with replacing certain characters.
For example, replacing an O with a 0, or replacing the letter t with the number 7 because attackers already know that these techniques are in use, and they’re already planning their brute force software to take those into account. These days we tend to create passwords that are eight characters or longer. And very often, you can choose a phrase or set of words to make your password even stronger.
One of the challenges we have with the DHCP, or the Dynamic Host Configuration Protocol, is that there’s no security built into the DHCP specification. We can add additional security in our switches by enabling DHCP snooping. This allows us to track IP addresses and MAC addresses on this layer 2 device. The switch would effectively become a DHCP firewall.
You would configure the switch to trust routers, switches, DHCP servers, and anything else that is legitimately handing out DHCP responses. You would not want to have the switch trust any of the other devices on your network, such as other computers or devices that could be turned in to unofficial DHCP servers.
With DHCP snooping, your switch is always examining the DHCP conversations, and it’s building its own table as to what IP addresses are associated with which MAC addresses on that switch. This allows the switch to filter out any traffic that doesn’t match that list of pre-assigned DHCP assignments. This allows the switch to filter out any traffic that doesn’t match this predefined list of IP addresses and MAC addresses.
So if someone tries to statically assign an IP address on their system, it would be filtered by the switch. Or if an attacker tries to create their own DHCP server or send an invalid traffic pattern, all of that communication will be automatically filtered by DHCP snooping.
If you look at the configuration of a switch, you would find that all access ports, which are all devices that are not trunk interfaces, are assigned to a specific VLAN. This means the user connecting on that physical interface on the switch will be added to the VLAN associated with that port.
If we look at this VLAN configuration on my network, you can see there are a number of interfaces, 24 fast Ethernet interfaces and two gig interfaces. All of those interfaces are configured with the default VLAN, which is VLAN 1. If I connect a device to fast ethernet port 0/14 and turn it on, it will automatically be part of VLAN 1.
One of the challenges with having users on a default VLAN is that there might be other administrative traffic on that VLAN as well. For example, control plane access or management of the switch might occur on the default VLAN. From a security best practice, we don’t want to have our users on the same VLAN that’s used by our management traffic. So we might want to have a separate VLAN created on that switch that’s just for our management communication.
We also might want to configure our switch so that any of these interfaces that currently don’t have anything connected to them don’t have a connection into the default VLAN. Instead, we might want to create a dead-end VLAN, or an impasse VLAN, and assign any unused interfaces to the dead-end VLAN. This way. If someone does find their way onto that interface– they plug in their device and try to gain access to the network– they’ll find they’re on a VLAN that goes nowhere.
If you look in the internals of your switches, and routers, and other network devices, you’ll find that they’re not using a traditional operating system. Normally, there’s not Linux, Windows, or some other OS running on those devices. Instead, they’re running their own type of firmware. And occasionally, there will be a need to upgrade the firmware on those devices, so that system is always up to date.
This usually happens when there’s some type of security vulnerability associated with that firmware, so you have to upgrade to the latest version to be able to patch that hole. Unfortunately, the upgrade process doesn’t always go as planned. And sometimes upgrading firmware can introduce other bugs, or other problems, and you may need to downgrade that firmware after identifying those problems.
Unfortunately, it’s not always easy to find one of those older versions of firmware. So you want to be sure to keep a library of all of your devices and all of the firmware that’s running on those devices. This will allow you to move to any particular firmware version at any time, especially, if you run into a problem.
This idea of patching a system should not be a surprise. It should be part of the normal procedures that you go through. You want to be sure that you’re able to keep up with the latest version, so that your systems are not only stable, but you fix any security problems that may be introduced in the current version.
Some manufacturers will create service packs, where you can introduce or install many different patches all at one time. Or you may just want to install patches as they’re updated every month. Sometimes the manufacturer will introduce patches outside of this normal scope, especially if it’s an emergency or a zero-day attack, and they may create an out-of-band update and require you to update as soon as possible.
As a network administrator, you need full and complete access to your switches, routers, and other infrastructure devices. But you may want to have other individuals in the organization with their own access to this device, but you may not want to give them administrative access. Perhaps you only want them to be able to view statistics on that device or to view the logs on that device. In those cases, you may want to configure role-based access, so you can create one role for administrators and a different role for the help desk or management.
You may find that the switches, routers, firewalls, and other devices you’re using do allow the configuration of specific roles. So you could create an administrative group, a help desk group, and an IT management group within your device and then assign users to each of those groups. You would then specify what those groups are able to access and what parts of that system those groups would not be able to access.
For example, the help desk may be able to view statistics. And an API access group may not be able to log in interactively. You could even take this a step further by creating a set of Access Control Lists, or ACLs. This would allow or disallow access to the system based on a number of tuples.
These would be groupings of categories that might include source IP addresses, destination IP addresses, port numbers, or anything else you can use to make a decision on whether traffic should be allowed or denied.
Maybe you’d like to restrict access to a particular switch or router based on a series of IP addresses. Maybe you know that the network administrative team is on a very specific VLAN, or set of IP address ranges, and you might want to prevent all access to that device if they don’t come from that specific range.
You, obviously, want to be careful when configuring these because if you’re outside of your local VLAN and you need access to this device, you might be locked out of your own equipment. You want to be sure that the access control lists are strong enough to prevent unauthorized use, but still allow you to be able to manage those devices.
One type of access control list is a firewall rule. We may want to allow or disallow traffic through our network based on a series of rules that we can add to our firewall. This list of rules is followed one at a time, and if the traffic matches that particular rule, then it follows the disposition that’s in the action column.
When you get to the bottom of the list, on most firewalls, there is an implicit deny, which means if none of these rules match when you get to the bottom of the rule list, that traffic is automatically dropped. These implicit denies are, commonly, not logged in a system. That’s why you’ll find many firewall administrators will add one final rule at the bottom.
That is in any IP to any IP over any port number and any protocol will automatically be denied, which is, effectively, the same thing as an implicit deny, except we are explicitly creating this deny rule. Most firewalls are configured to log anything that’s in the rule base. So by adding this explicit deny to the bottom of the list, we can log any traffic that doesn’t match any of the rules inside of our firewall.
This is a very simple rule base for a layer four firewall. The rules have a rule number, a remote IP address, a remote port number, a local port number, a protocol, and an action to follow.
Let’s look at this first rule of the firewall. We can see that any remote IP and any remote port can communicate to a local port 22 over TCP and that traffic would be allowed. Since we know that TCP port 22 is for SSH traffic, then this rule was, probably, set up to allow inbound SSH.
Rule number two is configured to allow any remote IP address over any remote port number to communicate to a local device over port 80 using TCP. That traffic would be allowed. TCP port 80 is commonly used by HTTP, so this would allow traffic to a web server.
We have a rule right after that one that includes TCP port 443, which would be the HTTPS traffic to that web server. And the last rule is an explicit deny. This means if traffic does not match anything in rule number one, number two, or number three, we will deny that traffic and log it in the firewall.