Book 2: Cisco ASA Series Firewall CLI Configuration Guide, 9.1
Configuring Inspection of Basic Internet Protocols
Downloads: This chapterpdf (PDF - 358.0KB) The complete bookPDF (PDF - 10.46MB) | The complete bookePub (ePub - 3.57MB) | The complete bookMobi (Mobi - 3.47MB) | Feedback

Table of Contents

Configuring Inspection of Basic Internet Protocols

DNS Inspection

Information About DNS Inspection

General Information About DNS

DNS Inspection Actions

Default Settings for DNS Inspection

(Optional) Configuring a DNS Inspection Policy Map and Class Map

Configuring DNS Inspection

Monitoring DNS Inspection

FTP Inspection

FTP Inspection Overview

Using the strict Option

Configuring an FTP Inspection Policy Map for Additional Inspection Control

Verifying and Monitoring FTP Inspection

HTTP Inspection

HTTP Inspection Overview

Configuring an HTTP Inspection Policy Map for Additional Inspection Control

ICMP Inspection

ICMP Error Inspection

Instant Messaging Inspection

IM Inspection Overview

Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control

IP Options Inspection

IP Options Inspection Overview

Configuring an IP Options Inspection Policy Map for Additional Inspection Control

IPsec Pass Through Inspection

IPsec Pass Through Inspection Overview

Example for Defining an IPsec Pass Through Parameter Map

IPv6 Inspection

Information about IPv6 Inspection

Default Settings for IPv6 Inspection

(Optional) Configuring an IPv6 Inspection Policy Map

Configuring IPv6 Inspection

NetBIOS Inspection

NetBIOS Inspection Overview

Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control

PPTP Inspection

SMTP and Extended SMTP Inspection

SMTP and ESMTP Inspection Overview

Configuring an ESMTP Inspection Policy Map for Additional Inspection Control

TFTP Inspection

Configuring Inspection of Basic Internet Protocols

This chapter describes how to configure application layer protocol inspection. Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the ASA to do a deep packet inspection instead of passing the packet through the fast path. As a result, inspection engines can affect overall throughput.

Several common inspection engines are enabled on the ASA by default, but you might need to enable others depending on your network.

This chapter includes the following sections:

DNS Inspection

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

Information About DNS Inspection

General Information About DNS

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

DNS Inspection Actions

DNS inspection is enabled by default. You can customize DNS inspection to perform many tasks:

  • Translate the DNS record based on the NAT configuration. For more information, see the “DNS and NAT” section.
  • Enforce message length, domain-name length, and label length.
  • Verify the integrity of the domain-name referred to by the pointer if compression pointers are encountered in the DNS message.
  • Check to see if a compression pointer loop exists.
  • Inspect packets based on the DNS header, type, class and more.

Default Settings for DNS Inspection

DNS inspection is enabled by default, using the preset_dns_map inspection class map:

  • The maximum DNS message length is 512 bytes.
  • The maximum client DNS message length is automatically set to match the Resource Record.
  • DNS Guard is enabled, so the ASA tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the ASA. The ASA also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.
  • Translation of the DNS record based on the NAT configuration is enabled.
  • Protocol enforcement is enabled, which enables DNS message format check, including domain name length of no more than 255 characters, label length of 63 characters, compression, and looped pointer check.

See the following default DNS inspection commands:

class-map inspection_default
match default-inspection-traffic
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
dns-guard
protocol-enforcement
nat-rewrite
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
! ...
service-policy global_policy global

(Optional) Configuring a DNS Inspection Policy Map and Class Map

To match DNS packets with certain characteristics and perform special actions, create a DNS inspection policy map. You can also configure a DNS inspection class map to group multiple match criteria for reference within the inspection policy map. You can then apply the inspection policy map when you enable DNS inspection.

Prerequisites

If you want to match a DNS message domain name list, then create a regular expression using one of the methods below:

  • Create a regular expression (see the general operations configuration guide).
  • Create a regular expression class map (see the general operations configuration guide).

Detailed Steps

 

Command
Purpose

Step 1

Do one of the following:

class-map type inspect dns [match-all | match-any] class_map_name

 

ciscoasa(config)# class-map type inspect dns match-all dns-class-map

Creates a DNS inspection class map, where class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one of the criteria.

A class map groups multiple traffic matches. You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.

The CLI enters class-map configuration mode, where you can enter one or more match or match not commands.

For the traffic that you identify in this class map, you can only specify actions (such as drop) for the entire class. If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.

policy-map type inspect dns name

 

ciscoasa(config)# policy-map type inspect dns dns-map

Creates an inspection policy map in which you want to match traffic directly.

You can specify multiple match commands in the policy map. For information about the order of match commands, see the “Defining Actions in an Inspection Policy Map” section.

Step 2

match [ not ] header-flag [eq] {f_well_known [ f_well_known ...] | f_value}

 

For direct match only:

{ drop [ log ] | drop-connection [ log ]| [ enforce-tsig {[ drop ] [ log ]}] [ mask [ log ]] | log }

 

ciscoasa(config-pmap)# match header-flag AA QR

ciscoasa(config-pmap-c)# mask log

ciscoasa(config-pmap-c)# enforce-tsig log

Matches a specific flag or flags that are set in the DNS header, where the f_well_known argument is the DNS flag bit. The f_value argument is the 16-bit value in hex starting with 0x. The eq keyword specifies an exact match (match all); without the eq keyword, the packet only needs to match one of the specified headers (match any).

To specify traffic that should not match, use the match not command.

If you are matching directly in the inspection policy map, specify the action(s) for the match:

  • drop [ log ]—Drops the packet. log also logs the packet.
  • drop-connection [ log ]—Drops the packet and closes the connection. log also logs the packet.
  • enforce-tsig {[ drop ] [ log ]}—Enforces the TSIG resource record in a message. drop drops a packet without the TSIG resource record. log also logs the packet.
  • mask [ log ]— M asks out the matching portion of the packet. log also logs the packet.
  • log —Logs the packet.

Step 3

match [ not ] dns-type { eq {t_well_known | t_val}} { range t_val1 t_val2}

 

For direct match only:

{ drop [ log ] | drop-connection [ log ]| enforce-tsig {[ drop ] [ log ]} | log }

 

ciscoasa(config-pmap)# match dns-type eq aaaa

ciscoasa(config-pmap-c)# enforce-tsig log

Matches a DNS type, where the t_well_known argument is the DNS flag bit. The t_val arguments are arbitrary values in the DNS type field (0-65535). The range keyword specifies a range, and the eq keyword specifies an exact match.

To specify traffic that should not match, use the match not command.

If you are matching directly in the inspection policy map, specify the action for the match:

  • drop [ log ]—Drops the packet. log also logs the packet.
  • drop-connection [ log ]—Drops the packet and closes the connection. log also logs the packet.
  • enforce-tsig {[ drop ] [ log ]}—Enforces the TSIG resource record in a message. drop drops a packet without the TSIG resource record. log also logs the packet.
  • log —Logs the packet.

Step 4

match [ not ] dns-class { eq { in | c_val}} | range c_val1 c_val2}

 

For direct match only:

{ drop [ log ] | drop-connection [ log ]| enforce-tsig {[ drop ] [ log ]} | log }

 

ciscoasa(config-pmap)# match dns-class eq in

ciscoasa(config-pmap-c)# log

Matches a DNS class, either in (for Internet) or c_val, an arbitrary value from 0 to 65535 in the DNS class field. The range keyword specifies a range, and the eq keyword specifies an exact match.

