ASA and IPS Parallel Features – Part II

Tuesday, July 19, 2011

Dawn Hopper


Article by Doug McKillip

ASA and IPS Parallel Features – Part I HERE

To continue a post from several weeks ago, I’d like to compare another parallel feature between the Cisco ASA security appliance and the Cisco Intrusion Prevention System (IPS): the normalizer function.

On both device platforms this component is a valuable defense mechanism against both fragmentation and denial-of-service (DoS) attacks. Once more I’ll highlight key operational characteristics.

Normalizer Engine – Cisco IPS

On the Cisco IPS, the normalizer engine can only be utilized if the sensing appliance or module is configured for in-line operation. In other words, this means that the sensor has to be directly in the path of packet flow as opposed to promiscuous operation where mere copies of packets are seen.

The value of the normalizer with inline mode cannot be overstated; it can reassemble entire fragmented streams as well as modify packets with illegal and/or malformed options before they reach their intended target.

Not surprisingly, some technical documents refer to this function as “packet scrubbing”. A sample display of signatures belonging to the normalizer engine category from IPS Manager Express is shown below:


As the screenshot suggests, the “modify packet” signature action effectively “sanitizes” the offending packet to either clear an option or provide some other adjustment.

Normalizer Function – Cisco ASA

Now, let’s look at the ASA normalizer function. In its most rigorous form, normalization of packets is implemented using a TCP Map which I covered before. The screenshot below shows the default settings for any administratively-created map.

Note that some similar detection capabilities exist (e.g. bad checksum, TTL evasion, etc). The major difference here, however, is that the IPS has these modify actions enabled by default whereas the ASA doesn’t unless a TCP Map is explicitly configured and referenced in a service policy rule.


Normalizer Function Across Platforms

One further point regarding both platforms which will serve as a brief introduction to a future post – use of the normalizer on either the ASA or the Intrusion Prevention System assumes that the device sees BOTH directions of traffic flow.

If asymmetric routing paths exist for return traffic to bypass either device, not only is normalizer function rendered ineffective, but the state-ful inspection capabilities are as well. Additional implications of this bypass will be covered in a later article.

Cross-posted from Global Knowledge

Possibly Related Articles:
Cisco Network Security Intrusion Detection IDS/IPS TCP Deep Packet Inspection ASA
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.