Examining IPS Technologies

Although IDS and IPS perform similar functions, this section explores how these network security solutions differ. Various approaches to detecting and preventing an intrusion are discussed. This section also explores signatures and how they can trigger an alarm. This section concludes by discussing best practices for IPS network design.

IDS Versus IPS

Although both IDS and IPS devices can recognize network attacks, they differ primarily in their network placement. Specifically, although an IDS device receives a copy of traffic to be analyzed, an IPS device resides inline with the traffic, as illustrated in Figure 11-1.

Figure 11-1 IDS and IPS Network Placement

Figure 11-1 IDS and IPS Network Placement

Appliance (ASA)

Because the analyzed traffic does not flow through the IDS device, the IDS device is considered passive, whereas the IPS device is considered active. Both the IDS and IPS devices can send alerts to, for example, a management station. Although an IDS device can also communicate with a security appliance or router to prevent subsequent attack packets, the initially offending traffic reaches its destination. Conversely, an IPS device can drop the traffic inline, thus preventing even the first malicious packet from reaching its intended target.

This discussion of IDS versus IPS devices might seem to suggest that IPS devices should always be used instead of IDS devices. However, in some network environments, these two solutions complement one another. For example, an IDS device can add value to a network that already employs an IPS device by verifying that the IPS device is still operational. The IDS device might also identify suspicious traffic and send alerts about that traffic, without having the IPS device drop the traffic.

IDS and IPS Device Categories

IDS and IPS devices can be categorized based on how they detect malicious traffic. Alternatively, IPS devices can be categorized based on whether they run on a network device or on a host.

Detection Methods

Consider the following approaches for detecting malicious traffic:

■ Signature-based detection

■ Policy-based detection

■ Anomaly-based detection

■ Honey pot detection

The following sections discuss each of these in detail. Signature-Based Detection

The primary method used to detect and prevent attacks using IDS and/or IPS technologies is signature-based. A signature can recognize a string of bytes, in a certain context, that triggers detection.

For example, attacks against a web server typically take the form of URLs. Therefore, URLs could be searched for a certain string that would identify an attack against a web server.

As another example, the IDS and/or IPS device could search for a pattern in the MIME header of an e-mail message. However, because signature-based IDS/IPS is, as the name suggests, based on signatures, the administrator needs to routinely update those signature files. This routine update is similar in nature to regular antivirus updates that you might perform on your computer to make sure the antivirus program is up-to-date.

Policy-Based Detection

Another approach to IDS/IPS is policy-based. With a policy-based approach, the IDS/IPS device needs a very specific declaration of the security policy. For example, you could write a network access policy that identified which networks could communicate with specific hosts. The IDS/IPS device could then recognize "out of profile" traffic that does not conform to the policy and then report that activity.

Anomaly-Based Detection

A third approach to detecting and/or preventing malicious traffic is anomaly-based. This approach is prone to false positives, because a "normal" condition is difficult to measurably define. However, you have a couple of options when detecting anomalies:

■ Statistical anomaly detection: This approach watches network traffic patterns over a period of time and dynamically builds a baseline. Then, if traffic patterns significantly vary from the baseline, an alarm can be triggered.

■ Nonstatistical anomaly detection: This approach allows an administrator to define what traffic patterns are supposed to look like. However, imagine that Microsoft released a large service pack for its Vista operating system, and your company has hundreds of computers that are configured to automatically download that service pack. If multiple employees turn on their computers at approximately the same time tomorrow morning, and multiple copies of the service pack simultaneously start to download from microsoft.com, the IDS/IPS device might consider that traffic pattern to be significantly outside of the baseline. As a result, the nonstatistical anomaly detection approach could lead to a false positive (that is, an alarm being triggered in the absence of malicious traffic).

Honey Pot Detection

Finally, the "honey pot" acts as a distracter. Specifically, a system designated as the honey pot appears to be an attractive attack target. One school of thought on the use of a honey pot is to place one or more honey pot systems in the network to entice attackers into thinking the system is real. The attackers then use their resources attacking the honey pot, resulting in their leaving the real servers alone.

