This article can also be found in the Premium Editorial Download "Information Security magazine: Keeping on top of risk management and data integrity essentials."
Download it now to read this article plus other related content.
The ubiquitous management protocol is more secure, but upgrading isn't simple. The "S" in SNMP never stood for secure; it was always meant to be "simple."
Simple Network Management Protocol provides a critical functionality for facilitating network monitoring and management with products such as Hewlett-Packard's OpenView and IBM Tivoli. But it always came with a risk. The protocol's first version was inherently insecure; it lacked encryption and authentication, and was vulnerable to a number of easily exploited attacks.
SNMPv2 was designed to fix many of the original security issues, but failed to close all the holes. It did add minimal authentication and some encryption, but it wasn't backwards compatible and was significantly slower than version 1. SNMPv3, on the other hand, gives security and network managers a protocol that is robust, uncomplicated and secure. However, while backwards compatible, it isn't supported by all devices out of the box.
SNMPv3, of course, is not new. But, not everyone has upgraded, and many enterprises are using a hodgepodge of the protocol's three versions. If you haven't done so already, you should examine its security improvements and how to apply it to both supported and unsupported network devices.
Third Time's the Charm
In reality, SNMPv3 is more a fix of version 1, since it essentially ignores version 2. It corrects the baseline problems of the original protocol, including
SNMPv3 encrypts all transmissions, but also enables the responder (usually an SNMP agent) to authenticate the user generating the request, to guarantee the integrity of the message using a digital signature, and to apply complex and granular access control rules to each request.
A big problem with SNMPv1 is the selection and protection of the public (read access, such as memory and CPU utilization) and private (write access, such as instructing a reboot or making configuration changes) community strings. Both public and private access are given community strings; however, most people haven't realized that the strings are essentially passwords, and, for a long time, have used the word "public" as the public community string and "private" as the private community string. SNMPv3 allows complex checks that will keep users from picking easy-to-crack strings.
Significant improvements to SNMPv3 are user-based authentication and the use of MD5 and SHA protocols. Authentication in versions 1 and 2 is based on knowledge of a community string. You either know the string or you don't, which makes every system equal and makes it hard to distinguish between different classes of systems. SNMPv3 allows you to create different classes and levels of authentication, and set up within each class what access can or can't be performed. User- and group-level authentication provides greater degrees of privilege rights and access management. Privileges are stored in the protocol's configuration database, which contains all permissions and authentication information. SNMPv3 can also utilize third-party databases, such as RADIUS or TACACS+.
In SNMPv1, strings are transmitted in the clear. Someone could intercept the plaintext community string and use it to reboot a server. SNMPv3 encrypts all traffic with CBC-DES and checks string integrity. A common integrity checking method is to run the message through a hash. You can prevent an attacker from changing the message and recomputing a new hash by using asymmetric encryption, which creates a digital signature. After the hash is computed, it's encrypted with the sender's private key. This allows anyone to verify it with the sender's private key, but not change it, eliminating the threat of unauthorized modifications of SNMP messages in transit, unauthorized users masquerading as authorized users, delay and replay attacks, and eavesdropping.
This was first published in April 2005