The following topics describe how to configure application layer protocol inspection.
Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the ASA to do a deep packet inspection instead of passing the packet through the fast path (see the general operations configuration guide for more information about the fast path). As a result, inspection engines can affect overall throughput. Several common inspection engines are enabled on the ASA by default, but you might need to enable others depending on your network.
The following topics explain application inspection in more detail.
As illustrated in the following figure, the ASA uses three databases for its basic operation:
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 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.
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.
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.
If you need to replace an inspection policy map that you are already using in a service policy, use the following methods:
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.
State information for multimedia sessions that require inspection are not passed over the state link for stateful failover. The exceptions are GTP and SIP, which are replicated over the state link.
Supports IPv6 for the following inspections:
Supports NAT64 for the following inspections:
Additional Guidelines and Limitations
The following topics explain the default operations for application inspection.
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:
The default policy configuration includes the following commands:
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.
You configure application inspection in service policies. Service policies provide a consistent and flexible way to configure ASA features. For example, you can use a service policy to create a timeout configuration that is specific to a particular TCP application, as opposed to one that applies to all TCP applications. For some applications, you can perform special actions when you enable inspection. See “Service Policy Using the Modular Policy Framework,” for information about service policies in general.
Inspection is enabled by default for some applications. See Default Inspections and NAT Limitations section for more information. Use this section to modify your inspection policy.
Step 1 Unless you are adding inspection to an existing class map, identify the traffic to which you want to apply inspections in a Layer 3/4 class map either for through traffic or for management traffic.
See Create a Layer 3/4 Class Map for Through Traffic and Create a Layer 3/4 Class Map for Management Traffic for detailed information. The management Layer 3/4 class map can be used only with the RADIUS accounting inspection.
There are important implications for the class map that you choose. You can have more than one inspection on the inspection_default class only, and you might want to simply edit the existing global policy that applies the inspection defaults. For detailed information on which class map to choose, see Choosing the Right Traffic Class for Inspection.
Step 2 (Optional) Some inspection engines let you control additional parameters when you apply the inspection to the traffic. The table later in this procedure shows which protocols allow inspection policy maps, with pointers to the instructions on configuring them.
Step 3 Add or edit a Layer 3/4 policy map that sets the actions to take with the class map traffic.
The default policy map is called “global_policy.” This policy map includes the default inspections listed in Default Inspections and NAT Limitations. If you want to modify the default policy (for example, to add or delete an inspection, or to identify an additional class map for your actions), then enter global_policy as the name.
Step 4 Identify the class map to which you want to assign an action.
If you are editing the default policy map, it includes the inspection_default class map. You can edit the actions for this class by entering inspection_default as the name. To add an additional class map to this policy map, identify a different name.
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 map.To enable SNMP inspection, enable SNMP inspection for the default class. Do not add another class that matches SNMP.
Step 5 Enable application inspection.
The protocol is one of the following values:
|
|
---|---|
See CTIQBE Inspection. |
|
See DCERPC Inspection. If you added a DCERPC inspection policy map according to Configure a DCERPC Inspection Policy Map, identify the map name in this command. |
|
See DNS Inspection. If you added a DNS inspection policy map according to Configure DNS Inspection Policy Map, identify the map name in this command. The default DNS inspection policy map name is “preset_dns_map.” To enable DNS snooping for the Botnet Traffic Filter, enter the dynamic-filter-snoop keyword. |
|
See SMTP and Extended SMTP Inspection. If you added an ESMTP inspection policy map according to Configure an ESMTP Inspection Policy Map, identify the map name in this command. |
|
See FTP Inspection. Use the strict keyword to increase the security of protected networks by preventing web browsers from sending embedded commands in FTP requests. See Strict FTP for more information. If you added an FTP inspection policy map according to Configure an FTP Inspection Policy Map, identify the map name in this command. |
|
See GTP Inspection. If you added a GTP inspection policy map according to Configure a GTP Inspection Policy Map, identify the map name in this command. |
|
See H.323 Inspection. If you added an H323 inspection policy map according to Configure H.323 Inspection Policy Map, identify the map name in this command. |
|
See H.323 Inspection. If you added an H323 inspection policy map according to Configure H.323 Inspection Policy Map, identify the map name in this command. |
|
See HTTP Inspection. If you added an HTTP inspection policy map according to Configure an HTTP Inspection Policy Map, identify the map name in this command. |
|
See ICMP Inspection. |
|
See ILS Inspection. |
|
See Instant Messaging Inspection. If you added an Instant Messaging inspection policy map according to Configure an Instant Messaging Inspection Policy Map, identify the map name in this command. |
|
If you added an IP Options inspection policy map according to Configure an IP Options Inspection Policy Map, identify the map name in this command. |
|
See IPsec Pass Through Inspection. If you added an IPsec Pass Through inspection policy map according to IPsec Pass Through Inspection, identify the map name in this command. |
|
See IPv6 Inspection. If you added an IPv6 inspection policy map according to Configure an IPv6 Inspection Policy Map, identify the map name in this command. |
|
See MGCP Inspection. If you added an MGCP inspection policy map according to Configuring an MGCP Inspection Policy Map for Additional Inspection Control, identify the map name in this command. |
|
See NetBIOS Inspection. If you added a NetBIOS inspection policy map according to Configure a NetBIOS Inspection Policy Map for Additional Inspection Control, identify the map name in this command. |
|
See PPTP Inspection. |
|
See RADIUS Accounting Inspection. The radius-accounting keyword is only available for a management class map. You must specify a RADIUS accounting inspection policy map; see Configure a RADIUS Accounting Inspection Policy Map. |
|
See RSH Inspection. |
|
See RTSP Inspection. If you added a RTSP inspection policy map according to Configure RTSP Inspection Policy Map, identify the map name in this command. |
|
If you want to enable ScanSafe (Cloud Web Security), use the procedure described in the following topic rather than this procedure: Configure a Service Policy to Send Traffic to Cloud Web Security. The cited procedure explains the full policy configuration, including how to configure the policy inspection map. |
|
See SIP Inspection. If you added a SIP inspection policy map according to Configure SIP Inspection Policy Map, identify the map name in this command. Specify a TLS proxy to enable inspection of encrypted traffic. |
|
If you added a Skinny inspection policy map according to Configure a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control, identify the map name in this command. Specify a TLS proxy to enable inspection of encrypted traffic. |
|
See SNMP Inspection. If you added an SNMP inspection policy map, identify the map name in this command. |
|
See SQL*Net Inspection. |
|
See Sun RPC Inspection. The default class map includes UDP port 111; if you want to enable Sun RPC inspection for TCP port 111, you need to create a new class map that matches TCP port 111, add the class to the policy, and then apply the inspect sunrpc command to that class. |
|
See TFTP Inspection. |
|
Enables TCP option 33 parsing. Use when deploying Cisco Wide Area Application Services products. |
|
See XDMCP Inspection. |
Note If you are editing the default global policy (or any in-use policy) to use a different inspection policy map, you must remove the old inspection with the no inspect protocol command, and then re-add it with the new inspection policy map name.
Step 6 To activate the policy map on one or more interfaces, enter the following command:
Where global applies the policy map to all interfaces, and interface applies the policy to one interface. By default, the default policy map, “global_policy,” is applied globally. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
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:
Regular expressions define pattern matching for text strings. You can use these expressions in some protocol inspection maps to match packets based on strings such as URLs or the contents of particular header fields.
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.
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.
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.
The following example creates two regular expressions for use in an inspection policy 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.
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:
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.”