Chapter 13. Application Inspection

This chapter covers the following topics:

Enabling application inspection

Selective inspection

Computer Telephony Interface Quick Buffer Encoding inspection

Distributed Computing Environment Remote Procedure Calls inspection

Domain Name System inspection

Extended Simple Mail Transfer Protocol inspection

File Transfer Protocol inspection

General Packet Radio Service Tunneling Protocol inspection

H.323 inspection

Cisco Unified Communications advanced support

Hypertext Transfer Protocol inspection

Internet Control Message Protocol inspection

Internet Locator Service inspection

Instant messenger inspection

IPsec pass-through inspection

Media Gateway Control Protocol inspection

NetBIOS inspection

Point-to-Point Tunneling Protocol inspection

Sun Remote Procedure Call inspection

Remote Shell inspection

Real-Time Streaming Protocol inspection

Session Initiation Protocol inspection

Skinny Call Control Protocol inspection

Simple Network Management Protocol inspection

SQL*Net inspection

Trivial File Transfer Protocol inspection

Wide Area Application Services inspection

X Display Manager Control Protocol inspection

The Cisco ASA mechanisms that are used for stateful application inspection enforce the secure use of applications and services in your network. The stateful inspection engine keeps information about each connection traversing the security appliance’s interfaces and makes sure they are valid. Stateful application inspection examines not only the packet header but also the contents of the packet up through the application layer.

Several applications require special handling of data packets when they pass through the Layer 3 devices. These include applications and protocols that embed IP addressing information in the data payload of the packet or open secondary channels on dynamically assigned ports. The Cisco ASA application inspection mechanisms recognize the embedded addressing information, which allows Network Address Translation (NAT) to work and update any other fields or checksums.

Using application inspection, the Cisco ASA identifies the dynamic port assignments and allows data exchange on these ports during a specific connection.

The following are all the applications and protocols supported by the Cisco ASA:

Computer Telephony Interface Quick Buffer Encoding (CTIQBE)

Distributed Computing Environment Remote Procedure Calls (DCERPC)

Domain Name System (DNS) over User Datagram Protocol (UDP)

Extended Simple Mail Transfer Protocol (ESMTP)

File Transfer Protocol (FTP)

General Packet Radio Service Tunneling Protocol (GTP)

H.323

Hypertext Transfer Protocol (HTTP)

Internet Control Message Protocol (ICMP) and ICMP Error

Integrated Library System (ILS) protocol

Instant messenger (IM)

IPsec pass-through

Media Gateway Control Protocol (MGCP)

NetBIOS

Point-to-Point Tunneling Protocol (PPTP)

Remote Shell (RSH)

Real-Time Streaming Protocol (RTSP)

Session Initiation Protocol (SIP)

Skinny Call Control Protocol (SCCP)

Simple Network Management Protocol (SNMP)

SQL*Net

Sun Remote Procedure Call (RPC)

Trivial File Transfer Protocol (TFTP)

Wide Area Application Services (WAAS)

X Display Manager Control Protocol (XDMCP)

The Cisco ASA supports IP version 6 (IPv6). The following are the application inspections that are supported when a Cisco ASA is configured for IPv6:

DNS

FTP

HTTP

ICMP

SIP

SMTP

IPsec pass-through

IPv6

The Cisco ASA supports NAT64 for the following inspections:

DNS

FTP

HTTP

ICMP

The following section includes thorough information on how to enable application inspection for the Cisco ASA, which is followed by individual sections detailing each application inspection protocol supported by the Cisco ASA.

As a general rule, the provisioning of inspection policies requires the following steps:

1. Configure traffic classes to identify interesting traffic.

2. Associate actions to each traffic class to create service policies.

3. Activate the service policies on an interface or globally.

You can complete these policy provisioning steps by using these three main commands of the MPF:

class-map: Classifies the traffic to be inspected. Various types of match criteria in a class map can be used to classify traffic. The primary criterion is the use of an access control list (ACL). Example 13-1 demonstrates this.

policy-map: Configures security or QoS policies. A policy consists of a class command and its associated actions. Additionally, a policy map can contain multiple policies.

service-policy: Activates a policy map globally (on all interfaces) or on a targeted interface.

Example 13-1 Matching Specific Traffic Using an ACL

Click here to view code image

---

NewYork(config)# access-list tftptraffic permit udp any any eq 69
NewYork(config)# class-map TFTPclass
NewYork(config-cmap)# match access-list tftptraffic
NewYork(config-cmap)# exit
NewYork(config)# policy-map tftppolicy
NewYork(config-pmap)# class TFTPclass
NewYork(config-pmap-c)# inspect tftp
NewYork(config-pmap-c)# exit
NewYork(config-pmap)# exit
NewYork(config)# service-policy tftppolicy global

---

In Example 13-1, an ACL named tftptraffic is configured to identify all UDP traffic. This ACL is then used as a match criteria in a class map named TFTPclass.

A policy map named tftppolicy is configured that has the class map TFTPclass mapped to it. The policy map is set up to inspect all TFTP traffic from the UDP packets that are being classified in the class map. Finally, the service policy is applied globally.

The security appliance contains a default class map named inspection_default and a policy map named global_policy. Example 13-2 shows the default class map and policy map in the Cisco ASA.

Example 13-2 Default Class and Policy Maps

Click here to view code image

---

class-map inspection_default
 match default-inspection-traffic
!
!
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp
!
service-policy global_policy global

---

If you are using Cisco ASDM, navigate to Configuration > Firewall > Service Policy Rules to edit or create a new service policy for application inspection. Steps on how to configure each application inspection parameter are shown later in this chapter.

Example 13-3 Supported Traffic Classification Options

Click here to view code image

---

NewYork(config)# class-map my_class_map
NewYork(config-cmap)# match ?
mpf-class-map mode commands/options:
  access-list                 Match an Access List
  any                         Match any packet
  default-inspection-traffic  Match default inspection traffic:
                              ctiqbe——tcp—2748      dns———-udp—53
                              ftp———-tcp—21        gtp———-udp—2123,3386
                              h323-h225-tcp—1720      h323-ras—udp—1718-1719
                              http———tcp—80        icmp———icmp
                              ils———-tcp—389       mgcp———udp—2427,2727
                              netbios—-udp—137–138   rpc———-udp—111
                              rsh———-tcp—514       rtsp———tcp—554
                              sip———-tcp—5060      sip———-udp—5060
                              skinny——tcp—2000      smtp———tcp—25
                              sqlnet——tcp—1521      tftp———udp—69
                              xdmcp——-udp—177
  dscp                        Match IP DSCP (DiffServ CodePoints)
  flow                        Flow based Policy
  port                        Match TCP/UDP port(s)
  precedence                  Match IP precedence
  rtp                         Match RTP port numbers
  tunnel-group                Match a Tunnel Group

---

Table 13-1 lists all the options supported by the match command.

If you are using ASDM, configure traffic classification by navigating to Configuration > Firewall > Service Policy Rules, selecting the service policy you want to revise, and clicking Edit. The Edit Service Policy Rule dialog box shown in Figure 13-1 is displayed.

To view the inspections that are enabled by default on the Cisco ASA, click the Default Inspections tab, as shown in Figure 13-2. These are the specific inspections that will be applied if the appropriate inspect actions are taken on a class-map that matches default-inspection-traffic.

To display statistics on the traffic being inspected on the Cisco ASA, use the show service-policy command. Example 13-4 demonstrates the output of this command.

Example 13-4 Output of show service-policy Command

Click here to view code image

---

