Table Of Contents

Configuring Application Layer Protocol Inspection

Inspection Engine Overview

When to Use Application Protocol Inspection

Inspection Limitations

Default Inspection Policy

Configuring Application Inspection

CTIQBE Inspection

CTIQBE Inspection Overview

Limitations and Restrictions

Verifying and Monitoring CTIQBE Inspection

DCERPC Inspection

DCERPC Overview

Configuring a DCERPC Inspection Policy Map for Additional Inspection Control

DNS Inspection

How DNS Application Inspection Works

How DNS Rewrite Works

Configuring DNS Rewrite

Using the Static Command for DNS Rewrite

Using the Alias Command for DNS Rewrite

Configuring DNS Rewrite with Two NAT Zones

DNS Rewrite with Three NAT Zones

Configuring DNS Rewrite with Three NAT Zones

Verifying and Monitoring DNS Inspection

Configuring a DNS Inspection Policy Map for Additional Inspection Control

ESMTP Inspection

Configuring an ESMTP Inspection Policy Map for Additional Inspection Control

FTP Inspection

FTP Inspection Overview

Using the strict Option

Configuring an FTP Inspection Policy Map for Additional Inspection Control

Verifying and Monitoring FTP Inspection

GTP Inspection

GTP Inspection Overview

Configuring a GTP Inspection Policy Map for Additional Inspection Control

Verifying and Monitoring GTP Inspection

H.323 Inspection

H.323 Inspection Overview

How H.323 Works

Limitations and Restrictions

Configuring an H.323 Inspection Policy Map for Additional Inspection Control

Configuring H.323 and H.225 Timeout Values

Verifying and Monitoring H.323 Inspection

Monitoring H.225 Sessions

Monitoring H.245 Sessions

Monitoring H.323 RAS Sessions

HTTP Inspection

HTTP Inspection Overview

Configuring an HTTP Inspection Policy Map for Additional Inspection Control

Instant Messaging Inspection

IM Inspection Overview

Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control

ICMP Inspection

ICMP Error Inspection

ILS Inspection

IPSec Pass Through Inspection

IPSec Pass Through Inspection Overview

Configuring an IPSec Pass Through Inspection Policy Map for Additional Inspection Control

MGCP Inspection

MGCP Inspection Overview

Configuring an MGCP Inspection Policy Map for Additional Inspection Control

Configuring MGCP Timeout Values

Verifying and Monitoring MGCP Inspection

NetBIOS Inspection

Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control

PPTP Inspection

RADIUS Accounting Inspection

Configuring a RADIUS Inspection Policy Map for Additional Inspection Control

RSH Inspection

RTSP Inspection

RTSP Inspection Overview

Using RealPlayer

Restrictions and Limitations

SIP Inspection

SIP Inspection Overview

SIP Instant Messaging

Configuring a SIP Inspection Policy Map for Additional Inspection Control

Configuring SIP Timeout Values

Verifying and Monitoring SIP Inspection

Skinny (SCCP) Inspection

SCCP Inspection Overview

Supporting Cisco IP Phones

Restrictions and Limitations

Verifying and Monitoring SCCP Inspection

Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control

SMTP and Extended SMTP Inspection

SNMP Inspection

SQL*Net Inspection

Sun RPC Inspection

Sun RPC Inspection Overview

Managing Sun RPC Services

Verifying and Monitoring Sun RPC Inspection

TFTP Inspection

XDMCP Inspection

Configuring 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 security appliance to do a deep packet inspection instead of passing the packet through the fast path (see the "Stateful Inspection Overview" section on page 1-4 for more information about the fast path). As a result, inspection engines can affect overall throughput.

Several common inspection engines are enabled on the security appliance by default, but you might need to enable others depending on your network. This chapter includes the following sections:

•Inspection Engine Overview

–When to Use Application Protocol Inspection

–Inspection Limitations

–Default Inspection Policy

•Configuring Application Inspection

•CTIQBE Inspection

•DCERPC Inspection

•DNS Inspection

•ESMTP Inspection

•FTP Inspection

•GTP Inspection

•H.323 Inspection

•HTTP Inspection

•Instant Messaging Inspection

•ICMP Inspection

•ICMP Error Inspection

•ILS Inspection

•IPSec Pass Through Inspection

•MGCP Inspection

•NetBIOS Inspection

•PPTP Inspection

•RADIUS Accounting Inspection

