Cisco Secure IDS is a network-based intrusion detection system that uses a signature database to trigger intrusion alarms. The system is composed of sensors that perform the real-time monitoring of network packets and a Director platform that provides the management software used to configure, log, and display alarms generated by sensors. Cisco Secure IDS supports two Director platforms:
- Cisco Secure Policy Manager (CSPM)
- Cisco Secure IDS Director for UNIX
Cisco Secure IDS Sensors are available in two distinct platforms. The 4200 Series Sensors are network appliances that can be deployed throughout your network. (See Chapter 7, "4200 Series Sensor Installation Within CSPM.") The Intrusion Detection System Module (IDSM) for the Catalyst 6000 family of switches is a sensor that resides on a blade in your Catalyst 6000 family switch. (See Chapter 14, "Catalyst 6000 IDS Module Configuration.") A final IDS monitoring device is the Cisco IOS Firewall IDS. This platform enables you to change your router into an IDS monitoring device. (See Chapter 17, "Cisco IOS Firewall Intrusion Detection System.")
All Cisco Secure IDS Sensors have two interfaces:
- Command and control
Sensors monitor network traffic for alarms in real time through the monitoring interface. All alarms are then transmitted through the command and control interface to the Director platform.
When Cisco Secure IDS analyzes network data, it looks for patterns of attacks. Patterns can be as simple as an attempt to access a specific port on a specific host, or as complex as sequences of operations directed at multiple hosts over an arbitrary period of time.
This chapter covers the following aspects of Cisco Secure IDS:
- System function and features
- Sensor platforms and modules
- Director platforms
- Cisco Secure IDS and the PostOffice protocol
System Function and Features
Cisco Secure IDS is network-based IDS that compares network traffic against known intrusive signatures to define network attacks. It is composed of two major components:
- Director platform
The Cisco Secure IDS communications infrastructure handles communication between these two components and represents another major aspect of Cisco Secure IDS.
The basic Cisco Secure IDS process is as follows (refer to Figure 4-1):
A sensor captures network packets through its monitoring interface.
Packets are reassembled, if required, and compared against a signature indicating typical intrusion activity.
If an attack is detected, the sensor logs the attack and notifies the Director platform through the command and control interface.
The Director platform displays the alarms, logs the data, and takes action on attacks detected by a sensor.
You can program your sensors to respond in various ways upon alarm detection. This response is configurable based on the severity of the attack discovered. The possible responses are as follows:
- TCP reset
- IP blocking
- IP logging
The TCP reset response essentially kills the current TCP connection from the attacker by sending a TCP reset packet (see Figure 4-2). This response is effective only for TCP-based connections. UDP traffic, for example, is unaffected by TCP reset packets.
Figure 4-1 Basic Cisco Secure IDS Configuration.
TCP Reset Packets
The Transmission Control Protocol (TCP) provides a connection-oriented communication mechanism. The connection is established through a three-way handshake. To terminate a connection, each side of the connection can send a FIN packet, signaling the end of the connection. It also is possible for one side of the connection to abruptly terminate the connection by sending a TCP reset packet (a packet with the RST flag set) to the other side. The sensor uses this approach to terminate an attacker TCP connection. For a detailed explanation of TCP/IP protocols, refer to TCP/IP Illustrated Volume 1: The Protocols (W. Richard Stevens, Addison-Wesley).
Figure 4-2 TCP Reset Sensor Response.
With the IP blocking option, the sensor updates the access control list (ACL) on the perimeter router to deny all traffic from the offending IP address (see Figure 4-3). This response prevents the attacker from sending any further traffic into the protected network from that specific host. (Refer to Chapter 13, "IP Blocking Configurations," for a detailed description on IP blocking.)
Note that if an attacker has multiple compromised hosts at his disposal, he can keep launching attacks from machines that have not been blocked yet. Furthermore, some attacks enable the attacker to spoof the source host from which he appears to be coming. Against this type of attack, the IP blocking option is ineffective because the attacker can always choose a new source address for his attack traffic. (Refer to Chapter 1, "Need for Network Security," for more information on different attack methods.)
Figure 4-3 IP Blocking Response.
Blocking requires careful review before it is deployed, whether as an automatic response or through operational guidelines for the operators. To implement blocking, the sensor dynamically reconfigures and reloads a Cisco IOS router's ACL. This type of automated response by the sensor needs to be configured only for attack signatures with a low probability of false-positive detection. In case of any suspicious activity that does not trigger automatic blocking, you can use the Director platform to block manually. Cisco Secure IDS can be configured to never block specific hosts or networks. This safety mechanism prevents denial of service (DoS) attacks against the Cisco Secure IDS and other infrastructure components.
Using IP Blocking as a DoS Attack Vehicle
An attacker has a couple of ways in which he can use your own IP blocking response to attack your network. First, he can launch an attack, pretending to be an important host on your network or one of your business partners' networks. When you detect the attack and invoke IP blocking, you generate a DoS against that host. If this host is critical to your network, the DoS significantly disrupts the operation of your network. Another DoS situation is when an attacker launches an attack from a multiuser machine. In this scenario, all users on that machine are blocked, not just the attacker.
The third response, IP logging, records in a session log file what the attacker is doing (see Figure 4-4). This option is passive and does not prevent the attacker from continuing his attack. The logged information provides a record of what the attacker does against the network.
Figure 4-4 IP Logging Response.