In-Depth

Security Problems in Network Management

• 03/01/2000

The network has become a business-critical asset for most corporations. Managing the network and developing comprehensive security measures are necessities that often decrease the availability of network resources.

Where it once was sufficient to require passwords on all user accounts to maintain a reasonable information defense, now a vast number of techniques are required to confront the wily hacker. Firewalls are used to segment networks into zones of control, Network Address Translation (NAT) is used to restrict access and conceal internal network structures, and Virtual Private Networking (VPN) technology is used to hide sensitive information as it traverses unsecured networks.

With the evolution of network management, more responsibility has been placed upon the "framework" to fulfill the TMN FCAPS model. Typical network operations centers, which support Simple Network Management Protocol (SNMP)-based logical and physical devices, must now be capable of supporting all business units in a uniform fashion.

There is a fundamental security concern with any type of remote management, whether it is remote system management or remote network device management. The goal of the security system is usually to limit access to devices to a small set of services, and to track that access as closely as possible. However, remote management, by its nature, typically requires complete access to all devices. Security staff would prefer to limit access to only a specific set of programs and files, on a limited set of systems, during fixed periods, from fixed locations.

SNMP provides this pervasive access to network systems and devices. As with any application protocol, this system has implications to the security environment that creates a large number of risks, but it also provides great benefit that cannot be ignored.

The primary purpose of SNMP V1, introduced in 1988, was to be an interim solution until a more complete management framework became available. Due to its simplicity and extensibility, the protocol rapidly became popular among vendors. Largely because of this simplicity, and despite some shortcomings, the SNMP V1 architecture has been widely accepted and implemented throughout today’s enterprise management solutions.

Figure 1 illustrates the typical SNMP V1 centralized framework. The principal component is the network management station, which supplies a point of entry for the operator into the network management system. Functional management applications, such as vendor- and device-specific management packages, interact with this network management station to obtain and interpret raw values into a manageable and controllable comprehensive view. The network management system also requires a Management Information Base (MIB), which will allow access to the managed entities.

The secondary component is the transport. This is the protocol suite, which allows the network management system to access the agent. In an SNMP V1 framework, IP and UDP are the preferred transport. The third component of the framework is the agent. The agent is a process that contains the MIB and interacts with the managed objects on that system. This then responds with the requested value via the transport back to the network management station. In this model, SNMP V1 security is limited to three methods of access: READ-ONLY, WRITE-ONLY and READ-WRITE. This access is controlled by "community strings" that are, in a network management view, groups to which these devices belong. From the point of view of security, these community strings are passwords.

The third version of the SNMP framework (SNMP V3) is extracted from and expands upon SNMP versions 1 and 2. Simply put, the SNMP V3 framework is the SNMP V2 suite, with the addition of security and administration functionality.

The SNMP V3 framework supports multiple security models, which can exist simultaneously, within an SNMP entity (see Figure 2). SNMP V3 messages contain a field in the header that identifies which security model must process the message. To ensure some form of interoperability, a User-based Security Model (USM) must be implemented by every compliant SNMP V3 entity. The USM is designed to defend against unauthorized modification of managed elements, and should prevent "masquerading" (otherwise known as spoofing). Additionally, SNMP V3 security provides limited protection against unauthorized disclosure of management information, and what is called "message stream modification." Message stream modification is the deconstruction and possibly malicious reconstruction of data in transit, such that the meaning of the data can be readily misinterpreted.

SNMP V3 security makes no attempt to prevent denial-of-service (DOS) attacks of management elements, and provides no protection against traffic analysis. Traffic analysis is the process of tracking the amount of information exchanged between two parties. If that traffic level increases or decreases dramatically, it is possible to derive meaning.

A large concern about the SNMP V3 security model is the requirement by the protocol designers that the security system be completely standalone. This places a requirement that each device maintain a full database of all management users and their passwords. Since it is unreasonable to expect that a network management team will keep separate accounts and passwords on each device, all devices are only as secure as the weakest link. It also means that any single sign-on solution that might be applied to the management stations and other internal resources cannot be used for the management system itself. This creates an operational inefficiency, or a security problem, depending upon the solution.

So far, we have been discussing only in-band network management (i.e., managing network elements, while using the network to pass the management traffic). Another option is to use out-of-band management, either by using a separate, almost redundant, network for managing the devices, or by making connections to the "console" ports of each device (either through direct wire connections, or via modems). By disabling the WRITE function in SNMP, we are safeguarded against most in-band attacks.

Out-of-band management enables the operators to access devices via remote access through a console port. This access method is an effective and comparatively secure way to configure critical network devices.

Figure 3 (on page 53) shows a fairly typical network, with out-of-band management connections. These connections are vital for the ongoing managment of the network in any case, as network commmunication outages can quite easily result from misconfigured interfaces. The out-of-band channel may be the only way to resolve the problem short of dispatching a field technician.