•RSH Inspection

•RTSP Inspection

•SIP Inspection

•Skinny (SCCP) Inspection

•SMTP and Extended SMTP Inspection

•SNMP Inspection

•SQL*Net Inspection

•Sun RPC Inspection

•TFTP Inspection

•XDMCP Inspection

Inspection Engine Overview

This section includes the following topics:

•When to Use Application Protocol Inspection

•Inspection Limitations

•Default Inspection Policy

When to Use Application Protocol Inspection

When a user establishes a connection, the security appliance checks the packet against access lists, 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 security appliance.

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 security appliance 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 security appliance monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.

Inspection Limitations

See the following limitations for application protocol inspection:

•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.

•Some inspection engines do not support PAT, NAT, outside NAT, or NAT between same security interfaces. See "Default Inspection Policy" for more information about NAT support.

Default Inspection Policy

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 25-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 25-1 Supported Application Inspection Engines 

Application1	Default Port	NAT Limitations	Standards2	Comments
CTIQBE	TCP/2748	—	—	—
DNS over UDP	UDP/53	No NAT support is available for name resolution through WINS.	RFC 1123	No PTR records are changed.
FTP	TCP/21	—	RFC 959	—
GTP	UDP/3386 UDP/2123	—	—	Requires a special license.
H.323 H.225 and RAS	TCP/1720 UDP/1718 UDP (RAS) 1718-1719	No NAT on same security interfaces. No static PAT.	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	—	—	—	All ICMP traffic is matched in the default class map.
ICMP ERROR	—	—	—	All ICMP traffic is matched in the default class map.
ILS (LDAP)	TCP/389	No PAT.	—	—
MGCP	UDP/2427, 2727	—	RFC 2705bis-05	—
NetBIOS Name Server over IP	UDP/137, 138 (Source ports)	—	—	NetBIOS is supported by performing NAT of the packets for NBNS UDP port 137 and NBDS UDP port 138.
PPTP	TCP/1723	—	RFC 2637	—
RADIUS Accounting	1646	—	RFC 2865	—
RSH	TCP/514	No PAT	Berkeley UNIX	—
RTSP	TCP/554	No PAT. No outside NAT.	RFC 2326, 2327, 1889	No handling for HTTP cloaking.
SIP	TCP/5060 UDP/5060	No outside NAT. No NAT on same security interfaces.	RFC 3261	—
SKINNY (SCCP)	TCP/2000	No outside NAT. No NAT on same security interfaces.	—	Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances.
SMTP and ESMTP	TCP/25	—	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	—	—	v.1 and v.2.
Sun RPC over UDP and TCP	UDP/111	No NAT or PAT.	—	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.
TFTP	UDP/69	—	RFC 1350	Payload IP addresses are not translated.
XDCMP	UDP/177	No NAT or PAT.	—	—

1 Inspection engines that are enabled by default for the default port are in bold. 2 The security appliance is in compliance with these 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 security appliance does not enforce the order.

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 512

policy-map global_policy

 class inspection_default

  inspect dns preset_dns_map 

  inspect ftp 

  inspect h323 h225 

  inspect h323 ras 

  inspect rsh 

  inspect rtsp 

  inspect esmtp 

  inspect sqlnet 

  inspect skinny 

  inspect sunrpc 

  inspect xdmcp 

  inspect sip 

  inspect netbios 

  inspect tftp 

service-policy global_policy global

Configuring Application Inspection

This feature uses Modular Policy Framework, so that implementing application inspection consists of identifying traffic, applying inspections to the traffic, and activating inspections on an interface. For some applications, you can perform special actions when you enable inspection. See Chapter 21, "Using Modular Policy Framework," for more information.

Inspection is enabled by default for some applications. See the "Default Inspection Policy" section for more information. Use this section to modify your inspection policy.

To configure application inspection, perform the following steps:

---

Step 1 To identify the traffic to which you want to apply inspections, add either a Layer 3/4 class map for through traffic or a Layer 3/4 class map for management traffic. See the "Creating a Layer 3/4 Class Map for Through Traffic" section on page 21-5 and "Creating a Layer 3/4 Class Map for Management Traffic" section on page 21-7 for detailed information. The management Layer 3/4 class map can be used only with the RADIUS accounting 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.

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 access list are ignored.

If you want to match non-standard ports, then create a new class map for the non-standard ports. See the "Default Inspection Policy" section 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 in Step 5. 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:

hostname(config)# access-list inspect extended permit ip 10.1.1.0 255.255.255.0 
192.168.1.0 255.255.255.0

hostname(config)# class-map inspection_default

hostname(config-cmap)# match access-list inspect

View the entire class map using the following command:

hostname(config-cmap)# show running-config class-map inspection_default

!

class-map inspection_default

 match default-inspection-traffic

 match access-list inspect

!

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

hostname(config)# access-list ftp_inspect extended permit tcp any any eq 21

hostname(config)# access-list ftp_inspect extended permit tcp any any eq 1056

hostname(config)# class-map new_inspection

hostname(config-cmap)# match access-list ftp_inspect

Step 2 (Optional) Some inspection engines let you control additional parameters when you apply the inspection to the traffic. See the following sections to configure an inspection policy map for your application:

•DCERPC—See the "Configuring a DCERPC Inspection Policy Map for Additional Inspection Control" section

•DNS—See the "Configuring a DNS Inspection Policy Map for Additional Inspection Control" section

•ESMTP—See the "Configuring an ESMTP Inspection Policy Map for Additional Inspection Control" section

•FTP—See the "Configuring an FTP Inspection Policy Map for Additional Inspection Control" section.

•GTP—See the "Configuring a GTP Inspection Policy Map for Additional Inspection Control" section.

•H323—See the "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section

•HTTP—See the "Configuring an HTTP Inspection Policy Map for Additional Inspection Control" section.

•Instant Messaging—See the "Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control" section

•MGCP—See the "Configuring an MGCP Inspection Policy Map for Additional Inspection Control" section.

•NetBIOS—See the "Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control" section

•RADIUS Accounting—See the "Configuring a RADIUS Inspection Policy Map for Additional Inspection Control" section

•SIP—See the "Configuring a SIP Inspection Policy Map for Additional Inspection Control" section

•Skinny—See the "Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control" section

•SNMP—See the "SNMP Inspection" section.

Step 3 To add or edit a Layer 3/4 policy map that sets the actions to take with the class map traffic, enter the following command:

hostname(config)# policy-map name

hostname(config-pmap)# 

The default policy map is called "global_policy." This policy map includes the default inspections listed in the "Default Inspection Policy" section. 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 To identify the class map from Step 1 to which you want to assign an action, enter the following command:

hostname(config-pmap)# class class_map_name

hostname(config-pmap-c)# 

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 in Step 5. Do not add another class that matches SNMP.

Step 5 Enable application inspection by entering the following command:

hostname(config-pmap-c)# inspect protocol

The protocol is one of the following values:

Table 25-2 Protocol Keywords

Keywords	Notes
ctiqbe	—
dcerpc [map_name]	If you added a DCERPC inspection policy map according to "Configuring a DCERPC Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
dns [map_name]	If you added a DNS inspection policy map according to "Configuring a DNS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command. The default DNS inspection policy map name is "preset_dns_map." The default inspection policy map sets the maximum DNS packet length to 512 bytes.
esmtp [map_name]	If you added an ESMTP inspection policy map according to "Configuring an ESMTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
ftp [strict [map_name]]	Use the strict keyword to increase the security of protected networks by preventing web browsers from sending embedded commands in FTP requests. See the "Using the strict Option" section for more information. If you added an FTP inspection policy map according to "Configuring an FTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
gtp [map_name]	If you added a GTP inspection policy map according to the "Configuring a GTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
h323 h225 [map_name]	If you added an H323 inspection policy map according to "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
h323 ras [map_name]	If you added an H323 inspection policy map according to "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
http [map_name]	If you added an HTTP inspection policy map according to the "Configuring an HTTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
icmp	—
icmp error	—
ils	—
im [map_name]	If you added an Instant Messaging inspection policy map according to "Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
mgcp [map_name]	If you added an MGCP inspection policy map according to "Configuring an MGCP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
netbios [map_name]	If you added a NetBIOS inspection policy map according to "Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
pptp	—
radius-accounting [map_name]	The radius-accounting keyword is only available for a management class map. See the "Creating a Layer 3/4 Class Map for Management Traffic" section on page 21-7 for more information about creating a management class map. If you added a RADIUS accounting inspection policy map according to "Configuring a RADIUS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
rsh	—
rtsp	—
sip [map_name]	If you added a SIP inspection policy map according to "Configuring a SIP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
skinny [map_name]	If you added a Skinny inspection policy map according to "Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
snmp [map_name]	If you added an SNMP inspection policy map according to "SNMP Inspection" section, identify the map name in this command.
sqlnet	—
sunrpc	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.
tftp	—
xdmcp	—

