Chapter 06: Network Security Using Cisco IOS IPS (Part01)

This chapter describes the functions and operations of IDS and IPS systems. This chapter will introduce you to:

• The underlying IDS and IPS technology that is embedded in the Cisco host- and network-based IDS and IPS solutions

• Cisco IOS IPS using Cisco SDM

Intrusion detection system (IDS) and intrusion prevention system (IPS) solutions form an integral part of a robust network defense solution. Maintaining secure network services is a key requirement of a profitable IP-based business. Using Cisco products and technologies as examples, this chapter defines IDS and IPS and how these systems work.

Introducing IDS and IPS

IDS and IPS work together to provide a network security solution. An IDS captures packets in real time, processes them, and can respond to threats, but works on copies of data traffic to detect suspicious activity by using signatures. This is called promiscuous mode. In the process of detecting malicious traffic, an IDS allows some malicious traffic to pass before the IDS can respond to protect the network. An IDS analyzes a copy of the monitored traffic rather than the actual forwarded packet. The advantage of operating on a copy of the traffic is that the IDS does not affect the packet flow of the forwarded traffic. The disadvantage of operating on a copy of the traffic is that the IDS cannot stop malicious traffic from single-packet attacks from reaching the target system before the IDS can apply a response to stop the attack. An IDS often requires assistance from other networking devices, such as routers and firewalls, to respond to an attack.

An IPS works inline in the data stream to provide protection from malicious attacks in real time. This is called inline mode. Unlike an IDS, an IPS does not allow packets to enter the trusted side of the network. An IPS monitors traffic at Layer 3 and Layer 4 to ensure that their headers, states, and so on are those specified in the protocol suite. However, the IPS sensor analyzes at Layer 2 to Layer 7 the payload of the packets for more sophisticated embedded attacks that might include malicious data. This deeper analysis lets the IPS identify, stop, and block attacks that would normally pass through a traditional firewall device. When a packet comes in through an interface on an IPS, that packet is not sent to the outbound or trusted interface until the packet has been determined to be clean. An IPS builds upon previous IDS technology; Cisco IPS platforms use a blend of detection technologies, including profile-based intrusion detection, signature-based intrusion detection, and protocol analysis intrusion detection.

The key to differentiating an IDS from an IPS is that an IPS responds immediately and does not allow any malicious traffic to pass, whereas an IDS allows malicious traffic to pass before it can respond.

Key Topic

IDS Analyzes copies of the traffic stream Does not slow network traffic Allows some malicious traffic into the network IPS Works inline in real time to monitor Layer 2 through Layer 7 traffic and content Needs to be able to handle network traffic Prevents malicious traffic from entering the network

IDS and IPS technologies share several characteristics:

• IDS and IPS technologies are deployed as sensors. An IDS or an IPS sensor can be any of the following devices:

  • A router configured with Cisco IOS IPS Software

  • An appliance specifically designed to provide dedicated IDS or IPS services

  • A network module installed in an adaptive security appliance, switch, or router

• IDS and IPS technologies typically monitor for malicious activities in two spots:

  • Malicious activity is monitored at the network to detect attacks against a network, including attacks against hosts and devices, using network IDS and network IPS.

  • Malicious activity is monitored on a host to detect attacks that are launched from or on target machines, using host intrusion prevention system (HIPS). Host-based attacks are detected by reading security event logs, checking for changes to critical system files, and checking system registries for malicious entries.

• IDS and IPS technologies generally use yes, signatures to detect patterns of misuse in network traffic, although other technologies will be introduced later in this chapter A signature is a set of rules that an IDS or IPS uses to detect typical intrusive activity. Signatures are usually chosen from a broad cross section of intrusion detection signatures, and can detect severe breaches of security, common network attacks, and information gathering.

• IDS and IPS technologies look for the following general patterns of misuse:

  • Atomic pattern: In an atomic pattern, an attempt is made to access a specific port on a specific host, and malicious content is contained in a single packet. An IDS is particularly vulnerable to an atomic attack because until it finds the attack, malicious single packets are being allowed into the network. An IPS prevents these packets from entering at all.

  • Composite pattern: A composite pattern is a sequence of operations distributed across multiple hosts over an arbitrary period of time.

Note

Note that sensors, even inline, might not be completely successful at drop packets of an attack. It is possible that an attack be on its way, if only partially, before even an inline sensor starts dropping packets matching a composite pattern signature. The drop action is much more effective for atomic signatures because the sensor makes a single packet match.

Figure 6-1 shows a sensor deployed in IDS mode and a sensor deployed in IPS mode.

Figure 6-1: IDS and IPS Operational Differences

