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.

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.

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.

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

Detailed Steps—Protocol Conformance

Step 1 Configure the following Protocol Conformance parameters:

Step 2 Enable DNS guard function —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.

Step 3 Enable NAT re-write function —Translates the DNS record based on the NAT configuration.

Detailed Steps—Filtering

Step 3 Server Settings: Drop packets that exceed specified maximum length and Drop packets sent to server that exceed length indicated by the RR —Sets the maximum server DNS message length, from 512 to 65535 bytes, or sets the maximum length to the value in the Resource Record. If you enable both settings, the lower value is used.

Step 4 Client Settings: Drop packets that exceed specified maximum length and Drop packets sent to server that exceed length indicated by the RR —Sets the maximum client DNS message length, from 512 to 65535 bytes, or sets the maximum length to the value in the Resource Record. If you enable both settings, the lower value is used.

Detailed Steps—Mismatch Rate

Step 1 Click the Mismatch Rate tab.

Step 2 Enable logging when DNS ID mismatch rate exceeds specified rate —Enables logging for excessive DNS ID mismatches, where the Mismatch Instance Threshold and Time Interval fields specify the maximum number of mismatch instances per x seconds before a system message log is sent.

Detailed Steps—Inspections

Step 1 Click the Inspections tab.

Step 2 Click Add .

The Add DNS Inspect dialog box appears.

Step 3You can configure DNS inspections using the following methods:

Single Match —Match a single criterion, and identify the action for the match.

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. If you want different actions for each criteria, use the single match option; you can only set one action for the entire class map.

You can add multiple class maps and single matches in the same policy map.

Actions for each Single Match, or for a Multiple match class map include:

Primary Action:

– Mask

– Drop Packet

– Drop Connection

– None

Log:

– Enable

– Disable

Enforce TSIG: Requires a TSIG resource record to be present.

– Do not enforce

– Drop packet

– Log

– Drop packet and log

Not all combinations are valid for all matching criteria. For example, you can configure both Mask and Enforce TSIG together only for the Criterion: Header Flag option.

Step 4 For Multiple matches, if you predefined a class map on the Configuration > Firewall > Objects > Class Maps > DNS pane, you can select it from the drop-down list, set the Actions, and click OK .

To add a new class map:

a. Click Manage .

The Manage DNS Class Maps dialog box appears

b. Click Add .

The Add DNS Traffic Class Map dialog box appears.

c. Click Add .

The Add DNS Match Criterion dialog box appears.

The match criteria are the same for a class map or for single matches; the following steps apply to both methods. The only difference is that you do not set an Action for each criterion in a class map.

Step 5 From the Criterion drop-down list, choose one of the following criteria:

Header Flag :

Set the following Value parameters:

– Match Option: Equals or Contains . If you choose Header Flag Name, and check multiple flags, you can set the ASA to match a packet only if all flags are present (Equals) or if any one of the flags is present (Contains).

– Match Value: Header Flag Name or Header Flag Value . If you click Header Flag Name , you can check one or more well-known flag values. If you want to specify a hex value, click the Header Flag Value radio button, and enter the hex value in the field.

Type :

Set the following Value parameters:

– DNS Type Field Name —Lists the DNS types to select.

A —IPv4 address

AXFR —Full (zone) transfer

CNAME —Canonical name

IXFR —Incremental (zone) transfer

NS —Authoritative name server

SOA —Start of a zone of authority

TSIG —Transaction signature

– DNS Type Field Value:

Value —Lets you enter a value between 0 and 65535 to match.

Range —Lets you enter a range match. Both values between 0 and 65535.

Class :

Set the following Value parameters:

– DNS Class Field Name: Internet —Internet is the only option.

– DNS Class Field Value :

Value —Lets you enter a value between 0 and 65535.

Range —Lets you enter a range match. Both values between 0 and 65535.

Question : Matches a DNS question.

Resource Record :

Set the following Value parameters:

– Resource Record:

additional —DNS additional resource record

answer —DNS answer resource record

authority —DNS authority resource record

Domain Name :

Set the following Value parameters:

– Regular Expression —Choose an existing regular expression from the drop-down menu, or click Manage to add a new one. See the “Creating a Regular Expression” section in the general operations configuration guide.

Step 7 Set the action for the Single Match, or for the Multiple matches class map; see Step 3 for actions.

Step 8 Click OK to return to the Add DNS Inspect dialog box.

Step 9 In some cases when you have more than one match in the inspection policy map, you can order the matches using the Move Up and Move Down buttons. Generally, the order is determined by internal ASA rules, so these buttons are not available for most entries. However, if you have a direct match and a class map that have the same match, then the order in the configuration determines which match is used, so these buttons are enabled. See the “Guidelines and Limitations” section for more information.

Step 10 Click OK to save the DNS inspect map.

Step 11 Click Apply .

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.

Step 3 (To change an in-use policy) If you are editing any in-use policy to use a different DNS inspection policy map, you must disable the DNS inspection, and then re-enable it with the new DNS inspection policy map name:

a. Uncheck the DNS check box.

b. Click OK .

c. Click Apply .

d. Repeat these steps to return to the Protocol Inspections tab.

Step 4 Check the DNS check box.

Step 5 Click Configure .

The Select DNS Inspect Map dialog appears.

Step 6 Choose the inspection map:

To use the default map, click Use the default DNS inspection map (preset_dns_map).

Step 7 If you use the Botnet Traffic Filter, click Enable Botnet traffic filter DNS snooping . Botnet Traffic Filter snooping compares the domain name with those on the dynamic database or static database, and adds the name and IP address to the Botnet Traffic Filter DNS reverse lookup cache. This cache is then used by the Botnet Traffic Filter when connections are made to the suspicious address. We suggest that you enable DNS snooping only on interfaces where external DNS requests are going. Enabling DNS snooping on all UDP DNS traffic, including that going to an internal DNS server, creates unnecessary load on the ASA. For example, if the DNS server is on the outside interface, you should enable DNS inspection with snooping for all UDP DNS traffic on the outside interface. See the “Enabling DNS Snooping” section.

Step 8 Click OK to return to the Protocol Inspections tab.

Step 9 Click OK to finish editing the service policy.

Step 10 Click Apply .

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.

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

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

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.

Select FTP Map

The Select FTP Map dialog box lets you enable strict FTP application inspection, select an FTP map, or create a new FTP map. An FTP map lets you change the configuration values used for FTP application inspection.The Select FTP Map table provides a list of previously configured maps that you can select for application inspection.

Fields

FTP Strict (prevent web browsers from sending embedded commands in FTP requests) — Enables strict FTP application inspection, which causes the ASA to drop the connection when an embedded command is included in an FTP request.

Use the default FTP inspection map—Specifies to use the default FTP map.

Select an FTP map for fine control over inspection — Lets you select a defined application inspection map or add a new one.

Add—Opens the Add Policy Map dialog box for the inspection.

FTP Class Map

An inspection class map matches application traffic with criteria specific to the application. You then identify the class map in the inspect map and enable actions. The difference between creating a class map and defining the traffic match directly in the inspect map is that you can create more complex match criteria and you can reuse class maps. The applications that support inspection class maps are DNS, FTP, H.323, HTTP, IM, and SIP.

Fields

Name—Shows the FTP class map name.

Match Conditions—Shows the type, match criterion, and value in the class map.

– Match Type—Shows the match type, which can be a positive or negative match.

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.

Fields

FTP Inspect Maps—Table that lists the defined FTP inspect maps.

Add—Configures a new FTP inspect map. To edit an FTP inspect map, choose the FTP entry in the FTP Inspect Maps table and click Customize .

The latter two features are configured in conjunction with Filter rules.

The enhanced HTTP inspection feature, which is also known as an application firewall and is available when you configure an HTTP map, 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.

Select HTTP Map

The Select HTTP Map dialog box lets you select or create a new HTTP map. An HTTP map lets you change the configuration values used for HTTP application inspection. The Select HTTP Map table provides a list of previously configured maps that you can select for application inspection.

Fields

Use the default HTTP inspection map—Specifies to use the default HTTP map.