Step 6 To activate the policy map on one or more interfaces, enter the following command:

hostname(config)# service-policy policymap_name {global | interface interface_name}

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.

---

CTIQBE Inspection

This section describes CTIQBE application inspection. This section includes the following topics:

•CTIQBE Inspection Overview

•Limitations and Restrictions

•Verifying and Monitoring CTIQBE Inspection

CTIQBE Inspection Overview

CTIQBE protocol inspection supports NAT, PAT, and bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across the security appliance.

TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate with Cisco CallManager.

Limitations and Restrictions

The following summarizes limitations that apply when using CTIQBE application inspection:

•CTIQBE application inspection does not support configurations with the alias command.

•Stateful failover of CTIQBE calls is not supported.

•Entering the debug ctiqbe command may delay message transmission, which may have a performance impact in a real-time environment. When you enable this debugging or logging and Cisco IP SoftPhone seems unable to complete call setup through the security appliance, increase the timeout values in the Cisco TSP settings on the system running Cisco IP SoftPhone.

The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:

•If two Cisco IP SoftPhones are registered with different Cisco CallManagers, which are connected to different interfaces of the security appliance, calls between these two phones fails.

•When Cisco CallManager is located on the higher security interface compared to Cisco IP SoftPhones, if NAT or outside NAT is required for the Cisco CallManager IP address, the mapping must be static as Cisco IP SoftPhone requires the Cisco CallManager IP address to be specified explicitly in its Cisco TSP configuration on the PC.

•When using PAT or Outside PAT, if the Cisco CallManager IP address is to be translated, its TCP port 2748 must be statically mapped to the same port of the PAT (interface) address for Cisco IP SoftPhone registrations to succeed. The CTIQBE listening port (TCP 2748) is fixed and is not user-configurable on Cisco CallManager, Cisco IP SoftPhone, or Cisco TSP.

Verifying and Monitoring CTIQBE Inspection

The show ctiqbe command displays information regarding the CTIQBE sessions established across the security appliance. It shows information about the media connections allocated by the CTIQBE inspection engine.

The following is sample output from the show ctiqbe command under the following conditions. There is only one active CTIQBE session setup across the security appliance. It is established between an internal CTI device (for example, a Cisco IP SoftPhone) at local address 10.0.0.99 and an external Cisco CallManager at 172.29.1.77, where TCP port 2748 is the Cisco CallManager. The heartbeat interval for the session is 120 seconds.

hostname# # show ctiqbe

Total: 1

        LOCAL           FOREIGN         STATE   HEARTBEAT

---------------------------------------------------------------

1       10.0.0.99/1117  172.29.1.77/2748        1       120

        ----------------------------------------------

        RTP/RTCP: PAT xlates: mapped to 172.29.1.99(1028 - 1029)

        ----------------------------------------------

        MEDIA: Device ID 27     Call ID 0

               Foreign 172.29.1.99      (1028 - 1029)

               Local   172.29.1.88      (26822 - 26823)

        ----------------------------------------------

The CTI device has already registered with the CallManager. The device internal address and RTP listening port is PATed to 172.29.1.99 UDP port 1028. Its RTCP listening port is PATed to UDP 1029.

The line beginning with RTP/RTCP: PAT xlates: appears only if an internal CTI device has registered with an external CallManager and the CTI device address and ports are PATed to that external interface. This line does not appear if the CallManager is located on an internal interface, or if the internal CTI device address and ports are translated to the same external interface that is used by the CallManager.

The output indicates a call has been established between this CTI device and another phone at 172.29.1.88. The RTP and RTCP listening ports of the other phone are UDP 26822 and 26823. The other phone locates on the same interface as the CallManager because the security appliance does not maintain a CTIQBE session record associated with the second phone and CallManager. The active call leg on the CTI device side can be identified with Device ID 27 and Call ID 0.

The following is sample output from the show xlate debug command for these CTIBQE connections:

hostname# show xlate debug

3 in use, 3 most used

Flags:  D - DNS, d - dump, I - identity, i - inside, n - no random,

        r - portmap, s - static