The following are the steps that occur when an attack is launched in an environment monitored by an IDS:

Step 1	An attack is launched on a network that has a sensor deployed in IDS mode.
Step 2	The switch sends copies of all packets to the IDS sensor (configured in promiscuous mode, which is explained later in this section) to analyze the packets. At the same time, the target machine experiences the malicious attack.
Step 3	The IDS sensor, using a signature, matches the malicious traffic to the signature.
Step 4	The IDS sensor sends the switch a command to deny access to the malicious traffic.
Step 5	The IDS sends an alarm to a management console for logging and other management purposes.

The following are the steps that occur when an attack is launched in an environment monitored by an IPS:

Step 1	An attack is launched on a network that has a sensor deployed in IPS mode (configured in inline mode, which is explained later in this section).
Step 2	The IPS sensor analyzes the packets as soon as they come into the IPS sensor interface. The IPS sensor, using signatures, matches the malicious traffic to the signature and the attack is stopped immediately. Traffic in violation of policy can be dropped by an IPS sensor.
Step 3	The IPS sensor can send an alarm to a management console for logging and other management purposes.

Key Topic

A sensor can be deployed either in promiscuous mode or inline mode. In promiscuous mode, the sensor receives a copy of the data for analysis, while the original traffic still makes its way to its ultimate destination. By contrast, a sensor working inline analyzes the traffic live and therefore can actively block the packets before they reach their destination. It is worth mentioning that Cisco appliances, such as the Cisco ASA AIP SSM (discussed later in the section, “Cisco ASA AIP SSM”), although advertised as IPS device, can work either in promiscuous mode or in inline mode.

Key Topic

The term management console, used in this chapter and seen in Figure 6-1, requires some explanation. A management console is a separate workstation equipped with software to configure, monitor, and report on events. The section, “Monitoring IOS IPS,” introduces some of Cisco’s IPS management solutions.

Table 6-1 lists some of the advantages and limitations of deploying an IDS platform in promiscuous mode.

Table 6-1: Advantages and Limitations of Deploying an IDS in Promiscuous Mode
Open table as spreadsheet

Advantage	Limitation
Deploying the IDS sensor does not have any impact on the network (latency, jitter, and so on).	IDS sensor response actions cannot stop the trigger packet and are not guaranteed to stop a connection. IDS response actions are typically better at stopping an attacker more than a specific attack itself.
The IDS sensor is not inline and, therefore, a sensor failure cannot affect network functionality.	IDS sensor response actions are less helpful in stopping email viruses and automated attackers such as worms.
Overrunning the IDS sensor with data does not affect network traffic; however, it does affect the capability of the IDS to analyze the data.	Users deploying IDS sensor response actions must have a well thought-out security policy combined with a good operational understanding of their IDS deployments. Users must spend time to correctly tune IDS sensors to achieve expected levels of intrusion detection.
	Being out of band (OOB), IDS sensors are more vulnerable to network evasion techniques, which are the process of totally concealing an attack.

Table 6-2 lists some of the advantages and limitations of deploying an IPS platform in inline mode.

Table 6-2: Advantages and Limitations of Deploying an IPS in Inline Mode
Open table as spreadsheet

Advantage	Limitation
You can configure an IPS sensor to perform a packet drop that can stop the trigger packet, the packets in a connection, or packets from a source IP address.	An IPS sensor must be inline and, therefore, IPS sensor errors or failure can have a negative effect on network traffic.
Being inline, an IPS sensor can use stream normalization techniques to reduce or eliminate many of the network evasion capabilities that exist.	Overrunning IPS sensor capabilities with too much traffic does negatively affect the performance of the network.
	Users deploying IPS sensor response actions must have a well thought-out security policy combined with a good operational understanding of their IPS deployments.
	An IPS sensor will affect network timing because of latency, jitter, and so on. An IPS sensor must be appropriately sized and implemented so that time-sensitive applications, such as VoIP, are not negatively affected.

Traffic normalization includes techniques such as fragmentation reassembly to check the validity of the transmission.

Note

Packets that are dropped based on false alarms can result in network disruption if the dropped packets are required for mission-critical applications downstream of the IPS sensor. Therefore, do not be overly aggressive when assigning the drop-action to signature. Also, “drop” discards the packet without sending a reset. Cisco recommends using “drop and reset” in conjunction with alarm.

Table 6-3 summarizes some of the advantages and limitations of an IDS in promiscuous mode and an IPS in inline mode explained earlier.

Table 6-3: Summary of Advantages and Limitations of IDS and IPS Modes
Open table as spreadsheet

	Advantages	Limitations