To specify traffic that should not match, use the match not command.

If you are matching directly in the inspection policy map, specify the action for the match:

  • drop [ log ]—Drops the packet. log also logs the packet.
  • drop-connection [ log ]—Drops the packet and closes the connection. log also logs the packet.
  • enforce-tsig {[ drop ] [ log ]}—Enforces the TSIG resource record in a message. drop drops a packet without the TSIG resource record. log also logs the packet.
  • log —Logs the packet.

Step 5

match { question | resource-record { answer | authority | additional }}

 

For direct match only:

{ drop [ log ] | drop-connection [ log ]| enforce-tsig {[ drop ] [ log ]} | log }

 

ciscoasa(config-pmap)# match resource-record answer

ciscoasa(config-pmap-c)# drop-connection

Matches a DNS question or resource record, where the question keyword specifies the question portion of a DNS message. The resource-record keyword specifies the resource record portion of a DNS message; the answer keyword specifies the Answer RR section; the authority keyword specifies the Authority RR section; the additional keyword specifies the Additional RR section.

To specify traffic that should not match, use the match not command.

If you are matching directly in the inspection policy map, specify the action for the match:

  • drop [ log ]—Drops the packet. log also logs the packet.
  • drop-connection [ log ]—Drops the packet and closes the connection. log also logs the packet.
  • enforce-tsig {[ drop ] [ log ]}—Enforces the TSIG resource record in a message. drop drops a packet without the TSIG resource record. log also logs the packet.
  • log —Logs the packet.

Step 6

match [not] domain-name regex {regex_id | class class_id]

 

For direct match only:

{ drop [ log ] | drop-connection [ log ]| enforce-tsig {[ drop ] [ log ]} | log }

 

ciscoasa(config-pmap)# match domain-name regex regex1

ciscoasa(config-pmap-c)# drop-connection

Matches a DNS message domain name list. The regex_name argument is a regular expression. The class regex_class_name is a regular expression class map. See the “Prerequisites” section.

To specify traffic that should not match, use the match not command.

If you are matching directly in the inspection policy map, specify the action for the match:

  • drop [ log ]—Drops the packet. log also logs the packet.
  • drop-connection [ log ]—Drops the packet and closes the connection. log also logs the packet.
  • enforce-tsig {[ drop ] [ log ]}—Enforces the TSIG resource record in a message. drop drops a packet without the TSIG resource record. log also logs the packet.
  • log —Logs the packet.

Step 7

(If you are using a DNS inspection class map)

policy-map type inspect dns name

class class_map_name

{ drop [ log ] | drop-connection [ log ]| enforce-tsig {[ drop ] [ log ]} | mask [ log ] | log }

 

 

ciscoasa(config)# policy-map type inspect dns dns-map

ciscoasa(config-pmap)# class dns-class-map

ciscoasa(config-pmap-c)# drop

ciscoasa(config-pmap-c)# match header-flag eq aa

ciscoasa(config-pmap-c)# drop log

Creates an inspection policy map, specifies the DNS inspection class map, and sets the action for the class map:

  • drop [ log ]—Drops the packet. log also logs the packet.
  • drop-connection [ log ]—Drops the packet and closes the connection. log also logs the packet.
  • enforce-tsig {[ drop ] [ log ]}—Enforces the TSIG resource record in a message. drop drops a packet without the TSIG resource record. log also logs the packet.
  • mask [ log ]— M asks out the matching portion of the packet. log also logs the packet.
  • log —Logs the packet.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the “Defining Actions in an Inspection Policy Map” section.

Step 8

parameters

{ dns-guard | id-mismatch count number duration seconds action log | id-randomization | message-length maximum { length | client {[ length ] [ auto ]} | server {[ length ] [ auto ]}} | nat-rewrite | protocol-enforcement | tsig enforced action {[ drop ] [ log ]}}

 

ciscoasa(config-pmap)# parameters

ciscoasa(config-pmap-p)# dns-guard

ciscoasa(config-pmap-p)# id-mismatch action log

ciscoasa(config-pmap-p)# message-length maximum 1024

ciscoasa(config-pmap-p)# nat-rewrite

ciscoasa(config-pmap-p)# protocol-enforcement

Enters parameters configuration mode so you can set one or more parameters:

  • dns-guard —Enables DNS Guard. The ASA tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the ASA. The ASA also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.
  • id-mismatch count number duration seconds action log —Enables logging for excessive DNS ID mismatches, where the count number duration seconds arguments specify the maximum number of mismatch instances per second before a system message log is sent.
  • id-randomization —Randomizes the DNS identifier for a DNS query.
  • message-length maximum { length | client {[ length ] [ auto ]} | server {[ length ] [ auto ]}}—Sets the maximum DNS message length, from 512 to 65535 bytes. You can also set the maximum length for client or server messages. auto sets the maximum length to the value in the Resource Record.
  • nat-rewrite —Translates the DNS record based on the NAT configuration.
  • protocol-enforcement —Enables DNS message format check, including domain name length of no more than 255 characters, label length of 63 characters, compression, and looped pointer check.
  • tsig enforced action {[ drop ] [ log ]}—Requires a TSIG resource record to be present. drop drops a non-conforming packet. log logs the packet.

Examples

The following example shows a how to define a DNS inspection policy map.

regex domain_example “example\.com”
regex domain_foo “foo\.com”
 
! define the domain names that the server serves
class-map type inspect regex match-any my_domains
match regex domain_example
match regex domain_foo
 
! Define a DNS map for query only
class-map type inspect dns match-all pub_server_map
match not header-flag QR
match question
match not domain-name regex class my_domains
 
policy-map type inspect dns new_dns_map
class pub_server_map
drop log
match header-flag RD
mask log
parameters
message-length maximum client auto
message-length maximum 512
dns-guard
protocol-enforcement
nat-rewrite

Configuring DNS Inspection

The default ASA configuration includes many default inspections on default ports applied globally on all interfaces. A common method for customizing the inspection configuration is to customize the default global policy. The steps in this section show how to edit the default global policy, but you can alternatively create a new service policy as desired, for example, an interface-specific policy.

Detailed Steps

 

Command
Purpose

Step 1

class-map name

 

ciscoasa(config)# class-map dns_class_map

Creates a class map to identify the traffic for which you want to apply the inspection.

In the default global policy, the inspection_default class map is a special class map that includes default ports for all inspection types ( match default-inspection-traffic ). If you are using this class map in either the default policy or for a new service policy, you can skip this step and the next step.

Step 2

match parameter

 

ciscoasa(config-cmap)# match access-list dns

Specifies the traffic in the class map. See the “Identifying Traffic (Layer 3/4 Class Maps)” section for more information.

Step 3

policy-map name

 

ciscoasa(config)# policy-map global_policy

Adds or edits a policy map that sets the actions to take with the class map traffic.

In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name.

Step 4

class name

 

ciscoasa(config-pmap)# class inspection_default

Identifies the class map created in Step 1.

To edit the default policy, or to use the special inspection_default class map in a new policy, specify inspection_default for the name .

Step 5

inspect dns [ dns_policy_map ] [ dynamic-filter-snoop ]

 

ciscoasa(config-class)# no inspect dns

ciscoasa(config-class)# inspect dns dns-map

Configures DNS inspection. Specify the inspection policy map you created in the “(Optional) Configuring a DNS Inspection Policy Map and Class Map” section.

