CIDS Operations and Functionality

CIDS Operations and Functionality

CIDS is a network-based IDS system that uses both a director platform and network sensors. The director platform(s) are used to view alarms generated by the sensors, configure the sensors, and maintain the IDS environment. The sensor is the most critical component of Cisco’s IDS system because it monitors, analyzes, responds to, and reports intrusions to the director platform.

The basic operations and functionality of the CIDS can be described in the following five steps:

  • Step 1 Monitoring

  • Step 2 Analyzing

  • Step 3 Communications

  • Step 4 Centralized Alarm Display and Management

  • Step 5 (Optional) Sensor Response


Monitoring is accomplished with network sensors. Sensors have two interfaces: one monitoring interface, and one command and control interface. The monitoring interface is used to capture all network traffic from the network to which it’s connected. Sensors capture all packets on the network and, if configured to do so, will reassemble fragmented packets in order to defend against a common IDS defeating technique.

The command and control interface is used to configure the sensor, communicate with the director platform, and perform device management. When an intrusion signature is matched, the sensor is responsible for logging the event, and notifying the director through the command and control interface. Device management is the term used to describe the sensor’s capability to reconfigure Cisco routers, firewalls, and switches to stop an intrusion. Device management is discussed in more detail in the section “IP Blocking.”

Cisco currently has four different network sensors. Three of the sensors are all members of the 4200 series; the fourth sensor is an integrated switch module for the Catalyst 6500 series switch. Each of these four sensors has been engineered and tuned for optimum performance.

Cisco 4200 Series Sensors

The 4200 series network sensors are stand-alone components running their own operating system (OS) and are referred to as appliances. To protect the sensors, the host OS on the 4200 series sensors should be secured and patched, and any unneeded services should be removed. The three network sensor appliances belonging to the 4200 series are the following:

  • 4210

  • 4235 (replaces the 4230)

  • 4250

The model 4210 is the entry-level network sensor capable of monitoring up to 45Mbps of network traffic. The back panel of the 2410 is illustrated in Figure 24-1. The 4210 has a console port located on the front panel, much like the 2600 and 3600 series routers, but some Cisco documentation shows the com port on the rear panel labeled as the console port. For an Ethernet network configuration:

Click To expand
Figure 24-1: Model 4210 rear panel
  • Use the iprb1 interface for command and control.

  • Use the iprb0 interface for capturing packets.

Some of the features of the 4210 include the following:

  • Performance: 45Mbps

  • Network Interface: 10/100Base-T

  • Chassis: 1U

The model 4235 is a replacement for model 4230 and represents the mid-level network sensor. The 4235 is capable of monitoring up to 200Mbps of data. The back panel of the 4230 is illustrated in Figure 24-2. For an Ethernet network configuration:

Click To expand
Figure 24-2: Models 4235 and 4250 rear panel
  • Command and Control interface: e1000g1

  • Sniffing interface: e1000g0

Some of the features of the 4235 include the following:

  • Performance: 200Mbps

  • Network Interface: 10/100/1000Base-TX

  • Chassis: 1U

The model 4250 is Cisco’s latest addition to the 4200 series and represents the highest level of network performance. The 4250 is capable of monitoring and analyzing up to 500Mbps. The back panels of the 2450 and the 2435 are identical and are illustrated in Figure 24-2. For an Ethernet network configuration:

Click To expand
Figure 24-3: Model 4230 rear panel
  • Command and Control interface: e1000g1

  • Sniffing interface (Copper, next to C&C): e1000g0 (IDS-4250-TX)

  • Sniffing interface (Fiber, PCI add on card): e1000g3 (IDS-4250-SX)

The features of the 4250 include the following:

  • : 10/100/1000Base-TX, 1000Base-SX (Fiber)

  • Chassis: Performance: 500Mbps

  • Network Interface 1U

The Cisco sensor is currently end of life (EOL) and has been replaced by the 4235. For exam purposes, Figure 24-3 illustrates the rear panel of the 4U chassis.


You should be familiar with the network interfaces (monitoring, and command and control), as well as the console port locations for each model of the 4200 series network sensors’ appliances.

Table 24-1 compares the features for each member of the 4200 series network sensors.

