A-24
Cisco Intrusion Prevention System Sensor CLI Configuration Guide for IPS 7.2
OL-29168-01
AppendixA System Architecture
SensorApp
that were quiescent during the hold-down period will not be forwarded and will be allowed to
timeout. Those streams that were synchronized during the hold-down period are allowed to
continue.
•
Signature Analysis Processor—This proces sor dispatches packets to the inspectors that are not
stream-based and that are configured for inter est in the packet in process.
•
Slave Dispatch Processor—A process found only on dual CPU systems.
The SensorApp also supports the following units:
•
Analysis Engine—The Analysis Engine handles sensor configuration. I t maps the interfaces and
also the signature and alarm channel policy to the configured interfaces.
•
Alarm Channel—The Alarm Channel processes all signature events generated by the inspectors. Its
primary function is to generate alerts for each event it is passed.
Inline, Normalization, and Event Risk Rating Features
The SensorApp contains the following inline, normalization, and event risk rating features:
•
Processing packets inline
When the sensor is processing packets in the data path, all packets are forwarded w ithout any
modifications unless explicitly denied by policy configuration. Because of TCP normalization it is
possible that some packets will be delayed to ensure pro per coverage. When policy violations are
encountered, the SensorApp allows for the configuration of actions. Additional actions are available
in inline mode, such as deny packet, deny flow, and deny attacker.
All packets that are unknown or of no interest to the IPS are forwarded to the paired interface with
no analysis. All bridging and routing protocols are forwarded with no participation other than a
possible deny due to policy violations. There is no IP stack associated with any interface used for
inline (or promiscuous) data processing. The current support for 80 2.1q packets in promiscuous
mode is extended to inline mode.
•
IP normalization
Intentional or unintentional fragmentation of IP datagrams can serve to hide exploits making them
difficult or impossible to detect. Fragmentation can also be used to circumvent access control
policies like those found on firewalls and routers. 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 will reassemble the datagrams, it makes the sensor vulnerable to denial of
service attacks. Reassembling all fragmented datagrams inline and only forwarding completed
datagrams, refragmenting the datagram if necessary, is the solution to this problem. The IP
Fragmentation Normalization unit performs this function.
•
TCP normalization
Through intentional or natural TCP session segmentation, some classes of attacks can be hidden. To
make sure policy enforcement can occur with no false positives and false negatives, the state of the
two TCP endpoints must be tracked and only the data that is actua lly processed by the real host
endpoints should be passed on. Overlaps in a TCP stream can occur, but are extremely rare except
for TCP segment retransmits. Overwrites in the TCP session should not occur. If overwrites do
occur, someone is intentionally trying to elude the security policy or the TCP stack implementation
is broken. Maintaining full information about the state of both endpoints is not possible unless the
sensor acts as a TCP proxy. Instead of the sensor acting as a TCP proxy, the segments will be ordered
properly and the normalizer will look for any abnormal packets associated with evasion and attacks.