For information about the Botnet Traffic Filter dynamic-filter-snoop keyword, see the “Enabling DNS Snooping” section.

Note If you are editing the default global policy (or any in-use policy) to use a different DNS inspection policy map from the default preset_dns_map, you must remove the DNS inspection with the no inspect dns command, and then re-add it with the new DNS inspection policy map name.

Step 6

service-policy policymap_name {global | interface interface_name }

 

 

ciscoasa(config)# service-policy global_policy global

Activates the policy map on one or more interfaces. global applies the policy map to all interfaces, and interface applies the policy to one interface. 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.

The default configuration includes a global policy called global_policy. If you are editing that policy, you can skip this step.

Examples

The following example shows a how to use a new inspection policy map in the global default configuration:

policy-map global_policy
class inspection_default
no inspect dns preset_dns_map
inspect dns new_dns_map
service-policy global_policy global
 

Monitoring DNS Inspection

To view information about the current DNS connections, enter the following command:

ciscoasa# show conn
 

For connections using a DNS server, the source port of the connection may be replaced by the IP address of DNS server in the show conn command output.

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, when you enter the show conn command, you 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.

To display the statistics for DNS application inspection, enter the show service-policy command. The following is sample output from the show service-policy command:

ciscoasa# show service-policy
Interface outside:
Service-policy: sample_policy
Class-map: dns_port
Inspect: dns maximum-length 1500, packet 0, drop 0, reset-drop 0
 

FTP Inspection

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

FTP Inspection Overview

The FTP application inspection inspects the FTP sessions and performs four tasks:

  • Prepares dynamic secondary data connection
  • Tracks the FTP command-response sequence
  • Generates an audit trail
  • Translates the embedded IP address

FTP application inspection prepares secondary channels for FTP data transfer. Ports for these channels are negotiated through PORT or PASV commands. The channels are allocated in response to a file upload, a file download, or a directory listing event.


Note If you disable FTP inspection engines with the no inspect ftp command, outbound users can start connections only in passive mode, and all inbound FTP is disabled.


Using the strict Option

Using the strict option with the inspect ftp command increases the security of protected networks by preventing web browsers from sending embedded commands in FTP requests.


Note To specify FTP commands that are not permitted to pass through the ASA, create an FTP map according to the “Configuring an FTP Inspection Policy Map for Additional Inspection Control” section.


After you enable the strict option on an interface, FTP inspection enforces the following behavior:

  • An FTP command must be acknowledged before the ASA allows a new command.
  • The ASA drops connections that send embedded commands.
  • The 227 and PORT commands are checked to ensure they do not appear in an error string.

Caution Using the strict option may cause the failure of FTP clients that are not strictly compliant with FTP RFCs.

If the strict option is enabled, each FTP command and response sequence is tracked for the following anomalous activity:

  • Truncated command—Number of commas in the PORT and PASV reply command is checked to see if it is five. If it is not five, then the PORT command is assumed to be truncated and the TCP connection is closed.
  • Incorrect command—Checks the FTP command to see if it ends with <CR><LF> characters, as required by the RFC. If it does not, the connection is closed.
  • Size of RETR and STOR commands—These are checked against a fixed constant. If the size is greater, then an error message is logged and the connection is closed.
  • Command spoofing—The PORT command should always be sent from the client. The TCP connection is denied if a PORT command is sent from the server.
  • Reply spoofing—PASV reply command (227) should always be sent from the server. The TCP connection is denied if a PASV reply command is sent from the client. This prevents the security hole when the user executes “227 xxxxx a1, a2, a3, a4, p1, p2.”
  • TCP stream editing—The ASA closes the connection if it detects TCP stream editing.
  • Invalid port negotiation—The negotiated dynamic port value is checked to see if it is less than 1024. As port numbers in the range from 1 to 1024 are reserved for well-known connections, if the negotiated port falls in this range, then the TCP connection is freed.
  • Command pipelining—The number of characters present after the port numbers in the PORT and PASV reply command is cross checked with a constant value of 8. If it is more than 8, then the TCP connection is closed.
  • The ASA replaces the FTP server response to the SYST command with a series of Xs. to prevent the server from revealing its system type to FTP clients. To override this default behavior, use the no mask-syst-reply command in the FTP map.

Configuring an FTP Inspection Policy Map for Additional Inspection Control

FTP command filtering and security checks are provided using strict FTP inspection for improved security and control. Protocol conformance includes packet length checks, delimiters and packet format checks, command terminator checks, and command validation.

Blocking FTP based on user values is also supported so that it is possible for FTP sites to post files for download, but restrict access to certain users. You can block FTP connections based on file type, server name, and other attributes. System message logs are generated if an FTP connection is denied after inspection.

If you want FTP inspection to allow FTP servers to reveal their system type to FTP clients, and limit the allowed FTP commands, then create and configure an FTP map. You can then apply the FTP map when you enable FTP inspection.

To create an FTP map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the general operations configuration guide. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the general operations configuration guide.

Step 3 (Optional) Create an FTP inspection class map by performing the following steps.

A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map. You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.

To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string “example.com,” then any traffic that includes “example.com” does not match the class map.

For the traffic that you identify in this class map, you can specify actions such as drop, drop-connection, reset, mask, set the rate limit, and/or log the connection in the inspection policy map.

If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.

a. Create the class map by entering the following command:

ciscoasa(config)# class-map type inspect ftp [match-all | match-any] class_map_name
ciscoasa(config-cmap)#
 

Where class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one of the criteria. The CLI enters class-map configuration mode, where you can enter one or more match commands.

b. (Optional) To add a description to the class map, enter the following command:

ciscoasa(config-cmap)# description string
 

c. (Optional) To match a filename for FTP transfer, enter the following command:

ciscoasa(config-cmap)# match [not] filename regex [regex_name | class regex_class_name]
 

Where the regex_name is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

d. (Optional) To match a file type for FTP transfer, enter the following command:

ciscoasa(config-cmap)# match [not] filetype regex [regex_name | class regex_class_name]
 

Where the regex_name is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

e. (Optional) To disallow specific FTP commands, use the following command:

ciscoasa(config-cmap)# match [not] request-command ftp_command [ftp_command...]
 

Where ftp_command with one or more FTP commands that you want to restrict. See Table 10-1 for a list of the FTP commands that you can restrict.

.

Table 10-1 FTP Map request-command deny Options

request-command deny Option
Purpose

appe

Disallows the command that appends to a file.

cdup

Disallows the command that changes to the parent directory of the current working directory.

dele

Disallows the command that deletes a file on the server.

get

Disallows the client command for retrieving a file from the server.

help

Disallows the command that provides help information.

mkd

Disallows the command that makes a directory on the server.

put

Disallows the client command for sending a file to the server.

rmd

Disallows the command that deletes a directory on the server.

rnfr

Disallows the command that specifies rename-from filename.

rnto

Disallows the command that specifies rename-to filename.

site

Disallows the command that are specific to the server system. Usually used for remote administration.

stou

Disallows the command that stores a file using a unique file name.

f. (Optional) To match an FTP server, enter the following command:

ciscoasa(config-cmap)# match [not] server regex [regex_name | class regex_class_name]
 

Where the regex_name is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

g. (Optional) To match an FTP username, enter the following command:

ciscoasa(config-cmap)# match [not] username regex [regex_name | class regex_class_name]
 

Where the regex_name is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

Step 4 Create an FTP inspection policy map, enter the following command:

