16.2 SNMP

   

SNMP is, by far, the most popular method of monitoring network devices. The reasons for SNMP's popularity are threefold: modularity, scalability, and adaptability. A SNMP monitoring system (Figure 16.2) can be developed to gather as much information about a network as possible, or it can be used to gather only selected information.

Figure 16.2. A typical SNMP monitoring network. The monitoring server receives information from and polls the managed devices. Workstations responsible for monitoring pull information from the monitoring server

graphics/16fig02.gif

SNMP works for high-traffic devices and networks just as well as it works for low- and medium-traffic devices and networks. The SNMP framework has been ported to just about every device that can be used on a network.

SNMP is an UDP-based protocol (Port 161) that is used to exchange management information between devices on a network. The devices can be part of the same network or on disparate networks. SNMP relies on three different components : the managed devices, agents residing on those devices, and the network management system or systems (NMS).

As Figure 16.2 illustrates, the software agents reside on the network devices and communicate information about the devices to the management software, usually referred to as the manager. Workstations pull monitoring information from the monitoring server, or servers, and can generate alerts about the network devices.

The agents and the monitoring server communicate using a series of different commands. The four commands used by the manager to communicate with the agents are:

  1. GetRequest

  2. GetNextRequest

  3. GetResponse

  4. SetRequest

The agents can also send information directly to the manager using the Trap command.

Different vendors often have different names for these command types. For example, Cisco uses the following SNMP commands to communicate with its network devices: read , write , trap , and traversal . This underscores the importance of ensuring that a network device is compatible with the monitoring software being used on the network, or that the monitoring software is modular enough to allow new devices to be added to it.

SNMP uses protocol data units (PDUs), usually packets, to communicate between the manager and the agents. The manager will send a GetRequest or SetRequest to the agent. The agent responds with a GetResponse PDU which contains the results of the request. The GetRequest command asks for certain objects and their values. These objects can be current CPU temperature, amount of hard drive space available, amount of bandwidth, or anything else that can be managed through SNMP. SetRequest , on the other hand, provides a value to which the remote agent should be set.

GetNextRequest is used to traverse a series of agents on a managed device to extract information from all agents. This command is commonly used when the manager does not know exactly what it should be looking for, so it requests everything.

The Trap command is a PDU that originates from the agent. It is the only command that originates from the agent, and it is used to communicate unusual events, such as sudden spikes in traffic, CPU usage, or a network failure, that have occurred on the remote device. A trap can even be configured when a hard drive reaches a certain capacity. When a trap is sent from the agent to the manager it is usually a sign there is a problem, or a pending problem.

Agents collect information about the network device using a Management Information Base (MIB). An MIB is a set of information, organized hierarchically, about a managed device. This hierarchical organization is also known as an MIB tree (Figure 16.3). Each MIB is made up of objects, and is categorized by object identifiers. An object is specific information about a device, and the object identifiers are the variables that are the possible values for those objects.

Figure 16.3. A partial view of the SNMP MIB tree for a Cisco router

graphics/16fig03.gif

Figure 16.3 is a partial view of the MIB tree of a router. This information can be automatically collected by most monitoring devices that support SNMP. In this case, WhatsUp Gold, from IPSwitch, built the entire MIB tree automatically. An MIB tree is similar to a directory structure, with each part of the MIB tree branching off to smaller parts . Again, using Figure 16.3 as the basis for discussion, this SNMP view contains a mib-2 group, under that is a system group, and within the system group are the objects.

Each of the objects has an assigned value that is communicated from the agent to the monitoring server. For example, the object sysUpTime has a value of "0 days 22:11:11". While this information is useful, it is not really necessary.

Figure 16.4 contains slightly more useful information. It is a partial view of the information available from one of the interfaces on the same router. The interface is located within the ifTable group, and contains a different set of objects, all of which represent information normally available using the command line interface (CLI). Information for which objects are available includes the interface type, speed, errors, number of packets, and the Maximum Transmission Unit (MTU) speed. Some of these objects, such as the MTU, can be changed remotely, while others are set to read-only.

Figure 16.4. The interface information from a Cisco router

graphics/16fig04.gif

The MIB tree-like interface allows network administrators to drill deeper into a problem when it is necessary. If an administrator logs into a router and notices that it is extremely slow, he or she can examine individual objects closer to see what may be causing the problem. Figure 16.5 shows an extended view of ifInOctets. There is a sudden spike in the number of octets directed at that interface, which may account for the poor performance of the router. The next step would be to determine why the sudden spike occurred.

Figure 16.5. Drilling deeper into the MIB objects allows an administrator to gain a deeper view of problems on the network

graphics/16fig05.gif

