Starting with Cisco IOS® Software release 12.4(11)T, Cisco IOS Intrusion Prevention System (IPS) introduces support for the Cisco IPS Software Version 5.x/6.0 signature format, used by other Cisco appliance-based IPS products. This document covers IOS IPS features in 12.4(11)T and later software releases that use Cisco IPS version 5.x signature format.
The Cisco IPS version 5.x signature format supports encrypted signature parameters and other features such as signature Risk Rating. The following table shows the appropriate signature package for Cisco IOS Software releases.
Table 1. IOS Release and Signature Format Version
|
IOS Release Version |
Cisco IPS Signature Format Version |
Cisco.com Download URL |
|
12.4(11)T and later T Train Releases |
5.x/6.0 |
|
|
Prior to 12.4(11)T and 12.4 Mainline |
4.x |
Feature History
Table 2 shows the feature history of Cisco IOS IPS.
Table 2. Feature History of Cisco IOS IPS
More information on Cisco IOS IPS features can be found in the Cisco IOS Software release 12.4T Release Notes:
Overview
In today's business environment, network intruders and attackers can come from both outside and inside the network. They can launch denial-of-service (DoS) attacks or distributed denial-of-service (DDoS) attacks; attack Internet connections; and exploit network and host vulnerabilities. At the same time, Internet worms and viruses can spread across the world in a matter of minutes. There is often no time to wait for human intervention-the network itself must possess the intelligence to instantaneously recognize and mitigate these attacks, threats, exploits, worms, and viruses.
Cisco IOS Intrusion Prevention System (IPS) is an inline, deep-packet-inspection-based feature that enables Cisco IOS Software to effectively mitigate a wide range of network attacks. While it is common practice to defend against attacks by inspecting traffic at the data centers and corporate headquarters, it is also critical to distribute the network-level defense to stop malicious traffic close to its entry point at the branch or telecommuter offices.
Cisco IOS IPS capabilities include:
• Dynamically load and enable selected IPS signatures in real time
• Support the same 2000 signatures as Cisco IPS sensor platforms
• Modify existing signatures or create new signatures to address newly discovered threats
Key Features and Benefits
Cisco IOS IPS offers the following features and benefits:
• Provides network-wide, distributed protection from many attacks, exploits, worms and viruses exploiting vulnerabilities in operating systems and applications
• Eliminates the need for a standalone IPS device at branch and telecommuter offices as well as small and medium-sized business networks
• Unique and risk rating based signature event action policy processor dramatically improves the ease of management of IPS policy.
• Offers field-customizable worm and attack signature set and event actions
• Offers inline inspection of traffic passing through any combination of router LAN and WAN interfaces in both directions
• Works with Cisco IOS® Firewall, control-plane policing, and other Cisco IOS Software security features to protect the router and networks behind the router
• Supports about 2000 attack signatures from the same signature database available for Cisco Intrusion Prevention System (IPS) appliances
Deployment Scenarios
Figure 1 describes the three main deployment scenarios.
Figure 1. Cisco IOS IPS Deployment Scenarios
Protect Branch PCs from Internet Worms
The Internet is one of the major sources of attacks and exploits targeting today's corporate networks. Applying Cisco IOS IPS on router interfaces connected to the Internet helps defend the corporate network against such vulnerabilities. Even with a firewall enabled to restrict access from the untrusted Internet, intruders can still potentially invade the perimeter router on the telecommuter side and gain access to the corporate network. Common security attacks include IP spoofing, man-in-the-middle attacks, and unauthorized access that may have slipped through the firewall. Outgoing traffic from the telecommuter's end also poses a threat to the internal network, if the telecommuter attempts to compromise the corporate network or the Internet. Cisco IOS IPS can be applied at the incoming and outgoing interfaces of the perimeter router to monitor and discard malicious activity.
In the network topology shown in Figure 1, the branch offices are the best places to enable Cisco IOS IPS on both directions of the Internet-facing interface. A common scenario is when split tunneling is enabled while running VPN tunnels to the corporate network. Cisco recommends enabling Cisco IOS IPS on the Internet traffic to protect the network from attacks and exploits that might come into the branch office or telecommuter personal computers, which could in turn affect the corporate network.
Move Worm Protection to the Network Edge
Network attacks and exploits come from not only the Internet, but often from within the corporate network itself. These attacks or exploits could be deliberate or inadvertent (for example, an infected laptop brought into the office and connected to the corporate LAN). Deploying Cisco IOS IPS within the corporate network helps mitigate attacks, and helps prevent exploits from spreading within the network.
In the network topology shown in Figure 1, the branch offices have client PCs and might provide guest access to customers. Applying IOS IPS on the inside interface on the branch router will prevent attacks from spreading to the headquarters and the rest of the network. Moving worm prevention as close to the network edge as possible will mitigate the attacks and exploits from their early stages into the network.
Protect Branch-Office Servers
In the network topology shown in Figure 1, the branch offices not only have client PCs but also hosting servers on the inside network. Deploying IOS IPS on the branch router will protect inside networks and servers from being attacked without adding additional devices to perform this function.
By enabling Cisco IOS IPS together with IP Security (IPsec) VPN, Network Admission Control (NAC), and Cisco IOS Firewall, a Cisco router can perform encryption, firewalling, and traffic inspection at the first point of entry into the network-an industry first. This setup reduces the additional devices needed to support the system, reduces operating and capital expenditures, and enhances security.
General Cisco IOS IPS Structure
Cisco IOS IPS uses technology from Cisco Intrusion Detection System (IDS) and Cisco IPS sensor product lines, including Cisco IDS 4200 Series stand-alone Sensors, Cisco Catalyst® 6500 Series IDS Services Modules, and IPS modules for Cisco ISR routers and ASA appliances. Cisco IOS IPS relies on signature micro-engines (SMEs) to support IPS signatures. Each engine categorizes a group of signatures, and each signature detects patterns of misuse in network traffic. For example, all HTTP engine signatures are grouped under the HTTP engine and these signatures specialize in attacks and exploits over the http channel. Currently, Cisco IOS IPS supports approximately 2000 signatures-part of the common set of signatures that Cisco IPS sensors and modules support-helping ensure that all Cisco products use a common set of attack signatures. These signatures are available for download from Cisco.com at http://www.cisco.com/cgi-bin/tablebuild.pl/ios-v5sigup.
Starting from 12.4(11)T, IOS IPS uses Cisco IPS version 5.x/6.0 format signatures and a simpler signature update process. IOS IPS loads and saves entire signature information from the signature package posted on Cisco.com. Since IOS IPS can not load all the signatures, the IOS IPS configuration governs which signatures are loaded such as IOS IPS category based CLI configuration. In addition, the signature update process can be configured to automatically download s signature package from a locally accessible storage location, such as a local TFTP server. For detailed information of how to use IOS IPS in 5.x signature format, please refer the step by step guide at: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6634/prod_white_paper0900aecd805c4ea8.shtml.
Cisco IOS IPS and Cisco IDS Network Module
The Cisco IDS Network Module is available on Cisco modular access router platforms. Cisco does not support the configuration when both Cisco IOS IPS and the Cisco IDS Network Module are used at the same time. To configure the Cisco IDS Network Module, visit: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a008045922b.html
Packet Flow
Packets traverse routers in a particular order. When multiple features are configured on a router, understanding the traffic flow helps in the understanding of how the router works and how each feature plays a role in inspecting the traffic passing through the router.
Packets Flowing from Inside the Network to Outside the Network
Figure 2 shows how a packet is scanned against any inbound IPS policy at the inside interface. Next, any inbound access control list (ACL) is checked. Then Network Address Translation (NAT) and routing is applied. Finally, inbound Cisco IOS Firewall policy inspects the packet. If the stateless IPS input policy drops a packet, the other features will not see the packet.
As the packet is on its way out of the router, at the outside interface the packet is checked against atomic signatures per outbound IPS policy and then checked against any outbound ACLs, followed by NAT, and stateful inspection based on outbound Cisco IOS Firewall and IPS policy. Finally, the packet is encrypted by any IPsec rule as it leaves the router.
Figure 2. Packets Flowing from Inside to Outside the Network
Packets Flowing from Outside the Network to Inside the Network
In Figure 3, as the packet enters from the outside interface, the IPsec policy decrypts the packet (if needed). Next, the inbound IPS policy scans the packet for atomic signatures, followed by inbound ACL checks. The NAT and routing process follows. If the inbound IPS policy drops a packet, the other features will not see the packet.
At the inside interface, the packet is checked against atomic signatures per outbound IPS policy, followed by outbound ACL checking, NAT process, and finally stateful inspection based on outbound Cisco IOS Firewall and IPS policy. All this occurs before the packet makes its way onto the private network.
Figure 3. Packets Flowing from Outside to Inside the Network
Signature Micro-Engines and Signatures
Signature Micro-engines
A Signature Micro-engine (SME) is a component of Cisco IOS IPS that supports signatures in a certain category or protocol. Customized for the protocol and fields it is designed to inspect, each engine defines a set of legal parameters that have allowable ranges or sets of values. The SMEs look for malicious activity in a specific protocol. Signatures can be defined for any of the supported SMEs using the parameters offered by those micro-engines. Packets are scanned by the micro-engines that understand the protocols contained in the packet.
A regular expression is a systematic way to specify a search for a pattern in a series of bytes. When a signature engine is built (building refers to loading an SME on the router when Cisco IOS IPS is enabled on the interface), it may compile one or more regular expressions. Compiling a regular expression requires more memory than the final storage of the regular expression-important information to know when considering loading and merging new signatures.
Cisco IOS IPS also introduces the concept of parallel scanning. All the signatures in a given micro-engine are scanned in parallel, in a single pass of the packet bytes, rather than serially (one signature at a time). Each SME extracts values from the packet and passes portions of the packet to the regular expression engine. The regular expression engine can search for multiple patterns at the same time (in parallel). Parallel scanning increases efficiency and results in higher throughput.
In Cisco IOS Software release 12.4(11)T, Cisco IOS IPS combined 5 ATOMIC engines into one single ATOMIC.IP engine, although flexibility in writing atomic signatures increased, the behavior for existing signatures did not change. Table 3 shows a list of SMEs supported by Cisco IOS Software.
Table 3. SMEs Supported by Cisco IOS IPS
For more details about SMEs and signature parameters, refer to the "Advanced Topics" section at the end of this document.
Signature Actions
IOS IPS supports signature action configuration on a per-signature basis. Each signature can be configured to any combination of the following actions:
• produce-alert: send a alarm when a signature fires
• deny-packet-inline: drop the packet when a signature fires, this action will not send TCP reset
• reset-tcp-connection: send TCP reset to both the attacker and victim when a signature fires
• deny-attacker-inline: deny the attacker ip address by using a dynamic access list
• deny-connection-inline: deny the attacker session by using a dynamic access list
Customers can use Cisco Router and Security Device Manager (SDM) version 2.4 or Cisco Security Manager (CSM) version 3.1 to manage Cisco IOS IPS, or customers can use CLI to tune signature parameters. The event action configuration can be performed either based on signature category groups or on a per signature basis. For detailed CLI configuration, refer to the Cisco IOS IPS configuration guide at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124newft/124t/124t11/ips_v5.htm
Signature Category and Signature CLI Package
Signature category is a group of relevant signatures represented by a meaningful name. For example, p2p category contains all peer-to-peer application signatures such as Bittorrent, eDonkey and Kazaa. The signature category information is an integral part for each signature update in version 5.x signature format.
To configure Cisco IOS IPS, customers need to download a signature package in Cisco IPS version 5.x format and load it to the Cisco IOS IPS router. Detailed configuration information can be found in the step by step guide: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6634/prod_white_paper0900aecd805c4ea8.shtml
Cisco maintains backward compatibility with the basic and advanced signature sets. The following example details how to configure the basic signature set. First, for category "all", retire all signatures. This instructs Cisco IOS not to compile any signatures. Second, select Cisco IOS IPS category "basic" and configure retired parameter to false, this instructs Cisco IOS to compile all signatures for "basic" category for IOS IPS.
ip ips signature-category
category all
retired true
category ios_ips basic
retired false
Cisco recommends customers use either the basic or advanced category (not both) since the advanced category is a superset of basic category. Customers can add or remove signatures after enabling a signature category by using management applications such as CSM and SDM or by using CLI based configurations.
For additional configuration details, refer to the Cisco IOS IPS configuration guide at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124newft/124t/124t11/ips_v5.htm
Memory Consideration
With sufficient memory, Cisco IOS IPS supports more than 2000 signatures. However the number of supported signatures also varies by router platform. The number of supported signatures and engines depends only on the memory available. The basic and advanced signature categories contain optimum combination of signatures for all standard memory configurations, providing a good starting point.
While adding new signatures, consider that signatures in STATE, STRING.TCP, and STRING.UDP engines are more memory-intensive than other signature engines. From Cisco IOS Software release 12.4(3a) onward, these three engines have been optimized to support more signatures and use less memory than earlier releases.
Alarming and Logging
Cisco IOS IPS supports alarming and logging of events through syslog and SDEE. Cisco SDM version 2.2 and later releases as well as Cisco Security Monitoring, Analysis, and Response System (CS-MARS) can be used to view signature alarms, events, and logs.
In addition, the Cisco IPS Event Viewer (IEV) offers a free monitoring solution for small-scale IPS deployments. With ability to monitor up to 5 IPS devices, the IPS Event Viewer is easy to set up and use, and provides the user with:
• Support for IOS IPS through SDEE compatibility
• Customizable reporting
• Tunable notification actions such as e-mail and paging
• Visibility into applied response actions, learned threat rating
Cisco IPS Event View can be downloaded from Cisco.com at: http://www.cisco.com/cgi-bin/tablebuild.pl/ids-ev
Cisco IOS Firewall
One of the main advantages of running Cisco IOS Firewall and Cisco IOS IPS together is the additional layer of security this setup provides. Cisco IOS Firewall helps ensure that traffic policies are enforced. For example, if inspection rules are configured to allow TCP packets only from a certain source address, the firewall inspects that traffic stream. Cisco IOS IPS works together with Cisco IOS Firewall and verifies this TCP traffic against its signature database. If a hacker manages to spoof the source IP address and attempts to send an attack, the firewall inspects the source address and allows the traffic. However, Cisco IOS IPS finds a match against the signature database and drops the malicious traffic or denies (shuns) all or only bad traffic from the spoofed IP address.
IMPORTANT WARNING
You should understand and set proper DOS protection threshold values for your network. Refer the section below for details.
Understanding the Inspection Threshold Values
Cisco IOS IPS uses the same set of threshold values as Cisco IOS Firewall. These threshold values are used to mitigate DoS attacks. Cisco IOS Firewall maintains counters of the number of "half-open" or "embryonic" TCP connections, as well as the total connection rate through the firewall and IPS software. These embryonic connections are TCP connections that have not completed the SYN-SYN/ACK-ACK handshake that is always used by TCP peers to negotiate the parameters of their mutual connection. Some malicious individuals write worms or viruses that infect multiple hosts on the Internet, and then attempt to overwhelm specific Internet servers with a SYN attack, in which large numbers of SYN connections are sent to a server by multiple hosts on the public Internet or within an organization's private network. SYN attacks represent a hazard to Internet servers, because a server connection table can be loaded with "bogus" SYN connection attempts that arrive faster than the server can deal with the new connections. This type of attack is called a denial-of-service (DoS) attack, because the large number of connections in the victim's server TCP connection list prevents legitimate users from gaining access to the victim's Internet servers.
Cisco IOS Firewall provides protection from DoS attacks as a default when an inspection rule is applied. The DoS protection is enabled on the interface, in the direction in which the firewall is applied, for the protocols that the firewall policy is configured to inspect. DoS protection is enabled on network traffic only if the traffic enters or leaves an interface with inspection applied in the same direction as the initial movement of the traffic. Cisco IOS Firewall inspection provides several adjustable values to protect against DoS attacks. These settings have default values that may interfere with proper network operation if they are not configured for the appropriate level of network activity:
• ip inspect max-incomplete high <number-of-connections> (default 500)
• ip inspect max-incomplete low <number-of-connections> (default 400)
• ip inspect one-minute high <number-of-connections> (default 500)
• ip inspect one-minute low <number-of-connections> (default 400)
• ip inspect tcp max-incomplete host <half-open-sessions> (default 50) [block-time <block-time-in-minutes> (default 0)]
These parameters configure the points at which the firewall router DoS protection begins to take effect. When the router DoS counters exceed the default or configured values, the router resets one old embryonic connection for every new connection that exceeds the configured max-incomplete or one-minute high values, until the number of embryonic sessions drops below the max-incomplete low values. The router sends a syslog message if logging is enabled, and if IPS is configured on the router, the router sends a DoS signature message through SDEE. If the DoS parameters are not adjusted to normal network behavior, normal network activity may trigger the DoS protection mechanism, causing application failures, poor network performance, and high CPU use on the Cisco IOS Firewall router.
These threshold values are important in protecting the network from DoS and DDoS attacks. Threshold values should be set appropriately to help ensure smooth operation of the network. If the values are set too high, DoS and DDoS attacks might not be blocked at the early stage of the attack. On the other hand, if the values are set too low, legitimate traffic might get dropped because of the lower limit imposed by the thresholds.
The following example shows the default threshold configuration values:
Router#show ip inspect all
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [400:500] connections
(low threshold 400, high threshold 500)
max-incomplete sessions thresholds are [400:500]
(low threshold 400, high threshold 500)
max-incomplete tcp connections per host is 50. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
dns-timeout is 5 sec
Tuning the Inspection Threshold Values
Although it cannot be completely disabled, the firewall DoS protection can be adjusted so that it does not take effect unless a very large number of embryonic connections are present in the firewall router Stateful Inspection session table.
Follow this procedure to tune the firewall DoS protection to the activity of the network:
Step 1. Be sure the network is not infected with viruses or worms that could lead to erroneously large embryonic connection values. If the network is not "clean", there is no way to properly adjust your firewall DoS protection.
Step 2. Set the max-incomplete high values to very high values:
ip inspect max-incomplete high 20000000
ip inspect one-minute high 100000000
ip inspect tcp max-incomplete host 100000 block-time 0
These settings will prevent the router from providing DoS protection during the network connection patterns observation period. If you wish to leave DoS protection disabled, stop following this procedure now.
Step 3. Clear the IOS Firewall statistics, using the following command:
show ip inspect statistics reset
Step 4. Leave the router configured in this state for some time, perhaps as long as 24 to 48 hours, to observe the network pattern over at least a full day's activity cycle. While the values are adjusted to very high levels, your network will not benefit from Cisco IOS Firewall or IPS DoS protection.
Step 5. When your observation period is over, check the DoS counters with the following command (the key parameters for tuning DoS protection are highlighted in BOLD):
router#show ip inspect statistics
Packet inspection statistics [process switch:fast switch]
tcp packets: [528:22519]
udp packets: [318:0]
Interfaces configured for inspection 1
Session creations since subsystem startup or last reset 766
Current session counts (estab/half-open/terminating) [1:0:0]
Maxever session counts (estab/half-open/terminating) [48:12:5]
Last session created 00:12:21
Last statistic reset never
Last session creation rate 0
Last half-open session total 0
Step 6. Configure ip inspect max-incomplete high to a value 25-percent higher than the indicated maxever session count half-open value on the router.
For example:
Maxever session counts (estab/half-open/terminating) [920:460:331]
460 * 1.25 = 575, thus, configure:
router(config)#ip inspect max-incomplete high 575
Step 7. Configure ip inspect max-incomplete low to the value the router displayed for its maxever session count half-open value.
For example:
Maxever session counts (estab/half-open/terminating) [920:460:331]
Thus, configure:
router(config)#ip inspect max-incomplete low 460
Step 8. The counters for ip inspect one-minute high and one-minute low maintain a sum of all TCP, UDP and ICMP connection attempts during the preceding minute of the router's operation, whether the connections have been successful or not. A rising connection rate could be indicative of a worm infection on a private network, or an attemplted DoS against a server. Cisco IOS IPS does not maintain a value of the maxever one-minute connection rate, so you must calculate the value you will apply based on observed maxever values. To calculate the ip inspect one-minute low value, multiply the "established" value by 3.
For example:
Maxever session counts (estab/half-open/terminating) [920:460:331]
920 * 3 = 2760, thus, configure:
ip inspect one-minute low 2760
Step 9. Calculate and configure ip inspect max-incomplete high. The ip inspect one-minute high value should be 25-percent greater than the calculated one-minute low value.
For example:
ip inspect one-minute low (2760) * 1.25 = 3450, thus, configure:
ip inspect one-minute high 3450
Step 10. Determine a value for ip inspect tcp max-incomplete host according to the capability of the server.
Step 11. Monitor the network DoS protection activity. Ideally, a syslog server should be used and occurrences of DoS attack detection should be recorded. If detection happens frequently, some adjustments of the DoS protection parameters may be needed.
No predefined threshold values suit every network. The best practice is to fine-tune the network based on real network usage patterns. When the network is operational with a first set of threshold values, look out for the inspection logs and network usage pattern changes. If legitimate traffic is getting dropped at the firewall, increase these threshold values. If a DoS or DDoS attack is expected, decrease the threshold values such that the firewall can detect and mitigate the attack at an earlier time.
Understanding the Inspect Hash Table Size
The ip inspect hashtable-size command is available to fine-tune the system hash-table size for session counters. How is this command related to session threshold values? A firewall inspects packets and keeps track of sessions by using a hash table. When it inspects packets, it must find out which session the packet belongs to; thus the firewall implements a hash table to search for the session of the packet. Collisions in a hash table result in poor hash function distribution because many entries are hashed into the same bucket for certain patterns of addresses. As the number of sessions increases, the collisions increase, thereby increasing the length of the linked lists and deteriorating the throughput performance.
As a general rule, to configure inspect hash-table size, the ip inspect hashtable-size command can be used to dynamically change the hash-table size to help ensure optimum performance. The hash-table size should be increased when the total number of sessions running through the firewall router is approximately twice the current hash size, and should be decreased when the total number of sessions is reduced to approximately half the current hash size. Essentially, try to maintain a 1:1 ratio between the number of sessions and the size of the hash table.
Deploying to Multiple Routers
Table 4 summarizes the options for managing Cisco IOS IPS on multiple routers.
Table 4. Managing Cisco IOS IPS on Multiple Routers
|
Software or Hardware |
Number of Devices |
Version |
Product Home Page |
|
Cisco SDM1 |
1-10 |
2.4 |
|
|
Cisco Security Manager2 |
10-500 |
3.1 |
|
|
Cisco Configuration Engine |
500-2500 |
2.0 |
http://www.cisco.com/en/US/products/sw/netmgtsw/ps4617/tsd_products_support_series_home.html |
|
1SDM version 2.4 requires 12.4(11)T2 and later T-train releases
2CSM version 3.1 requires 12.4(11)T2 and later T-train releases
|
SDM is best used for managing 1 to 10 devices. Cisco Security Manager should be used when managing from 10 to 500 Cisco IOS IPS routers or Cisco IPS sensors. For large-scale deployment of up to 2500 devices, Cisco Configuration Engine should be used.
Advanced Topics
There are a total of 13 engines in 12.4(11)T and later release.
ATOMIC-IP Engine
Atomic engine do not store persistent data across packets; instead, it can fire an alarm from the analysis of a single packet. Therefore, the basic features of the engine do not require attachment to a nonglobal StorageKey-they use the StorageKey xxxx. Because atomic engine has no storage, atomic engine signatures are essentially 1:1 signatures.
Starting in Cisco Software release12.4(11)T, the previous ATOMIC.L3.IP, ATOMIC.ICMP, ATOMIC.UDP, ATOMIC.IPOPTIONS and ATOMIC.TCP engines are merged into one single engine-ATOMIC-IP.
MULTI-STRING Engine
The MULTI-STRING engine inspects Layer 4 protocol packets in a flexible manner. This engine also supports Trend Labs network virus signatures normally deployed to Cisco IOS IPS through the Cisco Incident Control System (ICS).
String Engines
String engines include STRING-ICMP, STRING-TCP and STRING-UDP engines. String engine is a generic-based pattern-matching inspection engine for ICMP, TCP, and UDP, it uses a regular expression engine that can combine multiple patterns into a single pattern-matching table, allowing for a single search through the data.
Service Engines
Service engines include SERVICE-HTTP, SERVICE-FTP, SERVICE-RPC and SERVICE-DNS engines. Service engines analyze Layer 5+ traffic between two hosts. These signatures are 1:1 signatures that track persistent data on the stream (AaBb) for TCP or QUAD (AaBb) for User Datagram Protocol (UDP). The engines decode and interpret the Layer 5+ payload in a manner similar to that for the live service. A full-service-like decode may not be necessary if the partial decode provides adequate information to inspect the signatures. The engines decode enough of the data to make the signature determinations but do not decode more than is needed, minimizing CPU and memory load.
Service engines have common characteristics, such as using the output from the stream processor, but each engine has specific knowledge of the service that it is inspecting. Service engines supplement the capabilities of the generic string engine, specializing in algorithms where using the string engine is inadequate or undesirable.
The purpose of the service decode is to mimic the interpretation of the live server of the Layer 5+ payload. These interpretations are used primarily in the determination of signatures, as the decoded fields are compared to the signature parameters.
As the engine is decoding, errors with bad payloads can occur. These error conditions are linked to different kinds of signatures, known as protocol violations or error traps, which occur when the engine is decoding the payload and an error occurs because of a malformation in the payload that violates the rules of the service protocol. An error trap handles this malfunction in the analysis code. Specifying the trap conditions that map to signatures is done by using the normal parameters, such as the SERVICE-FTP with BadPort. In some cases, these trap conditions can be combined to form a signature that results when multiple trap conditions are encountered. However, in most cases, the trap conditions have a 1:1 mapping to the trap signatures.
STATE Engine
The State engine provides state-based regular expression-based pattern inspection of TCP streams. A state engine is a device that stores the state of something and at a given time can operate on input to transition from one state to another and/or cause an action or output to take place. State machines are used to describe a specific event that causes an output or alarm.
NORMALIZER Engine
The Normalizer engine deals with IP fragment reassembly. Intentional or unintentional fragmentation of IP datagrams can hide exploits making them difficult or impossible to detect. Fragmentation can also be used to circumvent access control policies. And different operating systems use different methods to queue and dispatch fragmented datagrams. If the sensor has to check for all possible ways that the end host can reassemble the datagrams, the sensor becomes vulnerable to DoS attacks. Reassembling all fragmented datagrams inline and only forwarding completed datagrams, refragmenting the datagram if necessary, prevents this.
References
• Cisco IOS IPS on Cisco.com: http://www.cisco.com/go/iosips
• Cisco IOS IPS Signature Package: