SNMP security: Maligned or ignored, but useful for risk management

Mark Underwood looks at the state of SNMP utilization in today's networks, perceived risks, and how its role is reflected in the design of recent hardware.

In the polarizing health care debate raging for the past couple of years, one blistering argument concerns how to manage risk. Should individual citizens be forced to manage risk by purchasing insurance, or should they be permitted to manage risk through other means as they see fit? There are clear analogies to this debate in network management. By centralizing network infrastructure in the cloud, there's less need to manage certain on-premises gear. On the other hand, the cloud itself becomes an increasingly attractive target because of its size.

Cloud access, enabled by, say, a fiber connection into a building, represents a single point of failure for entire classes of computing resources rather than just WAN access. Conclusion: Risk management must be part of network planning.

In a recent post, I offered the view that for large networks, SNMP is an essential monitoring resource. For smaller networks, SNMP is a typically underutilized tool. In considering the reasons for this, it's tempting to assume lackluster product usability and expanding network complexity as likely culprits. These are surely factors, but perhaps even more relevant are lingering doubts caused by SNMP flaws reported around 2002 and before.

Yes, SNMP is old (1988). It's undergone several major revisions (three), and has been the subject of various hack attempts. For those curious about SNMP hacking, one interesting attack walkthrough is provided by Symantec, whose specialist demonstrates one technique for implementing a man-in-the-middle attack against SSL and SSH encrypted protocols.  Defending against this particular walkthrough requires an Access Control List (ACL) on a router's TFTP and a high quality password instead of a guessable community name.

Such concerns, coupled with not unfounded anxieties over User Datagram Protocol (UDP) traffic at the perimeter, may have created a cadre of SNMP-shy administrators. Table 1 is offered as a good, but by no means, definitive starting point for SNMP hardening tactics. Adding to this aura of distrust, for reasons that are unclear, some software has been released without SNMPv3 support (e.g., see a Glassfish 2009 release). This has resulted in a large inventory of devices deployed with only SNMPv1 and SNMPv2 capabilities, and at least some enterprise applications that can't speak SNMPv3. Cost is probably not the reason; Figure A shows a low-cost access point device that implements SNMPv3 for under $200.

Throw it out and start over?

This is no reason to give up on SNMP; as with human health, network health must still be managed despite limitations of The System. Consider the role played by the Distributed Management Task Force's (DMTF) Common Information Model (CIM). CIM data elements are part of Windows Management Instrumentation and other management layer tooling, and the reason is clear. The value of device Management Information Bases (MIBs) and CIM more generally are that they help shape a standard network semantics. They are a basis for ontologies of configuration management and numerous other uses. As the DMTF writes while extolling the virtues of CIM "all goals and uses derive from the ability to define a single model for management information and service semantics - and to position everything relative to that model." The development of object models that facilitate abstraction would be difficult to implement without such standards. CIM and SNMP could perhaps be delinked, but that would reverse a decade-long practice.

Uncertain market future

SNMP is venerable and remains important, but what role has it played in the design of recent hardware? For instance, what role did it play in the monitoring architecture for Cisco's Unified Computing System (UCS)? Are manufacturers lukewarm about SNMP because there's no demand for it? A search of Newegg's inventory for "SNMP" may not be definitive proof of anything, but the number of devices listing SNMP as a feature numbers well under a couple hundred, and the number calling out SNMPv3 is in the dozens. Perhaps reflecting this underutilized state of affairs, SNMP is often listed in online catalogs as a device feature without indicating whether it's v1, v2 or v3. A typical network could have hundreds of devices worth monitoring with SNMP, so the task of addressing SNMP security beyond simple hardware replacement is nontrivial.

Table 1

Secure Community Strings as passwords Make community strings hard to detect. Treat them as though they were passwords. Change them periodically.
Use Access Control Lists Especially control write access to settings
Retire flawed SNMP implementations HP Series 5 printers and obsolete firmware
Encrypt SNMP packets Nominal traffic concealment
Test trap handlers for vulnerabilities Not only the SNMP sensor but the software handling the device must be hardened.
Know your Network Mgmt System (NMS) and related packet test tools If there is no enterprise NMS, try Cacti, OpenNMS or Spiceworks or similar. See where SNMP is in use on the network, intentionally or otherwise.
Monitor rogue connections Detect infrastructure sniffing.  SNMP can help with this by monitoring port usage on switches.  Monitor wireless connections, too.
Lock down and audit affected software settings Prohibit changes to configurations such as the Windows registry.  E.g., this could prevent attackers from switching to secondary gateways.
Periodic  SNMP-targeted penetration testing Determine effectiveness of hardening measures.
Implement information value risk management Expend IT $, hardening and test resources where protections are most needed.

