5 Secure Switch Management Best Practices
Posted by
Jennifer Minella
March 29, 2012
One of the easiest things an organization can do to help increase the security posture of their infrastructure is to implement a policy and standard for secure management. Often overlooked, or not fully executed, this is what I consider to be the low-hanging fruit of network security.
After you have performed the 5 basic configurations on your switches, follow these recommended configurations which are considered best practices by most, if not all, network engineers and networking vendors. Since different types of organizations have different security requirements, there are some exceptions and some options for common practice (versus best practices) and I'll explain that as we go along.
I know many of you will argue that the entire list should be in the best practices for minimum configurations, but each situation is unique, and there are times when some best practices don't fit into the organization's structure. A practice, best or common, is useless if it's not followed, or not manageable for the organization.
Set console and CLI access passwords
We have to start with this task, since the other settings will require this to be done first. Out of the box, you should always configure proper passwords for the switch's various CLI access methods, and levels of authorization. As an example, if you're using Cisco devices, you'll want to set the console and telnet credentials. Be sure to configure different passwords for each authorization level, and don't reuse passwords. Most switches have at least a look-only access as well as a full management access privilege. In many switches, you can assign a more specific privilege level. HP switches ship with two privilege levels, an operator (look) and manager (full management). Cisco and HP's A-series (3Com) have privilege levels through 15 and 3, respectively and you can assign commands to different levels. Cisco has documentation on how to use privilege levels.
Regardless of the switch type, I highly recommend you take this opportunity while assigning passwords to also assign usernames. Although they're not required for basic CLI access, many 3rd-party network management tools have complications with a null username. It's a few extra keystrokes in the line with the password configuration.
Secure CLI (enable SSH, disable Telnet)
The next thing you'll want to do is enable SSH (secure shell). Using SSH instead of Telnet encrypts management communications between the terminal and the switch. Just like other management security best practices, this prevents anyone from sniffing the traffic on the wire and collecting usernames, passwords and configuration data or commands. Enabling SSH may seem like a bit of a pain, but you only have to do it once, and when it's done, you'll have made leaps toward your management security.
Once this is configured, the only difference for the network admin between managing with Telnet and SSH, is that SSH will require a client to run, while Telnet is built in and enabled by default in most Windows operating systems. The two most common free clients for SSH are Putty and Terra Term. When configuring SSH on the switch, one of the steps will be to create a public/private SSH key which your SSH client will use to authenticate the switch when you connect. Each switch will have its own SSH key. It is recommended you save and install this key to whatever client you're using to prevent man-in-the-middle attacks, but I can tell you few network admins actually do this. If security is important, do it. If you're just trying to prevent the management traffic from being sniffed unencrypted, you may choose to skip that step. Note, I'm not recommending readers skip this step, but I'm being realistic in day-to-day management practices.
When SSH is configured, test it first, before you disable Telnet access. As a side note, in new infrastructures that are distributed, I recommend testing access with the switch in situ. It's rare, but I have seen some instances in enterprise networks where locations were on different subnets and the traffic between was filtered by ACLs or a firewall rule that was accidentally blocking port 22 (SSH) but not port 23 (Telnet).
With SSH configured, tested and working. Make sure all of your management and monitoring tools that require CLI access are using SSH instead of Telnet. When you've got everything talking to the switch via SSH, it's time to disable telnet.
Page: 1 | 2 | Next Page »
