Foundation and Supplemental Topics

Cisco Intrusion Prevention Solution

Proactively protecting your network resources is the latest trend in security. Most Intrusion Detection Systems (IDS) passively monitor your network for signs of intrusive activity. When intrusive activity is detected, the IDS provides the capability to block further intrusive activity from the suspect host. This reactive approach does not prevent the initial attack traffic from reaching the targeted device. An Intrusion Prevention System (IPS), however, can proactively stop even the initial attack traffic. This chapter provides an overview of the Cisco IPS solution by focusing on the following topics:

• Intrusion Prevention Overview

• Cisco Intrusion Prevention System Hardware

• Inline Mode Versus Promiscuous Mode

• Software Bypass

• Cisco Sensor Deployment

• Cisco Sensor Communications Protocols

Intrusion Prevention Overview

Since intrusion prevention is a relatively new technology, it is helpful to review how it differs from a traditional IDS and to explain the terms commonly used in discussions on this subject. This review and explanation will be covered by the following topics:

• Intrusion-Prevention Terminology

• IPS/IDS Triggers

• IPS/IDS Monitoring Locations

• Cisco Hybrid IPS/IDS Solution

• Risk Rating

• Meta-Event Generator

• Inline Deep-Packet Inspection

Intrusion-Prevention Terminology

Table 1-2 describes the primary terms that are used to describe the functionality of the Cisco IPS solution.

Table 1-2. Primary IPS Terminology

Terminology	Description
Inline mode	Examining network traffic while having the ability to stop intrusive traffic from reaching the target system
Promiscuous mode	Passively examining network traffic for intrusive behavior
Signature engine	An engine that supports signatures that share common characteristics (such as same protocol)
Meta-Event Generator	The capability to define meta signatures based on multiple existing signatures
Atomic signature	A signature that triggers based on the contents of a single packet
Flow-based signature	A signature that triggers based on the information contained in a sequence of packets between two systems (such as the packets in a TCP connection)
Behavior-based signature	A signature that triggers when traffic deviates from regular user behavior
Anomaly-based signature	A signature that triggers when traffic exceeds a configured normal baseline
False negative	A situation in which a detection system fails to detect intrusive traffic although there is a signature designed to catch that activity
False positive	A situation in which normal user activity (instead of intrusive activity) triggers an alarm
True negative	A situation in which a signature does not fire during normal user traffic on the network
True positive	A situation in which a signature fires correctly when intrusive traffic for that signature is detected on the network (The signature correctly identifies an attack against the network.)
Deep-packet inspection	Decoding protocols and examining entire packets to allow for policy enforcement based on actual protocol traffic (not just a specific port number)
Event correlation	Associating multiple alarms or events with a single attack
Risk rating (RR)	A threat rating based on numerous factors besides just the attack severity

Note

Some systems refer to promiscuous mode as passive mode. Both of these terms refer to passively examining network traffic.

IPS/IDS Triggers

The purpose of any IPS/IDS is to detect when an intruder is attacking your network. Not every IDS/ IPS, however, uses the same triggering mechanisms to generate intrusion alarms. There are three major triggering mechanisms used by current intrusion systems:

• Anomaly detection

• Misuse detection

• Protocol analysis

Note

Triggering mechanisms refer to the action that causes the IDS/IPS to generate an alarm. The triggering mechanism for a home burglar alarm could be a window breaking. A network IDS may trigger an alarm if it sees a packet to a certain port with specific data in it. A host-based IPS/ IDS may generate an alarm if a certain system call is executed. Anything that can reliably signal an intrusion can be used as a triggering mechanism.

Anomaly Detection

Anomaly detection is also sometimes referred to as profile-based detection. With anomaly detection, you must build profiles that define what activity is considered normal. These profiles can be learned over a period of time or they can be modeled on historical behavior. After defining which traffic or activity is considered normal, then anything that deviates from this normal profile generates an alert (since it is abnormal).

The main advantage of anomaly detection is that the alarms generated are not based on signatures for specific known attacks. Instead, they are based on a profile that defines normal user activity. Therefore, an anomaly-based intrusion system can generate alarms for previously unpublished attacks, as long as the new attack deviates from normal user activity by a significant amount.

Misuse Detection

Misuse detection, also known as signature-based detection, looks for intrusive activity that matches specific signatures. These signatures are based on a set of rules that match typical patterns and exploits used by attackers to gain access to your network. Highly skilled network engineers research known attacks and vulnerabilities to develop the rules for each signature.

Some of the benefits of misuse detection are as follows:

• Signatures are based on known intrusive activity

• Attacks detected are well defined

• System is easy to understand

• Detects attacks immediately after installation

Protocol Analysis

The final triggering mechanism is a variation on misuse detection. Misuse detection is looking for a specific attack signature in your network traffic. With protocol analysis, the IPS/IDS analyzes the data stream based on the normal operation of a specific protocol. Therefore, the intrusion system is verifying the validity of the packets with respect to the protocol definition and then looking for specific patterns in the various fields of the protocol or a packet's payload. This in-depth analysis utilizes a protocol's Request for Comments (RFC) as a baseline and focuses on two major areas:

• Verifying validity of packet (based on protocol RFC)

• Checking the contents of payload

Using protocol analysis, not only must the attack traffic match a valid packet for the protocol in question, but it must also then contain known attack traffic in the payload or protocol fields of the packet.

IPS/IDS Monitoring Locations

Now that you have a basic understanding of the intrusive activity that can generate alarms from your intrusion system, it is time to examine where your IPS/IDS watches for this intrusive traffic. The major IPS/IDS monitoring locations are as follows:

• Host-Based

• Network-Based

Host-Based

Host-based intrusion systems check for malicious activity by checking information at the host or operating system level. These intrusion systems examine many aspects of your host, such as system calls, audit logs, error messages, and so on.

Since a host-based IPS/IDS examines traffic after it reaches the target of the attack (assuming the host is the target), it has first hand information on the success of the attack. With a network-based intrusion system, the alarms are generated on known intrusive activity, but only a host-based intrusion system can determine the actual success or failure of an attack.

Network-Based

A network-based intrusion system examines packets traversing the network to locate attacks against the network. The network-based IDS sniffs the network packets and compares the traffic against signatures for known intrusive activity. A network-based IPS actually checks network traffic for malicious activity while functioning as a Layer-2 forwarding device.

Note

To sniff network packets means to examine all of the packets that are traveling across the network. Normally, a host only examines packets that are addressed to it specifically, along with packets that are broadcast to all of the hosts on the network. To be capable of seeing all of the packets on the network, the IDS must place the network interface card (NIC) into promiscuous mode. While in promiscuous mode, the NIC examines all packets regardless of their destination address.

A network-based intrusion system (compared to a host-based solution) has the following benefits:

• Overall network perspective

• Does not have to run on every OS on the network.

By viewing traffic destined for multiple hosts, a sensor receives a network perspective in relation to the attacks against your network. If someone is scanning multiple hosts on your network, this information is readily apparent to the sensor.

Another advantage to a network-based intrusion system is that it does not have to run on every OS in the network. Instead, a network-based intrusion system relies on a limited number of sensor devices to capture network traffic. Managing these various sensor platforms is accomplished through a couple of management platforms. Based on specific performance requirements, you can choose different sensor platforms to provide complete coverage of your network. Furthermore, these sensing devices can easily be hardened to protect them from attack, since they serve a specific purpose on the network.

Cisco Hybrid IPS/IDS Solution

IDSs passively monitor network traffic for intrusive activity. When intrusive activity is detected, the sensor can reset TCP connections and block future traffic from the attacking system. The initial attack packet, however, will still reach the target system. In Cisco IPS version 5.0, this mode of operation is known as promiscuous mode. It requires only a single sensor interface to monitor each network location.

With intrusion prevention, your sensor functions as a layer 2 forwarding device on your network. In Cisco IPS version 5.0, this mode of operation is known as inline mode and requires allocating two sensor interfaces (known as an interface pair) at each monitoring point in your network. The major advantage of intrusion prevention is that network traffic is examined in line, enabling your sensor to drop all intrusive packets before they reach the target system, as well as resetting TCP connections and blocking future traffic from the attacking system.

Cisco IPS version 5.0 enables you to operate your sensors in both modes of operation simultaneously. For instance, if your sensor has four monitoring interfaces, your system can operate in the following configurations:

• 2 interface pairs (both inline)

• 1 interface pair, 2 promiscuous interfaces

• 4 promiscuous interfaces

Depending on your network topology, you may want to combine inline processing and promiscuous processing to create a hybrid security protection solution. Inline processing works well in situations in which all of the traffic being examined goes through a single location (such as the Internet entry point into your network). Promiscuous mode works better than inline mode in situations in which the number of paths makes inline processing prohibitive (such as when traffic is monitored between numerous hosts on a single subnet). In promiscuous mode, your system can monitor all of this host-to-host traffic by using a traffic capture mechanism such as a Switched Port Analyzer (SPAN), whereas inline mode requires a sensor between each host pair.

Note