Another use of a honey pot is to use it as a system that is extensively monitored, to learn the attacker's identity and what he is attempting to do on the system. For example, a honey pot could be a UNIX system configured with a weak password. After an attacker logs in, surveillance software could log what the attacker does to the system. This knowledge could then be used to protect real servers in the network.

Summary of IDS/IPS Detection Methods

Table 11-2 summarizes these IDS/IPS detection methods.

Table 11-2 IDS/IPS Detection Methods i Kev.

Table 11-2 IDS/IPS Detection Methods

Detection Method

Description

Signature-based detection

The primary method used to detect and prevent attacks using IDS and/or IPS technologies is signature-based. A signature could be a string of bytes, in a certain context, that triggers detection.

Policy-based detection

With a policy-based approach, the IDS/IPS device needs a very specific declaration of the security policy. The IDS/IPS device could recognize "out of profile" traffic that does not conform to the policy and then report that activity.

Anomaly-based detection

This approach is prone to false positives, because a "normal" condition is difficult to measurably define. However, you have a couple of options when detecting anomalies:

• Statistical anomaly detection watches network traffic patterns over a period of time and dynamically builds a baseline. Then, if traffic patterns significantly vary from the baseline, an alarm can be triggered.

• Nonstatistical anomaly detection allows an administrator to define what traffic patterns are supposed to look like.

Honey pot detection

The "honey pot" acts as a distracter. A system designated as the honey pot appears to be an attractive attack target. One use of a honey pot is to place one or more honey pot systems in the network to entice attackers into thinking the system is real. The attackers then use their resources attacking the honey pot, resulting in their leaving the real servers alone. Another use of a honey pot is to use it as a system that is extensively monitored to learn what the attacker is attempting to do on the system.

Network-Based Versus Host-Based IPS

As previously mentioned, IPS solutions can be either network-based or host-based. Often network-based and host-based solutions can be used together to protect against a wider range of potential attacks.

Network-Based Sensors

A Cisco IOS router configured for the IPS feature could serve as a network-based IP device. Alternatively, a network-based IPS device could be a dedicated appliance such as Cisco's 4200 series of IDS/IPS sensors, as shown in Figure 11-2.

Figure 11-2 Cisco 4200 Series IDS/IPS Sensor Appliance

Figure 11-2 Cisco 4200 Series IDS/IPS Sensor Appliance

Cisco also supports other hardware modules that can be inserted in a variety of network devices:

■ AIP-SSM: The Advanced Inspection and Prevention Security Services Module (AIP-SSM), shown in Figure 11-3, installs in a Cisco Adaptive Security Appliance (ASA) to add IPS and/or IDS features to the ASA. Interestingly, even though the module resides in an ASA, the AIP-SSM runs its own software (with its own CPU, RAM, and storage), which is the same software found on other sensor appliances.

Figure 11-3 AIP-SSM

Figure 11-3 AIP-SSM

■ IDSM-2: The Cisco Catalyst 6500 Intrusion Detection System Module 2 (IDSM-2), shown in Figure 11-4, inserts into a slot in a Cisco Catalyst 6500 chassis. Because the module has direct access to the switch's backplane, it can monitor any or all of the VLANs configured on the switch. Like the AIP-SSM, the IDSM-2 supports IDS and/or IPS services and runs the same sensor software found on dedicated IDS/IPS appliances.

Figure 11-4 IDSM-2

Figure 11-4 IDSM-2

■ NM-CIDS: The Cisco IDS Network Module (NM-CIDS), shown in Figure 11-5, is supported on a variety of router platforms. The module installs in a router's network module bay, and the NM-IDS can monitor traffic from all the router's interfaces. Although the NM-CIDS does run the same sensor software as the previously mentioned appliances and modules, the NM-CIDS module performs only the IDS function, as opposed to both IDS and IPS functions. However, an NM-CIDS does allow a network administrator to implement full signature protection without negatively impacting router performance.

Figure 11-5 NM-CIDS

Figure 11-5 NM-CIDS