Table 24-1: Comparison of 4200 Series Network Sensors

Cisco IDS Sensor 4210

Cisco IDS Sensor 4235

Cisco IDS Sensor 4250





Network Interface

10/100 Base-T


1000Base-SX (Fiber)





Catalyst 6000 Intrusion Detection System Module (IDSM)

The Cisco IDSM was designed to allow the inclusion of IDS into enterprise networks by integrating IDS functionality directly into the switching fabric. The IDSM is a passive monitoring module that inspects copies of packets and isn’t in the switch-forwarding path. Because the module isn’t in the switch-forwarding path, the IDS module doesn’t impact switch performance. The IDSM is a blade module that can be inserted into any available slot on any 6000 series Catalyst switch, as shown in Figure 24-4.

Click To expand
Figure 24-4: Cisco Catalyst 6000 IDS module

The IDSM monitors and analyzes traffic, just as the 4200 series network appliances. If an intrusion is detected, an alarm is generated and sent to the director platform. The IDS module captures packets directly off the catalyst’s backplane. Two methods can be used to direct copies of packets from the backplane to the IDS module, and the two methods are the following:

  • Switch Port Analyzer (SPAN)

  • Virtual LAN access control lists (VLAN ACL)

Spanning is a feature that allows the switch administrator to configure a port as a SPAN port. The term “SPAN” isn’t associated with the common Spanning Tree protocol. The switch can be configured to copy all packets from a particular port/VLAN or to a particular port/VLAN to the SPAN port.

VLAN ACLs allow the IDSM to monitor traffic based on more granular criteria, such as specific IP addresses or network services. The monitoring is passive and only inspects copies of the packets, not the original packets, allowing real-time monitoring without affecting switch performance. The features of the IDSM include the following:

  • 100Mbps performance

  • Multi-VLAN visibility

  • Fully integrated line card

  • Complete signature set

  • No performance impact

The IDSM also can use the same director platform as the 4200 series network sensors. One director or management platform can be used to monitor and configure both 4200 series network appliances, and one or more IDSMs.


Packets captured by the sensors are reassembled, if required, and then compared against the signature database. When the sensors analyze network traffic, they’re looking for patterns of activity that match known intrusive activity. These patterns are defined in the signature database held on the network sensors. Patterns of activity can be as basic as an attempt to access a specific port on a specific host or as complex as a set of operations directed at a number of different hosts over an extended period of time. If a signature is matched, the sensor logs the information and sends an alarm to the director platform through the command and control interface.


The sensors and the director platforms must have a communication medium to allow for the sending of alarms, sensor configurations, and messages. Cisco’s proprietary PostOffice protocol provides this communication vehicle used by the sensors to communicate with one another and management consoles.

PostOffice Protocol

The PostOffice protocol is a proprietary protocol only used between the sensors and directors and shouldn’t be confused with common e-mail protocols, such as SMTP, IMAP, or POP. The PostOffice protocol is not an e-mail protocol. Through the use of the PostOffice protocol, the director platforms can send configuration files to the sensors, and the sensors can send messages and alarms to a centralized sensor or director. The messages sent between the directors and the sensors are controlled by services running on both devices. These services, called daemons, run on both the sensors and directors. Daemons are discussed in the sections “CIDS Software Architecture” and “Daemon Configuration Files.”

The PostOffice protocol uses User Datagram Protocol (UDP) as the transport layer protocol on port 45000. The PostOffice protocol also uses a proprietary addressing scheme to address all CIDS infrastructure devices. The following are the message types sent among CIDS service, sensors, and directors:

  • Command Messages

  • Error Messages

  • Command Log Messages

  • Alarm Messages

  • IP log Messages

  • Redirect Messages

  • Heartbeat Messages

Communication between services on both the sensors and the directors represents a critical component of Cisco’s IDS system. Because of its critical nature, Cisco developed the PostOffice protocol to be reliable, redundant, and fault tolerant.

PostOffice Reliability

When a sensor detects an intrusion, it must send an alarm to the centralized director or sensor. Because of its critical nature, the PostOffice protocol supports guaranteed delivery of all messages sent from the sensors to the directors. As seen in Figure 24-5, guaranteed delivery is accomplished through the use of acknowledgments. When a sensor sends a message, it expects to receive an acknowledgment (ack) in a predetermined amount of time. If an acknowledgment isn’t received, the sensor will repeatedly repeat the message until the director replies with an ack.