ciscoasa(config)# policy-map type inspect ftp policy_map_name
ciscoasa(config-pmap)#
 

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

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

ciscoasa(config-pmap)# description string
 

Step 6 To apply actions to matching traffic, perform the following steps.

a. Specify the traffic on which you want to perform actions using one of the following methods:

  • Specify the FTP class map that you created in Step 3 by entering the following command:
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)#
 
  • Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.

b. Specify the action you want to perform on the matching traffic by entering the following command:

ciscoasa(config-pmap-c)# {[drop [send-protocol-error] | drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 

Not all options are available for each match or class command. See the CLI help or the command reference for the exact options available.

The drop keyword drops all packets that match.

The send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.

The log keyword, which you can use alone or with one of the other keywords, sends a system log message.

The rate-limit message_rate argument limits the rate of messages.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the “Defining Actions in an Inspection Policy Map” section.

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

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

ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)#
 

b. To mask the greeting banner from the FTP server, enter the following command:

ciscoasa(config-pmap-p)# mask-banner
 

c. To mask the reply to syst command, enter the following command:

ciscoasa(config-pmap-p)# mask-syst-reply


 

Before submitting a username and password, all FTP users are presented with a greeting banner. By default, this banner includes version information useful to hackers trying to identify weaknesses in a system. The following example shows how to mask this banner:

 
ciscoasa(config)# policy-map type inspect ftp mymap
ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)# mask-banner
 
ciscoasa(config)# class-map match-all ftp-traffic
ciscoasa(config-cmap)# match port tcp eq ftp
 
ciscoasa(config)# policy-map ftp-policy
ciscoasa(config-pmap)# class ftp-traffic
ciscoasa(config-pmap-c)# inspect ftp strict mymap
 
ciscoasa(config)# service-policy ftp-policy interface inside
 

Verifying and Monitoring FTP Inspection

FTP application inspection generates the following log messages:

  • An Audit record 303002 is generated for each file that is retrieved or uploaded.
  • The FTP command is checked to see if it is RETR or STOR and the retrieve and store commands are logged.
  • The username is obtained by looking up a table providing the IP address.
  • The username, source IP address, destination IP address, NAT address, and the file operation are logged.
  • Audit record 201005 is generated if the secondary dynamic channel preparation failed due to memory shortage.

In conjunction with NAT, the FTP application inspection translates the IP address within the application payload. This is described in detail in RFC 959.

HTTP Inspection

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

HTTP Inspection Overview

Use the HTTP inspection engine to protect against specific attacks and other threats that are associated with HTTP traffic. HTTP inspection performs several functions:

  • Enhanced HTTP inspection
  • URL screening through N2H2 or Websense

See Information About URL Filtering for information.

  • Java and ActiveX filtering

The latter two features are configured in conjunction with the filter command. For more information about filtering, see Chapter29, “Configuring Filtering Services”

The enhanced HTTP inspection feature, which is also known as an application firewall and is available when you configure an HTTP map (see “Configuring an HTTP Inspection Policy Map for Additional Inspection Control”), can help prevent attackers from using HTTP messages for circumventing network security policy. It verifies the following for all HTTP messages:

  • Conformance to RFC 2616
  • Use of RFC-defined methods only.
  • Compliance with the additional criteria.

Configuring an HTTP Inspection Policy Map for Additional Inspection Control

To specify actions when a message violates a parameter, create an HTTP inspection policy map. You can then apply the inspection policy map when you enable HTTP inspection.


Note When you enable HTTP inspection with an inspection policy map, strict HTTP inspection with the action reset and log is enabled by default. You can change the actions performed in response to inspection failure, but you cannot disable strict inspection as long as the inspection policy map remains enabled.


To create an HTTP inspection policy map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the general operations configuration guide. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the general operations configuration guide.

Step 3 (Optional) Create an HTTP inspection class map by performing the following steps.

A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map. You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.

To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string “example.com,” then any traffic that includes “example.com” does not match the class map.

For the traffic that you identify in this class map, you can specify actions such as drop, drop-connection, reset, mask, set the rate limit, and/or log the connection in the inspection policy map.

If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.

a. Create the class map by entering the following command:

ciscoasa(config)# class-map type inspect http [match-all | match-any] class_map_name
ciscoasa(config-cmap)#
 

Where class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one of the criteria. The CLI enters class-map configuration mode, where you can enter one or more match commands.

b. (Optional) To add a description to the class map, enter the following command:

ciscoasa(config-cmap)# description string
 

c. (Optional) To match traffic with a content-type field in the HTTP response that does not match the accept field in the corresponding HTTP request message, enter the following command:

ciscoasa(config-cmap)# match [not] req-resp content-type mismatch
 

d. (Optional) To match text found in the HTTP request message arguments, enter the following command:

ciscoasa(config-cmap)# match [not] request args regex [regex_name | class regex_class_name]
 

Where the regex_name is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

e. (Optional) To match text found in the HTTP request message body or to match traffic that exceeds the maximum HTTP request message body length, enter the following command:

ciscoasa(config-cmap)# match [not] request body {regex [regex_name | class regex_class_name] | length gt max_bytes}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.

f. (Optional) To match text found in the HTTP request message header, or to restrict the count or length of the header, enter the following command:

ciscoasa(config-cmap)# match [not] request header {[field] [regex [regex_name | class regex_class_name]] | [length gt max_length_bytes | count gt max_count_bytes]}
 

Where the field is the predefined message header keyword. The regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes. The count gt max_count is the maximum number of header fields.

g. (Optional) To match text found in the HTTP request message method, enter the following command:

ciscoasa(config-cmap)# match [not] request method {[method] | [regex [regex_name | class regex_class_name]]
 

Where the method is the predefined message method keyword. The regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

h. (Optional) To match text found in the HTTP request message URI, enter the following command:

ciscoasa(config-cmap)# match [not] request uri {regex [regex_name | class regex_class_name] | length gt max_bytes}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.

i. Optional) To match text found in the HTTP response message body, or to comment out Java applet and Active X object tags in order to filter them, enter the following command:

ciscoasa(config-cmap)# match [not] response body {[active-x] | [java-applet] | [regex [regex_name | class regex_class_name]] | length gt max_bytes}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes.

j. (Optional) To match text found in the HTTP response message header, or to restrict the count or length of the header, enter the following command:

ciscoasa(config-cmap)# match [not] response header {[field] [regex [regex_name | class regex_class_name]] | [length gt max_length_bytes | count gt max_count]}
 

Where the field is the predefined message header keyword. The regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2. The length gt max_bytes is the maximum message body length in bytes. The count gt max_count is the maximum number of header fields.

k. (Optional) To match text found in the HTTP response message status line, enter the following command:

ciscoasa(config-cmap)# match [not] response status-line {regex [regex_name | class regex_class_name]}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

Step 4 Create an HTTP inspection policy map, enter the following command:

ciscoasa(config)# policy-map type inspect http policy_map_name
ciscoasa(config-pmap)#
 

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

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

ciscoasa(config-pmap)# description string
 

Step 6 To apply actions to matching traffic, perform the following steps.

a. Specify the traffic on which you want to perform actions using one of the following methods:

  • Specify the HTTP class map that you created in Step 3 by entering the following command:
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)#
 
  • Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.

b. Specify the action you want to perform on the matching traffic by entering the following command:

ciscoasa(config-pmap-c)# {[drop [send-protocol-error] | drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 

Not all options are available for each match or class command. See the CLI help or the command reference for the exact options available.