Select an HTTP map for fine control over inspection — Lets you select a defined application inspection map or add a new one.

Add—Opens the Add Policy Map dialog box for the inspection.

HTTP Class Map

An inspection class map matches application traffic with criteria specific to the application. You then identify the class map in the inspect map and enable actions. The difference between creating a class map and defining the traffic match directly in the inspect map is that you can create more complex match criteria and you can reuse class maps. The applications that support inspection class maps are DNS, FTP, H.323, HTTP, IM, and SIP.

Fields

Name—Shows the HTTP class map name.

Match Conditions—Shows the type, match criterion, and value in the class map.

– Match Type—Shows the match type, which can be a positive or negative match.

HTTP application inspection scans HTTP headers and body, and performs various checks on the data. These checks prevent various HTTP constructs, content types, and tunneling and messaging protocols from traversing the security appliance.

Spoof String—Enter a string to substitute for the server header field. Maximum is 82 characters.

– Body Match Maximum—The maximum number of characters in the body of an HTTP message that should be searched in a body match. Default is 200 bytes. A large number will have a significant impact on performance.

Inspections—Tab that shows you the HTTP inspection configuration and lets you add or edit.

– Match Type—Shows the match type, which can be a positive or negative match.

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.

Step 7 In the Match Type field, click the Match or No Match radio button.

Step 8 In the Criterion drop-down list, select one of the following options and specify the criteria value. Depending on which option you select, the Value fields dynamically refresh to display the appropriate values for that criteria.

Protocol—Select to match traffic of a specific IM protocol, such as Yahoo Messenger or MSN Messenger.

Service—Select to match a specific IM service, such as chat, file-transfer, webcam, voice-chat, conference, or games.

Version—Select to match the version of the IM message. In the Value fields, click the Regular Expression or Regular Expression Class option and select an expression from the drop-down list.

Client Login Name—Select to match the source login name of the IM message. In the Value fields, click the Regular Expression or Regular Expression Class option and select an expression from the drop-down list.

Client Peer Login Name—Select to match the destination login name of the IM message. In the Value fields, click the Regular Expression or Regular Expression Class option and select an expression from the drop-down list.

Select IM Map

The Select IM Map dialog box lets you select or create a new IM map. An IM map lets you change the configuration values used for IM application inspection. The Select IM Map table provides a list of previously configured maps that you can select for application inspection.

Fields

Add—Opens the Add Policy Map dialog box for the inspection.

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.

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

Click the Use the default IP-Options inspection map radio button to use the default IP Options map. The default map drops packets containing all the inspected IP options, namely End of Options List (EOOL), No Operation (NOP), and Router Alert (RTRALT).

Click the Select an IP-Options inspect map for fine control over inspection radio button to select a defined application inspection map.

Click Add to open the Add IP-Options Inspect Map dialog box and create a new inspection map.

Step 5 (Optional) If you clicked Add to create a new inspection map, define the following values for IP Options Inspection:

a. Enter a name for the inspection map.

b. Enter a description for the inspection map, up to 200 characters long.

c. From the Parameters area, select which IP options you want to pass through the ASA or clear and then pass through the ASA:

– Allow packets with the End of Options List (EOOL) option

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.

– Allow packets with the No Operation (NOP) option

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.

– Allow packets with the Router Alert (RTRALT) option

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.

– Clear the option value from the packets

When an option is checked, the Clear the option value from the packets check box becomes available for that option. Select the Clear the option value from the packets check box to clear the option from the packet before allowing the packet through the ASA.

d. Click OK .

Step 6 Click OK .

Step 7 Click Finish .

Select IP Options Inspect Map

The Select IP-Options Inspect Map dialog box lets you select or create a new IP Options inspection map. Use this inspection map to control whether the ASA drops, passes, or clears IP packets containing the following IP options—End of Options List, No Operations, and Router Alert.

Fields

Use the default IP-Options inspection map—Specifies to use the default IP Options map. The default map drops packets containing all the inspected IP options, namely End of Options List (EOOL), No Operation (NOP), and Router Alert (RTRALT).

Select an IP-Options map for fine control over inspection — Lets you select a defined application inspection map or add a new one.

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

