Introduction to SNMPv3's security functionality

While SNMP is well established, inherent security gaps were only closed in the latest version of the network protocol. If you're not already using SNMPv3, you should consider upgrading, as failure

    Requires Free Membership to View

to do so could lead to a critical attack on your organization's infrastructure.

Weak authentication and access control are among the security problems that exist in the original 1988 implementation of SNMP. These were partly addressed with the 1993 SNMPv2 release. Unfortunately, the added security facility in SNMPv2 was cumbersome and administrators simply didn't use it, so it was dropped from SNMPv2c. The current SNMPv3 release, approved as an Internet standard in March 2002, adequately corrects previous security flaws to provide enhanced security functionality that's vital for managing networks.


The problematic version 1 and 2 protocol implementations employ plaintext passwords, known as "community strings," to enable authentication services. The use of plaintext is inherently insecure. It allows an eavesdropper to run a sniffer, learn the SNMP community string and "become" an administrator. In turn, the eavesdropper can perform any action permitted by SNMP, including the manipulation of network devices.

SNMPv3 adds security to the protocol -- not as a replacement for earlier versions of SNMP, but as an added feature set. The figure below demonstrates how the SNMPv3 security header fits in relation to the SNMPv1 or SNMPv2 Primary Data Unit (PDU) and the IP/UDP headers.

SNMPv3's security header implements the User Security Model (USM), which provides confidentiality and integrity for network management communications. Confidentiality is provided through the use of Data Encryption Standard (DES). Although this algorithm is notoriously weak (due to its use of a 40-bit encryption key), it provides a marked advantage over plaintext community strings. Even a weak algorithm like DES still requires a concerted effort to break, so you'll at least be protected against casual eavesdroppers.

Integrity service is provided through the use of the Hashed Message Authentication Code algorithm in conjunction with one of two secure hash functions: MD5 or the Secure Hash Algorithm (SHA-1). Use of the hashes ensures that the SNMP devices know the communication wasn't altered while in transit (either accidentally or maliciously). It's important to remember that malicious individuals can still attack the integrity and availability of encrypted communications by merely altering the ciphertext, rendering correct decryption impossible. Hash integrity provides the recipient with a means to detect this type of activity.

SNMPv3's USM also allows for user-based authentication and access control. Rather than using the two-level "read" and "write" community strings of prior SNMP implementations, administrators can create specific accounts for each SNMP user and grant privileges through those user accounts. For example, you might grant an operator the ability to monitor device status, but reserve modification privileges for network engineers. This has a significant impact on the security of the system by increasing accountability for user actions. It also facilitates the exclusion of a user from the system without requiring the reconfiguration of all SNMP devices.

Unfortunately, not all networking devices support SNMPv3. If you're using older devices that don't currently support this security functionality, there are two steps you should take. First, contact the vendor. It's possible that you can obtain a software or firmware update under an existing support contract that enables SNMPv3. Otherwise, if you can't take advantage of SNMPv3's built-in security functionality, find another add-on that provides similar security. For example, you could use IPSec or another encryption technology to secure SNMP communications between devices. It would be difficult (maybe impossible) to replicate the full functionality of SNMPv3 on non-compliant devices, but encryption is better than nothing!

About the author
Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles including the CISSP Prep Guide and Information Security Illuminated.

This was first published in April 2005

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.