NetRanger Overview

The Sensor captures network packets with one of its own interfaces, then reassembles and compares this data against a rule set indicating typical intrusion activity. The syslog traffic is sent to UDP port 514, and is analyzed by the Sensor's intrusion detection engine.

When NetRanger analyzes network data, it looks for patterns of misuse. Patterns can be as simple as an attempt to access a specific port on a specific host, or as complex as sequences of operations distributed across multiple hosts over an arbitrary period of time. The first type of pattern is termed an atomic pattern; the second, a composite pattern.

NetRanger searches for patterns of misuse by examining either the data portion or the header portion of network packets. Content-based attacks derive from the data portion, and context-based attacks derive from the header portion. Table 1-1 lists examples of the types of attacks and patterns that NetRanger detects.

Attack	Pattern
Atomic	Composite
Context (header)	Ping of Death Finger	Port Sweep SYN Attack TCP Hijacking
Content (data)	MS IE Attack E-mail Attacks	Telnet Attack

Table 1-1: Types of Patterns and Attacks

Attack Pattern

Atomic Composite

Context (header)

Ping of Death

Finger

Port Sweep

SYN Attack

TCP Hijacking

Content (data)

MS IE Attack

E-mail Attacks

Telnet Attack

Attack Response

After it detects an attack, a Sensor can respond in the following user-configurable ways:

Generate an alarm. Alarms are generated by the Sensor, and are typically routed to one or more remote Director systems, where they are logged or displayed on a graphical user interface.
Generate IP session logs. IP session logs are used to gather information about unauthorized use. This type of log file is only written to when a certain event or events occur (for example, a connection request from a specific IP address, or detection of a string such as "Confidential"). When these types of conditions are met, the Sensor can be configured to write every incoming and outgoing packet to an IP session log for a predefined period of time.

Note Both alarm and IP session information can be logged locally on a Sensor system as well as remotely on Director systems; exactly what information is sent where depends on how each Sensor system is configured.

Reset TCP connections after an attack begins. The Sensor can reset individual TCP connections after an attack to eliminate the threat. Communication between all other connections continues, thereby decreasing the likelihood of denial of service problems that can occur after shunning TCP-based attacks.
Shun the attack. Shunning is a term that refers to the Sensor's ability to use a network device to deny entry to a specific network host or an entire network. To implement shunning, the Sensor dynamically reconfigures and reloads a network device's access control lists. This type of automated response by the Sensor should only be configured for attack signatures with a low probability of false positive detection, such as an unambiguous SATAN attack. In case of any suspicious activity that does not trigger automatic shunning, you can use a Director menu function to shun manually.

Caution
Shunning requires careful review before it is deployed, whether as a set of automatic rules or operational guidelines for staff. In case an alarm is generated from a critical host or network, NetRanger can be configured to never shun that host or network. This safety mechanism prevents denial of service attacks using the NetRanger infrastructure.

Device Management

Device management is a term that refers to the Sensor's ability to dynamically reconfigure a router's access control lists to shun the source of an attack in real time. This capability greatly enhances the Sensor's ability to secure a network from external and internal threats.

The Sensor can be configured to create an alarm when it detects a policy violation from the syslog generated by a Cisco router. A policy violation is generated by a Cisco router when a packet fails to pass a designated Access Control List. Security data from Sensor and Cisco routers, including policy violations, is monitored and maintained on the Director.

The Sensor (illustrated in Figure 1-2) uses one of its network interfaces to monitor traffic, and another interface to execute commands and communicate with the router. This allows the Sensor to dynamically update the router's access control lists in response to traffic that enters the network.

Currently, the Sensor is packaged to support Ethernet, Fast Ethernet, Token Ring, and FDDI monitoring interfaces. It is important that the Sensor be used on a promiscuous mode hub and not a switched hub. If used on a switched hub, the Sensor can only "see" traffic if the switch supports a monitoring or SPAN port. The command interface is always Ethernet.

Figure 1-2: Preferred Sensor-Network Device Deployment

Director Capabilities

The Director provides centralized command and control over an organization's Sensors. A Director's capabilities are:

Sensor Initial Configuration

