If you have an Internet-connected network, you're taking calculated risks. You're dealing with the potential for attacks and exploits on your Web server, and you have a separate set of considerations for your mail server. In addition, another vulnerability that you might not be aware of is probably lurking in your network. Most networks have SNMP running on some devices, often unnecessarily and sometimes without the knowledge of system personnel.
According to the SANS Institute (http://www.sans.org), SNMP is one of the top 10 threats facing Internet-based hosts. SNMP is also one of the most ubiquitous services running on Internet-based hosts today. What makes the SNMP threat even more acute is that it typically runs on network devices at the edge of your network—outside the protection of a firewall. That sounds like a recipe for disaster, but it doesn't need to be. If you follow my recommendations, you can protect your network from the hidden threat of SNMP.
A Little Background
SNMP was developed in the early 1990s to simplify management and data gathering from many network devices on large networks. Many software packages, such as Hewlett-Packard's HP OpenView and Nortel Networks' Optivity Network Management System (as well as free alternatives such as the Multi Router Traffic Grapher—MRTG), use SNMP to simplify the life of the network administrator.
However, SNMP worked so well that network-hardware manufacturers began putting it on everything they made. Today, SNMP is enabled by default on all kinds of devices, from switches to routers to firewalls to network printers, and is even enabled on some file servers.
This ubiquity alone doesn't pose a problem except that manufacturers often install default community strings (i.e., passwords) that let programs poll the machine for information and, in some cases, make configuration changes. As a result, software that doesn't know much about the devices on a network can poll the network and gather information without needing significant preconfiguration.
Community strings let users send two types of commands: GET commands and SET commands. A GET command gathers data from the device. This data typically consists of operating parameters such as link status or interface names. A SET command, as the term implies, lets a user set certain parameters on the device. This functionality is typically limited, but it can include such abilities as taking an interface down and changing a router's parameters. The Denial of Service (DoS) possibilities, as well as the potential for intruders to obtain information on your network, are clear.
The most common default community strings are public (for read-only access) and private (for read/write access), but many other manufacturer-specific defaults also exist. You'll find some form of default community string on almost every device that runs SNMP. An unauthorized user of these strings could gain valuable information about your network, and in some cases, actually could change the configuration. Point-and-click tools, such as Snmpwalk and Snmpset, that take advantage of these default passwords are available for free on the Internet.
Additionally, SNMP 2.0 and SNMP 1.0 are unsecured because they don't encrypt communications between management stations and clients. Your community strings and all data are sent as plain text. If attackers can gain access to your network traffic, they can use a sniffer utility to read the community strings straight off the wire, even if you've changed the strings from their default values.
SNMP 3.0, which has been available for a few years, fixes some of these problems. To protect community strings, SNMP 3.0 uses Data Encryption Standard (DES) encryption for in-transit messages. SNMP 3.0 also uses MD5 and Secure Hash Algorithm (SHA) hashes to verify the identity of a node or management station. This verification protects against spoofing attacks from someone who tries to execute commands by masquerading as a management station. SNMP 3.0 also offers other advantages, such as better management features and the ability to set up different user levels so that you can track which devices are accessing the SNMP service. To learn more about SNMP 3.0's feature set, see the SNMP 3.0 Internet Engineering Task Force (IETF) Request for Comments (RFC) document at http://www.ietf.org/rfc/rfc2570.txt.
However, although SNMP 3.0 has been around for a while, it still isn't widely deployed. If the device in question is more than 2 years old, it probably doesn't use SNMP 3.0. Even some current devices are still being shipped with SNMP 2.0 or SNMP 1.0. Check your documentation to determine which version your product uses. If the documentation is unclear or doesn't say specifically, call technical support.
Even if the device uses SNMP 3.0, manufacturers still typically ship products with built-in standard community strings that are well known in the hacker community. So, although SNMP 3.0 offers many security advantages over previous implementations, it doesn't protect you from danger if it isn't properly implemented.
Exacerbating this lack of protection is the fact that SNMP often runs on devices that reside at the edge of your network. Routers, which often sit outside a firewall, frequently run SNMP. SNMP also runs on most switches, printers, and other network devices. Other potentially SNMP-enabled devices that pose nightmare scenarios are UPSs and networked medical equipment.
Such longstanding SNMP concerns are sufficient reason to review your network and disable SNMP where possible. However, on February 12, 2002, the Computer Emergency Response Team (CERT) at Carnegie Mellon University raised more red flags with its "CERT Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)" alert (http://www.cert.org/advisories/CA-2002-03.html). The Oulu University Secure Programming Group (OUSPG) discovered the vulnerabilities that this alert describes. These SNMP weaknesses involve buffer-overflow conditions that can occur in SNMP 1.0. (Devices that run SNMP 3.0 and SNMP 2.0 don't seem to be affected.) Intruders can exploit these vulnerabilities to gain privileged access and cause erratic behavior on affected machines. In light of this information, SNMP is no longer just a service that might leak sensitive information or permit a DoS attack but rather a potentially faulty service that can give an intruder full access to your machines.
Disabling SNMP
The best way to avoid the SNMP risk is to disable the service. If you aren't actively using SNMP for network management, you have no reason to run it. If you aren't sure whether you need to run it, you probably don't need to run it. Even if you intend to use SNMP for network management but haven't yet implemented it, you should disable the service until you're ready to roll out the SNMP software.
Here are instructions for disabling SNMP on a few major platforms. If your machine or OS isn't listed, check with your vendor for instructions for disabling SNMP.
Windows XP and Windows 2000. In XP and Win2K, right-click My Computer and select Manage. Click Services and Applications, Services. Select SNMP from the list of services and click Stop. Select Startup and click Disabled. Click OK to close the dialog box, then close the Computer Management window. (According to Microsoft, SNMP isn't installed by default on XP or Win2K; however, many network server packages install it by default.)
Windows NT 4.0. In NT 4.0, select Start, Settings. Go to the Control Panel Services applet. Select SNMP from the list of services and click Stop. Select Startup and click Disabled. Click OK to close the dialog box, then close Control Panel. These procedures also apply to NT Server 4.0, Terminal Server Edition.
Windows 9x. In Win9x, go to the Control Panel Network applet. On the Configuration tab, select Microsoft SNMP Agent from the list of installed components. Click Remove. Check the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices and HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry subkeys and confirm the absence of snmp.exe.
Cisco Systems hardware. For Cisco hardware, issue the following command:
no SNMP-server
To verify that the service is no longer running, type
show SNMP
You should receive a reply that states SNMP agent not enabled. This procedure applies only to platforms running Cisco IOS. For non-IOS Cisco devices, consult your documentation.
HP hardware. On any HP network devices that use the JetDirect card—a group that includes most HP network printers—telnet to the JetDirect card's IP address and type
SNMP-config: 0
Then, type
quit
Doing so should disable the SNMP agent on that device. Disabling this service might affect device discovery and port monitors that use SNMP to obtain device status.
Red Hat Linux. For Red Hat Linux, use the Linuxconf utility to remove SNMP from the list of startup services, or remove the SNMP daemon startup line from the /etc/services file. These procedures might also work on other UNIX-based systems, depending on your configuration. Check with your vendor for specific instructions.
Securing SNMP
When you must run SNMP on certain devices, you need to secure those devices. First, determine on which devices you're running SNMP. Unless you regularly port-scan your network and are exceedingly familiar with the services running on your machines, you can count on SNMP running somewhere. Certainly, you'll find the service on your network switches and printers. Then, take the following steps.
Patch SNMP devices. Apply a patch to upgrade your SNMP service to SNMP 2.0 or later. Check with your vendor to determine whether your machines are vulnerable and whether a patch is available. If no patches are available, I strongly recommend disabling SNMP on those machines until a patch is available.
Secure SNMP community strings. Changing all your default community strings is essential. Again, the most common default strings are public and private, but they differ from manufacturer to manufacturer. Be sure to check your documentation to ensure that you find them all, and don't be afraid to contact technical support if you're unsure. Keep in mind that simply changing your default passwords won't protect you from the new SNMP 1.0 vulnerabilities that CERT reported. The new exploits don't require the community string in order to wreak havoc. To truly secure the service, you must make sure you're patched or running SNMP 2.0 or later.
Filter SNMP. Another protective measure you can take is to filter SNMP traffic and requests at your network border. At your firewall or border router, you can block the ports through which SNMP requests are made. Standard SNMP uses ports 161 and 162; other vendor-specific implementations use ports 199, 391, 705, and 1993. By stopping this traffic, you'll limit access to internal sources. For internal routers, you should write an ACL that permits access to or from only a trusted SNMP management station. The following sample ACL denies all SNMP traffic on a network except traffic coming from or going to your SNMP management station:
access-list 100 permit ip host w.x.y.z any access-list 100 deny udp any any eq snmp access-list 100 deny udp any any eq snmptrap access-list 100 permit ip any any
The ACL's first line defines the IP address of the trusted management station (w.x.y.z). You must use the following commands to apply this ACL to all interfaces:
interface serial 0 ip access-group 100 in
Worth Your Time
SNMP was a good idea when it debuted and can still help network managers efficiently administer large networks. However, earlier versions of this service are innately insecure, and even the latest version has problems. As with any service you run on your network, you must take care to secure SNMP. With the publicity of new alerts and exploits comes the increasing importance to lock down this protocol if you plan to run it on your network. Even if you don't think you're using it, I recommend taking a few minutes to determine whether it's lurking in your network. You've got enough problems worrying about the services you do need, let alone dealing with the insecurities of a service you don't need.
