• 03/28/2012
    5:01 PM
  • Network Computing
  • News
  • Connect Directly
  • Rating: 
    0 votes
    Vote up!
    Vote down!

5 Secure Switch Management Best Practices

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.

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.

Log in or Register to post comments