SNMP | Logging

The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. SNMP messages are encoded as ASN.1 binary using BER encoding, and run over UDP/161 and UDP/162. SNMP enables network administrators to manage network performance and to find and solve network problems. Three versions of SNMP exist: SNMP version 1 (SNMPv1), SNMP version 2 (SNMPv2), and SNMP version 3 (SNMPv3). SNMPv1 and SNMPv2 have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Neither version provides for any authentication or encryption. SNMPv3 includes, among other things, a model for access control and security as well as for a new architecture. SNMPv3 has yet to attain wide acceptance; thus, SNMPv1 and SNMPv2 still predominate.

An SNMP network normally consists of three key components: managed devices, agents, and network-management systems (NMSs). A managed device is a network node that contains an SNMP agent. Almost every networked device functions as a managed device. An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. Applications such as HP Openview or Tivoli are examples of NMSs.

Managed devices are monitored and controlled using three basic SNMP commands: read, write, and trap. These commands are defined as follows:

• The read command is used by an NMS to monitor managed devices.
• The write command is used by an NMS to control managed devices.
• The tmp command is used by managed devices to asynchronously report events to the NMS.

Additionally, NMS and other applications (such as GetIF; see www.wtcs.org/snmp4tpc/getif.htm) can read and display the Management Information Base (MIB). A MIB is a (sometimes vendor-supplied) collection of information about the managed device that is organized hierarchically. The MIB contains fields that list all of the data the managed device can make available to the NMS.

SNMP community strings and some device configuration data are often among the first findings in penetration tests or vulnerability assessments. Most administrators forget about this threat or simply ignore it.

The best method for securing SNMP today is to turn it off. In VoIP networks, most IP-enabled telephones use SNMPV1 and SNMPv2 for configuration and performance moni-toring. Thus, it is often impossible to disable this service. If you must run SNMP over your internal networks, then adopt the following practices:

• Immediately change the default read/write community strings
  1. Do not use the default “public” or “private” string.
  2. Do not use a string that would be easy to guess, such as the company’s name or phone number.
  3. Do not use a text-only string; use an alphanumeric string (both text and numerals).
  4. Use both uppercase and lowercase letters (community strings are case-sensitive).
  5. Use a community string that is at least eight characters long.
• Employ ingress and egress filtering at the nearest network border, or limit SNMP to specific management and configuration VLANs.
• Allow SNMP traffic to only a few authorized internal hosts. Only a few network management systems need to initiate SNMP request messages. Thus, administrators can configure SNMP agents to prohibit request messages from unauthorized hosts.

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.

SNMP and Java

Although not a protocol, the Java Management API (JMAPI) includes a mapping to SNMP, enabling SNMP-enabled devices to be managed by JMAPI-compliant applications. JMAPI itself is only a framework for management systems. The protocol or standard supported can actually be anything, even RMON, as long as JMAPI includes the appropriate mappings. Sun has indicated that future mappings could include Common Object Request Broker Architecture (CORBA) and Common Management Information Protocol (CMIP).

One vendor offering an implementation of Java classes for SNMP Version 1 is Advent Network Management, Inc. The company's Advent Java SNMP Package helps programmers develop SNMP applets and applications. With the package, developers can focus on using the Web and Java with the Advent Web NMS framework, and produce the best applications and solutions, instead of dealing with multiple proprietary platform vendor APIs and multiple operating system versions.

The Advent Java SNMP Package is a group of Java class files that provide Java programmers a simple API for developing network management applets and applications that use SNMP version 1. Many different architectures are supported, such that SNMP can be used in the Web browser, on the server, or even on managed elements that have a Java Virtual Machine. Applets developed using this package can be loaded from the network or from local disks and run in any Java-enabled browser.

Java applets that are loaded from the network are usually restricted by browsers from connecting to any system other than the applet host. The Advent Java SNMP Package provides special support for applets loaded remotely via the network that run in browsers that have socket and file access restrictions. Via a Java program called the SNMP Applet Server (SAS) on the applet host (Web Server), applets can communicate with SNMP managed devices, and save and retrieve files on the applet host.

Developers can also use the Advent NetMonitor SNMP Applet Builder, which uses the SNMP Package libraries to communicate with SNMP agents. Advent NetMonitor lets developers visually build these applets without writing code. They can then use Java to add their own event handling code and components.

The company also offers a Management Information Base (MIB) Browser Applet (Figure 1). MIB Browsers allow the user to view and operate on data available through an SNMP agent on a managed device, such as a router. To get a better view of the data available on the SNMP agent, a MIB file is usually provided with the managed device. This MIB file contains a description of the object hierarchy on the managed device, as well as the syntax and access privileges for each variable in the MIB.

Figure 1: Shown here is the primary window of the MIB browser applet. (Although the screen is taken from Windows 95, it looks similar in Netscape and on other Java-enabled browsers.) The applet includes fields for community, SNMP agent name or address (Host), value used for a set request, the current Node OID that is being operated upon, a chooser for the current MIB module, a list of children of the current node, and a text area to view query results. The operations allowed with the MIB browser are available through the series of buttons at the bottom of the applet's main window.

Figure 1: Shown here is the primary window of the MIB browser applet. (Although the screen is taken from Windows 95, it looks similar in Netscape and on other Java-enabled browsers.) The applet includes fields for community, SNMP agent name or address (Host), value used for a set request, the current Node OID that is being operated upon, a chooser for the current MIB module, a list of children of the current node, and a text area to view query results. The operations allowed with the MIB browser are available through the series of buttons at the bottom of the applet's main window.

The Advent MIB Browser applet provides the capability to load and view multiple MIB modules, and traverse the MIB tree to look at the definitions for each node in the MIB tree. It allows the use of SNMP's get, getnext, and set requests to a particular variable in the MIB of an SNMP managed device. It also enables multiple real-time graphs of data on the managed device to be viewed as it changes over time. It also allows the user to view SNMP tables.

The major NMS platform providers are planning to support Java. IBM subsidiary, Tivoli Systems, for example, plans to evolve its TME 10 framework into a Java-based architecture by mid-1998. The architecture will support JMAPI for enabling Java management applications to take advantage of the platform's back-end functions, such as event and alarm correlation and data management. Computer Associates plans to add the ability to control its Unicenter TNG management functions from a Web browser as well as the ability for Java applications to invoke its functions. Unicenter TNG is the company's object-oriented enterprise management framework.