CLI Book 2: Cisco ASA Series Firewall CLI Configuration Guide, 9.3

How Inspection Engines Work

As illustrated in the following figure, the ASA uses three databases for its basic operation:

• ACLs—Used for authentication and authorization of connections based on specific networks, hosts, and services (TCP/UDP port numbers).
• Inspections—Contains a static, predefined set of application-level inspection functions.
• Connections (XLATE and CONN tables)—Maintains state and other information about each established connection. This information is used by the Adaptive Security Algorithm and cut-through proxy to efficiently forward traffic within established sessions.

Figure 6-1 How Inspection Engines Work

In this figure, operations are numbered in the order they occur:

1. A TCP SYN packet arrives at the ASA to establish a new connection.

2. The ASA checks the ACL database to determine if the connection is permitted.

3. The ASA creates a new entry in the connection database (XLATE and CONN tables).

4. The ASA checks the Inspections database to determine if the connection requires application-level inspection.

5. After the application inspection engine completes any required operations for the packet, the ASA forwards the packet to the destination system.

6. The destination system responds to the initial request.

7. The ASA receives the reply packet, looks up the connection in the connection database, and forwards the packet because it belongs to an established session.

The default configuration of the ASA includes a set of application inspection entries that associate supported protocols with specific TCP or UDP port numbers and that identify any special handling required.

When to Use Application Protocol Inspection

When a user establishes a connection, the ASA checks the packet against ACLs, creates an address translation, and creates an entry for the session in the fast path, so that further packets can bypass time-consuming checks. However, the fast path relies on predictable port numbers and does not perform address translations inside a packet.

Many protocols open secondary TCP or UDP ports. The initial session on a well-known port is used to negotiate dynamically assigned port numbers.

Other applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the ASA.

If you use applications like these, then you need to enable application inspection.

When you enable application inspection for a service that embeds IP addresses, the ASA translates embedded addresses and updates any checksum or other fields that are affected by the translation.

When you enable application inspection for a service that uses dynamically assigned ports, the ASA monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.

Inspection Policy Maps

You can configure special actions for many application inspections using an inspection policy map. These maps are optional: you can enable inspection for a protocol that supports inspection policy maps without configuring a map. These maps are needed only if you want something other than the default inspection actions.

See Configure Application Layer Protocol Inspection for a list of applications that support inspection policy maps.

An inspection policy map consists of one or more of the following elements. The exact options available for an inspection policy map depends on the application.

• Traffic matching criteria—You match application traffic to criteria specific to the application, such as a URL string, for which you then enable actions.

For some traffic matching criteria, you use regular expressions to match text inside a packet. Be sure to create and test the regular expressions before you configure the policy map, either singly or grouped together in a regular expression class map.

• Inspection class map—Some inspection policy maps let you use an inspection class map to include multiple traffic matching criteria. You then identify the inspection class map in the inspection policy map and enable actions for the class as a whole. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that you can create more complex match criteria and you can reuse class maps. However, you cannot set different actions for different matches.
• Parameters—Parameters affect the behavior of the inspection engine.

The following topics provide more details:

• Replacing an In-Use Inspection Policy Map
• How Multiple Traffic Classes are Handled

Replacing an In-Use Inspection Policy Map

If you need to replace an inspection policy map that you are already using in a service policy, use the following methods:

• All inspection policy maps—If you want to exchange an in-use inspection policy map for a different map name, you must remove the inspect protocol map command, and add it back with the new map. For example:

• HTTP inspection policy maps—If you modify an in-use HTTP inspection policy map (policy-map type inspect http), you must remove and reapply the inspect http map action for the changes to take effect. For example, if you modify the “http-map” inspection policy map, you must remove inspect http http-map command from the layer 3/4 policy, then add it back:

How Multiple Traffic Classes are Handled

You can specify multiple inspection class maps or direct matches in the inspection policy map.

If a packet matches multiple different match or class commands, then the order in which the ASA applies the actions is determined by internal ASA rules, and not by the order they are added to the inspection policy map. The internal rules are determined by the application type and the logical progression of parsing a packet, and are not user-configurable. For example for HTTP traffic, parsing a Request Method field precedes parsing the Header Host Length field; an action for the Request Method field occurs before the action for the Header Host Length field. For example, the following match commands can be entered in any order, but the match request method get command is matched first.

If an action drops a packet, then no further actions are performed in the inspection policy map. For example, if the first action is to reset the connection, then it will never match any further match criteria. If the first action is to log the packet, then a second action, such as resetting the connection, can occur.

If a packet matches multiple match or class commands that are the same, then they are matched in the order they appear in the policy map. For example, for a packet with the header length of 1001, it will match the first command below, and be logged, and then will match the second command and be reset. If you reverse the order of the two match commands, then the packet will be dropped and the connection reset before it can match the second match command; it will never be logged.

A class map is determined to be the same type as another class map or match command based on the lowest priority match command in the class map (the priority is based on the internal rules). If a class map has the same type of lowest priority match command as another class map, then the class maps are matched according to the order they are added to the policy map. If the lowest priority match for each class map is different, then the class map with the higher priority match command is matched first. For example, the following three class maps contain two types of match commands: match request-cmd (higher priority) and match filename (lower priority). The ftp3 class map includes both commands, but it is ranked according to the lowest priority command, match filename. The ftp1 class map includes the highest priority command, so it is matched first, regardless of the order in the policy map. The ftp3 class map is ranked as being of the same priority as the ftp2 class map, which also contains the match filename command. They are matched according to the order in the policy map: ftp3 and then ftp2.