IDS (Promiscuous Mode)	No impact on network (latency, jitter)	Response action cannot stop trigger packets
	No network impact if there is a sensor failure	Correct tuning required for response actions
	No network impact if there is sensor overload	Must have a well-thought out security policy
		More vulnerable to network evasion techniques
IPS (Inline Mode)	Stops trigger packets	Sensor issues might affect network traffic
	Can use stream normalization techniques	Sensor overloading impacts the network
		Must have a well-thought out security policy
		Some impact on network (latency, jitter)

Types of IDS and IPS Systems

Table 6-4 summarizes the advantages and limitations of the various types of IDS and IPS sensors available.

Table 6-4: Types of IDS and IPS Sensors
Open table as spreadsheet

	Advantages	Limitations
Signature Based	Easy configuration	No detection of unknown signatures
	Fewer false positives	Initially a lot of false positives
	Good signature design	Signatures must be created, updated, and tuned
Policy Based	Simple and reliable	Generic output
	Customized policies	Policy must be created
	Can detect unknown attacks
Anomaly Based	Easy configuration	Difficult to profile typical activity in large networks
	Can detect unknown attacks	Traffic profile must be constant
Honeypot Based	Window to view attacks	Dedicated honeypot server
	Distract and confuse attackers	Honeypot server must not be trusted
	Slow down and avert attacks
	Collect information about attack

Key Topic

False negative: Occurs when the IDS/IPS fails to report an actual intrusive action. False positive: Occurs when the IDS/IPS classifies an action as anomalous when in fact it is a legitimate action. These terms and others are discussed at length in the upcoming section “Signature Alarms.” Honeypot: A system deployed to entice a hacker to attack it and therefore track the hacker’s maneuvers and technique.

The sections that follow describe these IDS and IPS sensors in more detail.

Signature-Based IDS/IPS Systems

A signature-based IDS or IPS sensor looks for specific, predefined patterns (signatures) in network traffic. It compares the network traffic to a database of known attacks, and triggers an alarm or prevents communication if a match is found. The signature can be based on a single packet or a sequence of packets. New attacks that do not match a signature do not result in detection. For this reason, the signature database needs to be constantly updated.

Note

Protocol analysis-based intrusion detection relies on signature-based intrusion detection where the signature performs a check to ensure that the date unit header, flags, payload, and so on respect the protocol.

Signature-based pattern matching is an approach that is rigid but simple to employ. In most cases, the pattern is matched against only if the suspect packet is associated with a particular service or, more precisely, destined to and from a particular port. This matching technique helps to lessen the amount of inspection done on every packet. However, it makes it more difficult for systems to deal with protocols that do not reside on well-defined ports, such as Trojan horses and their associated traffic, which can move at will.

At the initial stage of incorporating signature-based IDS or IPS, before the signatures are tuned, there can be many false positives (traffic generating an alert which is no threat for the network). After the system is tuned and adjusted to the specific network parameters, there will be fewer false positives than with the policy-based approach.

Policy-Based IDS/IPS Systems

In policy-based systems, the IDS or IPS sensor is preconfigured based on the network security policy. You must create the policies used in a policy-based IDS or IPS. Any traffic detected outside the policy will generate an alarm or will be dropped. Creating a security policy requires detailed knowledge of the network traffic and is a time-consuming task.

Policy-based signatures use an algorithm to determine whether an alarm should be fired. Often, policy-based signature algorithms are statistical evaluations of the traffic flow. For example, in a policy-based signature used to detect a port sweep, the algorithm issues an alarm when the threshold number of unique ports is scanned on a particular machine. Policy-based signature algorithms can be designed to analyze only specific types of packets (for example, SYN packets, where the SYN bit is turned on during the handshaking process at the beginning of the session).

The policy itself might require tuning. For example, you might have to adjust the threshold level of certain types of traffic so that the policy conforms to the utilization patterns on the network that it is monitoring. Polices can be used to look for very complex relationships.

Anomaly-Based IDS/IPS Systems

Anomaly-based or profile-based signatures typically look for network traffic that deviates from what is seen “normally.” The biggest issue with this methodology is that you first must define what normal is. If during the learning phase your network is the victim of an attack and you fail to identify it, the anomaly-based IPS systems will interpret that malicious traffic as normal, and no alarm will be triggered next time this same attack takes place. Some systems have hard-coded definitions of normal traffic patterns and, in this case, could be considered heuristic-based systems.

Other systems are built to learn normal traffic behavior; however, the challenge with these systems is eliminating the possibility of improperly classifying abnormal behavior as normal. Also, if the traffic pattern being learned is assumed normal, the system must contend with how to differentiate between allowable deviations, and those deviations that are not allowed or that represent attack-based traffic. Normal network traffic can be difficult to define.

