Managed Security Services

Battening Down SNMP

Everyone now knows that SNMP has a security hole, but the protocol is so pervasive that little concrete advice has been profferred. Take a walk through your network with us at your side, battening down all those loose SNMP hatches.

by Lisa Phifer VP Core Competence, Inc. [February 15, 2002]

Tuesday's CERT advisory about the Simple Network Management Protocol (SNMP) is making headlines, but what can you do to protect yourself against these vulnerabilities?

Find vulnerabilities
First, determine where SNMP [definition] may be running in your network. Even if you do not actively use SNMP to manage your network or systems, you may still be vulnerable. SNMP provides a platform for distribution management: many network management systems (NMSs) use the SNMP protocol to listen to alarms and retrieve or modify configurable parameters from any networked device. This of course requires every device to have an SNMP agent—a daemon that sends alarms (TRAPS) and listens for incoming GET and SET requests.

Standardized a decade ago, SNMP agents are nearly as common today as TCP/IP itself. Agent daemons are commonly included in switches, routers, firewalls, VPN gateways, Web caches, load balancers, remote access servers, bridges, wireless access points—nearly any network device suitable for enterprise or ISP deployment. To enable remote management of hosts and servers, SNMP agents are embedded in nearly every commercial operating system, from Solaris and RedHat Linux to Microsoft Windows. With the exception of truly entry-level home networks, odds are that your network includes SNMP agents.

Search and destroy
However, just because SNMP code is available for your operating system does not necessarily mean that you are vulnerable. Most (but not all) of the vulnerabilities reported in the CERT advisory require the SNMP agent daemon to be running, listening to UDP/161 and/or sending to UDP/162. Ports used by SNMP extensions include TCP/199 and TCP/705.

To determine where SNMP exists in your network, invoke "netstat" or the equivalent from the command line on every node, looking for these ports. Check task lists, looking for processes named snmp(d) or snmptrap(d). Use a LAN analyzer like NAI Sniffer or shareware Ethereal to capture traffic, looking for packets to or from these ports. Run a scanner like WebTrends Security Analyzer or shareware NMAP to probe these ports. (Please remember that even a well-intentioned port scan may be interpreted as an attempted intrusion; scan only network nodes that belong to you!)

CERT recommends disabling all unnecessary services; that includes SNMP managers and agents. If you are not actively using SNMP or just had it enabled for testing, turn those SNMP daemons off! On Windows hosts, find the SNMP or SNMP Trap Service in the Services Control panel, stop the service, and set startup type to disabled or manual. On RedHat, use linuxconf Service Control to stop the snmpd from automatically running at boot time. On Cisco gear running IOS, use the config command to enter "no snmp-server". On other devices, use help to find the configuration knobs that control services—it is not enough to kill the running task; you need to stop the task from being restarted automatically at boot time. If practical, remove the SNMP service or package to completely eliminate vulnerability.

Bolt the door
Eliminating SNMP is not always practical. If you rely on SNMP for remote monitoring or administration—even if you disable SNMP but leave the code installed— there are steps you should take to reduce the risk of intrusion and exploit.

SNMPv1 uses community strings—text passwords—to provide weak authentication. In theory, agents and managers ignore SNMP messages unless they carry a valid community string for the requested operation. Unfortunately, many hardware and software products that support SNMP ship with defaults that permit GET and SET operations with "public" and "private" community strings. Like any password, community strings should always be set to hard-to-guess, non-default values.

Never rely on community strings to keep outsiders away. In SNMPv1, community strings are carried in plaintext—they can be sniffed rather easily by anyone else on the LAN. SNMPv3 uses encrypted authentication, but few products in the field today use this newest version of the protocol. In some cases, it may be feasible to secure your management traffic—for example, by using PPTP, IPsec, or SSH to tunnel SNMP between the manager and agent.

Community string vulnerabilities have been known for a long time; if you use SNMP, employ the strongest authentication and privacy mechanisms you can muster. However, this week's CERT advisory is a clear indication that authentication by itself is insufficient.

The vulnerabilities uncovered by the Oulu University Secure Programming Group (OUSPG) include a number of attacks that do not require a valid community string to compromise the target.

Go to page 2: Ask who's there>