Although http://www.cisco.com provides up-to-date information about which router platforms support the NM-CIDS, as a few examples, the following Cisco router platforms support the NM-CIDS:

— Cisco

2600XM series router

— Cisco

2691 router

— Cisco

3660 router

— Cisco

3725 router

— Cisco

3745 router

— Cisco

2811 ISR

— Cisco

2821 ISR

— Cisco

2851 ISR

— Cisco

3825 ISR

— Cisco

3845 ISR

The operating system running on network-based IPS (NIPS) sensors is considered to be "hardened" against network attacks. A NIPS solution also offers flexibility and scalability in a network design, because additional network devices can be added without necessarily necessitating the addition of new sensor appliances. However, if network patterns grow beyond the capacity of the existing sensor(s), new sensors can easily be added to the network.

Host-Based IPS Software

In addition to the previous examples of network-based IDS/IPS sensors, Cisco offers the Cisco Security Agent (CSA) as a HIPS solution. The CSA software can be installed on selected host systems and optionally report suspicious activity to a centralized management server.

Deploying Network-Based and Host-Based Solutions

NIPS and HIPS solutions can work in tandem. For example, although a NIPS solution can inspect traffic flowing through the network, what if a host had a Secure Socket Layer (SSL) connection to a server, and the malicious traffic traveled over the SSL connection? In that instance, the NIPS hardware would be unable to analyze the malicious traffic, because it would be encrypted inside the SSL connection. However, a HIPS software solution could analyze the malicious traffic after the traffic was decrypted on the host. Similarly, a NIPS device might be able to prevent a denial-of-service (DoS) attack or recognize network reconnaissance patterns. A HIPS solution could focus on protecting applications and host resources.

Figure 11-6 illustrates the deployment of network-based IDS (NIDS), NIPS, and HIPS technologies in the same network. Notice that the sensors are strategically deployed at network boundaries (that is, coming into the network from the Internet and going into the demilitarized zone [DMZ]). As previously discussed, NIDS and NIPS devices are used to complement each other's functions. Additionally, HIPS software (for example, Cisco Security Agent [CSA]) is deployed on strategic hosts—the HTTP, DNS, and e-mail hosts in this example. The NIDS, NIPS, and HIPS devices can all send any alarms triggered on their respective devices to the management console. Using input from these diverse sources, the management console software might be able to perform event correlation to recognize broader network attack patterns, rather than just examining a single attack against a single device.

Figure 11-6 NIDS, NIPS, and HIPS Deployment Example

Management Console

Figure 11-6 NIDS, NIPS, and HIPS Deployment Example

Management Console

DMZ

IDS and IPS Appliances

Cisco offers a series of IDS/IPS sensors—specifically, the Cisco 4200 series of IDS/IPS sensors. All sensors contain at least two interfaces:

Command and control interface: A sensor's command and control interface is configured with an IP address and is used to communicate with other network devices (for example, a security appliance or a management workstation) for management purposes.

■ Monitoring interface(s): All sensors have at least one monitoring interface, which is used to monitor network traffic.

Depending on the number of available interfaces, sensors can operate in one of two modes, as described in Table 11-3.

..■•— Table 11-3 Sensor Operating Modes f Key __

Operating Mode

Description

Promiscuous mode

Promiscuous mode operation requires only a single monitoring interface. Therefore, all Cisco 4200 sensors support promiscuous mode operation. When running in promiscuous mode, a sensor receives a copy of selected network traffic. If the sensor detects malicious traffic, it can take a variety of actions (for example, triggering an alarm or instructing a security appliance to drop traffic coming from a specific source). Because a sensor running in promiscuous mode is not inline with the traffic, IDS operation is supported, but not IPS operation.

Inline mode

Inline mode operation requires a least two monitoring interfaces (either virtual or physical), because the sensor resides inline with the traffic. (In other words, traffic enters the sensor on one monitoring interface and exits the sensor on another monitoring interface.) Therefore, a sensor running in inline mode supports IPS operation and can drop malicious traffic before the traffic reaches its intended target.

Cisco IDS 4215 Sensor