NewYork(config)# show service-policy
Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns preset_dns_map, packet 0, drop 0, reset-drop 0
      Inspect: ftp, packet 24, drop 0, reset-drop 0
      Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: netbios, packet 43, drop 0, reset-drop 0
      Inspect: rsh, packet 0, drop 0, reset-drop 0
      Inspect: rtsp, packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: skinny , packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: esmtp _default_esmtp_map, packet 155, drop 0, reset-drop 0
      Inspect: sqlnet, packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: sunrpc, packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: tftp, packet 0, drop 0, reset-drop 0
      Inspect: sip , packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: xdmcp, packet 0, drop 0, reset-drop 0

---

The show service-policy flow command is also very useful because it can be used to display traffic flow information for a specific protocol flow. The show service-policy flow command presents policies that match a particular flow identified by the 5-tuple (protocol, source IP address, source port, destination IP address, destination port). You can use this command to check that your service policy configuration will provide the services you want for specific connections. The following sections include information about each application inspection protocol supported by the Cisco ASA.

In Figure 13-3, a PC with Cisco IP Communicator (CIPC) softphone communicates with a Cisco CallManager. CTIQBE inspection is not enabled by default.

Complete the following steps to enable CTIQBE inspection via ASDM:

1. Log in to ASDM and navigate to Configuration > Firewall > Service Policy Rules.

2. Select the specific service policy rule and click Edit to manage a service policy. The Edit Service Policy Rule dialog box shown in Figure 13-4 is displayed.

3. Click the Rule Actions tab.

4. Check the CTIQBE check box on the Protocol Inspection tab.

5. Click OK.

6. Click Apply to apply the configuration changes.

7. Click Save to save the configuration in the Cisco ASA.

If configuring the Cisco ASA via the CLI, use the inspect ctiqbe command to enable CTIQBE inspection, as shown in Example 13-5.

Example 13-5 Enabling CTIQBE Inspection

Click here to view code image

---

NewYork# configure terminal
NewYork(config)# policy-map global_policy
NewYork(config-pmap)# class inspection_default
NewYork(config-pmap-c)# inspect ctiqbe

---

Use the show conn state ctiqbe command to display the status of CTIQBE connections. The C flag represents the media connections allocated by the CTIQBE inspection engine. Example 13-6 includes the output of the show conn state ctiqbe command.

Example 13-6 Output of the show conn state ctiqbe Command

Click here to view code image

---

NewYork# show conn state ctiqbe
5 in use, 11 most used

---

To enable DCERPC inspection with ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (shown in Figure 13-4), click the Rule Actions tab and check the DCERPC check box on the Protocol Inspection tab.

If configuring the Cisco ASA via the CLI, use the inspect dcerpc command to enable DCERPC inspection, as shown in Example 13-7.

Example 13-7 Enabling DCERPC Inspection

Click here to view code image

---

NewYork# configure terminal
NewYork(config)# policy-map global_policy
NewYork(config-pmap)# class inspection_default
NewYork(config-pmap-c)# inspect dcerpc

---

Cisco ASA DNS inspection provides the following benefits:

Guarantees that the ID of the DNS reply matches the ID of the DNS query.

Allows the translation of DNS packets through the use of NAT.

Allows the translation of AAAA Records to A Records and vice versa when doing NAT64.

Reassembles the DNS packet to verify its length. The Cisco ASA allows DNS packets of up to 65,535 bytes. When necessary, reassembly is done to verify that the packet length is less than the maximum length specified by the user. The packet is dropped if it is not compliant.

To enable DNS inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box, previously shown in Figure 13-4, click the Rule Actions tab and check the DNS check box on the Protocol Inspection tab. You can also configure several optional parameters for this DNS inspection by clicking the Configure button. The Select DNS Inspect Map dialog box is displayed. To configure a new DNS inspect map, click Add. The Add DNS Inspect Map dialog box shown in Figure 13-5 is displayed. You may need to click the Details button to see all the available options.

To configure the protocol conformance settings for DNS, click the Protocol Conformance tab, as shown in Figure 13-5. The following options are available:

Enable DNS Guard Function: This option enables the Cisco ASA to do a DNS query-and-response mismatch check, using the identification field within the header of the DNS packet.

Enable NAT Re-write Function: The Cisco ASA performs IP address translation in the A record of the DNS response.

Enable Protocol Enforcement: The Cisco ASA performs a DNS message-format check, including the following:

Domain name

Label length

Compression

Looped pointer check

Randomize the DNS Identifier for DNS Query: Check this box to randomize the DNS identifier in the DNS query message.

Enforce TSIG Resource Record to Be Present in DNS Message: The Cisco ASA enforces that a TSIG resource record be present in DNS transactions. The Cisco ASA can either drop the packet or log associated messages, depending on what you configure in the Actions area.

The Filtering tab enables you to configure the filtering settings for DNS, as shown in Figure 13-6.

In the Global Settings area, you can enable the Cisco ASA to drop packets that exceed the specified maximum length (globally). You can specify the maximum packet length (in bytes) in the Maximum Packet Length field.

The Server Settings area enables you to configure server-specific parameters. The Client Settings area allows you to configure client-specific parameters. The following options are available for both:

Drop packets that exceed specified maximum length

Drop packets sent that exceed the length indicated by the Resource Record (RR)

The Mismatch Rate tab enables you to configure the ID mismatch rate for DNS, as shown in Figure 13-7.

Check the Enable Logging when DNS ID Mismatch Rate Exceeds Specified Rate check box to allow logging on the Cisco ASA when excessive instances of DNS identifier mismatches are received. You can specify the maximum number of mismatch instances before logging is performed in the Mismatch Instance Threshold field. Use the Time Interval field to configure the time period (in seconds) to monitor.

The Inspections tab enables you to add or edit more granular matching parameters and actions. Click Add to add a new matching criteria or click Edit to edit an existing one. The Add DNS Inspect dialog box shown in Figure 13-8 is displayed.

The following options are available under the Match Criteria area when the Single Match radio button is chosen:

The Match Type field enables you to configure a positive or negative match based on a specific criterion.

The Criterion drop-down list box enables you to choose the criterion of the DNS inspection. You can match based on any of the following:

Header

Flag

Type

Class

Question

Resource record

Domain name

The Value area enables you to configure the value to match in the DNS inspection.

Similarly, you can also configure multiple matches by clicking the Multiple Matches radio button.

The Actions area enables you to configure the action to be taken by the Cisco ASA if the match condition is met.

The primary action can be configured to mask, drop the offending packet, drop the connection, or take no action. Logging can also be enabled. Additionally, when TSIG enforcement is enabled, you can drop the packet, enable logging, or do both.

If you are using the CLI, employ the inspect dns command. Example 13-8 includes the CLI commands for the parameters configured via ASDM in the previous examples.

Example 13-8 Enabling DNS Inspection

Click here to view code image

---

policy-map type inspect dns my-dns-map
 description Custom DNS Inspect Map
 parameters
  message-length maximum 512
 match header-flag eq AA
  drop-connection log
policy-map global_policy
 class inspection_default
    inspect dns my-dns-map

---

AUTH

DATA

EHLO

ETRN

HELO

HELP

MAIL

NOOP

QUIT

RCPT

RSET

SAML

SOML

VRFY

If an illegal command is found in an ESMTP or SMTP packet, it is modified and forwarded. This causes a negative server reply, forcing the client to issue a valid command. For example, you could try to send TURN, which is an unsupported illegal command. The Cisco ASA modifies it and makes the receiver reply with an SMTP error return code of 500 (command not recognized) and tears down the connection.

