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. 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.
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.
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
If you have an inspection enabled with a policy map in a service policy, replacing the policy map is a two-step process. First, you must remove the inspection. Then, you add it back with the new policy map name.
For example, to replace sip-map1 with sip-map2 in SIP inspection, use the following command sequence:
hostname(config)# policy-map test
hostname(config-pmap)# class sip
hostname(config-pmap-c)# no inspect sip sip-map1
hostname(config-pmap-c)# inspect sip sip-map2
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 classes or direct matches, 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
reset
match request method get
log
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 criteria 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.
match request header length gt 100
log
match request header length gt 1000
reset
A class map is determined to be the same type as another class map or direct match based on the lowest priority match option in the class map (the priority is based on the internal rules). If a class map has the same type of lowest priority match option 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 option 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.
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
class ftp3
log
class ftp2
log
class ftp1
log
Guidelines for Application Inspection
Failover
State information for multimedia sessions that require inspection are not passed over the state link for stateful failover. The exceptions are GTP, M3UA, and SIP, which are replicated over the state link. You must configure strict application server process (ASP) state checking in M3UA inspection to get stateful failover.
Clustering
The following inspections are not supported in clustering:
-
CTIQBE
-
H323, H225, and RAS
-
IPsec passthrough
-
MGCP
-
MMP
-
RTSP
-
SCCP (Skinny)
-
WAAS
IPv6
Supports IPv6 for the following inspections:
-
Diameter
-
DNS over UDP
-
FTP
-
GTP
-
HTTP
-
ICMP
-
IPsec pass-through
-
IPv6
-
M3UA
-
SCCP (Skinny)
-
SCTP
-
SIP
-
SMTP
-
VXLAN
Supports NAT64 for the following inspections:
-
DNS over UDP
-
FTP
-
HTTP
-
ICMP
-
SCTP
Additional Guidelines
-
Some inspection engines do not support PAT, NAT, outside NAT, or NAT between same security interfaces. For more information about NAT support, see Default Inspections and NAT Limitations.
-
For all the application inspections, the ASA limits the number of simultaneous, active data connections to 200 connections. For example, if an FTP client opens multiple secondary connections, the FTP inspection engine allows only 200 active connections and the 201 connection is dropped and the adaptive security appliance generates a system error message.
-
Inspected protocols are subject to advanced TCP-state tracking, and the TCP state of these connections is not automatically replicated. While these connections are replicated to the standby unit, there is a best-effort attempt to re-establish a TCP state.
-
If the system determines that a TCP connection requires inspection, the system clears all TCP options except for the MSS and selective-acknowledgment (SACK) options on the packets before inspecting them. Other options are cleared even if you allow them in a TCP map applied to the connections.
-
TCP/UDP Traffic directed to the ASA (to an interface) is inspected by default. However, ICMP traffic directed to an interface is never inspected, even if you enable ICMP inspection. Thus, a ping (echo request) to an interface can fail under specific circumstances, such as when the echo request comes from a source that the ASA can reach through a backup default route.
Defaults for Application Inspection
The following topics explain the default operations for application inspection.
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.
Application |
Default Protocol, Port |
NAT Limitations |
Standards |
Comments |
---|---|---|---|---|
CTIQBE |
TCP/2748 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
— |
— |
DCERPC |
TCP/135 |
No NAT64. |
— |
— |
Diameter |
TCP/3868 TCP/5868 (for TCP/TLS) SCTP/3868 |
No NAT/PAT. |
RFC 6733 |
Requires the Carrier license. |
DNS over UDP DNS over TCP |
UDP/53 TCP/53 |
No NAT support is available for name resolution through WINS. |
RFC 1123 |
You must enable DNS/TCP inspection in the DNS inspection policy map to inspect DNS over TCP. |
FTP |
TCP/21 |
(Clustering) No static PAT. |
RFC 959 |
— |
GTP |
UDP/3386 (GTPv0) UDP/2123 (GTPv1+) |
No extended PAT. No NAT. |
— |
Requires the Carrier license. |
H.323 H.225 and RAS |
TCP/1720 UDP/1718 UDP (RAS) 1718-1719 |
(Clustering) No static PAT. No extended PAT. No NAT on same security interfaces. No NAT64. |
ITU-T H.323, H.245, H225.0, Q.931, Q.932 |
— |
HTTP |
TCP/80 |
— |
RFC 2616 |
Beware of MTU limitations stripping ActiveX and Java. If the MTU is too small to allow the Java or ActiveX tag to be included in one packet, stripping may not occur. |
ICMP |
ICMP |
— |
— |
ICMP traffic directed to an ASA interface is never inspected. |
ICMP ERROR |
ICMP |
— |
— |
— |
ILS (LDAP) |
TCP/389 |
No extended PAT. No NAT64. |
— |
— |
Instant Messaging (IM) |
Varies by client |
No extended PAT. No NAT64. |
RFC 3860 |
— |
IP Options |
RSVP |
No NAT64. |
RFC 791, RFC 2113 |
— |
IPsec Pass Through |
UDP/500 |
No PAT. No NAT64. |
— |
— |
IPv6 |
— |
No NAT64. |
RFC 2460 |
— |
LISP |
— |
No NAT or PAT. |
— |
— |
M3UA |
SCTP/2905 |
No NAT or PAT for embedded addresses. |
RFC 4666 |
Requires the Carrier license. |
MGCP |
UDP/2427, 2727 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
RFC 2705bis-05 |
— |
MMP |
TCP/5443 |
No extended PAT. No NAT64. |
— |
— |
NetBIOS Name Server over IP |
UDP/137, 138 (Source ports) |
No extended PAT. No NAT64. |
— |
NetBIOS is supported by performing NAT of the packets for NBNS UDP port 137 and NBDS UDP port 138. |
PPTP |
TCP/1723 |
No NAT64. (Clustering) No static PAT. |
RFC 2637 |
— |
RADIUS Accounting |
UDP/1646 |
No NAT64. |
RFC 2865 |
— |
RSH |
TCP/514 |
No PAT. No NAT64. (Clustering) No static PAT. |
Berkeley UNIX |
— |
RTSP |
TCP/554 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
RFC 2326, 2327, 1889 |
No handling for HTTP cloaking. |
SCTP |
SCTP |
— |
RFC 4960 |
Requires the Carrier license. Although you can do static network object NAT on SCTP traffic (no dyamic NAT/PAT), the inspection engine is not used for NAT. |
SIP |
TCP/5060 UDP/5060 |
No NAT/PAT on interfaces with the same, or lower to higher, security levels. No extended PAT. No NAT64 or NAT46. (Clustering) No static PAT. |
RFC 2543 |
Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances. |
SKINNY (SCCP) |
TCP/2000 |
No NAT on same security interfaces. No extended PAT. No NAT64, NAT46, or NAT66. (Clustering) No static PAT. |
— |
Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances. |
SMTP and ESMTP |
TCP/25 |
No NAT64. |
RFC 821, 1123 |
— |
SNMP |
UDP/161, 162 |
No NAT or PAT. |
RFC 1155, 1157, 1212, 1213, 1215 |
v.2 RFC 1902-1908; v.3 RFC 2570-2580. |
SQL*Net |
TCP/1521 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
— |
v.1 and v.2. |
STUN |
TCP/3478 UDP/3478 |
(WebRTC) Static NAT/PAT44 only. (Cisco Spark) Static NAT/PAT44 and 64; and dynamic NAT/PAT. |
RFC 5245, 5389 |
— |
Sun RPC |
TCP/111 UDP/111 |
No extended PAT. No NAT64. |
— |
— |
TFTP |
UDP/69 |
No NAT64. (Clustering) No static PAT. |
RFC 1350 |
Payload IP addresses are not translated. |
WAAS |
TCP/1- 65535 |
No extended PAT. No NAT64. |
— |
— |
XDMCP |
UDP/177 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
— |
— |
VXLAN |
UDP/4789 |
Not applicable |
RFC 7348 |
Virtual Extensible Local Area Network. |
The default policy configuration includes the following commands:
class-map inspection_default
match default-inspection-traffic
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
dns-guard
protocol-enforcement
nat-rewrite
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225 _default_h323_map
inspect h323 ras _default_h323_map
inspect ip-options _default_ip_options_map
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp _default_esmtp_map
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
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.