The Cisco IDS 4215 Sensor, shown in Figure 11-7, has the following specifications:

■ Performance: 65 Mbps

■ Command and control interface speed: 10/100 Mbps

■ Maximum number of monitoring interfaces: Five m

Figure 11-7 Cisco IDS 4215 Sensor

Figure 11-7 Cisco IDS 4215 Sensor

Cisco IPS 4240 Sensor

The Cisco IPS 4240 Sensor, shown in Figure 11-8, has the following specifications:

■ Performance: 250 Mbps

■ Command and control interface speed: 10/100/1000 Mbps

■ Maximum number of monitoring interfaces: Four Figure 11-8 Cisco IPS 4240 Sensor

■ Maximum number of monitoring interfaces: Four Figure 11-8 Cisco IPS 4240 Sensor

Cisco IPS 4255 Sensor

The Cisco IPS 4255 Sensor, shown in Figure 11-9, has the following specifications:

■ Performance: 500 Mbps

■ Command and control interface speed: 10/100/1000 Mbps

■ Maximum number of monitoring interfaces: Four Figure 11-9 Cisco IPS 4255 Sensor

■ Maximum number of monitoring interfaces: Four Figure 11-9 Cisco IPS 4255 Sensor

Cisco IPS 4260 Sensor

The Cisco IPS 4260 Sensor, shown in Figure 11-10, has the following specifications:

■ Command and control interface speed: 10/100/1000 Mbps

■ Maximum number of monitoring interfaces: Nine

Signatures

Now that you posses a basic understanding of the roles of IDS and IPS sensors in a network and are acquainted with various IDS and IPS hardware solutions, next consider how a sensor detects an attack. The sensor uses a collection of signatures to detect potentially malicious network traffic. If the observed traffic matches a signature, the sensor can trigger an alarm (or perform a variety of other actions).

Because of the diversity of a sensor's signature collection, groups of similar signatures are handled by microengines. A sensor contains multiple microengines. The sensor decides which microengine(s) it will use to analyze traffic based on criteria such as the network protocol being used by the traffic, the signature's associated operating system, the port number being used by the session, and the type of attack the sensor is looking for. However, at a more macro level, you can categorize signatures into one of four broad categories, as described next.

Exploit Signatures

An exploit attempts to leverage a weakness in the network. That weakness could, for example, be associated with a network application at the application layer of the OSI model. Alternatively, exploit attacks could target the transport and/or network OSI layers. Following are examples of potential attacker exploits at these OSI layers:

■•— ■ Application layer: As an attacker is preparing to attack a network, he might perform

Topic network reconnaissance, in which he attempts to learn more about the network. One form of network reconnaissance involves performing Domain Name System (DNS) queries to learn more about a target domain. For example, the http:// www.betterwhois.com website provides, for free, detailed information about a domain, including contact information for the domain administrator. Other examples of application layer exploits include launching DoS attacks (attempts to deplete system resources), directory traversal attacks, viruses, Trojan horses, and worms.

■ Transport layer: Protocols such as TCP and UDP reside at the transport layer of the OSI model. Both TCP and UDP communicate on various ports. For example, the Telnet application communicates on TCP port 23, and Simple Mail Transfer Protocol (SMTP) communicates on TCP port 25. An attacker might perform a port scan to determine what services (for example, Telnet or SMTP) are available at specific IP addresses. Another example of a transport layer exploit floods a device with a series of TCP synchronization (SYN) segments, which is part of TCP's three-way handshake process. However, this TCP SYN flood attack never completes the three-way handshake. Rather, the attacker creates multiple partially open connections (that is, embryonic connections) to exhaust resources on the attack target.

■ Network layer: Similar to the transport layer's port scan attack, at the network layer an attacker might perform a ping sweep. Here the attacker attempts to ping a range of IP addresses to determine which ones respond to the ping. After the attacker compiles a list of IP addresses that responded to his pings, he can further investigate those systems using, for example, the previously mentioned port scan.

Connection Signatures

Connection signatures use a set of rules that state how certain protocols should behave on the network. For example, administrators can configure policies that dictate what types of network connections or network traffic are allowed.