The Cisco ASA may perform deeper parameter inspection for packets containing legal commands. This type of inspection is required for SMTP and ESMTP extensions. Deeper parameter inspection is used to inspect the following SMTP and ESMTP extensions:

Message Size Declaration (SIZE)

Remote Queue Processing Declaration (ETRN)

Binary MIME (BINARYMIME)

Command Pipelining (PIPELINING)

Authentication (AUTH)

Delivery Status Notification (DSN)

To enable ESMTP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the ESMTP check box on the Protocol Inspection tab.

You can also configure several optional parameters for this ESMTP inspection by clicking the Configure button to the right of the ESMTP check box. The Select ESMTP Inspect Map dialog box is displayed. To configure a new ESMTP inspect map, click Add. The Add ESMTP Inspect Map dialog box shown in Figure 13-9 is displayed.

There are three different security levels: High, Medium, or Low. Low is the default level and includes the following checks and actions:

Log if command line length is greater than 512

Log if command recipient count is greater than 100

Log if body line length is greater than 1000

Log if sender address length is greater than 320

Log if MIME file name length is greater than 255

When you move the slider to Medium for the security level, the following checks and actions are performed:

Obfuscate Server Banner

Drop Connections if command line length is greater than 512

Drop Connections if command recipient count is greater than 100

Drop Connections if body line length is greater than 1000

Drop Connections if sender address length is greater than 320

Drop Connections if MIME file name length is greater than 255

When you move the slider to High for the security level, the following checks and actions are achieved:

Obfuscate Server Banner

Drop Connections if command line length is greater than 512

Drop Connections if command recipient count is greater than 100

Drop Connections if body line length is greater than 998

Drop Connections and log if sender address length is greater than 320

Drop Connections and log if MIME file name length is greater than 255

Alternatively, you can click the Details button to configure each security parameter specifically.

Clicking the MIME File Type Filtering button enables you to configure MIME file type filters that can be defined by custom regular expressions.

To enable ESMTP inspection via the CLI, use the inspect esmtp command. This command is enabled in the default class and policy maps on the Cisco ASA. Example 13-9 shows the CLI configuration when the ESMTP inspect map security level is set to High in ASDM.

Example 13-9 Enabling ESMTP Inspection via the CLI

Click here to view code image

---

policy-map type inspect esmtp my-ESMTP-map
 description Custom ESMTP Inspection Map
 parameters
 match sender-address length gt 320
  drop-connection log
 match MIME filename length gt 255
  drop-connection log
 match cmd line length gt 512
  drop-connection log
 match cmd RCPT count gt 100
  drop-connection log
 match body line length gt 998999
  drop-connection log
policy-map global_policy
 class inspection_default
  inspect esmtp my-ESMTP-map

---

Enhanced security while creating dynamic secondary data connections for FTP transfers

Enforcement of FTP command-response sequence

Generation an audit trail for FTP sessions

Translation of embedded IP address when NAT is in use or in the FTP control channel

To enable FTP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the FTP check box on the Protocol Inspection tab. You can also configure several optional parameters for this FTP inspection by clicking the Configure button. The Select FTP Inspect Map dialog box is displayed.

To configure FTP inspection via the CLI, use the inspect ftp command to enable FTP inspection. The strict keyword (optional) enables the Cisco ASA to prevent client systems from sending embedded commands in FTP requests:

Click here to view code image

inspect ftp [strict] ftp-map-name

ftp-map-name is the name of an FTP map used to define FTP request commands to be denied. Example 13-10 demonstrates how to use the inspect ftp strict command in conjunction with an FTP map, called myftpmap, to deny several FTP commands.

Example 13-10 Denying Specific FTP Commands

Click here to view code image

---

ftp-map myftpmap
 deny-request-cmd cdup rnfr rnto stor stou
!
class-map inspection_default
 match default-inspection-traffic
!
policy-map asa_global_fw_policy
 class inspection_default
  inspect ftp strict myftpmap

---

When the strict option is enabled, the following anomalous activities in FTP commands and replies are denied:

The total number of commas in the PORT and PASV reply commands is checked. If there are not five commas, the PORT command is considered to be truncated and the connection is closed.

The Cisco ASA inspects all FTP commands to see whether they end with <CR><LF> characters, as specified by RFC 959, “File Transfer Protocol (FTP).” The connection is closed if these characters are not present.

The PORT command is always sent from the FTP client. If the PORT command is sent from the server, the connection is dropped.

The PASV reply is always sent from the server. If the PASV reply is sent from the client, the connection is dropped.

The Cisco ASA checks the negotiated dynamic port value in the passive FTP mode. The port should not be in the range from 1 to 1024. These are reserved for well-known protocols. The connection is closed if the negotiated port is within this range.

The Cisco ASA checks the number of characters included after the port numbers in the PORT and PASV reply commands. The maximum number of characters is eight. The Cisco ASA closes the TCP connection if the number of characters exceeds eight.

The FTP map request-command deny subcommand is used to deny specific FTP commands on the Cisco ASA. Table 13-2 lists all the request-command deny subcommand options that can be restricted under an FTP map.

The SYST FTP command allows a system to ask for information about the server’s operating system. The server accepts this request with code 215 and sends the requested information. The Cisco ASA replaces the FTP server response to the SYST command with an X for each character sent, to prevent FTP clients from seeing the FTP server system–type information. Use the no mask-syst-reply subcommand in FTP map configuration mode to disable this default behavior, as shown in Example 13-11.

Example 13-11 no mask-syst-reply Subcommand

Click here to view code image

---

ftp-map myftpmap
 no mask-syst-reply

---

Figure 13-10 illustrates a basic representation of the GPRS architecture.

Figure 13-10 shows a mobile station (MS) logically connected to an Serving GPRS Support Node (SGSN). The SGSN provides data services to the MS. The SGSN is logically connected to a Gateway GPRS Support Node (GGSN)via GTP. If the GTP tunnel connection is over the same Public Land Mobile Network (PLMN), the interface connecting the tunnel is called the Gn interface. Connections between two different PLMNs are known as Gp interfaces. The GGSN acts as a gateway to external networks such as the Internet or the corporate network via the Gi interface. In other words, the interface between a GGSN and an SGSN is called Gn, whereas the interface between the GGSN and an external data network is called Gi. GTP encapsulates data from the mobile station and controls the establishment, movement, and deletion of tunnels between the SGSN and GGSN in roaming scenarios.

There are two versions of GTP:

GTPv0

GTPv1

The common transport protocol for signaling messages for GTPv0 and v1 is UDP. GTPv0 can allow the use of TCP for the transport protocol data units (TPDU). The Cisco ASA supports only UDP. The UDP destination port for requests is port 3386.

Figure 13-11 illustrates call flow and the signaling messages involved for GTPv0.

The following is the sequence of events in the call flow shown in Figure 13-11:

1. The SGSN sends a Create PDP Context Request to the GGSN.

2. The PDP context is created and the GGSN sends a PDP response to the SGSN.

3. The SGSN sends an update PDP request message to the GGSN.

4. The GGSN replies with an update PDP response.

5. TPDUs are sent by the SGSN. (Figure 13-11 shows a sample of the TPDU as seen by the Cisco ASA inspection engine.)

6. The SGSN sends a request to delete the PDP context.

7. The PDP context is deleted and the GGSN sends its deletion response.

GTPv1 uses UDP port 2123 for requests and UDP port 2152 for data transfer.

Figure 13-12 illustrates call flow and the signaling messages involved for GTPv1.