Obviously, different devices will have different MIB trees, even when the same manufacturer makes them. However, all devices made by the same manufacturer should have the same top, or root, MIB entry. These root MIBs are registered through the ISO. For example, all Extreme Network devices are part of the root MIB: iso.org.dod.internet.private. enterprises .extremenetworks . Different group MIBs are assigned based on the purpose of the device. Switches have different group needs than routers, and both have different needs than a firewall, or IDS.

Fortunately, SNMP is versatile enough to monitor any type of network device, and can be easily adapted to fit any type of network device and meet the needs of network administrators. Most monitoring programs will allow administrators to track as much or as little information as desired. Full-blown SNMP monitoring of every device on the network may not be advisable, so it is usually a good idea to select just those objects and groups that are critical to network stability and monitor them. This allows the administrative staff to catch emergencies faster, without having to sift through reams of irrelevant data.

NOTE

The MIB tree for a network device is simply a list of the groups and objects within the MIB, stored in a plain text file. For some devices this list can be dozens of pages long. To make it easier for administrators to filter out unnecessary groups and objects, many monitoring tools include MIB viewers , which will import the MIB tree and allow an administrator to examine the information within the MIB. Companies like SolarWinds and MG-Soft also make applications that are stand-alone MIB browsers, which are very handy tools to have around.


16.2.1 SNMP Security

SNMP is a great tool for monitoring and managing networks. This is evidenced by the fact that SNMP is so widely deployed. While SNMP has proven to be a reliable and stable product, it has not proven to be very secure. In fact, considering the amount of information that can be polled using SNMP, the level of security contained within it is atrocious.

The original version of SNMP, SNMP Version 1.0, only included community strings as a means of securing communications. Community strings are, essentially , passwords used to determine whether a device has read or read and write access to the network device. These passwords were not encrypted and were sent in clear text from the manager to the agents on the network device.

NOTE

The most common passwords used for SNMP are public and private, for read, and read and write access respectively. Attackers know this and will often try to poll a network looking for network devices that have SNMP enabled with these default passwords. For this reason it is crucial that SNMP be disabled on all devices that are not actively being polled for SNMP information.


SNMP Version 2.0 added several enhancements over SNMP 1.0. SNMP 2.0 was designed to be relatively backward compatible with SNMP 1.0, although some enhancements made complete backwards compatibility impossible .

The creators of SNMP Version 2.0 realized the importance of security, and tried to implement it with mixed success. There were actually several versions of SNMP 2.0 released; the two that are most important to security are SNMP Version 2c and SNMP Version 2u. SNMP 2c basically abandoned the security features included in the original SNMP 2.0 specification and reverted to the community string model used in SNMP 1.0.

SNMP 2u took a different approach, and introduced a user -based security model to SNMP. SNMP 2u is documented in RFC 1910 and defines a method of access control for SNMP-based systems. The goal of SNMP 2u was to provide a way to authenticate users and prevent unauthorized access of information. SNMP 2u was never widely adopted, but many of the enhancements in SNMP Version 3.0 are based on SNMP 2u.

NOTE

SNMP is a very common attack target because it is ubiquitous. SNMP attacks can allow root compromises, crash operating systems, and be used to launch other types of DoS attacks. For that reason, many security experts recommend strong filters be placed on networks that rely on SNMP for monitoring.


16.2.2 SNMP 3.0

In 1998 the IETF released a series of RFCs that defined several security enhancements to SNMP. These security enhancements, known collectively as SNMP 3.0, were not developed to create a new version of SNMP. Rather, they enhance the existing versions of SNMP by creating several different types of security. The RFCs that outlined the SNMP 3.0 architecture are RFC 2271 through RFC 2275.

There are three areas of security on which SNMP 3.0 focuses: authentication, privacy, and access control. As with SNMP 2u, SNMP 3.0 PDUs can use authentication to ensure the validity of the information. On top of authentication, SNMP 3.0 supports DES encryption between managers and agents. Finally, agents can be configured to only allow certain managers, or groups of managers, to have access to information. Similar to authentication, access control limits the type of information provided to different groups ”unlike authentication, access control is handled at the group level, not the user level.

The security enhancements in SNMP 3.0 are made possible by the use of a principal. The principal is a user, or set of users, that resides on the manager and issues SNMP requests to the agents. When the principal issues a request to the agent, a negotiation takes place. The principal and the agent determine what security features will be used, and the agent uses the information provided by the principal to determine how much information will be shared. When the principal sends an SNMP request to an agent it includes a field in the PDU called msgSecurityModel. The msgSecurityModel will be set to 1, 2, or 3 depending on which version of SNMP is being used. The receiver should then use the same security model to process the message.