Click To expand
Figure 24-5: Reliable message delivery via the PostOffice protocol
PostOffice Redundancy

The PostOffice protocol allows for redundancy by allowing sensors to send messages to redundant director or sensor platforms. By sending alarms and messages to multiple platforms located in diverse locations, the CIDS infrastructure can be engineered for both redundancy and fault tolerance. You can configure the sensors to send alarms and messages to a maximum of 255 different destinations. Figure 24-6 illustrates a redundant director platform design.

Click To expand
Figure 24-6: Redundant director platforms
PostOffice Fault Tolerance

The PostOffice protocol allows the configuration of up to 255 alternate IP addresses for any single platform. These alternate IP addresses can represent separate network interface cards installed on a multihomed director platform, as seen in Figure 24-7. The sensors can be configured to use a primary address to reach a director platform and a secondary address if the primary address is unreachable. Sensors only use the secondary addresses if the primary address is unreachable. The sensors use a watchdog process to detect when the connectivity to the primary IP address is reestablished. Once a connection to the primary address is reestablished, the sensor resumes communications using the primary address.

Click To expand
Figure 24-7: CIDS multihomed director platform

By placing the director platform on a multihomed system, you allow the director to send and receive traffic on two or more networks. Using multihomed directors provides additional protection from network failures. By multihoming your director platform, you’re providing fault tolerance by creating multiple paths between your sensors and your directors. Figure 24-7 illustrates a multihomed director platform design.


A multihomed system is any system that has multiple network interfaces to separate networks. The networks can be logically separated or both physically and logically separated. Routers, by definition, are multihomed devices because they receive traffic on one network, and then route that traffic to another network. Multihomed computer systems running Unix or Windows NT/2000/XP can be configured as a router.

PostOffice Protocol Addressing

For devices within the CIDS infrastructure to communicate efficiently, the PostOffice protocol requires a unique protocol specific address for each device. Each device within the CIDS infrastructure has both a numeric identifier and an alphanumeric identifier.

The numeric identifier is a combination of the host ID and the organization ID, and is used for network communications. All devices within the same management must have the same organizational ID. Devices contained in the same organizational infrastructure share the same organizational ID, however, each device must have unique host IDs.

The alphanumeric identifier is used as the common name for the devices and is made up of the host name and the organizational name. As seen in Figure 24-8, each sensor and director platform has both a host ID and a host name. Each device also has both an organizational ID and an organizational name.

Click To expand
Figure 24-8: PostOffice host and organization addressing

The host ID and organizational ID are two parts of a three-part addressing scheme used by the PostOffice protocol. The third component that makes up a complete PostOffice protocol address is a unique application ID. All command and control messages are addressed using these three unique identifiers. Application IDs are discussed further in the section “The Services File.”

Centralized Alarm Display and Management

The director platforms act as centralized management stations for the entire CIDS infrastructure. In addition to displaying alarms, the director platforms are also responsible for manual intrusion response and sensor configuration. Cisco offers two different director platforms that can be used to manage your CIDS environment. Cisco Secure Policy Manager (CSPM) is the director platform of choice for Windows NT, while Cisco Intrusion Detection Director for UNIX (CIDS Director for UNIX) is for use in UNIX environments. Each sensor also has a built-in web interface that can be used to manage and configure the sensor.

Device Manager is an HTTP application installed on each sensor. This web interface can be used to configure and manage the sensor. The Event Viewer, a standalone application, can be used to view events and alarms generated by the sensors.


The CIDS exam focuses on the Device Manager for the configuration and management of network sensors.

Alarm Display

The Event Viewer is a responsible alarm display. Because manually monitoring all the sensors on the network is impractical, the Event Viewer provides a centralized management and alarm notification center. The Event Viewer includes the software necessary to display alarms generated by the sensors within a GUI interface.

The Event Viewer’s GUI interface displays alarms generated by the sensors in a unique color based on the severity of the alarm. Security administrators can quickly view all alarms as they’re reported in real time. This detail of alarm displaying allows administrators to examine all security threats quickly across the enterprise.