The following is the sequence of events in the call flow shown in Figure 13-12:

1. The SGSN sends a Create PDP Context Request for the primary PDP context.

2. The primary context is created and the GGSN sends its response.

3. The SGSN sends a PDP context create request for the second PDP context.

4. The second context is created and the GGSN sends its response.

5. The SGSN sends a PDP update request to the GGSN.

6. The GGSN replies with a PDP update response.

7. TPDU (data packets) are sent to the GGSN.

8. TPDU (data packets) are sent to the SGSN.

9. The SGSN sends a request to delete the primary PDP context.

10. The primary PDP context is deleted and the GGSN sends its response.

11. The SGSN sends a request to delete the second PDP context.

12. The second PDP context is deleted and the GGSN sends its response.

Figure 13-13 illustrates the Cisco ASA positioned between GPRS networks.

In Figure 13-13, the Cisco ASA is positioned between two GPRS PLMNs. This exemplifies how a mobile station may move from its home PLMN (HPLMN) to a visited PLMN (VPLMN) and communication is still possible through the Cisco ASA. The Cisco ASA inspects all traffic between the respective SGSNs and GGSNs.

There is only one security level setting for GTP inspection (Low), and the following parameters are set:

Do not Permit Errors

Maximum Number of Tunnels: 500

GSN timeout: 00:30:00

Pdp-Context timeout: 00:30:00

Request timeout: 00:01:00

Signaling timeout: 00:30:00

Tunnel timeout: 01:00:00

T3-response timeout: 00:00:20

Drop and log unknown message IDs

To configure IMSI prefix filters, click the MSI Prefix Filtering button. The IMSI Prefix Filtering dialog box enables you to design the IMSI prefix to allow within GTP requests. The following options are available:

Mobile Country Code: Non-zero, three-digit value identifying the mobile country code

Mobile Network Code: Two- or three-digit value identifying the network code

The Add and Delete buttons enable you to add or delete the specified country code and network code to or from the IMSI Prefix table.

To enable GTP inspection, use the inspect gtp command. You can also associate a GTP map to create a more customizable configuration. This provides granular control of various GTP parameters and filtering options.

Create a GTP map by using the gtp-map command, followed by the name of the map. Example 13-12 demonstrates how the Cisco ASA is configured with a GTP map, called mygtpmap, to enforce different restrictions.

Example 13-12 GTP Inspection Example

Click here to view code image

---

gtp-map mygtpmap
 tunnel-limit 1000
 request-queue 500
class-map inspection_default
 match default-inspection-traffic
policy-map asa_global_fw_policy
class inspection_default
  inspect gtp mygtpmap

---

In Example 13-12, the Cisco ASA allows a maximum of only 1000 GTP tunnels and allows a maximum of only 500 requests to be queued. The GTP map is mapped to the default policy map under the default inspection class.

Table 13-3 lists all the subcommands available to configure under a GTP map.

Terminals: Endpoints on the network that provide real-time two-way communications, such as Cisco IP phones

Gateways: Provide translation between circuit-switched networks and packet-based networks, enabling the endpoints to communicate

Gatekeepers: Responsible for call control and routing services to H.323 endpoints, system management, and some security policies

Multipoint control units (MCU): Maintain all the audio, video, data, and control streams between all the participants in the conference

Figure 13-14 shows a basic network topology that illustrates the components of an H.323 network.

The protocols are as follows:

The G.7nn components are audio codecs.

The H.26n components are video codecs. The standard is H.261.

Audio and video components sit on top of the Real-time Transport Protocol (RTP).

The T.12n protocols are used in real-time exchange of data. One example is an online whiteboard application.

In Figure 13-15, the protocols are illustrated in relation to the respective OSI layers.

The H.323 suite of protocols may use up to two TCP connections and four to six UDP connections:

RTP uses the Real-time Transport Control Protocol (RTCP) to control and synchronize streaming audio and video. It allows the application to adapt the flow to specific network conditions.

Terminals and gatekeepers use the Registration, Admission, and Status (RAS) protocol to exchange information about call registrations, admissions, and terminations. This protocol communicates over UDP.

H.225 is a protocol used to establish connections between two terminals. It runs over TCP.

H.245 is a protocol used between two terminals to exchange control messages. These messages include flow control and channel management commands.

Clients may request a Q.931 call setup over TCP port 1720 to H.323 servers. During the call setup process, the H.323 terminal provides the TCP port number for the client to use for an H.245 connection.

The Cisco ASA can monitor the Q.931 TCP connection to determine the H.245 port number. It dynamically allocates the H.245 connection based on the inspection of the H.225 messages if FastConnect is not used.

The terminals negotiate the port numbers to be used for subsequent UDP streams within each H.245 message. The Cisco ASA also monitors the H.245 messages to know about these ports and to create the necessary connections.

RTP uses the negotiated port number; however, RTCP uses the next higher port number.

The following are the key TCP and UDP ports in H.323 inspection:

Gatekeeper discovery: UDP port 1718

RAS: UDP port 1719

Control port: TCP port 1720

Figure 13-16 and Figure 13-17 show a major difference between older versions of H.323 and H.323v3 and later.

H.323v3 and later supports multiple calls on one signaling connection. It accomplishes this by examining the call reference value (CRV) within the Q.931 message. This results in reduced call setup and clearing times.

The Low security level is the default and supports the following checks and actions:

State Checking H.225 disabled

State Checking RAS disabled

Call Party Number disabled

Call Duration Limit disabled

RTP Conformance not enforced

The Medium security level supports the following checks and actions:

State Checking H.225 enabled

State Checking RAS enabled

Call Party Number disabled

Call Duration Limit disabled

RTP Conformance enforced

Does not limit payload to audio or video, based on the signaling exchange

The High security level supports the following checks and actions:

State Checking H.225 enabled

State Checking RAS enabled

Call Party Number enabled

Call Duration Limit 1:00:00

RTP Conformance enforced

Adds support to limit payload to audio or video, based on the signaling exchange

Clicking the Phone Number Filtering button enables you to configure the settings for a phone number filter.

You can configure additional settings for H.323 application inspection maps by clicking the Details button.

The State Checking tab enables you to configure state checking parameters for the H.323 inspection map. The following options are available:

Check State Transition of H.225 Messages: Used to enforce H.323 state checking on H.225 messages.

Check State Transition of RAS Messages: Used to enforce H.323 state checking on RAS messages.

The Call Attributes tab is where you configure call attribute parameters for the H.323 inspection map. The following options are available:

Enforce Call Duration Limit: Used in combination with the Call Duration Limit field.

Enforce Presence of Calling and Called Party Numbers: Used to enforce the presence of “calling” and “called” party numbers.

The Tunneling and Protocol Conformance tab is where you configure tunneling and protocol conformance parameters for the H.323 inspection map. The following options are available:

Check for H.245 Tunneling: Enables you to check for H.245 tunneling and to drop a connection or perform logging.

Check RTP Packets for Protocol Conformance: Applied to check RTP/RTCP packets on the pinholes for protocol conformance. This can be used in combination with the Limit Payload to Audio or Video, Based on the Signaling Exchange option to enforce the payload type to be audio or video based on the signaling exchange.

The HSI Group Parameters tab enables you to configure an HSI group. On the Inspections tab, you add or edit advanced matching parameters for H.323 inspection, using regular expressions.

To enable H.323 inspection for H.225, use the inspect h323 h225 command. For RAS, use the inspect h323 ras command. Example 13-13 shows both commands.

Example 13-13 H.323 Inspection Commands

Click here to view code image

---

policy-map global_policy
 class inspection_default
  inspect h323 h225
  inspect h323 ras

---

Example 13-14 shows the commands sent by ASDM to the Cisco ASA in the previous examples.

Example 13-14 H.323 Inspection Commands Sent by ASDM

Click here to view code image

---

policy-map type inspect h323 my-h323-map
 description Custom H.323 Inspect Map
 parameters
  state-checking h225
  state-checking ras
policy-map global_policy
 class inspection_default
  inspect h323 ras
  inspect h323 h225 my-h323-map

---

The Cisco ASA translates the necessary embedded IP addresses in the H.225 and H.245 packets. It also translates H.323 connections. It uses an ASN.1 decoder to decode the H.323 Packet Encoding Rules (PER) encoded messages. The Cisco ASA also dynamically allocates the negotiated H.245, RTP, and RTCP sessions.

Additionally, the Cisco ASA analyzes the TPDU Packet (TPKT) header to define the length of the H.323 messages. In H.323, Q.931 messages are exchanged over a TCP stream demarcated by TPKT encapsulations. It maintains a data structure for each connection that also contains the TPKT length for the H.323 messages to be received.

Direct Call Signaling (DCS)

Gatekeeper Routed Control Signaling (GKRCS)

Cisco ASA supports both methods. The Cisco ASA inspects DCS and GKRCS to ensure that the negotiation messages and correct fields are transferred between the respective devices. GKRCS inspection is performed when H.323 inspection is enabled in the Cisco ASA. No additional configuration is needed.

Phone Proxy

TLS Proxy

Mobility Proxy

Presence Federation Proxy

The Phone Proxy feature has several limitations:

It is not supported in multiple-context or transparent mode.

Packets from phones connecting to the phone proxy over a VPN tunnel cannot be inspected.

It does not support IP phones sending RTCP packets.

It does not enable end users to reset their device name in CIPC environments.

It does not enable IP phones to send SCCP video messages using Cisco Unified Video Advantage because SCCP video messages do not support SRTP keys.

For mixed-mode and non-mixed-mode clusters, the phone proxy does not support the Cisco Unified Call Manager using TFTP to send encrypted configuration files to IP phones through the Cisco ASA.

When the phone proxy is configured for a mixed-mode cluster and multiple IP phones are behind one NAT device and registering through the phone proxy, all the SIP and SCCP IP phones must be configured as authenticated or encrypted, or all as non-secure on the Unified Call Manager.

Complete the following steps to configure the Phone Proxy feature using ASDM:

1. Log in to ASDM and navigate to Configuration > Firewall > Unified Communications > Phone Proxy. The screen shown in Figure 13-18 is displayed.

2. Check Enable Phone Proxy to enable phone proxy support.

3. The Cisco ASA must have a Media Termination Address (MTA) instance, according to the following criteria:

One MTA instance must be configured for each phone proxy on the Cisco ASA. Multiple MTA instances are not supported.

A global MTA can be configured for all interfaces; alternatively, an MTA can be configured for different interfaces. A global MTA and individual MTAs cannot be configured for each interface at the same time.

If you configure an MTA for multiple interfaces, you must configure an address on each interface that the security appliance uses when communicating with IP phones or call endpoints.

The IP address on an interface cannot be the same address as that interface on the security appliance.

The IP addresses cannot overlap with existing static NAT pools or NAT rules or devices already present on the connected subnets.

The IP addresses cannot be the same as the Cisco Unified Communications Manager or TFTP server IP address.

When IP phones are behind a router or gateway, you must add routes to the MTA on the Cisco ASA interface with which the IP phones communicate so that the phone can reach the MTA.

4. At least one TFTP server must be configured on a trusted network for the Call Manager cluster. Add a TFTP server in the TFTP Server Settings area. For instance, you can configure the TFTP server address and the interface which it resides. The default TFTP port (UDP port 69) is also used.

5. In the Certificate Trust List File area, click the Generate Certificate Trust List File link to create a Certificate Trust List (CTL) file that is required by the Phone Proxy. This enables you to create trustpoints and generate certificates for each entity in the network (CUCM, CUCM and TFTP, TFTP server, and the Cisco Certificate Authority Proxy Function (CAPF) service) that the IP phones must trust. The certificates are used in creating the CTL file. Trustpoints must be designed for each CUCM (primary and secondary) and TFTP server in the network. The trustpoints need to be in the CTL file for the phones to trust the CUCM.

After you click the Generate Certificate Trust List File link, a new screen is shown where you can add the specific record entry used for the CTL file. Additionally, you can select the trustpoint to be used for the respective certificate. In this instance, the ASDM_Trustpoint0 is employed. Optionally, you can define a domain name to be used by the CTL. In this case, securemeinc.org is used.

6. In the Certificate Trust List File area, check the Use the Certificate Trust List File Generated by the CTL Instance check box to use the respective CTL file.

7. In the Call Manager and Phone Settings area, you can configure the CUCM cluster mode to Non-secure or Mixed.

8. Configure the idle timeout after which the secure-phone entry is removed from the Phone Proxy database. The default value of 5 minutes is used in Figure 13-19.

9. (Optional) To preserve Call Manager configuration on the IP phones, check the Preserve the Call Manager’s Configuration on the Phone check box. When this option is not checked, the following service settings are disabled on the IP phones:

PC Port

Gratuitous ARP

Voice VLAN Access

Web Access

Span to PC Port

10. (Optional) To force Cisco IP Communicator (CIPC) SoftPhones to operate in authenticated mode when CIPC SoftPhones are deployed in a voice and data VLAN scenario, check the Enable CIPC Security Mode Authentication check box.

11. (Optional) To configure an HTTP proxy for the Phone Proxy feature that is written into the IP phone’s configuration file under the <proxyServerURL> tag, check the Configure a HTTP-Proxy Which Would Be Written into the Phone’s Config File so that the Phone URLs Are Directed for Services on the Phone check box. Enter the IP address and the listening port of the HTTP proxy.

12. Click Apply to apply the configuration changes.

13. Click Save to save the configuration in the Cisco ASA.

Example 13-15 shows the commands sent by ASDM to the Cisco ASA after completing the aforementioned steps.

Example 13-15 Phone Proxy Commands Sent by ASDM

Click here to view code image

---

crypto ca trustpoint ASDM_TrustPoint0
 enrollment self
 subject-name CN=NewYork
 crl configure
crypto ca trustpoint _internal_asdm_CTL_File_SAST_0
 enrollment self
 fqdn none
 subject-name cn="_internal_asdm_CTL_File_SAST_0";ou="STG";o="Cisco Inc"
 keypair _internal_asdm_CTL_File_SAST_0
 crl configure
crypto ca trustpoint _internal_asdm_CTL_File_SAST_1
 enrollment self
 fqdn none
 subject-name cn="_internal_asdm_CTL_File_SAST_1";ou="STG";o="Cisco Inc"
 keypair _internal_asdm_CTL_File_SAST_1
 crl configure
crypto ca trustpoint _internal_PP_asdm_CTL_File
 enrollment self
 fqdn none
 subject-name cn="_internal_PP_asdm_CTL_File";ou="STG";o="Cisco Inc"
 keypair _internal_PP_asdm_CTL_File
 crl configure
crypto ca certificate chain ASDM_TrustPoint0
 certificate 3a70634a
    308201cb 30820134 a0030201 0202043a 70634a30 0d06092a 864886f7 0d010104
    0500302a 3110300e 06035504 0313074e 6577596f 726b3116 30140609 2a864886
