SNMP Security Best Practices

A question that often comes up during deployment is how best to ensure security while using SNMP to collect data from devices under management. This article will detail some of the best practices we have developed over the last 20 years of managing large internetworks and developing network management software.

But first, let's look at the differences between the SNMP versions.

SNMPv1/v2

SNMPv1 and SNMPv2 (properly referred to as v2c, however the terms are used interchangeably) are older versions of the protocol. SNMPv2 primarily consists of performance enhancements over the older v1 protocol, but from a security perspective SNMPv1 and v2 are identical.

Both versions use a "community string" which functions as a password. This community string is transmitted across the network without encryption, as are the responses from the device. When an SNMP manager application wants to connect to a device with SNMP, it includes the community string in the request. If the string is correct, the device responds with the appropriate values.

Most devices can support multiple community strings. Each community string can be configured with "read-only" or "read-write" permissions. The read-only permission type generally does not allow the management application to perform any "dangerous" actions, such as downloading device configurations (Netreo does not use SNMP to retrieve device configurations, so is not subject to this limitation), or making changes to device parameters.

On most devices, SNMPv1/v2 can be secured with address restrictions or "access lists," that prevent SNMP access except from authorized devices or subnets. Netreo recommends implementing these filters wherever possible for best security.

SNMPv3

SNMPv3 was developed to address the security limitations in SNMPv1/v2 and provide much more granular control over SNMP access. It can be configured in one of three primary modes:

• NoAuthNoPriv - this mode provides identical functionality to SNMPv1/v2 from a security perspective. All authentication information as well as device responses are sent "in the clear." This mode requires a configured "username" to access the device. Netreo recommends against the use of this mode, as it provides no additional security, but does decrease performance.
• AuthNoPriv - this mode encrypts the authentication credentials (essentially a username and password), but the device response is not encrypted. It can be configured to use either the MD5 or SHA hash algorithms for security. This mode requires a username, as well as an "authentication password".
  • The MD5 algorithm is generally considered insecure, and should not be used if possible.
• AuthPriv - this mode encrypts both the authentication credentials and all of the device response information. It uses the same algorithms for authentication as AuthNoPriv, and also allows the user to select either DES, 3DES or AES as the encryption algorithm for the device response data. It provides the highest security, at the cost of the slowest performance and largest impact on memory and CPU on monitored devices. This mode requires the username and authentication password, as above, but also requires a configured "privacy password."
  • The DES algorithm is insecure, and should not be used if any alternatives exist.

The AuthNoPriv and AuthPriv modes each require additional "passwords" that must be at least 8 characters in length.

Additionally, SNMPv3 users can be configured with "views" that further limit their access to the device's performance statistics. For example, a user could be enabled that had access only to the performance statistics of a specific group of interfaces, or that did not have access to system-wide statistics. Not all vendors support this functionality of SNMPv3, and it can create considerable configuration complexity—so it should be used with caution.

These SNMPv3 security models were developed to address the specific threat of a compromised system on your network being used as a packet sniffer to intercept data in transit. The idea being that if an attacker can intercept your SNMP strings, they could then use that information to further map out the internal architecture of the network, or to download device configurations (which generally requires read-write access) and then use that information to try and find additional ways into the network. The security issues it addresses are all based on the same assumption—that an attacker has already compromised an inside system and is trying to use SNMP to leverage it.

The profile of an attacker has drastically changed in the years since SNMPv3 was invented, which is part of the reason it is so rarely implemented today (we see it in fewer than 1% of our customer base). Insider threats comprise over 80% of all network breaches today. Even without an insider, it's much simpler and easier to compromise an end-user system with phishing attacks and targeted email, and then get them to unknowingly install malware. That malware can then do anything the attacker wants (up to and including full key logging). As a result, it's extremely rare to see anyone using SNMP as an attack vector any longer. The SANS Institute (one of the largest and most respected Internet security training firms in the world) lists SNMP probes as running at a typical rate of about 5,000 per day (worldwide). Compare that to the rate for HTTP attack probes at about 3.6 million per day, and you can see that the scope of this threat is fairly limited.

Another thing to consider is that SNMPv3 security doesn't come for free. Many manufacturers support SNMPv3 only in a limited fashion (such as without encryption, in which case it provides no benefit whatsoever), or support it only for some statistics and not all. It often requires a special "encryption license" for the software at additional cost. It also requires at least doubling the management traffic on the network compared to SNMPv2. It will have a measurable and significant impact on the monitored device's CPU utilization (which is of special concern when looking at low-powered access layer devices), and our testing shows that it typically performs at approximately 1/4 the speed of SNMPv2. This means there is the potential for a significant impact on how long it takes to monitor a given number of devices and overall network performance. The configuration of SNMPv3 is also considerably more involved and complicated, so it may impose a technical and/or training burden on network and support staff.

While it is true that SNMPv3 can provide better security, Netreo recommends the use of SNMPv3 only for customers who have an identified security risk that can be mitigated by encrypting performance statistics. Or for customers who require that read-write access to the devices be left constantly enabled.

Recommendations

With the above in mind, Netreo recommends the following practices to ensure security and performance when using SNMP.

• For most customer environments, Netreo recommends SNMPv2c, configured with read-only permissions.
• Read-write access is not generally required for Netreo to fully monitor devices and should not be left enabled.
  • Netreo can (optionally) use SNMP read-write access to configure specific features, like IPSLA monitoring for IPTel environments, or remote web response time monitors. Once configured, Netreo recommends turning off read-write access.
• Restrict SNMP access by using the filter or access-list functionality on the device under management to limit access to the specific IP address of the Netreo appliance.
• Ensure your edge routers or firewalls are blocking SNMP traffic from the Internet and from non-controlled networks.
• Customers should consider the implications carefully before deciding to standardize on SNMPv3. For assistance and advice specific to your environment and configuration, please feel free to contact Netreo Support.