Simple Network Management Protocol, or SNMP, was developed in the late 1980's as a means for remote administrators to communicate with network devices. SNMPv1 found increased use in the early '90s as the Internet started to bloom. With increased use came, as with anything else, problems. Interestingly enough, the problems often do not come from SNMP, but from the implementation of SNMP.
SNMP is a simple set of messages that can be exchanged between a network management station and an SNMP-compliant network agent. Each agent houses a small database of information about the device it represents called a Management Information Base (MIB).
So if SNMP is so simple and useful, where do the problems arise? Well for one, when SNMP was first developed the Internet was a simpler, safer place and there were fewer companies and individuals making decisions. The variety of SNMP-enabled devices was limited to hubs, routers, switches, servers and printers. Nowadays, any sort of device can be SNMP-enabled: even a toaster. To make sure all these devices can communicate properly, the networking world uses standards. Those standards exist for SNMP, but standards are useful only if people adhere to them. But the problem is that with more companies in the market there are more implantations of the standard with "enhancements" that sometimes stifle interoperability. Ten years ago, the Internet was pretty open, and things were a lot easier.
Now the wide-open days are behind us, and there is a security threat lurking around every hub and switch. One of SNMP's main weaknesses is that it sends information as clear text, easily intercepted by cyber evildoers who can use the network information to discover community names. The other security issue associated with SNMP is that it does have a control element, with which an administrator can make some changes in settings on a functioning device for management purposes. That's a great idea, except that the control mechanism can allow unauthorized users to corrupt a network device.
Traps? I don't need no stinking traps
Traps are merely event notifications that SNMP agents send to the management software, which then records the events so you can see what your network devices are doing. Sorting through all the traps that SNMP delivers from your various network devices can be a daunting task. "Administrators spend forever sifting important data from non-important data," says Tom Lancaster, a consultant in the networking industry. You might think you should reduce the number of traps you configure, but that may not be the case. Depending on the size of the network, different groups might be interested in different traps. Besides, a trap by itself may not provide you enough information to diagnose a problem with a network device, but two traps together can help you draw more solid conclusions. Lancaster says you often need to correlate information from more than one trap.
Frequency is another matter. Conceivably you could configure SNMP to send traps every minute, but for various reasons -- network overhead is just one of them -- that is impractical. So if you are going to limit the number of traps, the sending of each individual trap becomes more important and a potential cause of concern. A hung SNMP trap process or a change in SNMP configuration could cause a failure in communication.
There are a few reasons why a trap might not be received. One is that a device might not be sending them. You can check whether this is the case with many network devices, because they are capable of sending test traps from a command line that can be scripted for automated regular testing. For devices that can't send test traps, Lancaster recommends configuring the managed systems to send a trap when there is an authentication failure and writing a script that attempts to log in to that device with an incorrect password. Of course, this will have to be done at a specific time each week to avoid setting off any alarms. But at least you'll be able to check and see that the device is sending traps.
Another reason a trap might not be received is that it -- and all SNMP traffic -- rides on User Datagram Protocol (UDP), a notoriously unreliable transfer protocol. If some collision causes the packet containing the trap not to be received, a substitute packet will not be sent. In SNMP version 2C a new type of trap, called an inform, deals with this issue. An inform trap will send a reply from the receiver, a network monitoring station, to the sender, or network device. Informs are easy to configure, but be warned: They do double the amount of network traffic due to traps.
In many cases a new technology is only as good as the standards that are implemented by the Internet Engineering Task Force (IETF). Without standards, interoperability can become an issue. "A standard allows interoperation, which reduces costs and increases choices," says David Perkins, IETF member, author of Understanding SNMP MIBs and founder of consulting and software development company SNMPinfo. Perkins is part of a group that is working to standardize a management method based on XML.
"Standards only work when vendors conform to them," he says. The hope is that XML will make it easier for vendors to conform to standards. But in the meantime, testing potential products in a test network will go a long way to ensuring interoperability before you install something in your production network and the alarm bells start going off.
SNMP doesn't like walls
Usually, firewalls are used to protect your internal networks from the external network of the Internet, but often companies need firewalls to separate internal networks, possibly to section off departments. That can cause a nightmare for network administrators in charge of device that are behind the firewall. SNMP's innate insecurity makes passing it unchecked through a firewall kind of dangerous, but limiting the number of ports that SNMP can access can help alleviate some of these issues.
By default SNMP can use any of the 65535 ports available. If you limit that vast array of 24 UDP ports and 122 TCP ports, it will greatly reduce the risk, although that's still a lot of open ports.
INMP -- Insecure Network Management Protocol
The biggest hassle with SNMP is security. There are two main security flaws:
- SNMP data is sent in clear text
- The management mechanisms of SNMP can allow unauthorized users to control network devices or to shut them down
According to CERT, "Vulnerabilities in the decoding and subsequent processing of SNMP messages by both managers and agents may result in denial-of-service conditions, format string vulnerabilities and buffer overflows."
CERT described that situation in its Feb. 12, 2002, advisory. It is important to point out that those vulnerabilities apply solely to SNMPv1. But, of course, version one is the most commonly used version of SNMP. SNMPv2 does have a comprehensive security package, but it has been criticized as being too complicated to implement and operate. RFC 1503 clearly describes how to administer SNMPv2 network managers effectively, though it does not solve all of the security issues.
After the CERT advisory, many vendors still relying on SNMPv1 scurried to issue patches. Hopefully all those patches have been applied by now. If the patches have been applied and you are not running SNMPv3, which most people are not, you might want to take a look at these recommendations from Æleen Frisch, which appeared in her article "Monitoring Linux hosts with SNMP" in Linux Magazine:
- Disable SNMP on devices that are not being managed.
- Choose community names that are not likely to be easily guessed. Change default community names before devices are added to the network.
- Block external access to SNMP ports: TCP and UDP ports 161 and 162, as well as any additional vendor specific ports.
- If you want to perform SNMP operations over the Internet, use a VPN or an SSL-encrypted connection to protect your data.
- Configure agents to accept requests only from a small group of hosts (not all agents have this feature.
The best way to obviate SNMP security issues is to move to SNMPv3. SNMPv3 supports authentication mechanisms such as SHA, MD5 and DES encryption. Most vendors support SNMPv3, although a few server, operating system and application vendors lag behind. The adoption of SNMPv3 is also lagging. That could be due to the difficulties of moving from version 1 to version 3. According to Dennis Treece, the director of ISS's X-Force Special Operations Group, upgrading from version 1 to 3 is like "having to upgrade all your systems from Windows 95 to Windows XP right now." You can read more about SNMPv3 at www.snmp.com/snmpv3.
So SNMPv3 is the ultimate answer to all the SNMP security woes? Not so fast. According to Perkins, only the "User Security Model" (USM) has been defined and deployed for SNMPv3. "It 'works,' in that it provides solid privacy, integrity, authentication and authorization. However, it is not integrated with other security systems, and thus adds, deletions and key updates must be done in parallel with those operations in other security systems," he says. Perkins is currently working on a new security model that interoperates with existing security infrastructures used by network devices.
Manage with what?
I've neglected to mention any of the numerous network-management applications available based on this advice from Tom Lancaster: "Whether or not you need network management software to fully utilize SNMP data is more of a religious question than a technical one."
Here are some links that will help you to resolve that religious question:
About the author: Benjamin Vigil is a technical editor at TechTarget.