Although each Sensor needs to be initialized on its own, you use the Director to finalize each Sensor's configuration. This is accomplished through a step-by-step installation wizard that prompts you for data about the Sensor, including host name, IP address, the identities of routers to use for shunning and syslog monitoring, and other key information.

Sensor Monitoring

The Director displays real-time security information sent to it by Sensors. This information is presented via icons drawn on one or more network security maps.

The Director arranges icons into hierarchical security maps based on HP OpenView's Network Node Management (NNM) user interface. Users can double-click an icon to view the next lower "submap" in the hierarchy. The bottom layer of the submap hierarchy contains Alarm and Error icons, as illustrated in Figure 1-3 .

Figure 1-3: Sample Director Alarm Icons

Each icon, whether it represents a Machine, an Application, or an Alarm, has a state, which is expressed in the form of textual and graphical attributes. The most visible indication of an icon's state is its color. These colors represent states and alarm levels, which are defined in Table 1-2.

Icon Color	Icon State	Default Alarm Level
Green	Normal	1-2
Yellow	Marginal	3
Red	Critical	4-5

Table 1-2: Icon Color, State, and Default Alarm Level

Icon Color Icon State Default Alarm Level

Green

Normal

1-2

Yellow

Marginal

3

Red

Critical

4-5

An icon's color propagates upward through the submap hierarchy. For instance, an Alarm icon that is defined as "Critical" is red. The Application that generates a red alarm will turn red to match the Alarm; in turn, the Machine icon that owns the Application will also turn red.

Every icon in a Director hierarchy also possesses textual attributes, most of which are accessible by the user. Each type of icon (Machine, Application, Alarm) has a different set of attributes.

The types of icons are:

Intrusion---Intrusion alarms indicate that some type of unauthorized activity has occurred, whether a policy violation (as logged by a Cisco router), a fragmented packet header, a denial of service attack, or other event.
Context---Context alarms indicate that an intrusion occurred, but that the Sensor gathered extra context information about the intrusion.
Error---There are three types of Error alarms, indicating that a daemon has stopped working, that a daemon cannot be restarted, or that a communication route between NetRanger hosts is down.

Sensor Management

The Director can remotely manage the configuration of services on a Sensor. The application responsible for Sensor management is nrConfigure. nrConfigure's signature configuration dialog is shown in Figure 1-4.

Configuring signatures on a remote Sensor is a key method for securing a network with NetRanger. You can use the built-in, or embedded, signatures, or create your own custom string-matching signatures to meet the needs of your network environment.

Figure 1-4: Managing Sensor Actions with nrConfigure

nr Configure is a Java-based tool used for remote Sensor configuration and configuration file management. With this tool, a user can change the configuration files on a remote Sensor, and also manage versions of those configuration files. This functionality allows users to keep current as well as past configurations. At any point, nrConfigure allows a user to "roll back" a Sensor to a previous configuration.

For any given version of a Sensor's configuration, nrConfigure allows users to make changes to the following types of information:

Communications
Data management
Device management
Director forwarding
Event processing
Intrusion detection
System files

Collection of Sensor Data

The Director can collect and stage Sensor data using a simple push-pull mechanism: NetRanger writes (pushes) the data into flat files, then stages (pulls) the data into a database. The entire process is illustrated in Figure 1-5.

Writing to intermediate flat files in this manner provides levels of fault tolerance and performance that cannot be achieved when writing directly to a database. Data throughput in a distributed application such as NetRanger is constrained only by the weakest link in the system. With NetRanger's data collection process, data collection is not dependent on (or affected by) database availability or performance fluctuations.

Figure 1-5: Sensor Data Collection

The Director currently ships with drivers for Oracle and Remedy. However, these drivers can also be configured to write to other databases, such as Sybase and Informix. Example scripts shipped with the Director show how a database's native bulk load tools can be easily integrated into NetRanger.

The Director also includes a configurable file management capability that automatically archives event and IP logs, either on a Sensor or a Director. Sample file management profiles are provided for both Sensor and Director configurations.

Analysis of Sensor Data

The Director can also analyze Sensor data using third-party tools that provide relational database management, report writing, file management, and trouble-ticketing functionality.