Default Inspections and NAT Limitations

By default, the configuration includes a policy that matches all default application inspection traffic and applies inspection to the traffic on all interfaces (a global policy). Default application inspection traffic includes traffic to the default ports for each protocol. You can only apply one global policy, so if you want to alter the global policy, for example, to apply inspection to non-standard ports, or to add inspections that are not enabled by default, you need to either edit the default policy or disable it and apply a new one.

The following table lists all inspections supported, the default ports used in the default class map, and the inspection engines that are on by default, shown in bold. This table also notes any NAT limitations. In this table:

• Inspection engines that are enabled by default for the default port are in bold.
• The ASA is in compliance with the indicated standards, but it does not enforce compliance on packets being inspected. For example, FTP commands are supposed to be in a particular order, but the ASA does not enforce the order.

The default policy configuration includes the following commands:

Default Inspection Policy Maps

Some inspection types use hidden default policy maps. For example, if you enable ESMTP inspection without specifying a map, _default_esmtp_map is used.

The default inspection is described in the sections that explain each inspection type. You can view these default maps using the show running-config all policy-map command.

DNS inspection is the only one that uses an explicitly-configured default map, preset_dns_map.

Choosing the Right Traffic Class for Inspection

The default Layer 3/4 class map for through traffic is called “inspection_default.” It matches traffic using a special match command, match default-inspection-traffic, to match the default ports for each application protocol. This traffic class (along with match any, which is not typically used for inspection) matches both IPv4 and IPv6 traffic for inspections that support IPv6. See Guidelines for Application Inspection for a list of IPv6-enabled inspections.

You can specify a match access-list command along with the match default-inspection-traffic command to narrow the matched traffic to specific IP addresses. Because the match default-inspection-traffic command specifies the ports to match, any ports in the ACL are ignored.

Tip We suggest that you only inspect traffic on ports on which you expect application traffic; if you inspect all traffic, for example using match any, the ASA performance can be impacted.

If you want to match non-standard ports, then create a new class map for the non-standard ports. See Default Inspections and NAT Limitations for the standard ports for each inspection engine. You can combine multiple class maps in the same policy if desired, so you can create one class map to match certain traffic, and another to match different traffic. However, if traffic matches a class map that contains an inspection command, and then matches another class map that also has an inspection command, only the first matching class is used. For example, SNMP matches the inspection_default class. To enable SNMP inspection, enable SNMP inspection for the default class. Do not add another class that matches SNMP.

For example, to limit inspection to traffic from 10.1.1.0 to 192.168.1.0 using the default class map, enter the following commands:

View the entire class map using the following command:

To inspect FTP traffic on port 21 as well as 1056 (a non-standard port), create an ACL that specifies the ports, and assign it to a new class map:

Create a Regular Expression

A regular expression matches text strings either literally as an exact string, or by using metacharacters so that you can match multiple variants of a text string. You can use a regular expression to match the content of certain application traffic; for example, you can match a URL string inside an HTTP packet.

Before You Begin

Use Ctrl+V to escape all of the special characters in the CLI, such as question mark (?) or a tab. For example, type d[Ctrl+V]?g to enter d?g in the configuration.

See the regex command in the command reference for performance impact information when matching a regular expression to packets. In general, matching against long input strings, or trying to match a large number of regular expressions, will reduce system performance.

Note As an optimization, the ASA searches on the deobfuscated URL. Deobfuscation compresses multiple forward slashes (/) into a single slash. For strings that commonly use double slashes, like “http://”, be sure to search for “http:/” instead.

The following table lists the metacharacters that have special meanings.

Procedure

Step 1 Test a regular expression to make sure it matches what you think it will match.

Where the input_text argument is a string you want to match using the regular expression, up to 201 characters in length.

The regular_expression argument can be up to 100 characters in length.

Use Ctrl+V to escape all of the special characters in the CLI. For example, to enter a tab in the input text in the test regex command, you must enter test regex “test[Ctrl+V Tab]” “test\t”.

If the regular expression matches the input text, you see the following message:

If the regular expression does not match the input text, you see the following message:

Step 2 To add a regular expression after you tested it, enter the following command:

Where the name argument can be up to 40 characters in length.

The regular_expression argument can be up to 100 characters in length.

Examples

The following example creates two regular expressions for use in an inspection policy map:

Create a Regular Expression Class Map

A regular expression class map identifies one or more regular expression. It is simply a collection of regular expression objects. You can use a regular expression class map in many cases in replace of a regular expression object.

Procedure

Step 1 Create the regular expression class map.

Where class_map_name is a string up to 40 characters in length. The name “class-default” is reserved. All types of class maps use the same name space, so you cannot reuse a name already used by another type of class map.

The match-any keyword specifies that the traffic matches the class map if it matches at least one of the regular expressions.

Step 2 (Optional) Add a description to the class map:

Step 3 Identify the regular expressions you want to include by entering the following command for each regular expression:

Examples

The following example creates two regular expressions, and adds them to a regular expression class map. Traffic matches the class map if it includes the string “example.com” or “example2.com.”