<output truncated>
  quit
crypto ca certificate chain _internal_asdm_CTL_File_SAST_0
 certificate c070634a
    3082020d 30820176 a0030201 020204c0 70634a30 0d06092a 864886f7 0d010104
    0500304b 31123010 06035504 0a130943 6973636f 20496e63 310c300a 06035504
<output truncated>
  quit
crypto ca certificate chain _internal_asdm_CTL_File_SAST_1
 certificate c170634a
    3082020d 30820176 a0030201 020204c1 70634a30 0d06092a 864886f7 0d010104
    0500304b 31123010 06035504 0a130943 6973636f 20496e63 310c300a 06035504
    0b130353 54473127 30250603 55040314 1e5f696e 7465726e 616c5f61 73646d5f
    43544c5f 46696c65 5f534153 545f3130 1e170d30 39303731 39313931 3531335a
    170d3139 30373137 31393135 31335a30 4b311230 10060355 040a1309 43697363
<output truncated>
  quit
crypto ca certificate chain _internal_PP_asdm_CTL_File
 certificate c270634a
    30820205 3082016e a0030201 020204c2 70634a30 0d06092a 864886f7 0d010104
    05003047 31123010 06035504 0a130943 6973636f 20496e63 310c300a 06035504
<output truncated>
  quit
!
ctl-file asdm_CTL_File
 record-entry cucm-tftp trustpoint ASDM_TrustPoint0 address 172.18.108.26 domain-name securemeinc.com
 no shutdown
!
phone-proxy asdm_phone-proxy
 tftp-server address 172.18.108.26 interface inside
 cluster-mode mixed
 ctl-file asdm_CTL_File

---

Complete the following steps to configure the TLS Proxy feature, using ASDM:

1. Log in to ASDM and navigate to Configuration > Firewall > Unified Communications > TLS Proxy.

2. Click Add to add a new TLS Proxy instance. The Add TLS Proxy Instance Wizard is displayed.

3. Enter a name for the TLS Proxy instance and click Next. In this example, the name used is my-tls-proxy.

4. Specify the server proxy certificate from the Server Proxy Certificate drop-down menu.

5. Click Install TLS Server’s Certificate to install the TLS server certificate in Cisco ASA’s trust store. This is used to authenticate the TLS server during the TLS handshake between the TLS proxy and the TLS server.

6. Check the Enable Client Authentication During TLS Proxy Handshake check box so that the Cisco ASA sends a certificate and authenticates the TLS client during the TLS handshake.

7. Click Next.

8. (Optional) Check the Specify the Proxy Certificate for the TLS Client check box to specify a client proxy certificate to use for the TLS Proxy.

9. (Optional) Check the Specify the Internal Certificate Authority to Sign the Local Dynamic Certificate for Phones check box to specify an LDC Issuer to use for the TLS Proxy.

10. In the Security Algorithms area, specify the available and active algorithms to be announced or matched during the TLS handshake (i.e., des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, and null-sha1).

11. Click Next.

12. Click Finish.

13. Click Apply to apply the configuration changes.

14. Click Save to save the configuration in the Cisco ASA.

Example 13-16 shows the commands sent by ASDM to the Cisco ASA after completing the previous steps.

Example 13-16 TLS Proxy Commands Sent by ASDM

Click here to view code image

---

tls-proxy my-tls-proxy
 server trust-point ASDM_TrustPoint0

---

To enable MMP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the MMP check box on the Protocol Inspection tab. You can also configure several optional parameters for this MMP inspection by clicking the Configure button. The Configure TLS Proxy dialog box is displayed. Select the TLS proxy name from the TLS Proxy Name drop-down menu. The previously configured TLS proxy (my-tls-proxy) is used in this example.

To configure MMP inspection via the CLI, use the inspect mmp command to enable FTP inspection. Example 13-17 shows the commands sent by ASDM to the Cisco ASA.

Example 13-17 MMP Inspection Commands Sent by ASDM

Click here to view code image

---

policy-map global_policy
 class inspection_default
  inspect mmp tls-proxy my-tls-proxy

---

The configuration of the Presence Federation Proxy feature is the same as the TLS Proxy configuration.

OPTIONS

GET

HEAD

POST

PUT

DELETE

TRACE

CONNECT

The Cisco ASA checks for these HTTP commands; if the message does not have any of these, the Cisco ASA verifies that it is an HTTP extension method/command (such as MOVE, COPY, EDIT). A syslog message is generated if both checks fail and the packet can be dropped. The Cisco ASA also has the capability to detect double-encoding attacks. This method, known as HTTP de-obfuscation, is one where an HTTP message is encoded by the normalization of encoded characters to ASCII-equivalent characters (sometimes also referred to as ASCII normalization). In a double-encoding attack, the attacker sends an encoded HTTP URI request that has been through two rounds of encoding. Traditionally, firewalls and intrusion detection devices identify the first round of encoding and normalize it. Therefore, the attack still evades the firewall or IDS. The Cisco ASA HTTP inspection engine is able to detect double encoding and prevent this from happening.

The Cisco ASA also provides a feature to filter HTTP messages based on keywords. This is useful when looking for specific applications running over HTTP, such as online instant messenger (IM) applications, music sharing applications, and so on.

You can configure three different security levels (Low, Medium, or High). Low is the default. The following checks and actions are active when the security level is set to Low:

Protocol violation action: Drop connection

URI filtering (if configured)

Advanced inspections (if configured)

The following checks and actions are active when the security level is set to Medium:

Protocol violation action: Drop connection

Drop connections for unsafe methods: Allow only GET, HEAD, and POST

URI filtering (if configured)

Advanced inspections (if configured)

The following checks and actions are active when the security level is set to High:

Protocol violation action: Drop connection and log

Drop connections for unsafe methods: Allow only GET and HEAD

Drop connections for requests with non-ASCII headers

URI filtering (if configured)

Advanced inspections (if configured)

Clicking the URI Filtering button enables you configure the settings for an URI filter with the use of regular expressions.

If you are configuring the Cisco ASA via the CLI, use the inspect http command to enable HTTP inspection. You can also enable enhanced HTTP inspection by creating an HTTP map and associating it to the inspect http command. To create an HTTP map, use the http-map command, as shown in Example 13-18.

Example 13-18 HTTP Inspection Using an HTTP Map

Click here to view code image

---

http-map myhttpmap
 request-method rfc default action allow
 request-method ext move action reset
 request-method ext copy action reset
policy-map asa_global_fw_policy
 class inspection_default
 inspect http myhttpmap

---

In Example 13-18, an HTTP map named myhttpmap is configured. Request method inspection is enabled to allow all default RFC-compliant methods. The two extension methods, move and copy, are not allowed. If they are detected, the HTTP connection is reset. The following HTTP extensions are supported by the Cisco ASA:

copy

edit

getattribute

getattributenames

getproperties

index

lock

mkdir

move

revadd

revlabel

revlog

revnum

save

setattribute

startrev

stoprev

unedit

unlock

Several enhanced HTTP inspection options can be configured under the http-map subcommands. When you design an HTTP map, you are placed into the http-map prompt. The following subcommands are available to configure the necessary rules for enhanced HTTP inspection:

strict-http

content-length

content-type-verification

max-header-length

max-uri-length

port-misuse

request-method

transfer-encoding

Click here to view code image

strict-http action {allow | reset | drop}  [log]

Table 13-4 describes the strict-http command options.

The strict-http command is enabled by default when an HTTP parameter map is applied. The default action is to log and send a TCP reset.

Click here to view code image