The drop keyword drops all packets that match.

The send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.

The log keyword, which you can use alone or with one of the other keywords, sends a system log message.

The rate-limit message_rate argument limits the rate of messages.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the “Defining Actions in an Inspection Policy Map” section.

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

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

ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)#
 

b. To check for HTTP protocol violations, enter the following command:

ciscoasa(config-pmap-p)# protocol-violation [action [drop-connection | reset | log]]
 

Where the drop-connection action closes the connection. The reset action closes the connection and sends a TCP reset to the client. The log action sends a system log message when this policy map matches traffic.

c. To substitute a string for the server header field, enter the following command:

ciscoasa(config-pmap-p)# spoof-server string
 

Where the string argument is the string to substitute for the server header field. Note: WebVPN streams are not subject to the spoof-server comand.


 

The following example shows how to define an HTTP inspection policy map that will allow and log any HTTP connection that attempts to access “www\.xyz.com/.*\.asp" or "www\.xyz[0-9][0-9]\.com" with methods "GET" or "PUT." All other URL/Method combinations will be silently allowed.

ciscoasa(config)# regex url1 “www\.xyz.com/.*\.asp”
ciscoasa(config)# regex url2 “www\.xyz[0-9][0-9]\.com”
ciscoasa(config)# regex get “GET”
ciscoasa(config)# regex put “PUT”
 
ciscoasa(config)# class-map type regex match-any url_to_log
ciscoasa(config-cmap)# match regex url1
ciscoasa(config-cmap)# match regex url2
ciscoasa(config-cmap)# exit
 
ciscoasa(config)# class-map type regex match-any methods_to_log
ciscoasa(config-cmap)# match regex get
ciscoasa(config-cmap)# match regex put
ciscoasa(config-cmap)# exit
 
ciscoasa(config)# class-map type inspect http http_url_policy
ciscoasa(config-cmap)# match request uri regex class url_to_log
ciscoasa(config-cmap)# match request method regex class methods_to_log
ciscoasa(config-cmap)# exit
 
ciscoasa(config)# policy-map type inspect http http_policy
ciscoasa(config-pmap)# class http_url_policy
ciscoasa(config-pmap-c)# log
 

ICMP Inspection

The ICMP inspection engine allows ICMP traffic to have a “session” so it can be inspected like TCP and UDP traffic. Without the ICMP inspection engine, we recommend that you do not allow ICMP through the ASA in an ACL. Without stateful inspection, ICMP can be used to attack your network. The ICMP inspection engine ensures that there is only one response for each request, and that the sequence number is correct.

ICMP Error Inspection

When this feature is enabled, the ASA creates translation sessions for intermediate hops that send ICMP error messages, based on the NAT configuration. The ASA overwrites the packet with the translated IP addresses.

When disabled, the ASA does not create translation sessions for intermediate nodes that generate ICMP error messages. ICMP error messages generated by the intermediate nodes between the inside host and the ASA reach the outside host without consuming any additional NAT resource. This is undesirable when an outside host uses the traceroute command to trace the hops to the destination on the inside of the ASA. When the ASA does not translate the intermediate hops, all the intermediate hops appear with the mapped destination IP address.

The ICMP payload is scanned to retrieve the five-tuple from the original packet. Using the retrieved five-tuple, a lookup is performed to determine the original address of the client. The ICMP error inspection engine makes the following changes to the ICMP packet:

  • In the IP Header, the mapped IP is changed to the real IP (Destination Address) and the IP checksum is modified.
  • In the ICMP Header, the ICMP checksum is modified due to the changes in the ICMP packet.
  • In the Payload, the following changes are made:

Original packet mapped IP is changed to the real IP

Original packet mapped port is changed to the real Port

Original packet IP checksum is recalculated

Instant Messaging Inspection

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

IM Inspection Overview

The IM inspect engine lets you apply fine grained controls on the IM application to control the network usage and stop leakage of confidential data, propagation of worms, and other threats to the corporate network.

Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control

To specify actions when a message violates a parameter, create an IM inspection policy map. You can then apply the inspection policy map when you enable IM inspection.

To create an IM inspection policy map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the general operations configuration guide. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the general operations configuration guide.

Step 3 (Optional) Create an IM inspection class map by performing the following steps.

A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map. You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.

To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string “example.com,” then any traffic that includes “example.com” does not match the class map.

For the traffic that you identify in this class map, you can specify actions such as drop-connection, reset, and/or log the connection in the inspection policy map.

If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.

a. Create the class map by entering the following command:

ciscoasa(config)# class-map type inspect im [match-all | match-any] class_map_name
ciscoasa(config-cmap)#
 

Where the class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one of the criteria. The CLI enters class-map configuration mode, where you can enter one or more match commands.

b. (Optional) To add a description to the class map, enter the following command:

ciscoasa(config-cmap)# description string
 

Where the string is the description of the class map (up to 200 characters).

c. (Optional) To match traffic of a specific IM protocol, such as Yahoo or MSN, enter the following command:

ciscoasa(config-cmap)# match [not] protocol {im-yahoo | im-msn}
 

d. (Optional) To match a specific IM service, such as chat, file-transfer, webcam, voice-chat, conference, or games, enter the following command:

ciscoasa(config-cmap)# match [not] service {chat | file-transfer | webcam | voice-chat | conference | games}
 

e. (Optional) To match the source login name of the IM message, enter the following command:

ciscoasa(config-cmap)# match [not] login-name regex {class class_name | regex_name}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

f. (Optional) To match the destination login name of the IM message, enter the following command:

ciscoasa(config-cmap)# match [not] peer-login-name regex {class class_name | regex_name}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

g. (Optional) To match the source IP address of the IM message, enter the following command:

ciscoasa(config-cmap)# match [not] ip-address ip_address ip_address_mask
 

Where the ip_address and the ip_address_mask is the IP address and netmask of the message source.

h. (Optional) To match the destination IP address of the IM message, enter the following command:

ciscoasa(config-cmap)# match [not] peer-ip-address ip_address ip_address_mask
 

Where the ip_address and the ip_address_mask is the IP address and netmask of the message destination.

i. (Optional) To match the version of the IM message, enter the following command:

ciscoasa(config-cmap)# match [not] version regex {class class_name | regex_name}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

j. (Optional) To match the filename of the IM message, enter the following command:

ciscoasa(config-cmap)# match [not] filename regex {class class_name | regex_name}
 

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.


Note Not supported using MSN IM protocol.


Step 4 Create an IM inspection policy map, enter the following command:

ciscoasa(config)# policy-map type inspect im policy_map_name
ciscoasa(config-pmap)#
 

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

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

ciscoasa(config-pmap)# description string
 

Step 6 Specify the traffic on which you want to perform actions using one of the following methods:

  • Specify the IM class map that you created in Step 3 by entering the following command:
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)#
 
  • Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the “Defining Actions in an Inspection Policy Map” section.

Step 7 Specify the action you want to perform on the matching traffic by entering the following command:

ciscoasa(config-pmap-c)# {drop-connection | reset | log}
 

Where the drop-connection action closes the connection. The reset action closes the connection and sends a TCP reset to the client. The log action sends a system log message when this policy map matches traffic.


 

The following example shows how to define an IM inspection policy map.