Manual Intrusion Response

Based on the severity of an alarm, manual and automatic responses can be taken to prevent further activity. The sensors, not the directors, handle this automatic response. In many cases, an automatic response isn’t needed or wanted. Manual intrusion response can be accomplished through sensor configuration using the IDS Device Manager. Directly from the sensor platform, the administrator can initiate an IP blocking response, blocking either the offending IP address or the entire network address of the intrusive host.

Sensor Configuration

Configurations can be created on the director platform, and then they can either be pushed to the sensors to update their configuration or individual sensors can be configured using the IDS Device Manager. The UNIX version of the director (CIDS Director for UNIX) allows administrators to create multiple configurations on the Director, and then apply these configurations as needed to any sensor within the infrastructure. The Windows NT version of the director (Cisco Secure Policy Manager) allows administrators to create configuration templates that can be applied to one or more sensors on the network.

Introduced earlier, Cisco offers two different director platforms, which are the following:

  • Cisco Secure Policy Manager (CSPM)

  • CIDS Director for UNIX

Cisco Secure Policy Manager (CSPM)

Cisco Secure Policy Manager is a Windows NT 4.0 based application that can be used to provide security policy management and enforcement for:

  • Cisco PIX firewalls

  • Cisco IOS routers with the firewall feature set

  • Cisco Secure Integrated virtual private network (VPN)

  • Cisco Intrusion Detection System Sensors

CSPM is a vast application, capable of managing an enterprise’s entire security infrastructure. Entire books can be written describing all the features and functions of CSPM, but this chapter only details the features and functions of CSPM as they relate to the director platform for CIDS.

Sensor Configuration with CSPM

CSPM provides a centralized GUI management platform for the distributed sensor architecture. Sensors can be added to the Network Topology Tree (NTT) using the Add Sensor Wizard within CSPM. Once the sensors are added, CSPM enables security administrators to remotely configure each sensor individually or as a group. Different configurations can be created and saved as a template, and these template configurations can then be applied to one or more sensors within the CIDS infrastructure.


The NTT is a directory containing objects that represent the network and security infrastructure equipment. Much like the active directory in Windows 2000, the NTT provides a graphical view of your network components. The purpose of the NTT is to communicate the locations of objects installed on the network to CSPM. NTT can then be used to locate, view, and configure those objects. Infrastructure equipment that should be defined in the NTT includes networks, gateways, sensors, directors, and hosts.

CSPM Event Viewer

The Event Viewer located in CSPM allows security administrators to view, in real time, all suspected intrusive activity on their network. The Event Viewer display has two primary panes: the Connection Status pane and the Grid pane. The Event Viewer can be customized through the use of configurable grids that permit multiple views and instances. The CSPM Event Viewer combines the organization of a spreadsheet and the usability of a browser into a hierarchical collection of audit events called a drillsheet. The drillsheet combines data of similar audit event records into the single row of a grid, enabling security administrators to detect patterns in the data.

Cisco Secure Intrusion Detection Director for UNIX

The intrusion detection Director for UNIX is an HP OpenView application that runs on Sun Solaris or HPUX. Like CSPM, the Director provides a GUI interface for centralized management across the distributed sensor architecture.

Sensor Configuration with CIDS Director for UNIX

The Director enables security administrators to create and save multiple configuration files. Once a configuration is created, it can be applied to any sensor reporting to the Director platform. The Configuration Management Utility (nrConfigure) component of the director is used to create and save configuration files for later use.

CIDS Director Alarm Display

Alarms are recorded and displayed in real time. The Director for UNIX uses an HP OpenView submap to provide a GUI interface for alarm viewing.

Comparing the Two Director Platforms

While the overall objective of both platforms is to provide a centralized management location for all IDS-related activity, CSPM and Director for UNIX offer different features and use different methods to accomplish the same goals. Alarm severities in CSPM are low, medium, and high, while the Director for UNIX has severities of 1 through 5. A severity of 1 represents the lowest severity and 5 represents the highest severity.

