CCIE Study Notes

Here is the White Paper Listing on IOS IPS. And the IPS configuration guide - Signature Engines.

The IOS IPS and IPS appliances are basically the same. They provide the same functionality and use the same principles. So I'm going to use 5.4 as a "part 2" of 5.3.

Let's go a bit deeper into Signature Engines. A signature engine is a component of the Cisco IPS that is designed to support many signatures in a certain category. An engine is composed of a parser and an inspector. Each engine has a set of parameters that have allowable ranges or sets of values.

AIC Engine and Sensor Performance:
"Application policy enforcement is a unique sensor feature. Rather than being based on traditional IPS technologies that inspect for exploits, vulnerabilities, and anomalies, AIC policy enforcement is designed to enforce HTTP and FTP service policies. A large performance penalty is associated with using this feature. When AIC is enabled, the overall bandwidth capacity of the sensor is reduced."

Parameters specific to the AIC HTTP engine:
Content types
Define Web Traffic Policy
Max Outstanding Requests Overrun
Msg Body Pattern
Request Methods
Transfer Encoding

Parameters specific to the AIC FTP engine:
FTP commands
Unrecognized FTP command

The Atomic engine contains signatures for simple, single packet conditions that cause alerts to be fired.

Atomic IP Advanced engine signatures do the following:
- Inspect for anomalies in IP addresses, for example, spoofed addresses.
- Inspect for bad information in the length fields of the packet.
- Fire informational alerts about the packet.
- Fire higher severity alerts for the limited set of known vulnerabilities.
- Duplicate any IPv6-specific signatures in Engine Atomic IP that can also apply to IPv6.
- Provide default signatures for identifying tunneled traffic based on IP address, port, protocol, and limited information from the packet data.

You should probably read through the Atomic IP Advanced Engine Restrictions, but I would focus more on the capabilities.

The Atomic IP engine defines signatures that inspect IP protocol headers and associated Layer 4 transport protocols (TCP, UDP, and ICMP) and payloads. The Atomic engines do not store persistent data across packets. Instead they can fire an alert from the analysis of a single packet.

Note the difference between the Atomic IP engine and the Atomic IP Advanced engine.

The Atomic IPv6 engine detects two IOS vulnerabilities that are stimulated by malformed IPv6 traffic. These vulnerabilities can lead to router crashes and other security issues.
There are eight Atomic IPv6 signatures. The Atomic IPv6 inspects Neighborhood Discovery protocol of the following types:
Type 133—Router Solicitation
Type 134—Router Advertisement
Type 135—Neighbor Solicitation
Type 136—Neighbor Advertisement
Type 137—Redirect

Notice that everything else for IPv6 falls under Atomic IP Advanced.

The Meta engine defines events that occur in a related manner within a sliding time interval. This engine processes events rather than packets. As signature events are generated, the Meta engine inspects them to determine if they match any or several Meta definitions. The Meta engine generates a signature event after all requirements for the event are met.

The Normalizer engine deals with IP fragment reassembly and TCP stream reassembly.

The Service engines have common characteristics but each engine has specific knowledge of the service that it is inspecting. The Service engines supplement the capabilities of the generic string engine specializing in algorithms where using the string engine is inadequate or undesirable.

I would think that if they are going to hit on the Service engines, it would be something obvious. As long as you know and understand how these protocols work, you should be able to nail any questions on the Service engines.

The Traffic Anomaly engine contains nine anomaly detection signatures covering the three protocols (TCP, UDP, and other). Each signature has two subsignatures, one for the scanner and the other for the worm-infected host (or a scanner under worm attack).

The Traffic ICMP engine analyzes nonstandard protocols, such as TFN2K, LOKI, and DDoS. There are only two signatures (based on the LOKI protocol) with user-configurable parameters.

The Trojan engines analyze nonstandard protocols, such as BO2K and TFN2K. There are three Trojan engines: Trojan BO2K, TrojanTFN2K, and Trojan UDP.

Secure Device Event Exchange (SDEE) messages report on the progress of Cisco IOS IPS initialization and operation. I found an interesting post on Managing CISCO IOS IPS with Syslog or SDEE and Troubleshooting on the Cisco Support Forums. You should probably be familiar with this - or at least have an awareness of it and relate it to IPS messaging.

The ASA book also has a section on Cisco IPS Software Architecture that should be familiar to you.
The major components of CIPS software include the following:

MainApp
SensorApp
Attack Response Controller (formally known as NAC)
AuthenticationApp
cipsWebserver
Logger
EventStore
Transactional Services for Security Device Event Exchange (SDEE)
NotificationApp
InterfaceApp
CLI

And with that, I'm done with my IPS review. Note that with IPS, you set it up and then you TUNE it. If you set it up in monitoring mode, you can use that to tune the signatures until it's spitting out reasonable alerts. Remember the previous section on false positives. You want to get your signatures tuned so that you can respond to alerts and not get overwhelmed by false positives to the point where you're ignoring true positives.