The technique used by anomaly-based IDS/IPS systems is also referred as network behavior analysis or heuristics analysis.

Honeypot-Based IDS/IPS Systems

Honeypot systems use a dummy server to attract attacks. The purpose of the honeypot approach is to distract attacks away from real network devices. By staging different types of vulnerabilities in the honeypot server, you can analyze incoming types of attacks and malicious traffic patterns. You can use this analysis to tune your sensor signatures to detect new types of malicious network traffic.

Honeypot systems are used in production environments, typically by large organizations that come across as interesting targets for hackers, such as financial enterprises, governmental agencies, and so on. Also, antivirus and other security vendors tend to use them for research.

Tip

Many security experts preach the use of honeypots as an early-warning system to be deployed with your IDS/IPS system, not in lieu of. Honeyd is an example of a popular open-source honeypot software. Although honeypots are often found as dedicated servers, it is possible to set up virtual honeypots using VMWare or Virtual PC. Keep in mind that should the honeypot be successfully hacked and used as a launching platform for an attack on a third party, the honeypot’s owner could incur downstream liability.

IPS Actions

When an IPS sensor detects malicious activity, it can choose from any or all the following actions:

• Deny attacker inline: This action terminates the current packet and future packets from this attacker address for a specified period of time. The sensor maintains a list of the attackers currently being denied by the system. You can remove entries from the list or wait for the timer to expire. The timer is a sliding timer for each entry. Therefore, if attacker A is currently being denied, but issues another attack, the timer for attacker A is reset, and attacker A remains on the denied attacker list until the timer expires. If the denied attacker list is at capacity and cannot add a new entry, the packet is still denied.

• Deny connection inline: This action terminates the current packet and future packets on this TCP flow. This is also referred to as deny flow.

• Deny packet inline: This action terminates the packet.

• Log attacker packets: This action starts IP logging on packets that contain the attacker address and sends an alert. This action causes an alert to be written to the event store, which is local to the IOS router, even if the produce-alert action is not selected. Produce alert is discussed later in a bullet.

• Log pair packets: This action starts IP logging on packets that contain the attacker and victim address pair. This action causes an alert to be written to the event store, even if the produce-alert action is not selected.

• Log victim packets: This action starts IP logging on packets that contain the victim address and sends an alert. This action causes an alert to be written to the event store, even if the produce-alert action is not selected.

• Produce alert: This action writes the event to the event store as an alert.

• Produce verbose alert: This action includes an encoded dump of the offending packet in the alert. This action causes an alert to be written to the event store, even if the produce-alert action is not selected.

• Request block connection: This action sends a request to a blocking device to block this connection.

• Request block host: This action sends a request to a blocking device to block this attacker host.

• Request SNMP trap: This action sends a request to the notification application component of the sensor to perform Simple Network Management Protocol (SNMP) notification. This action causes an alert to be written to the event store, even if produce-alert action is not selected.

• Reset TCP connection: This action sends TCP resets to hijack and terminate the TCP flow.

Note

IP logging and verbose alert traces use a common capture file writing code called libpcap. This is the same format used by the famous packet-capture tool Wireshark (formerly Ethereal); by Snort, a famous freeware IDS; by NMAP, a well-known fingerprinting tool; and by Kismet, a famous wireless sniffing tool. You can use the reset TCP connection action in conjunction with deny-packet and deny-flow actions. However, deny-packet and deny-connection actions do not automatically cause TCP reset actions to occur.

Event Monitoring and Management

Event monitoring and management can be divided into the following two needs:

• The need for real-time event monitoring and management

• The need to perform analysis based on archived information (reporting)

These functions can be handled by a single server, or the functions can be placed on separate servers to scale the deployment. The number of sensors that should forward alarms to a single IPS management console is a function of the aggregate number of alarms per second that are generated by those sensors.

Key Topic

Reporting: Analysis based on archive information Event monitoring: Real-time monitoring

Experience with customer networks has shown that the number of sensors reporting to a single IPS management console should be limited to 25 or fewer. These customers use a mixture of default signature profiles and tuned signatures. The number of alarms generated by each sensor is determined by how sensitively the sensor is tuned; the more sensitive the tuning, the fewer the alarms that are generated, and the larger the number of sensors that can report to a single IPS management console.

Note

Obviously with the evolution of technology, the limit of 25 sensors reporting to a single IPS management console is constantly being pushed. Check with your vendor for the latest information.

