Cisco IDS Communications

[ LiB ]

The Cisco IDS sensors support several different types of communication protocols to manage and extract data and communicate with managed devices.

Management Communications

You can manage the IDS sensor with several different tools: Telnet clients, SSH clients, Web clients , and IDS MC servers. Figure 5.4 provides a graphical view of the different ways to connect to the sensor, and Table 5.4 details the connection types.

Figure 5.4. IDS management communications.

Table 5.4. IDS Management Communication Details

Client	Protocol	Management
Telnet	Cleartext	Connection to the CLI.
SSH	Data Encryption Standard (DES) or Triple DES (3DES)	Connection to the CLI.
Web client	HTTPS	Connection to the IDM port 443.
Web client	HTTPS	Connection to the IDS MC server port 443.
IDS MC server	SSH	Connection to the IDS sensors using SSH.

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.

Figure 5.5. IEV and Security Monitor communication.

Table 5.5. IEV and Security Monitor Communication Details

Client	Protocol	Sensor
IEV	RDEP	IDS 4.0 and above
Security Monitor	RDEP	IDS 4.0 and above
IEV	PostOffice	IDS 3.x
Security Monitor	PostOffice	IDS 3.x

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

Setting	Description
Host ID	A numeric identifier greater than zero for each of your IDS- related devices.
Host name	A friendly name for the host.
Organization ID	A numeric identifier greater than zero used to create a group of IDS-related devices. Similar to the community names used for Simple Network Management Protocol (SNMP).
Organization name	A friendly name for the organization.

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.

Figure 5.6. PostOffice organizations.

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.

Figure 5.7. RDEP XML feed.

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.

Figure 5.8. Managed device communications.

Table 5.7. Managed Device Communications

From	Protocol	To Managed Device
Sensor	Telnet	IOS Router or PIX Firewall
Sensor	SSH	IOS Router or PIX Firewall
Blocking forwarding sensor	RDEP	IDS 4.0 master blocking sensor
Blocking forwarding sensor	PostOffice	IDS 3.x master blocking sensor

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 ]