Occasionally I will be asked a question when I teach the Cisco IPS class of what goes on “under the covers” of the IPS appliance between the point where an IP packet arrives at an interface and where it exits the module or appliance. As an attempt to explain that, I have formalized, by way of a PowerPoint diagram, a whiteboard example which illustrates the core components below:
Let’s step through the key elements of packet analysis in the sensor. First, when the packet arrives at the input interface (part of an inline pair), it is subject to what is referred to as the Normalizer Engine. This component ensures that the IP and TCP header check-sums are correct, along with other header fields such as the IP fragmentation fields and TCP flags. Virtual packet reassembly is done here to prevent fragmentation exploits.
Next, the IPS Signature Engines are processed in parallel. It is here that the IP, TCP and application headers can be analyzed via pattern matching algorithms and, optionally, deep packet inspection can be undertaken using the Application Interface Controller (AIC) engine. If there are no matches, the packet is allowed to exit the other interface in the inline pair. With a match however, the signature configuration is examined for the action(s) to be taken.
Before the sensor actually performs these actions, any configured Event Action Overrides and/or Event Action Filters must be evaluated. With overrides, the sensor calculates an overall Risk Rating based on the severity of the alert, the user-defined value of the destination target, the fidelity (or trustworthiness) of the signature, and the relevance of the attack on the target operating system. If the minimum risk rating in the override is met, then additional actions are added.
The Event Action Filter acts in a “reverse” fashion, subtracting actions from a matched signature to “exempt”, for example, a vulnerability scanner from being blocked through the sensor. The criteria for a filter are more complex than those for the override (which is solely based on Risk Rating) and are a subject for a future blog article. Once both the configured override(s) and filter(s) have been evaluated, the alert is recorded in the Event Store, and, if no deny actions remain, the packet is permitted to flow.
If a deny action exists for the matched signature, not only can the offending packet be dropped, but subsequent packets can also be stopped. This latter function is accomplished via a configured deny attacker setting.
At the bottom of the block diagram is the Command/Control interface, used for both provisioning and monitoring the sensor. Since the Event Store is limited to only 30 Megabytes of space, the use of real-time monitoring software or hardware (e.g. Cisco MARS) is required.
Author: Doug McKillip