It is essential to tune out false positives to maximize the scalability of the network IPS deployment. Sensors that are expected to generate a large number of alarms, such as those sitting outside the corporate firewall, should log in to a separate IPS management console, because the number of false alarms raised dramatically increases the noise-to-signal ratio and makes it difficult to identify otherwise valid events.

Key Topic

False positives happen when the IDS/IPS mistakenly takes legitimate traffic for an attack. False negatives happens when the IDS/IPS sensor misses an attack.

When implementing multiple IPS management consoles, implement either separate monitoring domains or a hierarchical monitoring structure.

Cisco IPS Management Software

You can use the command-line interface (CLI) to configure an IPS solution, but it is simpler to use a graphical user interface (GUI)-based device manager. The following describes the Cisco device management software available to help you manage an IPS solution.

Cisco Router and Security Device Manager

Cisco Security Device Manager (SDM), shown in Figure 6-2, is a web-based device management tool for Cisco routers that can improve the productivity of network managers, simplify router deployments, and help troubleshoot complex network and virtual private network (VPN) connectivity issues. Cisco SDM supports a wide range of Cisco IOS Software releases and is available free on Cisco router models from the Cisco 850 Series Integrated Services Router to the Cisco 7301 Router.

Figure 6-2: Cisco Router and Security Device Manager

Cisco Security Monitoring, Analysis, and Response System

Cisco Security Monitoring, Analysis, and Response System (MARS), shown in Figure 6-3, is an appliance-based, all-inclusive solution that enables network and security administrators to monitor, identify, isolate, and counter security threats. This family of high-performance appliances enables organizations to more effectively use their network and security resources.

Figure 6-3: Cisco Security Monitoring, Analysis, and Response System

Cisco Security MARS can monitor security events and information from a wide variety of sources, including third-party devices and hosts. With its correlation engine, vector analysis, and hotspot identification, Cisco Security MARS can identify anomalous behavior and security threats, and recommend precision removal of those elements, which leads to rapid threat mitigation. In addition, Cisco Security MARS incorporates a comprehensive reporting engine that provides easy access to information for compliance reporting.

Cisco IDS Event Viewer

Cisco IDS Event Viewer (IEV), referred to also as Cisco IPS Event Viewer, is a Java-based application that enables you to view and manage alarms for up to five sensors. With Cisco IEV, you can connect to and view alarms in real time or in imported log files. You can configure filters and views to help you manage the alarms. You can also import and export event data for further analysis.

Cisco IEV offers a no-cost monitoring solution for small-scale IPS deployments. Monitoring up to five individual IPS devices, Cisco IEV is easy to set up and use, and provides the user with the following:

• Support for Cisco IPS Sensor Software Version 5.x through Security Device Event Exchange (SDEE) compatibility

• Customizable reporting

• Visibility into applied response actions and threat rating

Note

Cisco IEV is being phased out and replaced by Cisco IPS Express manager (http://tinyurl.com/5td7f2).

Cisco Security Manager

Cisco Security Manager is a powerful, but very easy-to-use solution, to centrally provision all aspects of device configurations and security policies for Cisco firewalls, VPNs, and IPS. The solution is effective for managing even small networks that consist of fewer than 10 devices, but also scales to efficiently manage large-scale networks that are composed of thousands of devices. Scalability is achieved through intelligent policy-based management techniques that can simplify administration.

Features of CSM include the following:

• Auto update for Cisco IOS Release 12.4(11)T2 or later

• Custom signature templates

• Signature wizards to create and update signatures

Cisco IPS Device Manager

Cisco IPS Device Manager (IDM) is a web-based configuration tool for network IPS appliances. It is shipped at no additional cost with the Cisco IPS Sensor Software. Cisco IDM implements a web-based GUI.

Note

In May 2008, Cisco announced the release of a new product called Cisco IPS Manager Express. The new Cisco IPS Manager Express (IME), shown in Figure 6-4, is a powerful yet easy-to-use all-in-one IPS management application for up to five IPS sensors. Cisco IME can be used to provision, monitor, troubleshoot, and provide reports for IPS 4200 series sensors, ASA 5500 IPS solution, AIM-IPS on ISRs, and IDSM2 on Catalyst 6500s. To have access to all the capabilities of Cisco IME, it has to be used with sensors running Cisco IPS Software 6.1. With IPS Software Versions 5.1 or 6.0, or IOS IPS, you can use IME to monitor and provide reports only, with limited dashboard support. Figure 6-4: Cisco IPS Manager Express Some of the features of Cisco IPS Manager Express are a customizable dashboard, powerful monitoring with real-time and historical viewing, integrated policy provisioning with risk rating, a flexible reporting tool, RSS feed integration, email notification, 75 events per second, and up to five IPS sensors.