Using Cisco IOS IPS to Secure the Network

Using Cisco IOS IPS to Secure the Network

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.

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.

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.

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 (AIPSSM), 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.

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

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

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.

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.

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

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

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

Cisco IPS 4260 Sensor

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

• Performance: 1 Gbps
• 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 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.

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.

Using SDM to Configure Cisco IOS IPS

Although Cisco offers IPS services on a wide variety of platforms, this section focuses on configuring IOS-based IPS using Cisco’s Security Device Manager (SDM). Cisco’s SDM is a graphical interface that supports a wizard-like configuration tool for configuring a variety of IOS features, including IOS-based IPS.

Launching the Intrusion Prevention Wizard

To begin configuring IPS on a Cisco IOS router using SDM, launch the SDM interface. The SDM home page, shown in Figure 11-11, provides summary information about the router. To begin a configuration task using SDM, click the Configure button at the top of the SDM home page. The configuration screen, as shown in Figure 11-12, has a column of tasks along the left side of the page.


A wide range of tasks, including configuring an IOS-based firewall or a virtual private network (VPN), is available. To configure an IOS-based IPS, click the Intrusion Prevention option in the Tasks column. The Intrusion Prevention System (IPS) configuration screen appears, as shown in Figure 11-13. This screen has three tabs: Create IPS, Edit IPS, and Security Dashboard.

The default tab is Create IPS; notice the Launch IPS Rule Wizard button. Click this button to begin the wizard.
An Information window appears, similar to the one shown in Figure 11-14, indicating that the router does not currently have SDEE notification enabled. By clicking OK in this window, you allow SDM to enable SDEE notification on the router.

Another information window appears, like the one shown in Figure 11-15. It lets you know that SDM will open a subscription with the router to get the SDEE events.

IPS Policies Wizard

After you confirm the SDEE messages, the IPS Policies Wizard window appears, as shown in Figure 11-16.
The initial screen explains that the IPS Policies Wizard helps you with the following tasks:

• Selecting the interface to which the IPS rule will be applied
• Selecting the direction of traffic that will be inspected
• Selecting the SDF file to be used by the router

After you click Next, the IPS Wizard prompts you to select the interface(s) to which the IPS rule should be applied, in addition to the direction of traffic (that is, inbound or outbound). In the example shown in Figure 11-17, the IPS Wizard has been instructed to apply the IPS rule to inbound traffic for interface Serial 1/0.

After you click Next again, the SDF Locations screen appears, as shown in Figure 11-18. It allows you to specify one or more locations for the router to retrieve an SDF file. You can set the order of the locations using the Move Up and Move Down buttons.
Click the Add button to bring up the Add a Signature Location window, as shown in Figure 11-19. From this window you can specify an SDF location in the router’s flash or at a specific URL. Also, notice the autosave checkbox. Checking this option allows the router to save the SDF file in the event of a router crash, eliminating the need to reconfigure the SDF location after the router comes back up.

In Figure 11-20, the 128MB.sdf SDF file stored in flash is specified. This particular file was selected because of the router’s memory. If the router contained 256 MB of RAM, the 256MB.sdf file could have been used instead, to provide a larger signature database.

The newly configured SDF location then appears in the SDF Locations pane, as shown in Figure 11-21. Multiple SDF locations could be specified, and the router would attempt to load the SDF from the first location in the list. If it failed, the next SDF location would be attempted. However, in this example, only a single SDF location is specified.

Also notice the Use Built-In Signatures (as backup) checkbox. Checking this box allows IPS to use the Cisco IOS built-in signatures if a signature definition file cannot be found. After you add one or more SDF locations, click the Next button to continue.

A Summary window appears, as shown in Figure 11-22. It identifies the interface(s) on which IPS will be applied and in what direction(s) traffic will be analyzed as it crosses the interface. Additionally, the location of the SDF file is specified, and you can see if the Use Built-In Signatures (as back) checkbox is checked. If the summary information appears to be correct, click the Finish button.

The commands required to configure IOS-based IPS are then sent from SDM to the router. After the commands are delivered, click the OK button in the Commands Delivery Status window, shown in Figure 11-23.

When the Intrusion Prevention Wizard is finished, your view changes in the Edit IPS tab, as shown in Figure 11-24. From this tab, you can edit IPS rules, set global IPS settings, and configure IPS signatures.

Creating IPS Rules

The previously described configuration enabled IOS-based IPS for interface Serial 0/1. If you click the interface, the IPS Filter Details pane, as shown in Figure 11-25, reveals that although the IPS rule is enabled, no filtering is associated with this rule.

To see how to add an associated rule, consider the following scenario:
You want to block inbound Telnet traffic on interface Serial 0/1 while permitting all other traffic.
The following steps illustrate how to accomplish this objective:
Step 1 With the desired interface selected (that is, highlighted), click the Edit button. This action displays the Edit IPS on an Interface window, as shown in Figure 11-26.

