SNMP | Support Protocols

SNMP, short for Simple Network Management Protocol, is a high-level protocol and architecture that allows for the monitoring and maintenance of network devices to detect problems, and to fine-tune the network for performance. There are two key versions of SNMP in use today, SNMPv1 and SNMPv2. While the two share many commonalities, there are some very beneficial additions made to SNMPv2. However, as many people disagreed with the security profiles implemented into SNMPv2, it has remained less popular and less used than SNMPv1. Since that time, a newer version of SNMP was released: the Community-Based SNMP, or SNMPv2c. However, the current standard, adopted in 2004, is SNMPv3. SNMP plays a useful role in maintaining and administering VoIP networks by allowing a person the ability to easily monitor the bandwidth and performance of all the major components of a network.

The SNMP protocol is defined under RFC 1157 as SNMPv1, and the characteristics of its immediate successor, SNMPv2, are defined in RFC 1902. SNMPv2c is officially detailed in RFC 1901 and in RFC 1908. SNMPv3 is defined in RFC 3411 and RFC 3418.

SNMP Architecture

An SNMP implementation on a network involves three components to be integrated: the devices to be managed, agents, and Network Management Systems (NMSes). The devices to be managed are simply computers or devices on the network that reside on the network. These are the devices that an administrator would like to monitor on the network. Each device must have an agent installed on them, which is a software application that continually monitors the device for predefined events or errors and transmits them to a centralized management server, an NMS. The NMS collects all of the data that is routinely transferred from the various network devices and correlates it into useful information for an administrator to read and evaluate.

However, even with all of these components working together on a network, there still must be a structure to all of the individual data that can be gathered across a network by an NMS. This is implemented by the use of a Management Information Base (MIB). See Figure 1 for a diagram on how these components work together.

 
Figure 1: SNMP Network Components

SNMP Operation

The SNMP protocol works under a very simplified model of data collection and control of the managed devices. Only a few basic commands are used in the SNMP protocol, such as GETKEQUEST, GETNEXTREQUEST, SETREQUEST, and TRAP. An NMS invokes GETREQUEST to collect data from a device, and GETNEXTREQUEST to retrieve the next value in a set. An NMS can also invoke the SETREQUEST command to save data to a managed device. The TRAP command is the only one not initiated by the NMS; it is sent out by the client to report any unusual activity it has detected.

On the client side, the Management Information Base (MIB) acts as a tree that catalogs all of the various data components of the system or device. Each of these data components are known by their object identifiers (OIDs). The OID is made up of multiple sets of numbers, each separated by a period, in a structured order similar to that of an IP address. As a general rule, all OIDs begin with .1.3.6.1.2.1, except on many Cisco devices which use .1.3.6.1.4.1.9. To request a data value, an established OID must be specified. For example, to request the system up time, OID .1.3.6.1.2.1.1.2 is read.

SNMP Architecture

The SNMP protocol has many areas that require careful attention and configuration simply due to the amount of information that could be leaked out to malicious users. Since all of this data is retrievable by anyone requesting it, there must be some safeguards put in place to prevent unauthorized users from being able to read data, or modify it. This is performed by the use of a community string. A community string acts as a password to group data into either read-only or read-write areas. By default, most software is setup to use a default community string of “public” for their read-only data. Likewise, many implementations use a default community string of “private” for their read-write data. It is particularly dangerous to leave such community strings in place, as they are well known to malicious users, and an unchanged read-write community string allows an attacker the ability to modify critical data on a device.

---

Are You Owned?—Are You Allowing Sensitive Data to Be Leaked?

Due to the open nature of SNMP, allowing any person to easily request data, unique community strings should be defined for network components that you can administer. Proper care must also be taken in evaluating IP telephones to ensure that they do not have unsecured SNMP access available. Otherwise, all of your SNMP-enabled components, such as workstations, servers, routers, and phones, can disclose sensitive information to anyone who asks. Unless you are constantly monitoring network traffic, you may not even know that this information is being gathered by malicious people within your network environment—or, even worse, being modified to cover unauthorized actions.

This issue came to light recently when it was discovered that the Cisco 7920 Wireless IP Phone contained a fixed community string that allowed malicious users to gather and modify data on the devices. The vulnerability and its fix were given a Cisco bug ID of CSCsb75186. They can also be reviewed at http://securitytracker.com/id?1015232.

Likewise, similar SNMP vulnerabilities surfaced with the Hitachi IP5000 phone. These devices did not have a protected community string, which meant that any person could have full SNMP access to all of the data on the device, including the ability to alter and erase it.

On a lesser scale, the UTstarcom F1000 IP phone featured the default public community string, which allowed anyone to view data stored on the phone, some of which could be considered sensitive. Additionally, when using SNMP scanning software, the phone suffered from numerous SNMP issues that required a full reboot to fix.