Almost every network device is shipped with a READ community string of "public," set at the factory. This means that anyone with access to the network can read the configuration of the device, and can determine its recent statistics, including the addresses of neighboring devices. As a result, all management information, short of actual passwords (which may be encrypted on the devices), is available to anyone. The result is that an attacker can rapidly create a map of the entire network, and use that map to develop a surgical strike plan to attack the most valuable assets with little or no warning.

We have found that almost half of the networks we have surveyed use the exact same WRITE community string: "private," to differentiate it from the "public" READ community string. The result is that a would-be attacker can use the network to subvert managed devices, reroute traffic to a point outside the administrative control area and "sniff" the traffic prior to routing it back inside.

The fact that SNMP uses UDP creates other problems. Most firewalls are very poor at maintaining what is called "stateful control" of UDP conversations. They can often be configured to only allow SNMP responses, but these systems are often configured incorrectly, or else the proper configuration is so complex, that many firewall administrators take dangerous shortcuts, resulting in no SNMP traffic control at all. Even if the firewall is configured correctly, most don’t keep sufficient state to actually track queries and responses to queries. It becomes a relatively simple matter to send forged SNMP responses or forged TRAP messages to the management system, and crash this valuable resource.

It must be emphasized that all default passwords, on all systems and devices (including community strings on network elements) must be changed, and they must be made as complex as the systems and users can tolerate.

When designing a secure, managed network, it’s important to tie the two functions together. The first step in this process is to integrate the security reporting systems into the management framework. For example, most firewalls can send SNMP traps when a filter rule is violated. A more complex, yet valuable, solution is to tie system and network intrusion detection systems, including log processors and integrity checkers, into the network management framework.

For example, a log processor might want to send traps to the management center if log files (which are expected only to grow) ever shrink. This would be an indication of a severe breach of security on a system, and would warrant immediate response. Many platforms have a generic program to send SNMP traps to a specified destination. By creating an MIB definition for security-specific traps, recurring scans of the system can report anomalous activity, such as log shrinkage, back to the NOC.

In one situation, we needed to place equipment in remote, unsecured locations. To effectively monitor the physical security of these devices, we placed the equipment in enclosed, locking racks. We attached a micro-switch to the door, and connected the switch to one of the systems installed in the rack. When the door was opened, a trap was sent to the NOC, indicating that the rack had been opened. This information was supplied to the event correlation framework and the trouble-ticketing system was queried. If there were no outstanding trouble tickets against the equipment located in the rack, an alarm was triggered within the NOC, and an operator would call the remote location to determine why the rack had been opened.

This example illustrates the value of integrating security into the network management framework. A system was already in place for reporting problems, and for tracking problem resolution efforts. Instead of creating a new infrastructure for security events, effort was put toward leveraging the existing infrastructure, and getting further return on prior investments.

The risks associated with managing equipment through a firewall can be quite high. In some cases, it is most beneficial to create separate domains in which a network management system can be liable for discovery, status polling, correlation, thresholding, and configuration functions (see Figure 4). There are several advantages of this architecture:

• SNMP traffic is at a minimum

• Events are locally generated and correlated

• Local operators have local views of the domain

• Redundancy

• Scalability and flexibility

Creating management zones makes it possible for other network management systems to share the responsibility of the monitoring process.

Figure 5 describes a reasonably secure network. The internal network is divided into three main zones of control, which align with the network management domains. All internal networks are protected from the Internet and the WAN by firewalls, and each has network-level intrusion detection systems (IDSs) installed. These IDSs are configured to send traps to the network management system. In the event of an attack attempt, all audit records from every system are copied to a centralized audit service on the local network management system.

Each system on the network has system integrity checking software installed. Should these checks fail, traps would be sent to the network management system. Domain name services have been split between internal and external servers. The firewall is configured to fail-secure, and all systems and devices have been stripped of any services or programs that are not regularly used. We will assume that all relevant security patches from vendors have been applied.

All polling is kept local to the network, and the R2 router is set up to filter all SNMP traffic from the Internet. This keeps SNMP from becoming a security risk, and minimizes the amount of wide-area bandwidth used for network and security management.

One of the main goals of network management is to increase the availability of network resources. To assist in this effort, a security system should be adopted that helps prevent unauthorized modification of network equipment and facilitates the confidentiality of network operations center information bases.

Similarly, an information security organization’s goal of ensuring the confidentiality, integrity and availability of proprietary information can be greatly facilitated through the use of network management access and infrastructures. Indeed, it is crucial to integrate the functions of both operations, whenever possible.

About the Authors: Steph Marr is Vice President of Information Security at Predictive Systems Inc. (Santa Cruz, Calif.), a vendor-neutral network consulting and integration firm. In1989, Marr helped capture and convict the elusive computer criminal Kevin Mitnik. He can be reached at steph.marr@predictive.com.

Lenny Rocci is Director of Enterprise Network Management at Predictive Systems. He can be reached at lenny.rocci@predictive.com.