CIDS Operations and Functionality

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:

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:

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:

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.

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

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.

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.

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.

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.

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.

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.

Note?

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.

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.”

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.

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.

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.

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.

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.

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

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.