Getting Started with Application Layer Protocol Inspection
This chapter describes 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 “Stateful Inspection Overview” section in 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.
This chapter includes the following sections:
Information about Application Layer Protocol Inspection
This section includes the following topics:
How Inspection Engines Work
As illustrated in Figure 10-1, 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 10-1 How Inspection Engines Work
In Figure 10-1, operations are numbered in the order they occur, and are described as follows:
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.
Guidelines and Limitations
This section includes the guidelines and limitations for this feature.
Context Mode Guidelines
Supported in single and multiple context mode.
Firewall Mode Guidelines
Supported in routed and transparent firewall mode.
Failover Guidelines
State information for multimedia sessions that require inspection are not passed over the state link for stateful failover. The exception is GTP, which is replicated over the state link.
IPv6 Guidelines
Supports IPv6 for the following inspections:
-
DNS
-
FTP
-
HTTP
-
ICMP
-
SIP
-
SMTP
-
IPsec pass-through
-
IPv6
Supports NAT64 for the following inspections:
Additional Guidelines and Limitations
Some inspection engines do not support PAT, NAT, outside NAT, or NAT between same security interfaces. See “Default Settings and NAT Limitations” for more information about NAT support.
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.
Default Settings 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.
Table 10-1
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.
Table 10-1 Supported Application Inspection Engines
|
|
|
|
|
CTIQBE
|
TCP/2748
|
No extended PAT.
No NAT64.
(Clustering) No static PAT.
|
—
|
—
|
DCERPC
|
TCP/135
|
No NAT64.
|
—
|
—
|
DNS
over UDP
|
UDP/53
|
No NAT support is available for name resolution through WINS.
|
RFC 1123
|
—
|
FTP
|
TCP/21
|
(Clustering) No static PAT.
|
RFC 959
|
—
|
GTP
|
UDP/3386
UDP/2123
|
No extended PAT.
No NAT64.
|
—
|
Requires a special license.
|
H.323 H.225
and
RAS
|
TCP/1720 UDP/1718
UDP (RAS) 1718-1719
|
No dynamic NAT or PAT.
Static PAT may not work.
(Clustering) No static PAT.
No extended PAT.
No per-session PAT.
No NAT on same security interfaces.
No outside NAT.
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 ERROR
|
—
|
—
|
—
|
—
|
ILS (LDAP)
|
TCP/389
|
No extended PAT.
No NAT64.
|
—
|
—
|
Instant Messaging (IM)
|
Varies by client
|
No extended PAT.
No NAT64.
|
RFC 3860
|
—
|
IP Options
|
—
|
No NAT64.
|
RFC 791, RFC 2113
|
—
|
IPsec Pass Through
|
UDP/500
|
No PAT.
No NAT64.
|
—
|
—
|
IPv6
|
—
|
No NAT64.
|
RFC 2460
|
—
|
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
|
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 outside NAT.
No NAT64.
(Clustering) No static PAT.
|
RFC 2326, 2327, 1889
|
No handling for HTTP cloaking.
|
ScanSafe (Cloud Web Security)
|
TCP/80
TCP/413
|
—
|
—
|
These ports are not included in the default-inspection-traffic class for the ScanSafe inspection.
|
SIP
|
TCP/5060
UDP/5060
|
No outside NAT.
No NAT on same security interfaces.
No extended PAT.
No per-session PAT.
No NAT64.
(Clustering) No static PAT.
|
RFC 2543
|
—
|
SKINNY (SCCP)
|
TCP/2000
|
No outside NAT.
No NAT on same security interfaces.
No extended PAT.
No per-session PAT.
No NAT64.
(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.
|
Sun RPC over UDP
and TCP
|
UDP/111
|
No extended PAT.
No NAT64.
|
—
|
The default rule includes UDP port 111; if you want to enable Sun RPC inspection for TCP port 111, you need to create a new rule that matches TCP port 111 and performs Sun RPC inspection.
|
TFTP
|
UDP/69
|
No NAT64.
(Clustering) No static PAT.
|
RFC 1350
|
Payload IP addresses are not translated.
|
WAAS
|
—
|
No extended PAT.
No NAT64.
|
—
|
—
|
XDCMP
|
UDP/177
|
No extended PAT.
No NAT64.
(Clustering) No static PAT.
|
—
|
—
|
Configu
ring Application Layer Protocol Inspection
This feature uses Security Policy Rules to create a service policy. 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. See “Configuring a Service Policy,” for more information.
Inspection is enabled by default for some applications. See the “Default Settings and NAT Limitations” section for more information. Use this section to modify your inspection policy.
Detailed Steps
Step 1 Choose
Configuration > Firewall > Service Policy Rules
.
Step 2 Add or edit a service policy rule according to the “Adding a Service Policy Rule for Through Traffic” section.
If you want to match non-standard ports, then create a new rule for the non-standard ports. See the “Default Settings and NAT Limitations” section for the standard ports for each inspection engine. You can combine multiple rules in the same service policy if desired, so you can create one rule to match certain traffic, and another to match different traffic. However, if traffic matches a rule that contains an inspection action, and then matches another rule that also has an inspection action, only the first matching rule is used.
Step 3 In the Edit Service Policy Rule > Rule Actions dialog box, click the
Protocol
Inspection
tab.
For a new rule, the dialog box is called Add Service Policy Rule Wizard - Rule Actions.
Step 4 Select each inspection type that you want to apply.
Step 5 (Optional) Some inspection engines let you control additional parameters when you apply the inspection to the traffic. Click
Configure
for each inspection type to configure an inspect map.
You can either choose an existing map, or create a new one. You can predefine inspect maps in the Configuration > Firewall > Objects > Inspect Maps pane.
Step 6 You can configure other features for this rule if desired using the other Rule Actions tabs.
Step 7 Click
OK
(or
Finish
from the wizard).