Discover how SNMP can make your network vulnerable to attack
SNMP provides an easy way for administrators to get topology information about their networks and even provides some management of remote devices and servers. However, you have to be very careful that you correctly block SNMP traffic at your firewall; otherwise, hackers can also use it to gather that valuable network information and exploit vulnerabilities. This article will explain the SNMP threat, show you how to block it at your firewall, and give you some background on the SNMP protocol.
The SNMP threat
As mentioned above, the main threat from SNMP is that it provides an easy way to collect basic system configuration information. For example, the SNMP systemInfo get string could be used to report what network adapters are available on the client during the logon sequence. This is exactly the sort of information a hacker tries to obtain before beginning penetration attempts.
SNMP is inherently insecure because SNMP messages are not encrypted. SNMP isn’t vulnerable because of a bug in the code; it’s dangerous because of how it was originally designed, before the proliferation of networks connected to the Internet.
In addition to information gathering, SNMP can be used to manage devices—for example, to shut down a network interface. This, of course, makes it even more dangerous as a tool for malicious hackers.
There are even reports in discussion groups and forums about poor firewall configurations that have let the SNMP service report the firewall version that’s installed and its settings, as well as information about the underlying system. Even the best firewall can be compromised if the system is publishing its exact version and settings.
The easiest way to deal with SNMP threats is to set your firewall to block UDP ports 161 and 162 (and any other port you may have custom-configured for SNMP traffic) to the outside world. At a minimum, you need to monitor activity on all ports utilizing SNMP.
How SNMP is exploited
The SNMP agent for Windows NT can disclose lots of useful data to a hacker, especially if the server is also running WINS and/or DHCP. If these services are running on the NT Server, SNMP can disclose the same data you get from NBTSTAT or remote procedure calls, including a network map and an IP address to MAC address mappings. SNMP management software can even change WINS and DHCP databases remotely if the read-write password is known. However, SNMP is a cross-platform protocol, so its vulnerabilities are definitely not limited to Windows networks.
Since management information databases (MIBs), an SNMP component, often include a TCP connection table listing all passive open ports and active TCP connections, this information can be accessed remotely. Some vendors, such as Cisco, automatically hide some of the SNMP information, but even Cisco software doesn’t hide all of the TCP table data—and many vendors’ implementations of SNMP don’t conceal any of it.
SNMP requests are accepted using one of two standard community names. Most SNMP agents use the terms “public” and “private” as the default settings for these names, making it very easy to set up for remote management. You can easily imagine that if you fail to change these default community settings, you are leaving yourself open to hackers who will automatically try the default names when making their attack.
Most SNMP security consists of two subsystems:
- The Security Module addresses the question of whether a message is authentic and timely (Internet delays can lead to the arrival of old messages) and identifies the originator.
- The Access Control Module identifies which objects are being managed and indicates whether the originator of the control message has permission to access these objects.
To understand just how vulnerable SNMP can be, it’s useful to understand where it came from. SNMP is an Internet protocol developed in the 1980s when TCP/IP networks were blossoming and it was recognized that network management was becoming a major problem. In other words, SNMP was developed when access to the Internet was rare and very restricted. SNMP quickly became popular when RFC 1157 was published in 1990. Neither of the first two versions of SNMP included any real security features.
SNMP consists of three components:
- Structure of management information (SMI)
- Management information base (MIB)
- Protocol data units (PDUs)
SMI is a toolkit that identifies data types and develops rules to create the MIB. PDUs define authorized network management messages. UDP ports 161 (agents) and 162 (managers) are the usual way of implementing SNMP using IP, but IPX, AppleTalk datagrams, or even HTTP can also support SNMP.
Vendors write SMI-compliant object definitions for their systems and compile them using a standardized MIB compiler to build executable code that’s used to manage hubs, routers, network cards, and so forth, which have agents that recognize MIB objects.
Access control and data packet authentication are password-protected but since they’re usually included in each SNMP packet, often in unencrypted format, they can be discovered using any packet sniffer. This means that network managers need to block the use of any of the control features of SNMP, such as Set, or any tool that allows packets to write data at any entity.
There may be some hope for the future. The IETF is currently working on a new version of SNMP called SNMPv3, which does include some security enhancements. After years of work, SNMPv3 should soon be published as an RFC.
SNMP can be exploited by hackers who are trying to attack a network, making it a major potential security risk. As we’ve discussed, you need to set up your firewall to block UDP ports 161 and 162 to the outside world, or at the very least, closely monitor all traffic on these ports. It’s also a good idea to change the default SNMP community names so that they are not an easy target for hackers.
Are you blocking SNMP traffic at your firewall and/or monitoring SNMP traffic? We look forward to getting your input and hearing your experiences regarding this topic. Join the discussion below or send the editor an e-mail.