Cisco IDS Communications

Extracting Data Communications

Two main programs extract data out of the IDS sensors: the IEV and the Security Monitor module inside CiscoWorks. These programs allow you to collect and review sensor data and record sensor activity. These programs are covered in greater detail in Chapter 13, "Monitor a Cisco IDS Protection Solution for Small and Medium Networks Using Cisco IDS and Cisco IEV," and Chapter 14, "Enterprise IDS Management with the Cisco IDS Management Center for VMS," but here we list what protocols they use to communicate with the Cisco IDS sensors.

In earlier versions of Cisco IDS, such as version 3.x and below, Cisco used a communication protocol named PostOffice to collect event messages. Now in IDS version 4.0, Cisco uses the RDEP to collect event messages and IP logs. For the exam, we cover both PostOffice and the RDEP. However, RDEP is Cisco's primary focus.

The IEV and Security Monitor support both protocols, PostOffice and RDEP. Figure 5.5 displays the connection types to each version, and Table 5.5 details the diagram.

Table 5.5. IEV and Security Monitor Communication Details

PostOffice Protocol

The PostOffice protocol was a pushing protocol used in version 3.x and below to allow event-message collection from the sensor to management stations such as the IEV and Security Monitor. This protocol required assigning the sensors and management stations with host ID and organization ID pairs. These pairs had to be unique within an organization to identify the correct sensor or management station. Table 5.6 describes the PostOffice settings.

Table 5.6. PostOffice Settings

PostOffice should not be confused with POP3 or anything to do with email because it's a proprietary protocol used between a sensor and monitoring interface.

Figure 5.6 displays two different director stations managing their corresponding organizational ID sensors.

The PostOffice protocol must have a unique host ID and organization ID combination for each station or device.

RDEP

The RDEP is a pull-based application-level communication protocol that formats the event messages and IP log messages into Extensible Markup Language (XML) documents. These XML documents are then encrypted and transmitted using the industry standard HTTPS (Transport Layer Security/Secure Socket Layer [TLS/SSL]) between the RDEP clients such as IEV and Security Monitor and the sensor.

The RDEP is a request and response type engine that provides a basic pulling mechanism. As data is requested , the sensor sends the data. For example, when IEV needs data, the following steps are taken:

1. The IEV initiates a encrypted HTTP over a TLS/SSL (HTTPS) connection with the sensor.
   
   

2. The IEV begins sending RDEP event requests to the desired sensor.
   
   

3. The sensor then responds with RDEP event response messages.
   
   

When using the RDEP protocol, sensors do not need unique names as in the days of using PostOffice protocols.

The RDEP consists of two main requests, a uri-es-request and a uri- iplog -request .

The uri-es-request has two different subtypes of event request:

• Queries Used to retrieve events stored on the sensor.

• Subscriptions Allow the collection of live-event feeds to an RDEP client. The RDEP client sends subscription-get messages to the sensor to retrieve the latest events.

The uri-iplog-request pulls IP log messages from the sensor.

Figure 5.7 displays an example of the IEV or Security Monitor pulling messages from the Cisco IDS 4.0 sensor.

Event Messages

Event messages contain IDS status, alarms, and error messages stored on sensors. Client applications such as the IEV and Security Monitor use PostOffice Protocol or RDEP to collect these messages from sensors. The basic communication relies on the client application to request a message and the sensor sends it. In Cisco IDS 4.0, the event messages in the sensor can store up to 4GB of data before older records are overwritten by newer ones.

IP Log Messages

The management stations use IP log messages to collect actual packet data detected off the monitoring ports. This data is usually collected during an attack to help determine what the actual attack is or was trying to accomplish.

Managed Devices Communications

The Cisco uses the term managed devices to describe things that can be controlled by an IDS sensor. IOS Routers, PIX Firewalls, and even other sensors are considered managed devices. For an attacker strike, you can configure a signature to send off a blocking ACL or shun to a managed device in an effort to stop the attacking host or connection.

A single managed device can only be controlled by a single sensor. This setup poses a problem in a large enterprise environment that consists of several different sensors that need to send blocking ACLs or shun commands to the same single devices. Cisco solves this problem by making a master blocking sensor control the single managed device. Other sensors called blocking forwarding sensors are configured to send their blocking ACL and shun commands to the master, who sends the actual blocking request.

Figure 5.8 displays a graphical view of the protocols and managed devices the IDS 4.0 sensors can connect to, and Table 5.7 provides a quick reference of protocols to managed devices.

Table 5.7. Managed Device Communications

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

You use The NAC to control managed devices, and in the CLI, you can look for the term "Network Access Control Service" to adjust settings for managed devices.

[ LiB ]