content-length {min bytes max bytes}  action {allow | reset | drop}  [log]

Table 13-5 describes the content-length command options.

Text/HTML

Application/Microsoft Word

Application/octet-stream

Application/x-zip

The following is the content-type-verification command syntax:

Click here to view code image

content-type-verification [match-req-rsp] action {allow | reset | drop}  [log]

The match-req-rsp keyword enables the Cisco ASA to verify that the content-type field in the HTTP response matches the accept field in the corresponding HTTP request message.

Click here to view code image

max-header-length {request bytes response bytes}  action {allow | reset | drop}  [log]

Table 13-6 describes the max-header-length command options.

Click here to view code image

max-uri-length bytes action {allow | reset | drop}  [log]

Table 13-7 describes the max-uri-length command options.

Click here to view code image

port-misuse {default | im | p2p | tunneling}  action {allow | reset | drop}  [log]

Table 13-8 describes the port-misuse command options.

Click here to view code image

request-method  rfc rfc_method action { allow | reset | drop}  [log]
request-method  ext ext_method action {allow | reset | drop}  [log]

Table 13-9 describes the request-method command options.

Click here to view code image

transfer-encoding type encoding_types action {allow | reset | drop}  [log]

Table 13-10 describes the transfer-encoding type command options.

Additionally, Cisco ASA can translate ICMP error messages. It translates intermediate hops that send ICMP error messages based on the NAT configuration. Cisco ASA accomplishes this by overwriting the packet with the translated IP addresses.

Cisco ASA also has the capability to inspect ICMP error messages. ICMP error messages always contain the full IP header, including options, of the IP packet that failed and the first eight bytes of the IP data field. Cisco ASA makes sure that this information is present and that it is correct.

To enable ICMP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the ICMP check box on the Protocol Inspection tab. To enable ICMP error inspection via ASDM, navigate to the same location and check the ICMP Error check box.

To enable inspection of ICMP error messages via the CLI, use the inspect icmp error command. If this command is disabled, Cisco ASA does not translate any ICMP error messages generated by intermediate devices.

To enable ILS inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the ILS check box on the Protocol Inspection tab.

To enable ILS inspection via the CLI, use the inspect ils command. This command is disabled by default.

The Cisco ASA ILS inspection engine provides support for the following:

Decoding of the LDAP REQUEST/RESPONSE PDUs using the BER decode functions

Parsing the LDAP packet

Extracting the IP addresses

Translating IP addresses as necessary (PAT is not supported)

Encoding the PDU with translated addresses using BER encode functions

Copying the newly encoded PDU back to the TCP packet

Performing incremental TCP checksum and sequence number adjustment

To enable IM inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the IM check box on the Protocol Inspection tab. You can also configure several optional parameters for IM inspection by clicking the Configure button. The Select IM Inspect Map dialog box is displayed. To create an IM inspect map for fine control over inspection, click Add.

Configure the match criterion and value for the IM inspect map within the Add IM Inspect dialog box.

To specify that the IM inspect map has only one match statement, click the Single Match radio button. The Match Type option is used to define whether traffic should match or not match the values. The Criterion drop-down menu enables you to configure the specific criterion of IM traffic to match. The following options are available:

Protocol

Service

Source IP Address

Destination IP Address

Version

Client Login Name

Client Peer Login Name

Filename

You can select which IM protocols to match within the Protocol area. Yahoo! Messenger and MSN Messenger protocols are the two options.

You can also specify multiple matches for the IM inspection by clicking the Multiple Matches radio button. Click the Manage button to add, edit, or delete IM class maps.

The Actions area enables you to configure the Cisco ASA to drop the connection, reset the connection, or enable logging when traffic matches the previously configured parameters.

To enable IM inspection via the CLI, use the inspect im command. This command is disabled by default. Example 13-19 shows the command sent by ASDM to the Cisco ASA for the previously configured parameters.

Example 13-19 IM Inspection CLI Configuration

Click here to view code image

---

policy-map type inspect im my-im-map
 description IM Inspection Custom Map
 parameters
 match protocol msn-im yahoo-im
  drop-connection log
policy-map global_policy
 class inspection_default
  inspect im my-im-map

---

To enable IPsec pass-through inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the IPSec Pass-Thru check box on the Protocol Inspection tab. You can also configure several optional parameters for this IPsec pass-through inspection by clicking the Configure button. The Select IPsec Pass-Through Inspect Map dialog box is displayed. To create an IPsec pass-through inspect map for fine control over inspection, click Add.

There are two different security levels (High and Low). Low is the default and includes the following checks and actions:

Maximum ESP flows per client: Unlimited

ESP idle timeout: 00:10:00

Maximum AH flows per client: Unlimited

AH idle timeout: 00:10:00

When the security level is set to High, the following checks and actions are enabled:

Maximum ESP flows per client: 10

ESP idle timeout: 00:00:30

Maximum AH flows per client: 10

AH idle timeout: 00:00:30

To enable IPsec pass-through inspection via the CLI, use the inspect ipsec-pass-thru command. Example 13-20 shows the CLI commands sent by ASDM when the security level is set to High.

Example 13-20 IPsec Pass-Through Inspection CLI Configuration

Click here to view code image

---

policy-map type inspect ipsec-pass-thru my-ipsec-passthru-map
 description Custom IPsec passthru inspection map
 parameters
  esp per-client-max 10 timeout 0:00:30
  ah per-client-max 10 timeout 0:00:30
policy-map global_policy
 class inspection_default
  inspect ipsec-pass-thru my-ipsec-passthru-map

---

MGCP messages are ASCII based and are transmitted over UDP. This protocol is defined in RFC 3661. There are eight types of MGCP commands:

CreateConnection

ModifyConnection

DeleteConnection

NotificationRequest

Notify

AuditEndpoint

AuditConnection

RestartInProgress

Each command requires a reply. The first four commands are sent by the call agent to the gateway. The Notify command is sent by the gateway to the call agent. In some cases the gateway may also send a DeleteConnection command to tear down a connection to the call agent. The RestartInProgress command is used in the registration process of the MGCP gateway. The AuditEndpoint and the AuditConnection commands are sent by the call agent to the gateway.

The Cisco ASA performs the following tasks for MGCP inspection:

Inspects all messages exchanged between the call agents and the media gateways

Dynamically creates RTP and RTCP connections

Supports and inspects retransmitted commands and responses

Dynamically adapts to allow a command response to arrive from any of the call agents

A call agent is a device that provides call-processing functions, feature logic, and gateway control in an IP telephony system. An MGCP gateway handles the translation between audio signals and the IP packet network. In the MGCP configurations that Cisco IOS supports, the gateway can be a Cisco router, access server, or cable modem, and the call agent can be a server from Cisco (Cisco PGW or Cisco BTS Softswitches) or from a third-party vendor.

To enable MGCP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the MGCP check box on the Protocol Inspection tab. You can also configure several optional parameters for this MGCP inspection by clicking the Configure button. The Select MGCP Inspect Map dialog box is displayed. To create an MGCP inspect map for fine control over inspection, click Add.

The Command Queue tab enables you to configure the permitted queue size (1 to 2,147,483,647) for MGCP commands. The Gateways and Call Agents tab enables you to configure groups of gateways and call agents. Click Add to add a new group of gateways and call agents for MGCP inspection. The Group ID identifies the ID of the call agent group. This group is used to associate one or more call agents with one or more MGCP media gateways. The Gateways field enables you to configure the IP address of the media gateway that is controlled by the associated call agent. The Call Agents field enables you to configure the IP address of a call agent that controls the MGCP media gateways in the call agent group.