As a foundation for custom reports, the Director includes a set of SQL queries that can be easily customized or integrated into any third-party tools.

The third-party data analysis tools can be configured to support ad hoc queries as well as predefined reports. For example, these tools can easily generate reports showing the following:

All alarms of levels 4 and 5 occurring in the last 30 days
A graph of web server activity over the last 24 hours
A table of all events in the last 30 days in order of increasing alarm levels

Access to the Network Security Database

The Director's Network Security Database (NSDB) is an HTML-based encyclopedia of network security information, including vulnerabilities, their associated exploits, and possible countermeasures. You can also customize the NSDB by adding user-defined notes for each vulnerability.

Support for User-Defined Actions

The Director can generate user-defined actions. A common action is to notify staff members via e-mail messages or feed data onto third-party devices, such as a printer or database management system. Support for multiple action scripts is also provided.

Post Office Capabilities

NetRanger services and hosts communicate with one another through the Post Office. This holds true for communication between services on the same host as well as those across a network. All communication is based on a unique three-part address with Organization, Host, and Application identifiers, which uniquely identifies each NetRanger node.

NetRanger's proprietary 3-part addressing scheme has the following characteristics:

It can be layered on top of existing network protocols.
It allows for fault-tolerant connectivity across heterogeneous network architectures.
It addresses a much larger domain than the current 32-bit IP protocol.

NetRanger's three-part addressing scheme also serves as the basis for a point-to-point protocol that allows for up to 255 alternate routes between two hosts. This alternate routing protocol automatically switches to the next route whenever the current route fails. It also uses a system heartbeat to detect when a connection to the preferred route can be reestablished. A system error message is generated (and logged) whenever a connection goes down, and any packets that were lost during the state transition are resent.

Another feature that complements alternate routing is the ability to build hierarchies of Sensor and Director systems through the use of message propagation. Instead of broadcasting events from a Sensor onto multiple hosts, information can be sent to a single Director, which can then propagate packets onto other platforms defined in its local configuration files. Sensors can propagate messages to more than one Director, thereby insuring fault-tolerant communication. Figure 1-6 illustrates this concept through a simple hierarchy of Director machines.

In addition to providing performance benefits and fault tolerance, distribution hierarchies can simplify system management. For example, local Director machines might be responsible for monitoring from 9AM to 5PM and then transfer control onto a central Director every evening.

Figure 1-6: Director Hierarchy Based on Message Propagation

NetRanger Architecture

Sensors, Directors, and the Post Office each have separate operational components, called daemons or services. Because each major NetRanger function is accomplished by a separate service, the results are a security system that is fast, durable, and scalable.

The services, illustrated in Figure 1-7, are defined as follows:

sensord/packetd---Both of these services provide intrusion detection. sensord is used when a Sensor is cooperating with a network device that supports copy_to/log_to functions (which sends copies of captured packets to the Sensor); packetd is used when the Sensor itself is capturing packets directly from the network.
loggerd---This service is NetRanger's logging facility. It is responsible for writing error, command, and alarm entries to log files on the Sensor.
sapd ---This service provides data and file management. It is responsible for moving log files to database staging areas, off-line archives, and other routine processes to prevent file systems from filling up.
postofficed---This service handles communication between NetRanger services and NetRanger nodes. As illustrated in Figure 1-7, when sensord detects unauthorized activity, it signals postofficed. postofficed is then responsible for telling loggerd to start logging, alerting smid on the Director, and for communicating orders to a router if the attack is to be shunned.
smid---This service runs on the Director only, and is responsible for translating Sensor data into meaningful information for nrdirmap.
nrdirmap---This service is responsible for displaying various icons representing machines, collections of machines, applications, alarms, and errors on the Director graphical interface.
eventd---This service is responsible for maintaining user-defined event notification processes. Users can define what kinds of alarms or other events launch an action, usually an e-mail or pager notification.
configd---This service provides a mechanism through which nrdirmap can interface with other services like postofficed, sensord, and managed. In other words, commands on the graphical interface can be executed via the underlying configd service.

Figure 1-7: NetRanger 2.2.0 A rchitecture

Table of Contents

NetRanger Overview