The Cisco hybrid IPS solution also includes a host-based component through the Cisco Security Agent (CSA) product. Discussion of this product is out of the scope of this book. For more information on CSA refer to the documentation at Cisco.com (http://www.cisco.com/en/US/products/sw/secursw/ps5057/index.html) or the Cisco Press book Cisco Security Agent (ISBN: 1-58705-205-9).

Risk Rating

One of the limiting factors associated with IDSs is false positive alarms. False positives generate more work for your security analysts and can reduce their confidence in the alarms that the intrusion system identifies. To reduce the probability of false positives, Cisco IPS version 5.0 calculates a risk rating (RR) for alerts from 0 to 100 (with 100 being the most severe). The RR is calculated according to not just the severity of the attack but also the following factors:

• Event severity

• Signature fidelity

• Asset value of target

Each of these factors is discussed in the following sections.

Event Severity

The event severity is also known as the attack severity or the alert severity. This value weights the RR based on the severity of a successful exploitation of the vulnerability. The event severity can be one of the following values (listed from most severe to least severe):

• High

• Medium

• Low

• Informational

Signature Fidelity

The signature fidelity weights the RR based on how well the signature might perform in the absence of specific knowledge of the target. This value is a numeric value between 0 and 100 (with 100 being the highest fidelity). Signatures that are based on very specific rules will have a higher signature fidelity value than signatures based on more generic rules. For instance, consider the two Cisco IPS 5.0 signatures shown in Table 1-3:

Table 1-3. Sample Signature Fidelity Ratings

Signature ID	SubSignature ID	Signature Name	Signature Fidelity
5406	0	Illegal MHTML URL	72
5406	1	Illegal MHTML URL	0

These signatures are designed to detect illegal MHTML URLs in a monitored connection. The signature with a SubSignature ID of 0 examines web traffic (to port 80), and the signature with a SubSignature ID of 1 examines e-mail traffic (to port 25). Assume that you treat the fidelity rating as a percentage indicating the likelihood that the signature detected the traffic that it is designed to identify (not a false positive).

Based solely on the signature fidelity, there is an approximately 72 percent likelihood that the traffic is not a false positive when the web signature triggers. The e-mail signature, on the other hand, has a fidelity rating of 0, indicating that without any target specific information the alarm is almost guaranteed to be a false positive.

Note

MIME (Multipurpose Internet Mail Extension) encapsulation of aggregate documents such as HTML (MHTML) is an Internet standard (RFC 2557) that defines a mechanism to enable a protocol to retrieve a complete multiresource HTML multimedia document in a single transfer. Although originally developed for e-mail messages, MHTML can also be employed by protocols such as HTTP and FTP.

Note

Signature fidelity is calculated by the signature author on a per-signature basis.

Asset Value of Target

The final weight, also known as the target-value rating, is based on the perceived value of the target. This value is user-configurable based on the IP address. You can assign one of the following values (listed in order, from lowest to highest priority) to a specific IP address or range of addresses:

• No value

• Low

• Medium

• High

• Mission critical

The assignment of values to systems is a subjective process. The important point is that the asset values enable you prioritize the devices on your network based on their perceived value. For instance, you may use the following classification model:

• Mission critical Server systems

• High Infrastructure systems

• Low Desktop systems

• No value Guest laptops

Meta-Event Generator

Suppose that you determine that a worm attack against your network will trigger five distinct signatures. Traditionally, to detect this worm, your security analyst must sift through all of the alarms detected by the IDS and then determine which of those individual events represent the worm attack.

With the Meta-Event Generator (MEG), you can perform this event correlation at the sensor level. Assume that a specific worm attack causes five distinct signatures to fire when it is launched against your network. If worm attacks are bombarding your network, then the number of alarms being generated is extensive (since each worm attack instance triggers multiples alarms). Using MEG, you can decrease the severity of the individual signatures that the worm triggers and use a meta-event to identify only instances of the worm attack.

Inline Deep-Packet Inspection

By definition, IDS and IPS solutions incorporate signatures that trigger based on information that is located throughout the packet. Inline deep-packet inspection refers to the ability to perform actual protocol analysis on network traffic. Many applications (including malicious programs) attempt to use open ports to pass information through access control lists on your network. Using inline deeppacket inspection enables you to enforce your security policy beyond basic port numbers. For instance, this functionality enables you to prevent attackers (and applications) from sending traffic to or from port 80 unless the traffic is legitimate HTTP traffic.

Cisco Intrusion Prevention System Hardware

Cisco provides a wide range of intrusion detection devices. Having multiple sensor platforms enables you to decide the best location within your network to monitor for intrusive activity. Cisco provides the following types of sensor platforms:

• Cisco IDS 4200 series network sensors

• Cisco IDSM-2 module for Catalyst 6500

• Cisco IDS network module for access routers

• Router sensor

• Firewall sensor

Cisco IDS 4200 Series Network Sensors

You must understand the features, connections, and interfaces on the different appliance models when installing these devices on your network. Knowing the bandwidth limitations will help you determine which appliance model matches your network environment. The following models will be examined in detail:

• IDS 4215

• IDS 4235

• IDS 4240*

• IDS 4250

• IDS 4250XL

• IDS 4255*

Note

The sensors marked by * are the appliance sensors most recently added to the Cisco IPS solution. These sensors use flash memory for storage instead of a regular hard disk. Using flash memory is more reliable than using a hard disk since flash memory has no moving parts.

Cisco 4215 Appliance Sensor

The low-end sensor is the IDS 4215. Its capabilities are as follows:

• Performance 80 Mbps

• Monitoring interface 10/100BASE-TX

• Command and control interface 10/100BASE-TX

• Optional interface 4 10/100BASE-TX

• Performance upgrade Not available

The features on the front of the IDS 4215 sensor are shown in Figure 1-1.

Figure 1-1. IDS 4215 Front Panel

Most of the connections are located on the back of the IDS 4215, including the two Ethernet interfaces (see Figure 1-2). The command and control interface is on the right, whereas the monitoring interface is on the left. The monitoring interface is FastEthernet0/0.

Figure 1-2. IDS 4215 Back Panel

Note

When you use the optional four-port interface, the additional monitoring interfaces are (from left to right) FastEthernet1/0, FastEthernet1/1, FastEthernet1/2, and FastEthernet1/3.

The performance of the Cisco IDS 4215 sensor is based on the following factors:

• 800 new TCP connections per second

• 800 HTTP connections per second

• Average packet size of 445 bytes

• Presence of Cisco IDS software version 4.1 or greater

Cisco 4235 Appliance Sensor

The following are the technical specifications for the Cisco IDS 4235 sensor:

• Performance 250 Mbps

• Monitoring interface 10/100/1000BASE-TX

• Command and control interface 10/100/1000BASE-TX

• Optional interface 4 10/100BASE-TX

• Performance upgrade Not available

The connections are on the back of the IDS 4235 (see Figure 1-3). The command and control interface is on the left (labeled 2), whereas the monitoring interface is on the right (labeled 1). The monitoring interface is FastEthernet0/0.

Figure 1-3. IDS 4235 Back Panel

The performance of the Cisco IDS 4235 sensor is based on the following factors:

• 3000 new TCP connections per second

• 3000 HTTP connections per second

• Average packet size of 445 bytes

• Presence of Cisco IDS software version 4.1 or greater

Cisco 4240 Diskless Appliance Sensor

The following are the technical specifications for the Cisco IDS 4240 sensor:

• Performance 250 Mbps

• Monitoring interface 4 10/100/1000BASE-TX

• Command and control interface 10/100/1000BASE-TX

• Optional interface 4 10/100BASE-TX

• Performance upgrade Not available

The connections are on the back of the IDS 4240 (see Figure 1-4). The command and control interface is on the left above the USB ports. The four monitoring interfaces are near the middle on the bottom (when interface 0 is on the right). The monitoring interfaces are GigabitEthernet0/0 and GigabitEthernet0/3.

Figure 1-4. IDS 4240 Back Panel

The performance of the Cisco IPS 4240 appliance is based on the following factors:

• 2500 new TCP connections per second

• 2500 HTTP connections per second

• Average packet size of 445 bytes

• Presence of Cisco IDS software version 4.1 or greater

Cisco 4250 Appliance Sensor

The following are the technical specifications for the Cisco IDS 4250 sensor:

• Performance 500 Mbps

• Monitoring interface 10/100/1000BASE-TX

• Command and control interface 10/100/1000BASE-TX

• Optional interface 1000BASE-SX (fiber) or 4 10/100BASE-TX

• Performance upgrade Yes

The connections on the back of the IDS 4250 are identical to those on the IDS 4235 (see Figure 1-3). The command and control interface is on the left (labeled 2), whereas the monitoring interface is on the right (labeled 1). The monitoring interface is GigabitEthernet0/0.

The performance of the Cisco IDS 4250 sensor is based on the following factors:

• 5000 new TCP connections per second

• 5000 HTTP connections per second

• Average packet size of 445 bytes

• Presence of Cisco IDS software version 4.1 or greater

Cisco 4250XL Appliance Sensor

The following are the technical specifications for the Cisco IDS 4250XL sensor:

• Performance 1000 Mbps

• Monitoring interface Dual 1000BASE-SX interface with MTRJ

• Command and control interface 10/100/1000BASE-TX

• Optional interface 1000BASE-SX (fiber)

• Performance upgrade Not available

The connections located on the back of the IDS 4250XL are identical to those on the IDS 4235 and IDS 4250, with the exception of the IDS Accelerator (XL) Card (see Figure 1-5). The command and control interface (labeled 2) is the leftmost of the two built-in interfaces, whereas the TCP Reset interface (labeled 1) is the built-in interface on the far right. The monitoring interface is the IDS Accelerator Card ports. The monitoring interfaces are GigabitEthernet1/0 and GigabitEthernet1/1.

Figure 1-5. IDS 4250XL Back Panel

The performance of the Cisco IDS 4250XL sensor is based on the following factors:

• 5000 new TCP connections per second

• 5000 HTTP connections per second

• Average packet size of 595 bytes

• Presence of Cisco IDS software version 4.1 or greater

Cisco 4255 Diskless Appliance Sensor

The following are the technical specifications for the Cisco IDS 4255 sensor:

• Performance 600 Mbps

• Monitoring interface 4 10/100/1000BASE-TX

• Command and control interface 10/100/1000BASE-TX

• Optional interface 1000BASE-SX (fiber) or 4 10/100BASE-TX

• Performance upgrade Yes

The connections on the back of the IDS 4255 are identical to those on the IDS 4240 (see Figure 1-4). The command and control interface is on the left, above the USB ports. The four monitoring interfaces are near the middle on the bottom (when interface 0 is on the right). The monitoring interfaces are GigabitEthernet0/0 and GigabitEthernet0/3.

The performance of the Cisco IPS 4255 appliance is based on the following factors:

• 6000 new TCP connections per second

• 6000 HTTP connections per second

• Average packet size of 445 bytes

• Presence of Cisco IDS software version 4.1 or greater

Cisco IDSM-2 for Catalyst 6500

The following are the technical specifications for the Cisco IDSM-2 (IDS Module 2) for Catalyst 6500:

• Performance 600 Mbps

• Built-in interfaces 2 10/100/1000BASE-TX

• Command and control interface 10/10 10/100BASE-TX

• Optional interface Not available

• Performance upgrade Not available

The performance of the Cisco IDSM-2 is based on the following factors:

• 4000 new TCP connections per second

• Average packet size of 450 bytes

• Presence of Cisco IDS software version 4.1 or greater

Note

For more information on the IDSM-2 for Catalyst 6500, refer to Chapter 13, "Cisco IDS Module (IDSM)," in the section titled "IDSM-2 Technical Specifications."

Cisco IDS Network Module for Access Routers

The IDS network module for access routers deploys sensor functionality in low-end routers such as the Cisco 2600XM, 2691, 3660, and 3700 series routers. The following are the technical specifications for the Cisco IDS network module for access routers:

• Performance Up to 45 Mbps

• Monitoring interface Router internal bus

• Command and control interface 10/10 10/100BASE-TX

• Optional interface Not available

• Performance upgrade Not available

The performance of the IDS network module for access routers is based on the following factors:

• 500 new TCP connections per second

• 500 HTTP connections per second

• Average packet size of 445 bytes

• Presence of Cisco IDS software version 4.1 or greater

Note

For more information on the network module, refer to Chapter 14, "Cisco IDS Network Module for Access Routers."

Router Sensor

The router sensor (Cisco IOS IDS) incorporates intrusion-detection functionality into the IOS software. Cisco IOS IDS can detect a limited subset of attacks that are detectable by the appliance sensor. The software and hardware requirements for Cisco IOS IDS are as follows:

• Cisco IOS software release 12.0(5)T or greater

• Cisco 830, 1700, 2600, 3600, 7100, 7200, or 7500 series routers

Note

Beginning with Cisco IOS software release 12.3(T), Cisco IOS IDS uses the same signature engines that are available with the appliance sensors. Although with Cisco IOS IDS you cannot check for all of the signatures that can be checked with an appliance sensor (because of performance reasons), you can identify a limited set of signatures to check (choosing from virtually all of the signatures available on the appliance sensor). You can also create custom signatures that can be addressed in your specific network environment.

Firewall Sensor

The firewall sensor (PIX Firewall IDS) integrates IDS functionality into PIX Firewall software. A PIX Firewall IDS can detect only a fixed subset of attacks that are detectable by the appliance sensor. The software and hardware requirements for using PIX Firewall IDS are as follows:

• PIX Firewall software, version 5.2 or greater

• PIX models 501, 506E, 515E, 525, or 535

Inline Sensor Support

Beginning with version 5.0, Cisco sensor software supports attack prevention by operating in inline mode. The following Cisco IDS sensors support inline mode:

• IDS 4215

• IDS 4235

• IDS 4240

• IDS 4250

• IDS 4255

• IDSM-2

Note

Inline functionality is currently not supported on the network module.

Inline Mode Versus Promiscuous Mode

An Intrusion Detection System (IDS) passively monitors network traffic at multiple locations within your network by using IDS sensors. This monitoring is referred to as promiscuous mode because it involves placing a network interface into promiscuous mode and then examining all of the traffic through the interface. Promiscuous interfaces are virtually invisible on the network because they are associated with no IP address.

When intrusive activity is detected, the IDS can generate an alarm. The IDS can also usually be configured to take reactive measures such as the following:

• TCP connection reset

• IP blocking

• IP logging

Note

For detailed explanations of IDS signature responses, refer to Chapter 9, "Cisco IPS Response Configuration."

Although these reactive measures can prevent further intrusive activity, the initial intrusive traffic still reaches, and can compromise, the target system.

An Intrusion Prevention System (IPS) also monitors network traffic by using sensors at specific locations throughout your network. These sensors, however, can be configured to examine traffic in inline mode. In inline mode, a pair of sensor interfaces serves as a layer-2 gateway for network traffic. Normal network traffic packets are received on one interface and then transmitted to the other interface (simulating the network wire). The sensor, however, examines the packets received on either inline interface. If the examined traffic triggers signatures that are enabled on the sensor, the sensor can drop the packets instead of transmitting them through the outbound interface (if that is the action configured for the signature). Therefore, a sensor operating in inline mode can drop intrusive traffic before it reaches the target system.

Software Bypass

A sensor operating in inline mode can disrupt the operation of your network if the sensor's analysis engine stops operating for some reason (since it would no longer be passing network traffic). To prevent a disruption (caused by the sensor no longer passing network traffic), the Cisco IPS sensor software provides a bypass mechanism that kicks in when a failure or stoppage occurs. The bypass can be configured to operate in one of the following modes:

• Auto

• Off

• On

Auto Mode

In Auto mode (also known as Fail Open mode), a sensor running in inline mode will continue to forward traffic even if the sensor's analysis engine stops processing traffic. Although this traffic is not inspected by the sensor, the network is still operational. Auto mode is useful on networks in which continued operation of the network takes highest priority.

Off Mode

In Off mode (also known as Fail Close mode), a sensor running in inline mode will stop forwarding traffic if the sensor's analysis engine software fails or stops. Since the sensor stops forwarding traffic, none of the traffic is allowed to pass the sensor without inspection. Off mode is useful on networks in which the security of the network takes highest priority.

On Mode

In On mode, a sensor running in inline mode will always forward traffic without inspecting it. This mode is useful in debugging situations in which you want to configure the sensor to forward traffic without inspecting the traffic.

Cisco Sensor Deployment

Cisco IPS supports various sensor platforms. Each platform has varying capabilities and is designed to operate in a specific network environment. You need to consider the following factors when deciding where to place sensors on your network:

• Internet boundaries

• Extranet boundaries

• Intranet boundaries

• Remote access boundaries

• Servers and desktops

Figure 1-6 shows a sample network with IPS sensors monitoring key functional boundaries (Internet boundaries, extranet boundaries, remote access boundaries, and so on) in the network.

Figure 1-6. Deploying Sensors at Common Functional Boundaries

By carefully analyzing your network topology, you can identify the locations at which your Cisco IPS should monitor the traffic flow. Then you can determine which Cisco IPS sensor is appropriate for each monitoring location that you have identified (as well as if you want to monitor with promiscuous or inline mode).

Internet Boundaries

Sensor 1 in Figure 1-6 monitors the perimeter of the network. All traffic traveling to and from the untrusted network is visible to this sensor. In most networks, perimeter protection refers to the link between your network and the Internet. Instead of monitoring the traffic outside the firewall, sensor 2 examines only the traffic that actually passes through the firewall. This can reduce the amount of traffic that the sensor must process. Sensor 2 also operates in inline mode so that it can prevent intrusive traffic from entering the network.

Note

Be sure to locate all Internet connections to your network. Many times, administrators forget that remote sites contain Internet connections. Departments within your network may have their own Internet connection, separate from the corporate Internet connection. Any connection to the Internet needs to be properly monitored.

Extranet Boundaries

Sensor 3 in Figure 1-6 is another inline sensor. It is positioned so that it can monitor the traffic traversing the link between your network and your business partner's network. This extranet link is only as strong as the security applied to either of the networks that it connects. If either network has weak security, the other network becomes vulnerable as well. Therefore, extranet connections need to be monitored. Because the IPS sensor monitoring this boundary can detect attacks in either direction, you might consider sharing the expense of this sensor with your business partner.

Intranet Boundaries

Sensor 4 in Figure 1-6 monitors traffic between the engineering network and the finance network. This is an example of a sensor monitoring traffic between separate network segments within a larger network. Many times organizations use intranets to divide their network into functional areas, such as engineering, research, finance, and human resources. At other times, organizations drive the boundary definitions. Sometimes both of these classifications define intranet boundaries.

In this example, the engineering network is separated from the finance network (and the router that separates the other networks) by its own router. A firewall is also commonly used to increase security. In either situation, you can use a sensor to monitor the traffic between the networks and to verify that the security configuration (for the firewall or router) is defined correctly. Traffic that violates the security configuration generates alerts, which you can use as a signal to update the configuration of the firewall or router because it is enforcing the security policy.

Remote Access Boundaries

Sensor 5 in Figure 1-6 monitors traffic from the dialup access server. Do not assume that dialup lines are safe because a hacker could not determine the phone numbers of your dialup modems; war dialers are freely available on the Internet. Furthermore, many remote users use home computers that are continuously connected to the Internet through high-speed Internet connections. An attacker who compromises one of these home systems can easily penetrate your remote access server.

Note

A war dialer is a tool that dials a specified range of phone numbers, looking for modem connections. Attackers can start a war dialer on their computer and let it run for days to locate potential modem connections. Hackers can then connect to an identified modem phone number and can infiltrate networks whose connections have weak authentication mechanisms.

Servers and Desktops

With the current Cisco host-based sensors, you can deploy intrusion-prevention functionality on your servers and desktop systems. Each host-based sensor is actually a software agent that runs on the individual systems on your network, serving as a security barrier around each host. These agents provide a final layer of security that can help protect your network from attack.

Sensor Deployment Considerations

Deploying Cisco IPS on your network requires a well-thought-out design to maximize its effectiveness. Besides the basic sensor capabilities and placement, you must also consider the following design issues when deploying Cisco IDS on your network:

• Sensor placement

• Sensor management and monitoring options

• Number of sensors

• External sensor communications

Sensor Placement

When you place an IPS sensor in front of a firewall (on the Internet, or external, side of the firewall), you allow the IPS sensor to monitor all incoming and outgoing network traffic. However, when deployed in this manner, the IPS sensor does not detect internal network traffic (such as traffic between two internal hosts). An internal attacker taking advantage of vulnerabilities in internal network services would remain undetected by the external IPS sensor. Placing an IPS sensor (a monitoring or sniffing interface) behind a firewall shields the IPS sensor from any policy violations that the firewall rejects.

Sensor Management and Monitoring Options

Each of your Cisco IPS sensors monitors network traffic at a specific location in your network. You must also, however, be able to communicate with your sensors by using their command and control interface. This communication path enables you to configure and manage your sensors as well as to retrieve alarm events for monitoring and reporting. The Cisco IPS 5.0 communication protocol uses Transport Layer Security (TLS) or Secure Sockets Layer (SSL) and Extensible Markup Language (XML) to provide a standardized interface between Cisco IPS devices. You have two options with respect to your sensor management:

• Out-of-band management network

• In-band management network

Number of Sensors

The number of sensors that you plan to deploy on your network will dictate how many management consoles you will need to also deploy to configure and manage your Cisco IPS Sensors. Each management solution is designed to effectively manage a specific number of sensors. The two management solutions for Cisco IPS version 5.0 are as follows:

• IDS Device Manager (IDM)

• IDS Management Center (IDS MC)

Note

IDS Management Center support for Cisco IPS version 5.0 sensors requires IDS MC release 3.0.

IDM enables you to configure a single sensor. This software is provided with Cisco IDS sensors that provide full IDS functionality. IDS MC, on the other hand, enables you to configure up to 300 sensors from one management system.

As the number of sensors deployed on your network increases the amount of work needed to monitor alerts, apply signature updates, and manage the sensors also increases. This increased workload may require a larger support staff than the workload that results from smaller sensor deployments.

External Sensor Communications

Traffic on the communication port between sensors and external systems must be allowed through firewalls to ensure functionality. Most of this communication passes through either TCP port 443 (TLS/SSL) or TCP port 22 (Secure Shell [SSH]).

Cisco Sensor Communications Protocols

Communication between your Cisco IPS sensors and other network devices involves the following protocols and standards:

• SSH

• TLS/SSL

• RDEP

• SDEE Standard

Secure Shell

SSH provides a protocol for secure access to remote devices by encrypting the communication session (refer to http://www.ietf.org/html.charters/secsh-charter.html for more information). SSH is the secure replacement for Telnet, since Telnet transmits its session information in an unencrypted form.

Transport Layer Security (TLS)/Secure Socket Layer (SSL)

The TLS/SSL protocol provides communication privacy (encryption) over the Internet, allowing client/server applications to communicate in a way that prevents eavesdropping, tampering, and message forgery. RFC 2246 details the TLS protocol.

Remote Data Exchange Protocol

Besides communicating between different applications or processes located on your sensor, your sensor must also communicate with your network's other Cisco IPS components, such as Security Monitor. RDEP handles all sensor communications to and from external systems. It uses HTTP and TLS/SSL to pass XML documents (over an encrypted session) between the sensor and external systems. XML files on the sensor control the configuration and operation of your sensor.

Each RDEP message consists of an HTTP header section followed by an optional entity, or message body. Event and transaction message entity bodies consist of XML documents. Your sensor configuration is stored in XML documents on your sensor, so processing XML information is built into the Cisco IPS software. The schema for the XML documents is specified by the Intrusion Detection Interaction and Operations Messages (IDIOM) specification. For more information on both RDEP and IDIOM, refer to the documentation provided at Cisco.com.

Note

The IDIOM specification defines the content of XML documents that are communicated between Cisco Intrusion Prevention System (CIPS) devices using RDEP. By following the IDIOM and RDEP specifications, third-party applications can easily interact with the Cisco IDS.

RDEP is an application-level communications protocol that is used to exchange IDS events, IP log information, and sensor configuration information between your sensor and an external system.

RDEP communication comprises request and response messages. The following three classes of request messages are supported by RDEP:

• Event messages

• IP log messages

• Transaction messages

Event Messages

Event messages include IPS/IDS alerts, status, and error messages. Monitoring applications such as IEV and the Security Monitor use RDEP to retrieve these events from the sensor. Since the monitoring application is responsible for retrieving or pulling the events (such as alerts) from the sensor, it can request the events at a pace that it can handle.

Events on the sensor are stored in a 4 GB circular queue. Since this queue is large, your monitoring application can lose connectivity for a fairly long time without losing any alarms. Under normal conditions, the event store will take at least a couple of days to fill up. Nevertheless, your monitoring application must retrieve events from the sensor before the queue becomes full; otherwise, the sensor will start overwriting the unread events.

Note

The circular queue used by Cisco IPS is a 4 GB fixed length file. As events are added to the file, it gradually gets full. When the file is full, the sensor starts overwriting the events at the beginning of the file. This process is repeated indefinitely, enabling the sensor to maintain a fixed amount of storage for events.

IP Log Messages

You can configure signatures to log the packets coming from the attacking system after a signature fires. These packets are stored on your sensor and represent the actual packets coming from the attacking system. Via the IP log RDEP request messages, your external monitoring application can request copies of the IP log information stored on the sensor. This information can also be viewed via the sensor CLI.

Transaction Messages

The first two message types are used by external systems to retrieve information from your sensor. Your management software uses the transaction messages to configure and control the operation of your sensor. This is accomplished by sending XML information that the sensor uses to change the configuration on the sensor and alter its operational characteristics.

Security Device Event Exchange Standard

The SDEE Standard is a product-independent standard for communicating security device events (see http://www.icsalabs.com/html/communities/ids/sdee/index.shtml). Cisco has been leading the development of this standard that is being adopted by various IDS/IPS vendors. SDEE does not replace RDEP; rather, it enhances RDEP with extensibility features that are needed for communicating events generated by various types of security devices.

Note

RDEP version 2 will specify that CIPS devices communicate events in accordance with the SDEE standard.

Cisco Sensor Software Architecture

Beginning with Cisco IDS 4.0, the entire communication infrastructure was rewritten. Therefore, the services running on the sensor were changed to match this new communication infrastructure. Figure 1-7 shows the Cisco sensor software architecture.

Figure 1-7. Cisco Sensor Software Architecture

One of the main differences of the new architecture is that the sensor no longer pushes events to your monitoring system. Instead, beginning with Cisco IDS 4.0 your monitoring system pulls the events from the sensor as it is ready to process them. The Cisco sensor software architecture can be broken down into the following main interacting applications or processes:

• cidWebServer

• mainApp

• logApp

• authentication

• Network Access Controller (NAC)

• ctlTransSource

• sensorApp

• Event Store

• cidCLI

cidWebServer

The cidWebServer application is the sensor's web server interface that facilitates interaction between the sensor and other Cisco IPS components on your network. This web server is capable of both HTTP and HTTPS communication sessions. Instead of simply providing static web pages, however, the web server provides functionality via several servlets. These servlets perform most of the real work accomplished via the cidWebServer application. One of the main functions provided by the web server is a front-end for the IDM.

Note

A servlet is a shared library that is loaded into the cidWebServer process at runtime.

The cidWebServer uses the following servlets to provide its functionality:

• IDM Servlet

• Event Server Servlet

• Transaction Server Servlet

• IP Log Server Servlet

Note

All of the cidWebServer application's servlets communicate with the RDEP. RDEP serves as the sensor's external communication protocol.

IDM Servlet

The IDM Servlet provides the IDM web-based management interface. You can use this interface to configure your sensors one sensor at a time.

Event Server Servlet

The Event Server Servlet is responsible for serving events to external management applications, such as Security Monitor.

Transaction Server Servlet

Whenever an external management application needs to configure or control your sensor, it needs to initiate a control transaction with the sensor. The Transaction Server Servlet manages these control transactions.

IP Log Server Servlet

The IP Log Server Servlet enables external systems to assess IP log information from the sensor. Like alert events, IP log information is stored on your sensor until retrieved by an external application (such as Security Monitor).

mainApp

The mainApp process is the first application to be launched on the sensor. It is responsible for configuring the sensor's operating system configuration (such as the IP address). The mainApp also handles starting and stopping all of the other Cisco IPS applications.

logApp

Your sensor logs various application messages to log files on the sensor. The logApp application handles writing all of an application's log messages to the log files on the sensor. It is also responsible for the writing of an application's error messages to the event store.

authentication

The authentication process configures and manages user authentication on the sensor. User access to the sensor is based on the following three factors:

• Username

• Password

• Assigned role

When a user accesses the sensor, he must specify a valid username and password combination to gain authenticated access to the sensor. Then the authorization for the user is handled by the user role that is assigned to the specified username.

Network Access Controller (NAC)

Your sensors support the ability to block traffic from an attacking system. This blocking action is enabled by the sensor communicating with one of your network devices and updating an ACL to block the offending system (initiate a shun command on a PIX firewall). The sensor uses the NAC process to initiate IP blocking.

ctlTransSource

Sometimes one of your sensors needs to initiate a control transaction with another one of your sensors. This functionality is performed by the ctlTransSource application. Currently, ctlTransSource is used to enable the master blocking sensor functionality.

sensorApp

The sensorApp process performs the actual sensing functionality on the sensor. Initially, the sensorApp processes the signature and alarm channel configurations for the sensor. Then it generates alert events based on this configuration and the IP traffic that is traversing the sensor's monitoring interface. The sensorApp stores these events (like all other applications) in the Event Store.

Event Store

The Event Store is a large, shared, memory mapped file where all events are stored on your sensor. The Event Store holds the events on your sensor in a 4 GB circular queue until you retrieve those events using your monitoring software or the events get overwritten. By storing the events on the sensor, your alarms are not lost, even if your monitoring software losses network connectivity with your sensor for a short period of time. The sensorApp is the only application that will write alert events into the Event Store, but all other applications may write log, status, and error events into the Event Store.

cidCLI

The cidCLI process is the process initiated when a user logs into the sensor via either Telnet or SSH. A separate cidCLI process is started for each CLI user shell.