To enable MGCP inspection via the CLI, use the policy-map type inspect mgcp command. Example 13-21 demonstrates how to configure enhanced MGCP inspection.

Example 13-21 Enhanced MGCP Inspection

Click here to view code image

---

policy-map type inspect mgcp mymgcpmap
 parameters
  call-agent 10.10.10.133 876
  gateway 192.168.11.23 876
  command-queue 500
policy-map asa_global_fw_policy
 class inspection_default

---

In Example 13-21, an MGCP map named mymgcpmap is configured. The call-agent command specifies a group of call agents that can manage one or more gateways. A call agent with IP address 10.10.10.133 and group ID 876 is configured.

The Cisco ASA can limit the maximum number of MGCP commands that will be queued waiting for a response to 500. The range of allowed values for the command-queue limit option is 1 to 2,147,483,647.

A gateway with IP address 192.168.11.23 in group 876 is also configured. This is used to specify which call agents are managing a particular gateway.

1. The client broadcasts itself and its NetBIOS information when it boots up.

2. If there is another machine on the network that already has the broadcasted name, that NetBIOS client issues its own broadcast to advertise that the name is in use. Subsequently, the client that is trying to register stops all attempts to register that specific name.

3. The client finishes the registration process if there is no other machine with the same name on the network.

Cisco ASA supports NetBIOS by performing NAT of the packets for NetBIOS Name Server (NBNS) UDP port 137 and NetBIOS Datagram Service (NBDS) UDP port 138.

To enable NetBIOS inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the NetBIOS check box on the Protocol Inspection tab.

To enable NetBIOS inspection on the Cisco ASA, use the inspect netbios command.

The Cisco ASA inspects PPTP protocol packets and dynamically creates the necessary GRE connections and translations to permit PPTP traffic. GRE traffic does not need to be explicitly permitted in the ASA when PPTP inspection is enabled.

To enable PPTP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the PPTP check box on the Protocol Inspection tab.

Use the inspect pptp command to enable PPTP inspection via the CLI.

Cisco ASA Sun RPC inspection provides the following:

Bidirectional inspection of Sun RPC packets

Support of Sun RPC over TCP and UDP

Support of Portmapper v2 and RPCBind v3 and v4

Support of DUMP procedure used by the client to query the server for all the supported services

NAT and PAT support

To enable Sun RPC inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the SUNRPC check box on the Protocol Inspection tab.

To enable Sun RPC inspection via the CLI, use the inspect sunrpc command. Use the Sun RPC services table to control Sun RPC traffic through the adaptive security appliance based on established Sun RPC sessions. To create entries in the Sun RPC services table, use the sunrpc-server command in global configuration mode.

Cisco ASA supports NAT of the negotiated port number with RSH inspection.

To enable RSH inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the RSH check box on the Protocol Inspection tab.

To enable this RSH inspection via the CLI, use the inspect rsh command.

RealAudio

Apple QuickTime

RealPlayer

Cisco IP/TV

Most RTSP applications use TCP port 554. On some rare occasions, UDP is employed in the control channel.

The commonly used TCP control channel negotiates the data channels used to transmit audio and video. This is negotiated based on the transport mode specified on the client.

The following are the supported Real Data Transport (RDT) protocol transports:

rtp/avp

rtp/avp/udp

x-real-rdt

x-real-rdt/udp

x-pn-tng/udp

To enable RTSP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the RTSP check box on the Protocol Inspection tab.

Use the inspect rtsp command to enable RTSP inspection via the CLI.

The Cisco ASA is able to inspect any NAT SIP transactions successfully.

To enable SIP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the SIP check box on the Protocol Inspection tab.

To enable SIP inspection via the CLI, use the inspect sip command. You can see SIP connection statistics by using the show conn state sip command. The show service-policy command provides you with SIP inspection statistics.

SIP is also used by IM applications. The details on SIP extensions for instant messaging are defined in RFC 3428. Instant messengers use MESSAGE/INFO requests and 202 Accept responses when users chat with each other. The MESSAGE/INFO requests are sent after registration and subscription transactions are completed. For example, two users may have their IM application connected at any time, but not talk to each other for a long period of time. The Cisco ASA SIP inspection engine maintains this information for a set period of time according to the configured SIP timeout value.

To configure the idle timeout after which an SIP control connection will be closed, use the timeout sip command. The default timeout value is 30 minutes. Use the timeout sip_media command to configure the idle timeout after which an SIP media connection will be closed. The default is 2 minutes.

Example 13-22 shows how the Cisco ASA is configured with an SIP timeout of one hour.

Example 13-22 SIP Timeout Example

Click here to view code image

---

NewYork(config)# timeout sip 1:00:00
NewYork(config)# timeout sip_media 0:30:00

---

In Figure 13-21, the Cisco IP phone is assigned to a specific VLAN. Then it sends a request to the DHCP server to get an IP address, DNS server address, and TFTP server name or address. It also gets a default gateway address if you have set these options in the DHCP server.

The Cisco IP phone obtains its configuration from the TFTP server. It resolves the Cisco CallManager name via DNS and starts the Skinny registration process.

To enable Skinny inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the SCCP (Skinny) check box on the Protocol Inspection tab.

To configure Skinny inspection via the CLI, use the inspect skinny command. This command is enabled by default.

As previously discussed, Cisco IP phones download their configuration information from a TFTP server. This information includes the name or IP address of the Cisco CallManager server to which they need to connect. You must use an ACL to open UDP port 69 when the Cisco IP phones are on a lower security–level interface compared to the TFTP server. Enabling TFTP inspection with the inspect tftp command may be necessary to allow the secondary data connection initiated by the Cisco CallManager. If the Cisco IP Phones are on a lower security–level interface compared to the Cisco CallManager, create a static NAT entry for the Cisco CallManager.

Example 13-23 SNMP Inspection

Click here to view code image

---

snmp-map mysnmpmap
 deny version 1
policy-map global_policy
 class inspection_default
  inspect snmp mysnmpmap

---

In Example 13-23, the Cisco ASA is set up for an SNMP map, called mysnmpmap, which denies any SNMPv1 packets. The following are the deny version subcommand options:

1 = SNMP version 1

2 = SNMP version 2 (party based)

2c = SNMP version 2c (community based)

3 = SNMP version 3

To enable SNMP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the SNMP check box on the Protocol Inspection tab. Click Configure to configure the specific SNMP version(s) that are to be denied.

The Add SNMP Map dialog box is displayed, and it enables you to create a new SNMP map for controlling SNMP application inspection.

To enable SQL*Net inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the SQLNET check box on the Protocol Inspection tab.

To enable SQL*Net inspection via the CLI, use the inspect sqlnet command.

To enable TFTP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the TFTP check box on the Protocol Inspection tab.

Use the inspect tftp command to enable TFTP inspection on the Cisco ASA via the CLI.

To enable WAAS inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the WAAS check box on the Protocol Inspection tab.

To enable WAAS application inspection via the CLI, use the inspect waas command.

XDMCP uses UDP port 177 to negotiate X sessions using a TCP port. The X manager communicates with the X server over TCP port 6000 + n (n = negotiated port).

To enable XDMCP inspection via ASDM, navigate to Configuration > Firewall > Service Policy Rules, select the respective service policy, and click Edit. In the Edit Service Policy Rule dialog box (previously shown in Figure 13-4), click the Rule Actions tab and check the XDMCP check box on the Protocol Inspection tab.

To enable XDMCP inspection via the CLI, use the inspect xdmcp command.