hostname(config)# regex loginname1 “ying\@yahoo.com”
hostname(config)# regex loginname2 “Kevin\@yahoo.com”
hostname(config)# regex loginname3 “rahul\@yahoo.com”
hostname(config)# regex loginname4 “darshant\@yahoo.com”
hostname(config)# regex yahoo_version_regex “1\.0”
hostname(config)# regex gif_files “.*\.gif”
hostname(config)# regex exe_files “.*\.exe”
 
hostname(config)# class-map type regex match-any yahoo_src_login_name_regex
hostname(config-cmap)# match regex loginname1
hostname(config-cmap)# match regex loginname2
 
hostname(config)# class-map type regex match-any yahoo_dst_login_name_regex
hostname(config-cmap)# match regex loginname3
hostname(config-cmap)# match regex loginname4
 
hostname(config)# class-map type inspect im match-any yahoo_file_block_list
hostname(config-cmap)# match filename regex gif_files
hostname(config-cmap)# match filename regex exe_files
 
hostname(config)# class-map type inspect im match-all yahoo_im_policy
hostname(config-cmap)# match login-name regex class yahoo_src_login_name_regex
hostname(config-cmap)# match peer-login-name regex class yahoo_dst_login_name_regex
 
hostname(config)# class-map type inspect im match-all yahoo_im_policy2
hostname(config-cmap)# match version regex yahoo_version_regex
 
hostname(config)# class-map im_inspect_class_map
hostname(config-cmap)# match default-inspection-traffic
 
hostname(config)# policy-map type inspect im im_policy_all
hostname(config-pmap)# class yahoo_file_block_list
hostname(config-pmap-c)# match service file-transfer
hostname(config-pmap)# class yahoo_im_policy
hostname(config-pmap-c)# drop-connection
hostname(config-pmap)# class yahoo_im_policy2
hostname(config-pmap-c)# reset
hostname(config)# policy-map global_policy_name
hostname(config-pmap)# class im_inspect_class_map
hostname(config-pmap-c)# inspect im im_policy_all
 

IP Options Inspection

This section describes the IP Options inspection engine. This section includes the following topics:

IP Options Inspection Overview

Each IP packet contains an IP header with the Options field. The Options field, commonly referred to as IP Options, provide for control functions that are required in some situations but unnecessary for most common communications. In particular, IP Options include provisions for time stamps, security, and special routing. Use of IP Options is optional, and the field can contain zero, one, or more options.

You can configure IP Options inspection to control which IP packets with specific IP options are allowed through the ASA. Configuring this inspection instructs the ASA to allow a packet to pass or to clear the specified IP options and then allow the packet to pass.

IP Options inspection can check for the following three IP options in a packet:

  • End of Options List (EOOL) or IP Option 0—This option, which contains just a single zero byte, appears at the end of all options to mark the end of a list of options. This might not coincide with the end of the header according to the header length.
  • No Operation (NOP) or IP Option 1—The Options field in the IP header can contain zero, one, or more options, which makes the total length of the field variable. However, the IP header must be a multiple of 32 bits. If the number of bits of all options is not a multiple of 32 bits, the NOP option is used as “internal padding” to align the options on a 32-bit boundary.
  • Router Alert (RTRALT) or IP Option 20—This option notifies transit routers to inspect the contents of the packet even when the packet is not destined for that router. This inspection is valuable when implementing RSVP and similar protocols require relatively complex processing from the routers along the packets delivery path.

Note IP Options inspection is included by default in the global inspection policy. Therefore, the ASA allows RSVP traffic that contains packets with the Router Alert option (option 20) when the ASA is in routed mode.


Dropping RSVP packets containing the Router Alert option can cause problems in VoIP implementations.

When you configure the ASA to clear the Router Alert option from IP headers, the IP header changes in the following ways:

  • The Options field is padded so that the field ends on a 32 bit boundary.
  • Internet header length (IHL) changes.
  • The total length of the packet changes.
  • The checksum is recomputed.

If an IP header contains additional options other than EOOL, NOP, or RTRALT, regardless of whether the ASA is configured to allow these options, the ASA will drop the packet.

Configuring an IP Options Inspection Policy Map for Additional Inspection Control


Step 1 To create an IP Options inspection policy map, enter the following command:

ciscoasa(config)# policy-map type inspect ip-options policy_map_name
ciscoasa(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:

ciscoasa(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:

ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)#
 

b. To allow or clear packets with the End of Options List (EOOL) option, enter the following command:

ciscoasa(config-pmap-p)# eool action {allow | clear}
 

This option, which contains just a single zero byte, appears at the end of all options to mark the end of a list of options. This might not coincide with the end of the header according to the header length.

c. To allow or clear packets with the No Operation (NOP) option, enter the following command:

ciscoasa(config-pmap-p)# nop action {allow | clear}
 

The Options field in the IP header can contain zero, one, or more options, which makes the total length of the field variable. However, the IP header must be a multiple of 32 bits. If the number of bits of all options is not a multiple of 32 bits, the NOP option is used as “internal padding” to align the options on a 32-bit boundary.

d. To allowor clear packets with the Router Alert (RTRALT) option, enter the following command:

ciscoasa(config-pmap-p)# router-alert action {allow | clear}
 

This option notifies transit routers to inspect the contents of the packet even when the packet is not destined for that router. This inspection is valuable when implementing RSVP and similar protocols require relatively complex processing from the routers along the packets delivery path.


Note Enter the clear command to clear the IP option from the packet before allowing the packet through the ASA.



 

IPsec Pass Through Inspection

This section describes the IPsec Pass Through inspection engine. This section includes the following topics:

IPsec Pass Through Inspection Overview

Internet Protocol Security (IPsec) is a protocol suite for securing IP communications by authenticating and encrypting each IP packet of a data stream. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. IPsec can be used to protect data flows between a pair of hosts (for example, computer users or servers), between a pair of security gateways (such as routers or firewalls), or between a security gateway and a host.

IPsec Pass Through application inspection provides convenient traversal of ESP (IP protocol 50) and AH (IP protocol 51) traffic associated with an IKE UDP port 500 connection. It avoids lengthy ACL configuration to permit ESP and AH traffic and also provides security using timeout and max connections.

Specify IPsec Pass Through inspection parameters to identify a specific map to use for defining the parameters for the inspection. Configure a policy map for Specify IPsec Pass Through inspection to access the parameters configuration, which lets you specify the restrictions for ESP or AH traffic. You can set the per client max connections and the idle timeout in parameters configuration.

NAT and non-NAT traffic is permitted. However, PAT is not supported.

Example for Defining an IPsec Pass Through Parameter Map

The following example shows how to use ACLs to identify IKE traffic, define an IPsec Pass Thru parameter map, define a policy, and apply the policy to the outside interface:

hostname(config)# access-list ipsecpassthruacl permit udp any any eq 500
hostname(config)# class-map ipsecpassthru-traffic
hostname(config-cmap)# match access-list ipsecpassthruacl
hostname(config)# policy-map type inspect ipsec-pass-thru iptmap
hostname(config-pmap)# parameters
hostname(config-pmap-p)# esp per-client-max 10 timeout 0:11:00
hostname(config-pmap-p)# ah per-client-max 5 timeout 0:06:00
hostname(config)# policy-map inspection_policy
hostname(config-pmap)# class ipsecpassthru-traffic
hostname(config-pmap-c)# inspect ipsec-pass-thru iptmap
hostname(config)# service-policy inspection_policy interface outside

IPv6 Inspection

Information about IPv6 Inspection

IPv6 inspection lets you selectively log or drop IPv6 traffic based on the extension header. In addition, IPv6 inspection can check conformance to RFC 2460 for type and order of extension headers in IPv6 packets.

Default Settings for IPv6 Inspection

If you enable IPv6 inspection and do not specify an inspection policy map, then the default IPv6 inspection policy map is used, and the following actions are taken:

  • Allows only known IPv6 extension headers
  • Enforces the order of IPv6 extension headers as defined in the RFC 2460 specification

If you create an inspection policy map, the above actions are taken by default unless you explicitly disable them.

(Optional) Configuring an IPv6 Inspection Policy Map

To identify extension headers to drop or log, and/or to disable packet verification, create an IPv6 inspection policy map to be used by the service policy.

Detailed Steps

 

Command
Purpose

Step 1

policy-map type inspect ipv6 name

 

ciscoasa(config)# policy-map type inspect ipv6 ipv6-map

Creates an inspection policy map.

Step 2

match header header

[ drop [ log ] | log ]

 

ciscoasa(config-pmap)# match header ah

ciscoasa(config-pmap-c)# drop log

ciscoasa(config-pmap-c)# match header esp

ciscoasa(config-pmap-c)# drop log

Specifies the headers you want to match. By default, the packet is logged ( log ); if you want to drop (and optionally also log) the packet, enter the drop and optional log commands in match configuration mode.

Re-enter the match command and optional drop action for each extension you want to match:

  • ah —Matches the IPv6 Authentication extension header
  • count gt number —Specifies the maximum number of IPv6 extension headers, from 0 to 255
  • destination-option —Matches the IPv6 destination-option extension header
  • esp —Matches the IPv6 Encapsulation Security Payload (ESP) extension header
  • fragment —Matches the IPv6 fragment extension header
  • hop-by-hop —Matches the IPv6 hop-by-hop extension header
  • routing-address count gt number —Sets the maximum number of IPv6 routing header type 0 addresses, greater than a number between 0 and 255
  • routing-type { eq | range } number —Matches the IPv6 routing header type, from 0 to 255. For a range, separate values by a space, for example, 30 40 .

Step 3

parameters

[ no ] verify-header { order | type }

 

ciscoasa(config-pmap)# parameters

ciscoasa(config-pmap-p)# no verify-header order

ciscoasa(config-pmap-p)# no verify-header type

Specifies IPv6 parameters. These parameters are enabled by default. To disable them, enter the no keyword.

  • [ no ] verify-header type —Allows only known IPv6 extension headers
  • [ no ] verify-header order —Enforces the order of IPv6 extension headers as defined in the RFC 2460 specification

Examples

The following example creates an inspection policy map that will drop and log all IPv6 packets with the hop-by-hop, destination-option, routing-address, and routing type 0 headers:

policy-map type inspect ipv6 ipv6-pm
parameters
match header hop-by-hop
drop log
match header destination-option
drop log
match header routing-address count gt 0
drop log
match header routing-type eq 0
drop log

Configuring IPv6 Inspection

To enable IPv6 inspection, perform the following steps.

Detailed Steps

 

Command
Purpose

Step 1

class-map name

 

ciscoasa(config)# class-map ipv6_traffic

Creates a class map to identify the traffic for which you want to apply the inspection.

Step 2

match parameter

 

ciscoasa(config-cmap)# match access-list ipv6

Specifies the traffic in the class map. See the “Identifying Traffic (Layer 3/4 Class Maps)” section for more information.

Step 3

policy-map name

 

ciscoasa(config)# policy-map ipv6_policy

Adds or edits a policy map that sets the actions to take with the class map traffic.

Step 4

class name

 

ciscoasa(config-pmap)# class ipv6_traffic

Identifies the class map created in Step 1

Step 5

inspect ipv6 [ ipv6_policy_map ]

 

 

ciscoasa(config-class)# inspect ipv6 ipv6-map

Configures IPv6 inspection. Specify the inspection policy map you created in the “(Optional) Configuring an IPv6 Inspection Policy Map” section.

Step 6

service-policy policymap_name {global | interface interface_name }

 

 

ciscoasa(config)# service-policy ipv6_policy outside

Activates the policy map on one or more interfaces. global applies the policy map to all interfaces, and interface applies the policy to one interface. 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.

Examples

The following example drops all IPv6 traffic with the hop-by-hop, destination-option, routing-address, and routing type 0 headers:

policy-map type inspect ipv6 ipv6-pm
parameters
match header hop-by-hop
drop
match header destination-option
drop
match header routing-address count gt 0
drop
match header routing-type eq 0
drop
policy-map global_policy
class class-default
inspect ipv6 ipv6-pm
!
service-policy global_policy global

NetBIOS Inspection

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

NetBIOS Inspection Overview

NetBIOS inspection is enabled by default. The NetBios inspection engine translates IP addresses in the NetBios name service (NBNS) packets according to the ASA NAT configuration.

Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control

To specify actions when a message violates a parameter, create a NETBIOS inspection policy map. You can then apply the inspection policy map when you enable NETBIOS inspection.

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


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the general operations configuration guide. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the general operations configuration guide.

Step 3 Create a NetBIOS inspection policy map, enter the following command:

ciscoasa(config)# policy-map type inspect netbios policy_map_name
ciscoasa(config-pmap)#
 

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

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

ciscoasa(config-pmap)# description string
 

Step 5 To apply actions to matching traffic, perform the following steps.

a. Specify the traffic on which you want to perform actions using one of the following methods:

  • Specify the NetBIOS class map that you created in Step 3 by entering the following command:
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)#
 
  • Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.

b. Specify the action you want to perform on the matching traffic by entering the following command:

ciscoasa(config-pmap-c)# {[drop [send-protocol-error] | drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 

Not all options are available for each match or class command. See the CLI help or the command reference for the exact options available.

The drop keyword drops all packets that match.

The send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.

The log keyword, which you can use alone or with one of the other keywords, sends a system log message.

The rate-limit message_rate argument limits the rate of messages.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the “Defining Actions in an Inspection Policy Map” section.

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

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

ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)#
 

b. To check for NETBIOS protocol violations, enter the following command:

ciscoasa(config-pmap-p)# protocol-violation [action [drop-connection | reset | log]]
 

Where the drop-connection action closes the connection. The reset action closes the connection and sends a TCP reset to the client. The log action sends a system log message when this policy map matches traffic.


 

The following example shows how to define a NETBIOS inspection policy map.

ciscoasa(config)# policy-map type inspect netbios netbios_map
ciscoasa(config-pmap)# protocol-violation drop log
 
ciscoasa(config)# policy-map netbios_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect netbios netbios_map
 

PPTP Inspection

PPTP is a protocol for tunneling PPP traffic. A PPTP session is composed of one TCP channel and usually two PPTP GRE tunnels. The TCP channel is the control channel used for negotiating and managing the PPTP GRE tunnels. The GRE tunnels carries PPP sessions between the two hosts.

When enabled, PPTP application inspection inspects PPTP protocol packets and dynamically creates the GRE connections and xlates necessary to permit PPTP traffic. Only Version 1, as defined in RFC 2637, is supported.

PAT is only performed for the modified version of GRE [RFC 2637] when negotiated over the PPTP TCP control channel. Port Address Translation is not performed for the unmodified version of GRE [RFC 1701, RFC 1702].

Specifically, the ASA inspects the PPTP version announcements and the outgoing call request/response sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing-call request and reply sequence are tracked. Connections and xlates are dynamic allocated as necessary to permit subsequent secondary GRE data traffic.

