Configuring Special Actions for Application Inspections (Inspection Policy Map)
Modular Policy Framework lets you configure special actions for many application inspections. When you enable an inspection engine in the Layer 3/4 policy map, you can also optionally enable actions as defined in an
inspection policy map
. When the inspection policy map matches traffic within the Layer 3/4 class map for which you have defined an inspection action, then that subset of traffic will be acted upon as specified (for example, dropped or rate-limited).
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 command—You can define a traffic matching command directly in the inspection policy map to match application traffic to criteria specific to the application, such as a URL string, for which you then enable actions.
– Some traffic matching commands can specify 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—An inspection class map includes multiple traffic matching commands. You then identify the class map in the policy map and enable actions for the class map 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.
Not all inspections support inspection class maps.
Parameters—Parameters affect the behavior of the inspection engine.
Guidelines and Limitations
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
action for the changes to take effect. For example, if you modify the “http-map” inspection policy map, you must remove and readd the
inspect http http-map
command from the layer 3/4 policy:
ciscoasa(config)# policy-map test
ciscoasa(config-pmap)# class http
ciscoasa(config-pmap-c)# noinspect http http-map
ciscoasa(config-pmap-c)# inspect http http-map
All inspection policy maps—If you want to exchange an in-use inspection policy map for a different map name, you must remove the
command, and readd it with the new map. For example:
ciscoasa(config)# policy-map test
ciscoasa(config-pmap)# class sip
ciscoasa(config-pmap-c)# noinspect sip sip-map1
ciscoasa(config-pmap-c)# inspect sip sip-map2
You can specify multiple
commands in the inspection policy map.
If a packet matches multiple different
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.
match request header host length gt 100
match request method get
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
commands. 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
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
commands, then the packet will be dropped and the connection reset before it can match the second
command; it will never be logged.
match request header length gt 100
match request header length gt 1000
A class map is determined to be the same type as another class map or
command based on the lowest priority
command in the class map (the priority is based on the internal rules). If a class map has the same type of lowest priority
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
command is matched first. For example, the following three class maps contain two types of
(higher priority) and
(lower priority). The ftp3 class map includes both commands, but it is ranked according to the lowest priority command,
. 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
command. They are matched according to the order in the policy map: ftp3 and then ftp2.
class-map type inspect ftp match-all ftp1
match request-cmd get
class-map type inspect ftp match-all ftp2
match filename regex abc
class-map type inspect ftp match-all ftp3
match request-cmd get
match filename regex abc
policy-map type inspect ftp ftp
Default Inspection Policy Maps
DNS inspection is enabled by default, using the preset_dns_map inspection class map:
The maximum DNS message length is 512 bytes.
The maximum client DNS message length is automatically set to match the Resource Record.
DNS Guard is enabled, so the ASA tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the ASA. The ASA also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.
Translation of the DNS record based on the NAT configuration is enabled.
Protocol enforcement is enabled, which enables DNS message format check, including domain name length of no more than 255 characters, label length of 63 characters, compression, and looped pointer check.
See the following default commands:
policy-map type inspect dns preset_dns_map
message-length maximum client auto
message-length maximum 512
Note There are other default inspection policy maps such as _default_esmtp_map. For example, inspect esmtp implicitly uses the policy map “_default_esmtp_map.” All the default policy maps can be shown by using the show running-config all policy-map command.
Defining Actions in an Inspection Policy Map
When you enable an inspection engine in the Layer 3/4 policy map, you can also optionally enable actions as defined in an inspection policy map.
argument is the name of the policy map up to 40 characters in length. All types of policy maps use the same name space, so you cannot reuse a name already used by another type of policy map. The CLI enters policy-map configuration mode.
Specify the traffic on which you want to perform actions using one of the following methods:
Not all applications support inspection class maps.
Specify traffic directly in the policy map using one of the
commands described for each application in the inspection chapter.
ciscoasa(config-pmap)# match req-resp content-type mismatch
If you use a
command, then any traffic that matches the criterion in the
command does not have the action applied.
For policy map types that support regular expressions, see the general operations configuration guide.
ciscoasa(config-pmap-c)# drop-connection log
Specifies the action you want to perform on the matching traffic. Actions vary depending on the inspection and match type. Common actions include:
. For the actions available for each match, see the appropriate inspection chapter.
Configures parameters that affect the inspection engine. The CLI enters parameters configuration mode. For the parameters available for each application, see the appropriate inspection chapter.
The following is an example of an HTTP inspection policy map and the related class maps. This policy map is activated by the Layer 3/4 policy map, which is enabled by the service policy.
ciscoasa(config-pmap)# class test (a Layer 3/4 class map not shown)
ciscoasa(config-pmap-c)# inspect http http-map1
ciscoasa(config-pmap-c)# service-policy test interface outside
Identifying Traffic in an Inspection Class Map
This type of class map allows you to match criteria that is specific to an application. For example, for DNS traffic, you can match the domain name in a DNS query.
A class map groups multiple traffic matches (in a match-all class map), or lets you match any of a list of matches (in a match-any class map). The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you group multiple match commands, and you can reuse class maps. For the traffic that you identify in this class map, you can specify actions such as dropping, resetting, and/or logging the connection in the inspection policy map. If you want to perform different actions on different types of traffic, you should identify the traffic directly in the policy map.
Not all applications support inspection class maps. See the CLI help for
class-map type inspect
for a list of supported applications.
Create a regular expression.
See the general operations configuration guide.
ciscoasa(config)# class-map type inspect http http_traffic
is the name of the class map up to 40 characters in length.
keyword is the default, and specifies that traffic must match all criteria to match the class map.
keyword specifies that the traffic matches the class map if it matches at least one of the criteria.
The CLI enters class-map configuration mode, where you can enter one or more
hostname(config-cmap)# description All UDP traffic
Adds a description to the class map.
Define the traffic to include in the class by entering one or more
commands available for your application.
To specify traffic that should not match the class map, use the
command. For example, if the
command specifies the string “example.com,” then any traffic that includes “example.com” does not match the class map.
To see the
commands available for each application, see the appropriate inspection chapter.
The following example creates an HTTP class map that must match all criteria:
ciscoasa(config-cmap)# class-map type inspect http match-all http-traffic
ciscoasa(config-cmap)# match req-resp content-type mismatch
ciscoasa(config-cmap)# match request body length gt 1000
ciscoasa(config-cmap)# match not request uri regex class URLs
The following example creates an HTTP class map that can match any of the criteria:
ciscoasa(config-cmap)# class-map type inspect http match-any monitor-http