Authentication is the most commonly used form of security with SNMP 3.0. Defined in RFC 2274, authentication of SNMP messages has two aspects: the actual authentication and the timeliness of the message. Authentication between the manager and the agent is handled through a shared-key process. The authentication is handled using a Keyed-Hash Message Authentication Code (HMAC). The key will need to be provided to the manager and the agent, prior to the first authentication.

In addition to authentication, SNMP 3.0 checks for the message time. Previous versions of SNMP 3.0 were susceptible to replay attacks. To avoid this problem, when an agent or manager receives a message it verifies the time of that message to ensure it is within the system's acceptable parameters.

To maintain the time synchronization between devices, each SNMP-enabled device has two values, snmpEngineBoots and snmpEngine Time . The values contain the number of system boots since SNMP was installed and the number of seconds since the last boot. Every time an SNMP PDU is transmitted these values are transmitted as well, allowing other SNMP devices to maintain a database with this information for all SNMP devices with which they communicate.

When an SNMP manager or agent receives a PDU from a device it checks the information in the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields. If that information is within 150 seconds of the information the device has stored in its local database, the PDU is considered valid and is accepted.

While authentication is useful, sending data in clear text is still a problem, especially if an organization is monitoring across a WAN. To resolve that problem SNMP 3.0 allows network administrators to use DES encryption to secure messages between devices. Keep in mind that any time encryption is used it can increase CPU usage significantly. While the security gains certainly make encryption worthwhile, its use should be monitored closely.

Encryption is used in conjunction with authentication to increase the level of privacy and security. The manager and the agent use the cipher block chaining (CBC) mode of DES to encrypt the data. The encryption is accomplished by creating an initialization value using a number found in the msgPrivacyParameters field of the PDU.

The View-based Access Control Model (VACM) is the SNMP version of an access control system, and is defined in RFC 2275. VACM is used to provide varying levels of control to managers, or groups of managers. VACM works by creating a table on each agent with different groups; the groups correspond with managers who can request data ”and what type of data can be requested ”from that agent. VACM rules can be applied to an entire MIB, groups of objects within an MIB, or a single object within the MIB.

There are several levels of security available using VACM rules. The most basic occurs when a request is made for an MIB object ”the agent checks the tables to determine whether the manager making the request is authorized to access the content. If not, the agent returns an error. The error returned is noSuchContext , rather than a not allowed error. This slows down a potential attacker who is trying common MIBs to determine what type of device it is.

In VACM architecture SNMP requests from managers will include two additional fields: securityModel and securityName. Both fields need to be propagated; the agent will examine the vacmSecurityToGroup table to determine if there is a match for both fields. If not, the agent returns a noGroupName error.

There is also a vacmAccessTable that needs to be checked. The agent examines the groupName, securityModel, contextName, and securityLevel sent by the manager against entries in that table. If a match is found, then requests can be processed up to the defined securityLevel for the requested content. In other words, if a manager wished to write information to the agent, he or she not only has to be allowed to access the MIB object, he or she has to have write permissions. This gives administrators a very granular level of control for each MIB and MIB object on a device.

VACM can enhance the security of network devices by granting different groups very specific levels of control. Unfortunately, there is not a method available ”at this time ”to apply VACM rules across multiple devices. This means each rule has to be defined on every device to which it applies. This can be a tedious task, especially in large networks. The tradeoff for the amount of planning and configuration time involved is that VACM allows administrators to create multiple device views without having to rely on software such as OpenView or Netcool to do it.

16.2.3 SNMP Recommendations

All SNMP requests should be using some form of SNMP 3.0 security, preferably a combination of the HMAC algorithm and DES encryption. However, not all devices support SNMP 3.0 security measures at this time. If a vendor does not support these enhanced security measures, they should be encouraged to do so.

If SNMP 3.0 is not an option at this point, there are still a few other options:

  • Change the default passwords. This won't stop an attacker who has access to the LAN and therefore may be able to sniff the information, but it will make things more difficult for attackers outside the network.

  • Disable write capabilities to all network devices. An attacker who is able to gain write access to these devices can cause a lot of damage in a very short time. Disabling write capabilities will slow the attacker down considerably.

  • Filter SNMP requests at the firewall level. SNMP should not be monitored remotely, only from within the network (ICMP, HTTP, and other requests can be monitored remotely). If requests are filtered at the firewall, an attacker will not be able to use the SNMP tool to map out a network and plan an attack.

   


The Practice of Network Security. Deployment Strategies for Production Environments
The Practice of Network Security: Deployment Strategies for Production Environments
ISBN: 0130462233
EAN: 2147483647
Year: 2002
Pages: 131
Authors: Allan Liska

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net