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.
|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.