Step 2 Verify that Inbound is the selected direction, and click the drop-down menu to the right of the Inbound Filter box. From the drop-down menu,
choose Create a new rule(ACL) and select, as shown in Figure 11-27.

Step 3 When the Add a Rule window appears, as shown in Figure 11-28, enter a name or number for the rule. Also select the type of rule (that is,
standard or extended) from the Type drop-down menu. Optionally, you can document the rule’s purpose in the Description field.

Step 4 Click the Add button in the Add a Rule window to bring up the Add an Extended Rule Entry window (assuming that you selected Extended Rule as the type of rule). In this window, shown in Figure 11-29, using a series of drop-down menus and … buttons, you can specify what traffic you want to permit or deny. In this example, the rule is configured to deny all traffic destined for the TCP Telnet service.

Step 5 Click OK to add the rule. You are returned to the Add a Rule window, as shown in Figure 11-30. Notice that the rule that denies inbound Telnet traffic appears in the Rule Entry pane. However, these rules contain an implicit deny ip any any statement. Therefore, if another rule to permit traffic is not added, all traffic will be denied.

Step 6 Click the Add button again to add a rule that permits any traffic to any destination, as shown in Figure 11-31.

Step 7 You are returned to the Add a Rule window. Notice, in Figure 11-32, that the newly configured permit ip any any rule is at the bottom of the rule list. The order of rules is critical, because they are processed top-down. You can optionally select one of the rules (by clicking it) and changing its order in the list using the Move Up and/or Move Down buttons. Click the OK button to complete the rule entry.

Step 8 The Edit IPS on an Interface window appears, as shown in Figure 11-33. From this window, you can specify whether you want the IOS router to perform Virtual Fragment Reassembly (VFR). Specifically, IOS-based IPS cannot thoroughly scan the contents of IP fragments, thus allowing fragmented traffic to pass through the router without being analyzed.

When the Enable fragment checking on this interface checkbox is checked, the router uses the VFR feature to dynamically create access control lists to protect the network from fragmentation attacks. Click OK to deliver the configuration commands to the router.

Step 9 The Commands Delivery Status window, shown in Figure 11-34, informs you when the IPS rule configuration commands have been delivered to the router. After the delivery is complete, click the OK button.

After the rules have been added to the interface, the rules appear in the IPS Filter Details pane. Figure 11-35 shows that the NO_TELNET inbound filter has been applied to the selected interface (Serial 1/0).

Manipulating Global IPS Settings

The Edit IPS tab also allows administrators to configure global IPS settings. Clicking the Global Settings button displays a screen similar to the one shown in Figure 11-36.

To configure these global settings, an administrator can double-click one of the shown parameters (Syslog, SDEE, or Engine Options). The Edit Global settings window appears, as shown in Figure 11-37.

Signature Configuration

After enabling the IPS feature on a router, you might want to manipulate the default signature settings. For example, you might want to disable some of the signatures that are enabled by default, and vice versa. Also, you might want to alter the action or actions taken in response to a signature being triggered.

To configure such signature parameters, click the Signatures button on the Edit IPS tab. This displays a listing of signatures, as shown in Figure 11-39. Notice that all known IPS signatures are listed in the right pane. If you know the name of the signature you are attempting to find, you can scroll through the list to locate it. Alternatively, notice that the signatures are categorized in a hierarchical fashion, under the OS, Attack, Service, L2/L3/L4 Protocol, and Releases categories.

To understand the editing of a signature, consider the following scenario:
You want to change the action taken in response to the POP Overflow signature being fired, such that an alarm is generated and the offending packet is dropped. The following steps illustrate how to accomplish this objective:
Step 1 Scroll down in the right pane, and locate the desired signature, as shown in Figure 11-40.

Step 3 Notice that the configurable values are currently dimmed. To make one of the fields editable, click the green square to the left of the field. The green square changes into a red diamond after you click it, and the field can now be edited. In this example, you click the green square adjacent to the EventAction field, as shown in Figure 11-42. To meet the scenario objective, both the alarm and drop actions must be selected (that is, highlighted). To select more than one action, click the first action, hold down the Ctrl key, and click the subsequent action(s).

After the parameters are configured as desired, click the OK button at the bottom of the Edit Signature window. You are returned to the Edit IPS tab. Notice that the signature you edited now has a yellow octagon symbol with a minus sign in it, in the ! column, as shown in Figure 11-43. This symbol indicates that the changes you made have not yet been delivered to the router. Click the Apply Changes button, which is just below the signatures pane, to deliver the commands to the router and make the specified changes.

• CCNA Security Study Notes