Posts Tagged ‘Layer 2 Security’

One thing that should be standard in your setup, is secure management. Being a network engineer requires you to secure your management interfaces, whether the management interface is a web page or remote CLI session, it should be encrypted and authenticated. After all configuring port security and firewalls are useless if your administrative credentials are sniffed off the network in clear text, or worst case your entire configuration.

First thing you want to do is activate the secure protocols and disable the weak protocols. So we would issue the following commands:

As you can see we first disabled the HTTP protocol, and then enabled HTTPS (Note: the first time you enable HTTPS a certificate may be generated), then configured the vty lines to accept only SSH, and not telnet connections.

Note: Prior to disabling telnet and enabling SSH, you want to configure the aaa new-model parameters along with any local users DB entries. See this Cisco guide for configuring SSH in more detail. Last thing you want to do is lose remote access to your device.

Now this device can only be managed via HTTPS or SSH, telnet and HTTP access have been disabled. This will prevent the administrative credentials of your network devices from being sniffed off the network in clear text, only encrypted cipher text will be found.

Just to push the point home some more, here is a TCP stream where I telnetted into a lab switch and issued the sh run command. First off you see the password I entered to access the switch and secondly the entire output of the sh run command is right there in clear text!

Now, I did a second capture where I accessed the switch via SSH and issued the same commands.

Very different output, as you can see, in the beginning you see I used Putty after that the encryption algorithm exchange and the rest is cipher text.

You can also verify this by using NMAP to perform a port scan on the device to see what ports the device is listening on.

Here is a NMAP Scan with all four protocols enabled (Telnet, SSH, HTTP, and HTTPS)

Here you can see, the lab switch is listening on all four ports, so individuals can connect to this device in an insecure manner. (The option should not even be out there)

Now a second NMAP scan after the commands shown above were entered.

Now the device is only listening on 22 and 443. This device can only be managed in a secure way.

I’ll end this on a final note… The tools I used here are all free to download NMAP, WireShark, and Putty. So it doesn’t take much for some barely knowledgeable (and bored) user on your network to start sniffing packets on your network.

I figure I would tackle some Cisco switch security, which oddly enough is typically overlooked, it seems most people primarily focus on their firewalls protecting layer 3 and above meanwhile you can plug right into a layer 2 switch and your in. So it just seems to me that layer 2 security is occasionally overlooked, but we shall cover a few good commands within Cisco switches to protect layer 2. Please keep in mind that security is a broad enough subject as it is, so this post itself will cover parts of port security here, and the discussion will be continued in another post.

I’ll start off by pointing out the most common kind of attack port security protects against, and that would be MAC Flooding in this type of attack an attacker sends multitudes of spoofed MAC addresses to the switch so the switch stores all the address in the CAM table, and at some point the CAM table overflows and the MAC addresses of legitimate clients are flushed out, at which point the switch forgets how to get data to the legitimately attached clients, so when any legitimate data is sent it gets flooded out all ports. This could have multiple effects one, the attacker can sniff the data off the network and, two any other attached network devices/workstations/servers will get flooded with the data as well so it will simulate a DoS attacks well. This can also protect against a MAC spoofing attacks, where an attacker will change their MAC address so the switch thinks the attacker is a different device like a router, at which point all data leaving the subnet is sent to the attacker so the attacker in essence performs a Man-In-The-Middle attack, where they can do whatever they want with the data they receive.

I would also like to include this will protect against DHCP attacks, after all DHCP leases are given to the MAC address so MAC flooding attacks could also be used to fill up your DHCP scopes (Another type of DoS attack), and when you sit back and think how important DHCP really is and how dependent most networks are of it, imagine losing it for a little while. As stated above however I will cover DHCP Snooping and Dynamic ARP inspection in the future, I just wanted to include this little tidbit.

You can protect against these types of attacks by implementing port security. Keep in mind when you implement port security you can either configure it to be really restrictive or just to protect against the mentioned attacks. The syntax to configure port security is below:

See quite simple really.

The first command simply activates port security on the switch port, but you still have a few more parameters to set. The next command sets the maximum number of MAC addresses the switch port can learn before a violation occurs, which is what is configured in the third line. The default is shutdown, which as you can guess shuts the switch port down, requiring IT to intervene to see what is happening. Their are two other violation modes you can configure instead of shutdown one of which is protect which will allow the computer with the configured MAC address(es) to communicate with the network while dropping the frames of any other computer with a different MAC address after the violation occurs, however the switch will not increase the violation count so their will be no indication at all that anything is happening until a legitimate user complains, so this will happen without your knowledge. The other violation parameter is restrict which acts very similar to protect but restrict will increase the violation count and sends an SNMP trap so at least their is an indication something is happening. I’ve honestly only used the shutdown parameter, since I really do not see the point behind the restrict/protect since an attack could be attempted without your knowledge, where as shutdown will stop any attempt in it’s tracks, and if your smart and this happens enough you will investigate. Now the mac-address sticky command, simple takes the first mac address the port learns and adds it to the running config, so if the device on other side of the switch port needs to be changed it requires administrator intervention.

Now when I said this could be configured to be really restrictive or just to prevent L2 attacks. A switch can hold a very large amount of MAC address, so you can simply set the maximum number of MAC address to 100 per port and forget about it for a while, or you can be really restrictive and set the number of MAC address to 1 or 2. Just keep in mind how often your users get new PC’s or if they move between offices with laptops. You’ll need to decide how restrictive you want to depending on your environment.

Another thing you want to plan for is how are you going to manage port security, just think when a user at a remote site calls up and says “I can’t connect” and you know it’s because of the port security and you have 3+ switches at that site, it doesn’t make much sense to go in their and clear every port security violation now does it or to connect to all 3 switches blindly issuing show port-security hunting for violations? I’ve got my switches sending port security and err-disable traps to a syslog server of mine where I can filter by those specific traps where I see the switch, the port, and the time it went down, from there is just takes a few questions to the user and it’s easier to figure out. (Thank you SolarWinds NPM!) Then simply issuing a shut no shut on the interface will clear it, now if you have issued the mac-address sticky command you will want to clear the original mac address or else the port will simply go back into and err-disable state, to clear the sticky mac address issue the clear port-security sticky int <specify single interface> from global config mode, then proceed to shut no shut the interface.