Cisco ASA Basic Internet Protocol Inspection

Overview

When many people think of protocol inspection, they think of a process that reads the data of a packet and inspects it for some amount of wrongdoing. In reality, the packet inspection feature of the Adaptive Security Appliance (ASA) is typically used to help make the protocol work better. This article covers some of the common Internet protocol inspection features that can be enabled  on the ASA.

What Exactly Is Internet Protocol Inspection?

For many protocols, protocol inspection is used only as a security technique because the protocol itself only uses a single commonly known port. However, what about those protocols that do not just use common ports; these protocols can be quite interesting to work with when configuring a firewall or Network Address Translation (NAT) device. This is because many of these protocols embed these dynamic port assignments within the user data portion of the traffic or open new secondary channels altogether. In these situations, for the protocol to be able to be used as expected, some amount of packet inspection is required so that the ASA can keep track of which ports are allowed through the firewall because they are attached to a primary data channel that is permitted.

Internet protocol inspection also enables the ASA administrator to control traffic based on a number of different parameters that exist within the Internet traffic, including the information contained within the data portion of the traffic. This article, because of its limited scope, cannot covers all the various possible combinations.

DNS Inspection

DNS inspection on the ASA is enabled by default and performs a number of different functions that many people might not even recognize. When enabled, DNS inspection makes the life of the ASA administrator much easier and keeps the relationship with the DNS administrators and the internal user base much happier. Functions that it provides include the following:

• Translates DNS record information based on the configuration of the NAT commands alias, static, and nat; this is referred to often as DNS rewrite. This translation affects only DNS A records and does not affect DNS PTR records.
• Enforces a maximum DNS message length. (The default is 512 bytes.)
• Enforces the domain name length of 255 bytes.

DNS inspection can also be used to control the behavior of the ASA based on a number of different traffic-matching criteria.

FTP Inspection

Like DNS inspection, FTP inspection is also enabled by default and provides a number of different functions. FTP can be a little bit interesting to work with when dealing with firewalls or NAT; this is because it can use different ports for control and data traffic and can use dynamic/well-known ports. The FTP inspection engine performs four main duties:

• Prepares dynamic secondary data connections
• Tracks the FTP command-response sequence
• Generates an audit trail
• Translates the embedded IP address

FTP inspection can also be used to control the behavior of the ASA based on a number of different traffic-matching criteria.

IP Options Inspection

The Options field within the IP header, commonly referred to as IP Options, provides some additional control of traffic. IP Options inspection is enabled by default. Although this field is typically not needed for most “normal” communications, in some situations the information is required (including for Integrated Services [IntServ]). The IP Options inspection engine enables you to check three different IP options in the packet:

• The End of Options List (EOOL): This marks the end of the IP options list.
• The No Operation (NOP): This is used to provide internal padding to align with the 32-bit IP header boundary.
• The Router Alert (RTRALT): This option is used to notify transit providers to inspect the contents of the packet even when the packet is not destined for that router. This is important when implementing protocols that require complex processing along the delivery path (This includes Resource Reservation Protocol [RSVP], which is used by IntServ implementations.)

HTTP Inspection

HTTP inspection is not enabled by default, but if any HTTP traffic is passing through the ASA it can be an important addition to the configuration. The HTTP inspection engine performs the following functions:

• Enhanced HTTP inspection
• URL screening through N2H2 or Websense
• Java and ActiveX filtering

The HTTP inspection engine can (like both the DNS and FTP inspection engines) control the behavior of the ASA based on different traffic-matching criteria. For the HTTP inspection engine, these criteria include conformance checks against published Request For Comments (RFC) and control based on most of the fields contained within the HTTP portion of the traffic (for example, HTTP header, body, method, URI).

ICMP Inspection

ICMP inspection is not enabled by default. Without being enabled, ICMP traffic is automatically not permitted through the ASA at all without additional security policy configuration. Permitting ICMP through the ASA via access policy is not recommended by Cisco. The ICMP inspection engine creates “sessions” out of ICMP traffic and inspects it like TCP or UDP. The ICMP inspection engine ensures that ICMP cannot be used to attack the internal network. The ICMP inspection engine also alters the way that the ASA treats ICMP error messages. These alterations include the following:

• The mapped IP is changed to the real IP, and the IP checksum is modified (in the IP header).
• The ICMP checksum is modified because of the changes in the ICMP packet (in the ICMP header).
• The original packet mapped IP is changed to the real IP (in the payload).
• The original packet mapped port is changed to the real port (in the payload).
• The original packet IP checksum is recalculated (in the payload).

Summary

Although this is certainly not an exhaustive list of the available inspection engines on the ASA platform, it does cover some of the most commonly used ones. Other than the ones covered here, a few other inspection engines are enabled by default, including H.323 H.225 and RAS, NetBIOS Name Server over IP, RSH, SIP, SKINNY (SCCP), SMTP (ESMTP), SQL*Net, Sun RPC over UDP and TCP, and XDCMP. When configuring an ASA, it is important to understand what is enabled by default and how those things will affect the configuration and the behavior of the device. This article provided a basis for this understanding.

Author: Sean Wilkins.