The PPTP inspection engine must be enabled for PPTP traffic to be translated by PAT. Additionally, PAT is only performed for a modified version of GRE (RFC2637) and only if it is negotiated over the PPTP TCP control channel. PAT is not performed for the unmodified version of GRE (RFC 1701 and RFC 1702).

As described in RFC 2637, the PPTP protocol is mainly used for the tunneling of PPP sessions initiated from a modem bank PAC (PPTP Access Concentrator) to the headend PNS (PPTP Network Server). When used this way, the PAC is the remote client and the PNS is the server.

However, when used for VPN by Windows, the interaction is inverted. The PNS is a remote single-user PC that initiates connection to the head-end PAC to gain access to a central network.

SMTP and Extended SMTP Inspection

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

SMTP and ESMTP Inspection Overview

ESMTP application inspection provides improved protection against SMTP-based attacks by restricting the types of SMTP commands that can pass through the ASA and by adding monitoring capabilities.

ESMTP is an enhancement to the SMTP protocol and is similar is most respects to SMTP. For convenience, the term SMTP is used in this document to refer to both SMTP and ESMTP. The application inspection process for extended SMTP is similar to SMTP application inspection and includes support for SMTP sessions. Most commands used in an extended SMTP session are the same as those used in an SMTP session but an ESMTP session is considerably faster and offers more options related to reliability and security, such as delivery status notification.

Extended SMTP application inspection adds support for these extended SMTP commands, including AUTH, EHLO, ETRN, HELP, SAML, SEND, SOML, STARTTLS, and VRFY. Along with the support for seven RFC 821 commands (DATA, HELO, MAIL, NOOP, QUIT, RCPT, RSET), the ASA supports a total of fifteen SMTP commands.

Other extended SMTP commands, such as ATRN, ONEX, VERB, CHUNKING, and private extensions and are not supported. Unsupported commands are translated into Xs, which are rejected by the internal server. This results in a message such as “500 Command unknown: 'XXX'.” Incomplete commands are discarded.

The ESMTP inspection engine changes the characters in the server SMTP banner to asterisks except for the “2”, “0”, “0” characters. Carriage return (CR) and linefeed (LF) characters are ignored.

With SMTP inspection enabled, a Telnet session used for interactive SMTP may hang if the following rules are not observed: SMTP commands must be at least four characters in length; must be terminated with carriage return and line feed; and must wait for a response before issuing the next reply.

An SMTP server responds to client requests with numeric reply codes and optional human-readable strings. SMTP application inspection controls and reduces the commands that the user can use as well as the messages that the server returns. SMTP inspection performs three primary tasks:

  • Restricts SMTP requests to seven basic SMTP commands and eight extended commands.
  • Monitors the SMTP command-response sequence.
  • Generates an audit trail—Audit record 108002 is generated when invalid character embedded in the mail address is replaced. For more information, see RFC 821.

SMTP inspection monitors the command and response sequence for the following anomalous signatures:

  • Truncated commands.
  • Incorrect command termination (not terminated with <CR><LR>).
  • The MAIL and RCPT commands specify who are the sender and the receiver of the mail. Mail addresses are scanned for strange characters. The pipeline character (|) is deleted (changed to a blank space) and “<” ‚”>” are only allowed if they are used to define a mail address (“>” must be preceded by “<”). To close the session when the PIPE character is found as a parameter to a MAIL from or RCPT to command, include the special-character command in the configuration as part of the inspection parameters ( parameters command).
  • Unexpected transition by the SMTP server.
  • For unknown commands, the ASA changes all the characters in the packet to X. In this case, the server generates an error code to the client. Because of the change in the packed, the TCP checksum has to be recalculated or adjusted.
  • TCP stream editing.
  • Command pipelining.

Configuring an ESMTP Inspection Policy Map for Additional Inspection Control

ESMTP inspection detects attacks, including spam, phising, malformed message attacks, buffer overflow/underflow attacks. It also provides support for application security and protocol conformance, which enforce the sanity of the ESMTP messages as well as detect several attacks, block senders/receivers, and block mail relay.

To specify actions when a message violates a parameter, create an ESMTP inspection policy map. You can then apply the inspection policy map when you enable ESMTP inspection.

To create an ESMTP inspection policy map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the general operations configuration guide. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the general operations configuration guide.

Step 3 Create an ESMTP inspection policy map, enter the following command:

ciscoasa(config)# policy-map type inspect esmtp policy_map_name
ciscoasa(config-pmap)#
 

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

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

ciscoasa(config-pmap)# description string
 

Step 5 To apply actions to matching traffic, perform the following steps.

a. Specify the traffic on which you want to perform actions using one of the following methods:

  • Specify the ESMTP class map that you created in Step 3 by entering the following command:
ciscoasa(config-pmap)# class class_map_name
ciscoasa(config-pmap-c)#
 
  • Specify traffic directly in the policy map using one of the match commands described in Step 3. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.

b. Specify the action you want to perform on the matching traffic by entering the following command:

ciscoasa(config-pmap-c)# {[drop [send-protocol-error] | drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 

Not all options are available for each match or class command. See the CLI help or the command reference for the exact options available.

The drop keyword drops all packets that match.

The send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.

The log keyword, which you can use alone or with one of the other keywords, sends a system log message.

The rate-limit message_rate argument limits the rate of messages.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the “Defining Actions in an Inspection Policy Map” section.

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

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

ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)#
 

b. To configure a local domain name, enter the following command:

ciscoasa(config-pmap-p)# mail-relay domain-name action [drop-connection | log]]
 

Where the drop-connection action closes the connection. The log action sends a system log message when this policy map matches traffic.

c. To enforce banner obfuscation, enter the following command:

ciscoasa(config-pmap-p)# mask-banner
 


 

The following example shows how to define an ESMTP inspection policy map.

ciscoasa(config)# regex user1 “user1@cisco.com”
ciscoasa(config)# regex user2 “user2@cisco.com”
ciscoasa(config)# regex user3 “user3@cisco.com”
ciscoasa(config)# class-map type regex senders_black_list
ciscoasa(config-cmap)# description “Regular expressions to filter out undesired senders”
ciscoasa(config-cmap)# match regex user1
ciscoasa(config-cmap)# match regex user2
ciscoasa(config-cmap)# match regex user3
 
ciscoasa(config)# policy-map type inspect esmtp advanced_esmtp_map
ciscoasa(config-pmap)# match sender-address regex class senders_black_list
ciscoasa(config-pmap-c)# drop-connection log
 
ciscoasa(config)# policy-map outside_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect esmtp advanced_esmtp_map
 
ciscoasa(config)# service-policy outside_policy interface outside
 

TFTP Inspection

TFTP inspection is enabled by default.

TFTP, described in RFC 1350, is a simple protocol to read and write files between a TFTP server and client.

The ASA inspects TFTP traffic and dynamically creates connections and translations, if necessary, to permit file transfer between a TFTP client and server. Specifically, the inspection engine inspects TFTP read request (RRQ), write request (WRQ), and error notification (ERROR).

A dynamic secondary channel and a PAT translation, if necessary, are allocated on a reception of a valid read (RRQ) or write (WRQ) request. This secondary channel is subsequently used by TFTP for file transfer or error notification.

Only the TFTP server can initiate traffic over the secondary channel, and at most one incomplete secondary channel can exist between the TFTP client and server. An error notification from the server closes the secondary channel.

TFTP inspection must be enabled if static PAT is used to redirect TFTP traffic.