String Signatures

Some attacks can be recognized by a series of bytes contained in the malicious packet. This series of bytes is called a string. Other than the strings already known to a sensor's signature database, administrators can use regular expressions to match known strings. Regular expressions leverage a series of wildcards, called metacharacters, to allow a single expression to match multiple strings.

Denial-of-Service Signatures

The purpose of a DoS attack is to consume the resources of the attack target, such as the memory or processor resources of a mission-critical server. DoS signatures can recognize multiple types of DoS attacks. By consuming system resources, an attacker can prevent legitimate users from accessing those resources. A distributed denial-of-service (DDoS) attack distributes a DoS attack, such that multiple devices attempt to consume resources on a target system.

Signature Definition Files

As mentioned earlier in this chapter, in addition to sensor appliances, a Cisco IOS router, with an appropriate version IOS, can act as an IPS sensor, thus allowing an IOS router to drop malicious traffic before the traffic reaches its intended target. In addition to dropping the offending traffic, the router can log the activity using either the syslog or Security Device Event Exchange (SDEE) protocol. The SDEE protocol is preferred over syslog. SDEE provides a secure communications channel, and it can be used to communicate between IPS clients and servers (for example, a management workstation that collects and correlates events from multiple IPS sensors in the network).

The IOS router acting as an IPS device needs a database of signatures to identify malicious traffic. The router's signature database is in the form of a Signature Definition File (SDF). Modern routers typically ship with an SDF installed in flash memory. However, the administrator usually needs to periodically update the router's SDF, because Cisco routinely updates these files to address emerging threats. A router can also reference multiple SDFs for increased signature coverage.

SDFs vary in their number of signatures, and the SDF used by a particular router platform is largely determined by the router's RAM. For example, if a router contains 128 MB of RAM, it might use the 128MB.sdf, which contains approximately 300 signatures. Alternatively, a router with 256 MB of RAM might use the 256MB.sdf, which contains approximately 500 signatures.

The collection of signatures contained in an SDF might not be appropriate for a specific network. Fortunately, network administrators can tune individual signatures, or even disable a signature, to better meet the needs of their network.

Alarms

After an IPS sensor triggers an alarm, which is sometimes called a "signature firing," one or more events can occur. These events are described in Table 11-4.

Table 11-4 Responses to a Signature Firing

Response

Description

Create a log entry

The triggering of an alarm can cause the IPS sensor to create a log message indicating that a particular signature was matched. The log message can be written using syslog or SDEE.

Drop the offending packet

When a packet triggers an alarm, the IPS sensor can be configured to drop the offending packet, thus preventing the potentially malicious traffic from reaching its intended target.

Reset the TCP connection

In a TCP-based connection, the IPS sensor can reset the connection when a signature is matched. Specifically, the sensor sends a TCP RST message to both parties involved in the TCP conversation.

Block the attacker's IP address

A signature firing can also cause the IPS sensor to drop all traffic sourced from the attacker's IP address. Typically, this blocking behavior occurs for only a specific period of time. However, if you configure this response using IOS-based IOS, be aware that you might block one of your own users, whose IP address is being spoofed by the attacker.

Table 11-4 Responses to a Signature Firing

Table 11-4 Responses to a Signature Firing

Response

Description

Block traffic associated with the offending connection

Perhaps you do not want a signature firing to block all traffic from the attacker's IP address, but you do want to block all traffic associated with a particular connection (such as an HTTP session). Such an action is possible with an IPS sensor. Like the action of blocking an attacker's IP address, this action of blocking a connection's traffic can be configured to remain in effect for a specified period of time. This approach reduces the likelihood that you will inadvertently block one of your network users because of the attacker spoofing the user's IP address. However, because only a single connection is being blocked, the attacker could relaunch his attack using a different protocol and/ or port number.

Sometimes a network administrator wants a signature firing to result in more than one of the previous actions. For example, you might want to generate a log entry and block all traffic sourced from the attacker's IP address. Changing these signature responses is called signature tuning.

0 0

Post a comment