Sunday, July 17, 2005

SNMP Security

My client has decided that monitoring power and environmental sevices with snmp would be a good idea. They already use snmp for monitoring servers and other network devices, feeding this information into HP Openview and Cricket for fault and trend analysis. They need to monitor support devices and not just network elements. For example, irregular power can affect network device reliability. A failure in an air conditioner may require planned shutdown of servers, if the data center temperature gets too high. These alert conditions require data center staff to take action, even though they do not manage the environmental devices themselves. Capacity trends are useful for data center planning as well. Knowing actual power use trends indicates whether a power upgrade would be required for anticipated new servers. The same holds true for air conditioning. Will the extra servers that will arrive in three months end up overtaxing the current air conditioning?

Environmental devices provide several options for this monitoring. The building management industry has evolved communication schemes for monitoring and management independent of mainstream network management practices. These include ModBus and BACnet. ModBus is based on an underlying multipoint master/slave serial protocol (see for more info). BACNet is often based on a variant of the old ARCNet LAN protocol (I never thought I’d see ARCNet again!). BACNet also supports “BACNet over IP” (see for more on BACNet). Typically, building management systems were managed and monitored on parallel networks. Their traffic was never carried over shared IT infrastructure. Attacks against environmental devices from the IT network would be near impossible.

This all changes when snmp is used. Network managers want to monitor their data center environmental systems using the same tools used to monitor switches and routers. Equipment vendors accommodate these desires by supporting snmp via Ethernet. Liebert, for example, markets what they call the OpenComms NIC, a network interface card with a built-in SNMP agent. Other options include gateways between Modbus/BACnet and TCP/IP that include support for snmp.

Using snmp opens up serious security holes. Most devices support snmp version 1. This version provides “authentication” via a cleartext community string. Bad enough, but in many installations, the vendor default community strings are never changed. There are some fairly basic tools for doing brute-force attacks against snmp. Unlike a console login, snmp will not “lock out” after a certain number of invalid access attempts. SANS has listed insecure snmp use as one of the top 20 security vulnerabilities ( Vendor snmp implementation have demonstrated vulnerabilities, which allow an intruder to “crash” the snmp agent and gain unauthorized access. CERT has published an advisory ( concerning this very issue.

Devices may be managed as well as monitored by snmp. Electric power devices may be shut down with a simple snmp command. Imagine the havoc that can be created in the data center by a mass power shut down.

The advice given by CERT is not to use snmp at all. Short of this, the following measures are recommended:

  • Use snmp version 3 instead of version 1, if supported by the vendor. Version 3 supports encrypted authentication, hampering community string sniffing.
  • Change the default community string to something not subject to dictionary attack. In no case use vendor defaults, or “public”/”private”.
  • Set up traffic filtering rule in your network to filter snmp traffic from outside the network, and to block snmp from unauthorized hosts.
  • Configure the snmp agent so that only specific management hosts have snmp access.
  • Disable snmp SET (if possible).
An snmp proxy would be a good solution. The ideal proxy would establish an encrypted channel with the management stations, and perform application level traffic filtering. Devices that only support snmp v1 would then only be vulnerable within their own subnet. Proxies for snmp have been proposed for managing devices in a firewalled DMZ. ExtraLan makes a proxy that translates between snmp v1 and the more secure snmp v3 (see

Some snmp agents allow authentication traps. The authentication trap reports that an attempt is made to access the agent using an invalid community string. This is useful evidence of an attempted brute-force attack against the agent. The net-snmp trap agent allows logging trap conditions into the syslog files.

Regarding tools for testing snmp security, ADMsmnp is a very simple tool for brute-force testing various community strings. It’s not included in WHoppix, but is part of the port tree in various BSD implementations. See to download the tarball.

SolarWinds makes a similar tool for Windows. It costs, but a 30-day free eval is available. I have downloaded this tool, but haven’t (yet) tried it out.

Lastly, the Protos test suite is available to test the robustness of various snmp agents when presented with non-compliant requests. Protos runs as a java application. It may be downloaded from . WARNING – these tests are designed to crash the snmp agent, and may result in the associated device halting or rebooting. You do not want to use this tool against a production system!


Post a Comment

<< Home