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.
Secure Web Management (enable HTTPS, disable HTTP)
Similarly to the use of SSH instead of Telnet, it is recommended you secure the management traffic that may be sent to the GUI as well. This is another simple configuration that doesn't affect how you manage the switches, or add complexity. The only difference here in managing the switch is that you'll now access it via HTTPS instead of HTTP.
When you configure HTTPS, you'll create a certificate for the switch to use to authenticate itself to the browser for an HTTPS connection. This ensures all management traffic including your login credentials sent via the web GUI will be encrypted via SSL/TLS instead of in the clear. You can follow these instructions on how to set-up a CA in less than 10 minutes.
Many organizations use self-signed certificates that ship with the unit, which are not validated by a certificate authority. If you have a certificate infrastructure in-house, use a real certificate. I don't know of any organizations that purchase 3rd-party certificates for this use, so my recommendation is to generate one with your internal certificate server, or let the switch create a self-signed certificate (note this will display a certificate warning in the browser).
You can add a self-signed certificate to your browser so that you don't get certificate warnings and the browser can authenticate the device. Just make sure that your initial configuration is performed on a trusted network or a direct connection to the appliance so you know there isn't a MITM.
Again here too, test HTTPS access, and when it's verified, disable HTTP access.
Securing SNMP (create custom strings, remove defaults)
SNMP, or simple network management protocol, is another method by which switches are managed. There are several versions of SNMP. For now we're discussing SNMPv1 and SNMPv2c. We're not going to get into the differences between them now, but just know that these two SNMP types use community-based strings to read or write to a switch. Part II of this series addresses SNMPv3, which makes uses of usernames and encryption.
If you think you've done everything else right, SNMP may be the weakest link in your network. Many network admins overlook these settings because they probably don't use SNMP directly to make changes, but it's possible (and easy) with tools available on the Internet so you should always change these.
By default, most switches are shipped with one or two default SNMP community strings such as public for read access and private for read-write. The SNMP restricted or read-only string can be used to view settings on the device and the SNMP read-write or unrestricted string can be used to make changes to the switch. Some switches ship with no defaults.
To secure SNMPv1/v2c, you need to define custom SNMP strings for the different levels of access (read-only and read-write) and then be sure to remove any and all default strings. Because SNMPv1/v2c communications are not encrypted, the strings are sent in clear text and could be intercepted or sniffed. For this reason, we never recommend using real passwords for SNMP strings. You should choose at least two strings that are unique, but don't divulge any secrets or passwords.
Once the SNMP strings are changed on the switch, you will need to update your management and monitoring tools to match. Most network management tools rely heavily on SNMP access to gather information and configurations from devices, so be sure you update any tools as soon as a change is made, to avoid complications or failed scans.
Removing unsecured management access
The recommendations above are only of value if you clean up the configuration by disabling the unsecured management access. If you enabled SSH, disable Telnet. When you enable HTTPS, disable HTTP, and when you set custom SNMP strings, remove all default strings.
This concludes Part I of our Best Practices for Secure Switch Management. As mentioned before, these are the minimum recommended settings for any production environment. In Part II we explore further best practices for security-conscious organizations.
Read more about Securing Flat Networks. Free, registration required.