CSPM allows security administrators to create configuration templates that can be applied to one or more sensors. When the template is updated, all sensors referencing the template are also updated. The CIDS Director for UNIX allows security administrators to create and save multiple configurations, and then apply those configurations as needed. The CIDS Director for UNIX also has a configuration-versioning mechanism that CSPM doesn’t have. When a configuration is changed within the CIDS Director for UNIX, the current configuration is saved as a previous version, allowing security administrators to roll back to a previous version of a configuration. CSPM doesn’t offer this versioning feature.

A final feature supported in the CIDS Director for UNIX that isn’t supported in CSPM is SNMP. The CIDS director for UNIX can be configured to generate SNMP traps once an alarm is received. CSPM doesn’t generate SNMP traps based on alarms. Table 24-2 shows a feature comparison of the two CIDS director platforms.

Table 24-2: CSPM and Director for UNIX Comparison

Director Features


Director for UNIX

Severity Levels

Low, Medium, High

1 through 5

Configuration Templates



Configuration Versioning



Local Logging


Text file

SNMP Traps



Sensor Response

When a signature is matched, the Cisco IDS sensors can be configured to take preventative action to stop further intrusive activity. The Cisco Active Response System (CARS) allows the sensor to take control of other systems, such as routers, firewalls, and switches to terminate unauthorized sessions. Sensors can be configured to take different actions based on the configurable severity of the signature matched, so different responses could be configured for different signatures. The configuration of sensor responses is discussed in Chapter 25. The possible actions that can be configured on the sensors are the following:

  • Terminate the TCP session

  • Block the IP address of the attacking host

  • Create an IP session log

Terminating the TCP Session

The transport layer protocol, Transmission Control Protocol (TCP), provides a connection-oriented communication mechanism with a three-way handshake. Both hosts can terminate this connection-oriented communication by sending and receiving a TCP packet with the FIN bit set to 1 within the TCP header. Additionally, either host can send a TCP reset packet and force the connection between the hosts to be reset immediately.

A TCP reset packet has the RST bit set to 1 in the TCP header. When a reset packet is received by either host, the connection is terminated. Sensors can take advantage of this protocol feature and send a reset packet to the affected hosts, thereby terminating the connection.


The TCP reset action is only appropriate as an action selection on those signatures associated with a TCP-based service. If selected as an action on non-TCP-based services, no action is taken. Additionally, TCP resets aren’t guaranteed to tear down an offending session because of limitations in the TCP protocol.

While resetting the TCP connections is a powerful feature, some drawbacks occur with its use. TCP resets are only effective with communications using the TCP transport layer protocol. Communications using User Datagram Protocol (UDP) aren’t affected by TCP resets.

IP Blocking

“Device management” is the term used by Cisco to describe actions taken by the sensors to reconfigure other network infrastructure equipment, such as routers, firewalls, and switches. Sensors can be configured for device management, allowing them to automatically reconfigure ACLs on infrastructure equipment blocking an intruder’s IP address or an entire network address range. The blocking of IP addresses through device management is also known as shunning. As seen in Figure 24-9, the sensor can reconfigure the ACL on the perimeter router to block the intruders’ IP address.

Click To expand
Figure 24-9: Using Device Management to block an IP address

Perimeter routers are referred to as Blocking Routers. Sensors create and maintain a Telnet session to Blocking Routers to reduce the time required to publish the ACL rule sets that block traffic. IP blocking with the use of Device Management is also known as shunning.

IP blocking should be used cautiously. A hacker could take advantage of this response mechanism to perform a DoS attack. This DoS attack could be aimed at the IDS system itself or at other critical network infrastructure equipment. An intruder could spoof the address of an important server or director platform. Using the spoofed address, the intruder could launch an attack, causing the IDS system to block the IP address of the spoofed host. In essence, the hacker is forcing your IDS system to attack your own hosts, by blocking their IP address. Additionally, intruders might have multiple hosts at their disposal and can continue scanning, probing, and attacking your network from hosts that haven’t yet been blocked. IP blocking could also be initiated manually from the director platform once an attack is discovered.

IP Logging

IP session logs can be used to gather information about the suspected intrusive activity. When a signature has been configured for IP logging and that signature is matched, the sensor begins writing every incoming and outgoing packet to a session log. Security administrators can configure how long the sensor should continue to perform IP logging after the signature was matched.

Part III: Virtual Private Networks (VPNs)