Add/Edit IP Options Inspect Map

Name—When adding an IP Options inspection map, enter the name of the map. When editing a map, the name of the previously configured map is shown.

Description—Enter the description of the IP Options inspection map, up to 200 characters in length.

Parameters—Select which IP options you want to pass through the ASA or clear and then pass through the ASA:

– Allow packets with the End of Options List (EOOL) option

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.

– Allow packets with the No Operation (NOP) option

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.

– Allow packets with the Router Alert (RTRALT) option

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.

– Clear the option value from the packets

When an option is checked, the Clear the option value from the packets check box becomes available for that option. Select the Clear the option value from the packets check box to clear the 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.

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.

Select IPsec-Pass-Thru Map

The Select IPsec-Pass-Thru dialog box lets you select or create a new IPsec map. An IPsec map lets you change the configuration values used for IPsec application inspection. The Select IPsec Map table provides a list of previously configured maps that you can select for application inspection.

Fields

Use the default IPsec inspection map—Specifies to use the default IPsec map.

Select an IPsec map for fine control over inspection — Lets you select a defined application inspection map or add a new one.

Add—Opens the Add Policy Map dialog box for the inspection.

IPsec Pass Through Inspect Map

The IPsec Pass Through Inspect Map dialog box is accessible as follows:

Configuration > Global Objects > Inspect Maps > IPsec Pass Through

The IPsec Pass Through pane lets you view previously configured IPsec Pass Through application inspection maps. An IPsec Pass Through map lets you change the default configuration values used for IPsec Pass Through application inspection. You can use an IPsec Pass Through map to permit certain flows without using an ACL.

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.

When you select any of the following criteria, you can configure to the ASA to drop or log when an IPv6 packet arrives matching the criterion:

– Authentication (AH) header

– Destination Options header

– Encapsulating Security Payload (ESP) header

– Fragment header

– Hop-by-Hop Options header

– Routing header—When Routing header is selected and an IPv6 routing extension header is detected, the ASA takes the specified action when the routing type is matched or a number when the specified routing type range is matched.

– Header count—When Header count is selected and an IPv6 routing extension header is detected, the ASA takes the specified action when number of IPv6 extension headers in the packet is more than the specified value.

– Routing header address count—When Routing header address count is selected, and an IPv6 routing extension header is detected, the ASA takes the specified action when the number of addresses in the type 0 routing header is more than the value you configure.

Select NETBIOS Map

The Select NETBIOS Map dialog box lets you select or create a new NetBIOS map. A NetBIOS map lets you change the configuration values used for NetBIOS application inspection. The Select NetBIOS Map table provides a list of previously configured maps that you can select for application inspection.

Fields

Use the default IM inspection map—Specifies to use the default NetBIOS map.

Select a NetBIOS map for fine control over inspection — Lets you select a defined application inspection map or add a new one.

NetBIOS application inspection performs NAT for the embedded IP address in the NetBIOS name service packets and NetBIOS datagram services packets. It also enforces protocol conformance, checking the various count and length fields for consistency.

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.

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:

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 “<”).

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.

Select ESMTP Map

The Select ESMTP Map dialog box lets you select or create a new ESMTP map. An ESMTP map lets you change the configuration values used for ESMTP application inspection. The Select ESMTP Map table provides a list of previously configured maps that you can select for application inspection.

Fields

Use the default ESMTP inspection map—Specifies to use the default ESMTP map.

Select an ESMTP map for fine control over inspection — Lets you select a defined application inspection map or add a new one.

Since ESMTP traffic can be a main source of attack from spam, phising, malformed messages, buffer overflows, and buffer underflows, detailed packet inspection and control of ESMTP traffic are supported. Application security and protocol conformance enforce the sanity of the ESMTP message as well as detect several attacks, block senders and receivers, and block mail relay.

Fields

ESMTP Inspect Maps—Table that lists the defined ESMTP inspect maps.

Add—Configures a new ESMTP inspect map. To edit an ESMTP inspect map, choose the ESMTP entry in the ESMTP Inspect Maps table and click Customize .

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.