SNMP Vulnerabilities Pose a Threat to Storage Networks

After years of being blasted for dragging their heels in supporting industry-standard protocols, Storage Area Network (SAN) vendors and storage-management software vendors now find that their products are vulnerable precisely because of their support for SNMP in some basic storage-management features.

SNMP is a standard protocol that lets network devices communicate information about their operational state to a central system. Version 1.0, which 95 percent of system-attachable devices use, first came out in 1989. Although a second version of the protocol appeared in 1995 and a third in 1999, version 1.0 remains the most prevalent for a simple reason: It works and it works well, so why bother changing?

The CERT Coordination Center (CERT/CC), a computer security consortium, shattered that perception last month when it announced that the Oulu University Secure Programming Group in Finland had discovered that SNMP is riddled with security holes. The news wasn't entirely surprising. For a long time, security experts have considered SNMP insecure but have tolerated the problem because, in many cases, the security experts use SNMP only to monitor statistics and configuration information. According to CERT/CC, SNMP has been at the center of only a few minor security alerts over the past 10 years.

Nevertheless, by using commonly available tools, Oulu University researchers posed as attackers to test 12 systems, all of which failed the test. The researchers found SNMP to be vulnerable to Denial of Service (DoS) conditions and service interruptions and found that an attacker can gain access to an affected device.

As you might expect of an early technology, SNMP relies on what's now a fairly simple structure. At the center of the system is a manager. Devices that communicate with the manager are agents. The manager can issue a few commands to the agent, which responds with the requested information. Under certain conditions, the SNMP manager can reconfigure a device by issuing a command called a "set." MIB defines the information that an agent or set can retrieve.

Since 1999, EMC has led a consortium of vendors that provide Fibre Channel-based components (e.g., hubs, switches, routers, host bus adapters—HBAs) that make up enterprise SANS. This consortium, named the FibreAlliance, has been working to develop MIBs for SANs. To ensure that SNMP remains platform independent, standards organizations must examine MIBs. The FibreAlliance has submitted MIB 4.0 for enterprise storage network management to the Internet Engineering Task Force (IETF) for review. Visit the FibreAlliance Web site to find the current status of MIB.

Ironically, pundits and industry observers have accused SAN vendors and storage-management software vendors of not supporting SNMP as vigorously as they should. SAN vendors argued that if they embraced SNMP, the vendors and the market would find it difficult to differentiate the vendors' products. Consequently, although SAN software vendors use SNMP for some basic storage-management operations, they more often implement higher-level functions using proprietary technology.

CERT/CC has proposed several strategies to counter the vulnerabilities in SNMP, but none is ideal. The first step for a user is to determine whether the vendor of a specific device has developed a patch or workaround. You can find a list of vendors' responses to the CERT/CC alert at the CERT Web site.

In lieu of a patch, CERT/CC has recommended that you disable or disconnect SNMP devices that aren't essential to the operation of the enterprise. If that step is impractical or if problems persist, you can try a variety of alternative approaches, such as ingress filtering, which manages the flow of traffic as it enters a network. Because external hosts seldom need to initiate inbound traffic to machines that provide no external services, you can configure ingress filtering to prohibit externally initiated inbound traffic to unauthorized services.

Other ideas include configuring SNMP agents to refuse request messages from unauthorized systems, or segregating SNMP traffic onto a separate management network. You can find a complete range of proposals at the URL below. According to CERT/CC, the SNMP vulnerabilities are real and dangerous, and companies need to take action immediately.