Future sensors and sense-making

Thinking of SNMP end points as sensors in a larger framework of interoperable sensor networks is one sensible approach. To gain a sense for what may become more commonplace for integrated sensor systems, one example may be the Open Geospatial Consortium's SensorML. SensorML enables not only geolocation of devices, but also a way to manage measurements of many types of devices for control and decision-making. SensorML processes are "discoverable and executable." Make it secure, and you have the makings of a healthier network lifestyle.

Sample SNMP hardening references


Mark Underwood ("knowlengr") works for a small, agile R&D firm. He thinly spreads interests (network manageability, AI, BI, psychoacoustics, poetry, cognition, software quality, literary fiction, transparency) and activations ( from...


I have said this before that if you are worried about someone capturing your SNMP traffic for malicious reasons then you already have much larger problems. A man in the middle attack is by far the largest threat to exploiting SNMP (I won't go into community strings with write permissions) but you could have been alerted to the man in the middle presence had SNMP been implemented. Without it you rely on vendor specific or home grown methods to detect this sort of thing. Anyway - while I agree the protocol needs to have an encrypted version I find not using it much more of a risk than using it. Also this should be added to the table - SNMP in it's current form(s) should only be used over a private LAN. If it must leave a private network segment and traverse an unknown network such as the public internet then it should go through some form of encrypted tunnel to do so. SSH tunnels for example are very simple to implement.


SNMP is needed by some Windows printer drivers to talk to the printer - and MS only supports SNMP V2 - so you can't set the printers to use V3. Bummer....


The fundamentals of SNMP are sound: you have a dedicated TCP/IP Port over which to view a common set of configuration data for devices attached to the network. SNMP's main vulnerabilities come in protecting access to the read-only information and in protecting the ability to change configuration information. Then there is the common issue of the vendor-specific portions of the MIB that throw all kinds of kinks in the works. What might work is to make SNMP read-only period and accessible only via a username/password or access control list. Then leave device management to the vendor's tools (HTTPS interface, etc.).

Neon Samurai
Neon Samurai

The newer version of the solution has native SSL layer support but the version I started with had no encryption so SSH provided the tunnels very nicely. Static ARP tables seems to be the other thing to mention. You can probably block most chances of a MITM by stamping a static ARP table into each of your client nodes through the login script.

Neon Samurai
Neon Samurai

I popped open a printer interface and spotted snmp enabled. Since we use a different management appliance, I unchecked the box and saved the printer settings. Moments later, none of my users can print; WTF is Windows using snmp in a printer driver to confirm that the printer is there? With the several ports it's going to open for each print job; it needs an additional port just to run a ping check? So, re-enable snmp read support in the printer interface and users are happy.

Neon Samurai
Neon Samurai

I don't mind the Write feature for management. My general approach would be to secure the protocol and add authentication. This may be there in v3 but anything I've seen with v2 or older has been cleartext and using easily sniffed community strings for authentication. - encrypt the network traffic. Give us snmps to run along side https, ftps, imaps, pop3s and the rest of it. There is no excuse for not providing encryption even if it's done by adding OpenSSL into the firmware. I want to be able to run that network traffic through my MITM tester and still get nothing unencrypted out of it. - use real authentication. A community string doesn't cut it the same way considering anyone who can tell you your wifi SSID authenticated and trustworthy. Keep the community strings for grouping relevant snmp nodes but add a real username/password combination. Ideally, skip the uname/passwd and add public/private key pair support. Once the protocol is capable of protecting itself, write permissions limited to the central management devices is not such a concern. This article helps greatly and my reading more on snmp can only help further but those protocol flaws still have me leaning towards ways I can remove it from my network rather than go network wide with an "if we're going to do it then lets do it right" install.

Editor's Picks