The more I teach the new Cisco FIREWALL and the newest version (7.0) of the Implementing Cisco Intrusion Prevention Systems classes, the more I’m struck by the similarities of functions between the two major platforms. Now to some that would seem like a silly statement since it’s common knowledge that an IPS card can be installed into an ASA chassis; however, what I’ll illustrate in this post is the similar functionalities in processing that can take place either with the ASA chassis CPU or the IPS appliance/module CPU. This first part of a two-part series will deal with Application Inspection and Control, sometimes referred to as DPI or Deep Packet Inspection. Rather than give detailed commands, this will serve as a high-level comparison.
On the Cisco ASA, the Application Inspection and Control (often referred to simply as AIC) is not enabled by default. Instead, it must be configured using a OSI Layer 5-7 policy map which can be supplemented by a Layer 5-7 class map. When we compare the OSI and TCP/IP protocol stacks we see that OSI Layers 5 through 7 correspond to the TCP/IP Application layer, hence the classification. Implementation on the ASA requires that these “inspect maps” be linked to OSI Layer 3-4 policy maps which further defines the flow of interest (specific session, VPN tunnel, QoS characteristics, etc.)
As the IPS Manager Express configuration screen below shows, Application Inspection and Control is also disabled by default on the Cisco IPS sensors. While the ASA incorporates more protocols (DNS, H323, SIP, NetBIOS, etc.), the Cisco IPS only focuses on FTP and HTTP.
The reason for the “zeroing in” on these two protocols is because of both their longevity and their history of compromise. FTP has a history of weaknesses and exploits, and, as any network administrator will tell you, there are widespread concerns about users being allowed to do peer-to-peer HTTP tunneling of any sort. Often, in an effort to make application protocols easier to use, the authors of revised standards unknowingly give reconnaissance tools to the would-be cracker. RFC959, for example, added the use of a “SYST” command for OS fingerprinting which can be explicitly blocked on both the ASA and IPS hardware. RFC2616 is the current standard for HTTP version 1.1.
The ASA and IPS implementations of AIC/DPI each rely heavily on Regular Expression pattern matching, often called “regex” for short. As any “grep” user or PCRE (Perl-Compatible Regular Expressions) programmer will tell you, implementing the combination of upper and lower case letters and numbers combined with special symbols known as metacharacters can be quite complex. A free RegEx interpreter is available online at http://gskinner.com/RegExr/
To conclude, the reason that AIC undoubtedly is disabled by default is because of the burden this puts on both the CPU of the respective platform as well as the throughput speed. On the ASA platform when the CPU is required for per-packet processing, the control-plane path is used — resulting in at least a 25% drop in throughput. As a result, deep-packet inspection is frequently implemented very selectively — either based on specific flows in the case of the ASA or with a select group of enabled signatures on the IPS.