Do we need to implement SNMPv3?
Secure SNMP monitoring of infrastructure assets

Do we need to implement SNMPv3?

Simple Network Management Protocol (SNMP) version 3 supports security features such as modification prevention, masquerading prevention, and confidentiality of messages. These features are available primarily due to the including of cryptography support in version 3 of SNMP. In addition to security enhancements, it also includes other benefits such as efficient information retrieval, additional protocol support, and additional definitions for MIBs.

This makes SNMPv3 a valuable proposition with tangible benefits. However, before we can make a conclusive decision to go with SNMPv3, we should weigh in benefits with the effort involved. SNMP version 3 offers security and many other enhancements. However, an interesting question is if the effort involved in rolling out SNMPv3 is worth the benefit and if so, where does it stand in the priority list.

But before we go there, a quick review of SNMP might be helpful.

SNMP Overview

Simple Network Management Protocol is used to interact with networked devices such as routers, switches, firewalls, servers, load-balancers, printers, and many other types. There are three main types of communication that happens between SNMP servers and SNMP clients.

1. SNMP Read:

This allows the SNMP servers to get information from the SNMP client (routers, servers, etc.). Some examples of information requested are the CPU, disk, and memory utilization. Each type of information is requested by sending a query to a specific object identified (OID).

The client device must support OID to provide relevant information. In theory, you can configure the SNMP management server to request an OID, for example, high availability status, but if the SNMP client devices do not support that OID then obviously there will not be any useful response. An SNMP polling interval determines how frequently the client devices are queried for information.

2. SNMP Write:

SNMP Writes allow SNMP servers to configure the client devices by sending configuration parameters. This is an especially useful feature to configure a large number of devices with standard configuration parameters such as logging destination, timeout sessions limits and such. However, before the end device accepts the configuration, it must prove that it is authorized to make changes to that client (router, server, printer)

3. SNMP Traps:

SNMP traps are alert messages initiated by the client devices and sent to preconfigured SNMP servers. These traps or alerts are triggered based on conditions, such as a spike in CPU. Unlike polling (SNMP reads), which occurs at predefined intervals (example every 5 minutes), traps send information as soon as the monitored event occurs. Once a trap is received by the SNMP server, it can further process it and send a notification email, log a message or open a ticket. SNMP traps are somewhat like log messages in the sense that they are sent by client devices. Traps can be extremely specific and can have custom thresholds configured, whereas logs are generated somewhat in a standard way.

Where is the security in SNMP?

SNMPv1 and SNMPv2c rely on preconfigured passwords on both server and client sides. In the SNMP domain, these passwords are called “community” strings. There can be different passwords for each of the communication types specified above. Standard SNMP read community string (password) is “public”, whereas standard out of the box, read and write community string is “private”. Many end clients have these two community strings configured by default with write community string disabled. At the same time, there are many end clients who have to write community string enabled which poses a security threat. A malicious actor can try to connect to all devices on the network with these default strings and collect valuable information that can further assist him/her with the attack.

Community strings are a form of a shared password which is a big “no-no” from the security perspective. SNMP reads provides a lot of information not only about a specific device but also the environment is in. Additionally, the communication being sent is not encrypted, so anyone who can sniff the traffic can get the information without specifically polling the client.

SNMPv2 and SNMPv3 uses port UDP 161 for

Threats to SNMP traffic

To overcome security deficiencies and add additional functionality, SNMPv3 was introduced in 2002 which has significant improvements over its predecessor SNMPv2 from 1993. RFC 3414, "User-Based Security Model (USM) for SNMPv3 describes the threats against which protection is provided, as well as the mechanisms, protocols, and supporting data used to provide SNMP message-level security with the user-based security model.

Key security features for SNMPv3 include enhanced authentication and encryption. This means SNMP traffic is encrypted during transit, which is a key requirement in many security policies.

SNMPv3 protects against the following 4 threats:

Modification of Information

Any unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object.

Masquerade

Unauthorize operations may be attempted by assuming the identity of another user that has the appropriate authorizations.

Disclosure

Eavesdropping on the exchanges between managed agents and a management station. Protecting against this threat may be required as a matter of local policy.

Message Stream Modification

The SNMP protocol is typically based upon a connection-less transport service which may operate over any sub-network service. The re-ordering, delay, or replay of messages can and does occur through the natural operation of many such sub-network services.

The message stream modification threat implies that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than the natural operation of a sub-network service, in order to effect unauthorized management operations.

SNMPv3 Modules to remediate risks

To address the above-mentioned threats, SNMPv3 offers allows for Data Integrity, Data Origin Authentication, Data Confidentiality, Message timeliness, and limited replay protection

The security features of SNMPv3 are split into 3 modules:  

1.      Authentication module which addresses data integrity and origin authentication

2.      Timeliness module which protects against message delay or replay attacks

3.      Privacy module that protects against disclosure of the message payload

Detailed technical specifications, including encryption mechanisms and authentication, of each of the above 3 modules are covered in RFC 3414.

Configuration steps for rolling out SNMPv3

Assuming we are convinced that SNMPv3 is the rights choice and we want to implement in our organization, the next question is how we roll it out. We can divide the configuration into distinct steps:

1.      Decide and document which features are needed from the above 3 domains.

2.      Agree on the configuration parameter to support features, this further includes:

  • a.      Authentication mechanism
  • b.      Privacy protocol
  • c.       Key

3.      Configure SNMP server

4.      Configure SNMP client – Configuration will vary by the client device vendor

5.      Remove SNMPv2 configuration from SNMP servers and clients

All SNMP messages are transported via User Datagram Protocol (UDP) port 161. When used with Transport Layer Security or Datagram Transport Layer Security, requests are received on port 10161, and Notifications are sent to port 10162. This means opening additional firewalls port is not required.

Final Thoughts

Based on SNMPv3 important (and many times required) security features, my suggestion would be to consider it seriously. As far as the priority goes, it depends on the maturity and current challenges on the hand of the organization.

Implementation should be carefully planned since there are dependencies on many vendors. Additionally, the vendors' implementation may not be mature and can have their own bugs which can make the implementation challenges.

References

RFC 3410 provides information on SNMP versions, applications, and security. It also points out to a list of additional RFCs that take a deeper dive into different SNMP features.

RFC 3414 provides information on User-based Security Model (USM)

Very succinctly articulated and clear recommendations. Thank you

Like
Reply

To view or add a comment, sign in

More articles by Taimoor Malik

Others also viewed

Explore content categories