TCP PAT from inside:10.0.0.99/1117 to outside:172.29.1.99/1025 flags ri idle 0:00:22 
timeout 0:00:30

UDP PAT from inside:10.0.0.99/16908 to outside:172.29.1.99/1028 flags ri idle 0:00:00 
timeout 0:04:10

UDP PAT from inside:10.0.0.99/16909 to outside:172.29.1.99/1029 flags ri idle 0:00:23 
timeout 0:04:10

The show conn state ctiqbe command displays the status of CTIQBE connections. In the output, the media connections allocated by the CTIQBE inspection engine are denoted by a `C' flag. The following is sample output from the show conn state ctiqbe command:

hostname# show conn state ctiqbe

1 in use, 10 most used

hostname# show conn state ctiqbe detail

1 in use, 10 most used

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,

       B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,

       E - outside back connection, F - outside FIN, f - inside FIN,

       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,

       i - incomplete, J - GTP, j - GTP data, k - Skinny media,

       M - SMTP data, m - SIP media, O - outbound data, P - inside back connection,

       q - SQL*Net data, R - outside acknowledged FIN,

       R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,

       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up

DCERPC Inspection

This section describes the DCERPC inspection engine. This section includes the following topics:

•DCERPC Overview

•Configuring a DCERPC Inspection Policy Map for Additional Inspection Control

DCERPC Overview

DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.

This typically involves a client querying a server called the Endpoint Mapper listening on a well known port number for the dynamically allocated network information of a required service. The client then sets up a secondary connection to the server instance providing the service. The security appliance allows the appropriate port number and network address and also applies NAT, if needed, for the secondary connection.

DCERPC inspect maps inspect for native TCP communication between the EPM and client on well known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and Port number are received from the applicable EPM response messages. Since a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.

Configuring a DCERPC Inspection Policy Map for Additional Inspection Control

To specify additional DCERPC inspection parameters, create a DCERPC inspection policy map. You can then apply the inspection policy map when you enable DCERPC inspection according to the "Configuring Application Inspection" section.

To create a DCERPC inspection policy map, perform the following steps:

---

Step 1 Create a DCERPC inspection policy map, enter the following command:

hostname(config)# policy-map type inspect dcerpc policy_map_name

hostname(config-pmap)# 

Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.

Step 2 (Optional) To add a description to the policy map, enter the following command:

hostname(config-pmap)# description string

Step 3 To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

hostname(config-pmap)# parameters

hostname(config-pmap-p)# 

b. To configure the timeout for DCERPC pinholes and override the global system pinhole timeout of two minutes, enter the following command:

hostname(config-pmap-p)# timeout pinhole hh:mm:ss

Where the hh:mm:ss argument is the timeout for pinhole connections. Value is between 0:0:1 and 1193:0:0.

c. To configure options for the endpoint mapper traffic, enter the following command:

hostname(config-pmap-p)# endpoint-mapper [service-only] [lookup-operation 
[timeout hh:mm:ss]]

Where the hh:mm:ss argument is the timeout for pinholes generated from the lookup operation. If no timeout is configured for the lookup operation, the timeout pinhole command or the default is used. The epm-service-only keyword enforces endpoint mapper service during binding so that only its service traffic is processed. The lookup-operation keyword enables the lookup operation of the endpoint mapper service.

---

The following example shows how to define a DCERPC inspection policy map with the timeout configured for DCERPC pinholes.

hostname(config)# policy-map type inspect dcerpc dcerpc_map

hostname(config-pmap)# timeout pinhole 0:10:00

hostname(config)# class-map dcerpc

hostname(config-cmap)# match port tcp eq 135

hostname(config)# policy-map global-policy

hostname(config-pmap)# class dcerpc

hostname(config-pmap-c)# inspect msrpc dcerpc-map

hostname(config)# service-policy global-policy global

DNS Inspection

This section describes DNS application inspection. This section includes the following topics:

•How DNS Application Inspection Works

•How DNS Rewrite Works

•Configuring DNS Rewrite

•Verifying and Monitoring DNS Inspection

How DNS Application Inspection Works

The security appliance tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the security appliance. The security appliance also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.

When DNS inspection is enabled, which is the default, the security appliance performs the following additional tasks:

•Translates the DNS record based on the configuration completed using the alias, static and nat commands (DNS Rewrite). Translation only applies to the A-record in the DNS reply; therefore, DNS Rewrite does not affect reverse lookups, which request the PTR record.

---

Note DNS Rewrite is not applicable for PAT because multiple PAT rules are applicable for each A-record and the PAT rule to use is ambiguous.

---

•Enforces the maximum DNS message length (the default is 512 bytes and the maximum length is 65535 bytes). The security appliance performs reassembly as needed to verify that the packet length is less than the maximum length configured. The security appliance drops the packet if it exceeds the maximum length.

---

Note If you enter the inspect dns command without the maximum-length option, DNS packet size is not checked

---

•Enforces a domain-name length of 255 bytes and a label length of 63 bytes.

•Verifies the integrity of the domain-name referred to by the pointer if compression pointers are encountered in the DNS message.

•Checks to see if a compression pointer loop exists.

A single connection is created for multiple DNS sessions, as long as they are between the same two hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs independently.

Because the app_id expires independently, a legitimate DNS response can only pass through the security appliance within a limited period of time and there is no resource build-up. However, if you enter the show conn command, you will see the idle timer of a DNS connection being reset by a new DNS session. This is due to the nature of the shared DNS connection and is by design.

How DNS Rewrite Works

When DNS inspection is enabled, DNS rewrite provides full support for NAT of DNS messages originating from any interface.

If a client on an inside network requests DNS resolution of an inside address from a DNS server on an outside interface, the DNS A-record is translated correctly. If the DNS inspection engine is disabled, the A-record is not translated.

As long as DNS inspection remains enabled, you can configure DNS rewrite using the alias, static, or nat commands. For details about the configuration required see the "Configuring DNS Rewrite" section.

DNS Rewrite performs two functions:

•Translating a public address (the routable or "mapped" address) in a DNS reply to a private address (the "real" address) when the DNS client is on a private interface.

•Translating a private address to a public address when the DNS client is on the public interface.

In Figure 25-1, the DNS server resides on the external (ISP) network The real address of the server (192.168.100.1) has been mapped using the static command to the ISP-assigned address (209.165.200.5). When a web client on the inside interface attempts to access the web server with the URL http://server.example.com, the host running the web client sends a DNS request to the DNS server to resolve the IP address of the web server. The security appliance translates the non-routable source address in the IP header and forwards the request to the ISP network on its outside interface. When the DNS reply is returned, the security appliance applies address translation not only to the destination address, but also to the embedded IP address of the web server, which is contained in the A-record in the DNS reply. As a result, the web client on the inside network gets the correct address for connecting to the web server on the inside network. For configuration instructions for scenarios similar to this one, see the "Configuring DNS Rewrite with Two NAT Zones" section.

Figure 25-1 Translating the Address in a DNS Reply (DNS Rewrite)

DNS rewrite also works if the client making the DNS request is on a DMZ network and the DNS server is on an inside interface. For an illustration and configuration instructions for this scenario, see the "DNS Rewrite with Three NAT Zones" section.

Configuring DNS Rewrite

You configure DNS rewrite using the alias, static, or nat commands. The alias and static command can be used interchangeably; however, we recommend using the static command for new deployments because it is more precise and unambiguous. Also, DNS rewrite is optional when using the static command.

This section describes how to use the alias and static commands to configure DNS rewrite. It provides configuration procedures for using the static command in a simple scenario and in a more complex scenario. Using the nat command is similar to using the static command except that DNS Rewrite is based on dynamic translation instead of a static mapping.

This section includes the following topics:

•Using the Static Command for DNS Rewrite

•Using the Static Command for DNS Rewrite

•Configuring DNS Rewrite with Two NAT Zones

•DNS Rewrite with Three NAT Zones

•Configuring DNS Rewrite with Three NAT Zones

For detailed syntax and additional functions for the alias, nat, and static command, see the appropriate command page in the Cisco Security Appliance Command Reference.

Using the Static Command for DNS Rewrite

The static command causes addresses on an IP network residing on a specific interface to be translated into addresses on another IP network on a different interface. The syntax for this command is as follows:

hostname(config)# static (real_ifc,mapped_ifc) mapped-address real-address dns

The following example specifies that the address 192.168.100.10 on the inside interface is translated into 209.165.200.5 on the outside interface:

hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.10 dns

---

Note Using the nat command is similar to using the static command except that DNS Rewrite is based on dynamic translation instead of a static mapping.

---

Using the Alias Command for DNS Rewrite

The alias command causes the security appliance to translate addresses on an IP network residing on any interface into addresses on another IP network connected through a different interface. The syntax for this command is as follows:

hostname(config)# alias (interface_name) mapped-address real-address

The following example specifies that the real address (192.168.100.10) on any interface except the inside interface will be translated to the mapped address (209.165.200.225) on the inside interface. Notice that the location of 192.168.100.10 is not precisely defined.

hostname(config)# alias (inside) 209.165.200.225 192.168.100.10

---

Note If you use the alias command to configure DNS Rewrite, proxy ARP will be performed for the mapped address. To prevent this, disable Proxy ARP by entering the sysopt noproxyarp command after entering the alias command.

---

Configuring DNS Rewrite with Two NAT Zones

To implement a DNS Rewrite scenario similar to the one shown in Figure 25-1, perform the following steps:

---

Step 1 Create a static translation for the web server, as follows:

hostname(config)# static (real_ifc,mapped_ifc) mapped-address real-address netmask 
255.255.255.255 dns

where the arguments are as follows:

•real_ifc—The name of the interface connected to the real addresses.

•mapped_ifc—The name of the interface where you want the addresses to be mapped.

•mapped-address—The translated IP address of the web server.

•real-address—The real IP address of the web server.

Step 2 Create an access list that permits traffic to the port that the web server listens to for HTTP requests.

hostname(config)# access-list acl-name extended permit tcp any host mapped-address eq port

where the arguments are as follows:

acl-name—The name you give the access list.

mapped-address—The translated IP address of the web server.

port—The TCP port that the web server listens to for HTTP requests.

Step 3 Apply the access list created in Step 2 to the mapped interface. To do so, use the access-group command, as follows:

hostname(config)# access-group acl-name in interface mapped_ifc

Step 4 If DNS inspection is disabled or if you want to change the maximum DNS packet length, configure DNS inspection. DNS application inspection is enabled by default with a maximum DNS packet length of 512 bytes. For configuration instructions, see the "Configuring Application Inspection" section.

Step 5 On the public DNS server, add an A-record for the web server, such as:

domain-qualified-hostname. IN A mapped-address

where domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The period after the hostname is important. mapped-address is the translated IP address of the web server.

---

The following example configures the security appliance for the scenario shown in Figure 25-1. It assumes DNS inspection is already enabled.

hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.1 netmask 
255.255.255.255 dns

hostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq www

hostname(config)# access-group 101 in interface outside

This configuration requires the following A-record on the DNS server:

server.example.com. IN A 209.165.200.225

DNS Rewrite with Three NAT Zones

Figure 25-2 provides a more complex scenario to illustrate how DNS inspection allows NAT to operate transparently with a DNS server with minimal configuration. For configuration instructions for scenarios like this one, see the "Configuring DNS Rewrite with Three NAT Zones" section.

Figure 25-2 DNS Rewrite with Three NAT Zones

In Figure 25-2, a web server, server.example.com, has the real address 192.168.100.10 on the DMZ interface of the security appliance. A web client with the IP address 10.10.10.25 is on the inside interface and a public DNS server is on the outside interface. The site NAT policies are as follows:

•The outside DNS server holds the authoritative address record for server.example.com.

•Hosts on the outside network can contact the web server with the domain name server.example.com through the outside DNS server or with the IP address 209.165.200.5.

•Clients on the inside network can access the web server with the domain name server.example.com through the outside DNS server or with the IP address 192.168.100.10.

When a host or client on any interface accesses the DMZ web server, it queries the public DNS server for the A-record of server.example.com. The DNS server returns the A-record showing that server.example.com binds to address 209.165.200.5.

When a web client on the outside network attempts to access http://server.example.com, the sequence of events is as follows:

1. The host running the web client sends the DNS server a request for the IP address of server.example.com.

2. The DNS server responds with the IP address 209.165.200.225 in the reply.

3. The web client sends its HTTP request to 209.165.200.225.

4. The packet from the outside host reaches the security appliance at the outside interface.

5. The static rule translates the address 209.165.200.225 to 192.168.100.10 and the security appliance directs the packet to the web server on the DMZ.

When a web client on the inside network attempts to access http://server.example.com, the sequence of events is as follows:

1. The host running the web client sends the DNS server a request for the IP address of server.example.com.

2. The DNS server responds with the IP address 209.165.200.225 in the reply.

3. The security appliance receives the DNS reply and submits it to the DNS application inspection engi