CCNP BCMSN Exam Certification Guide (3rd Edition)

2017-07-07 02:10:07

6-6. Application Inspection

A stateful firewall can easily examine the source and destination parameters of packets passing through it. Many applications use protocols that also embed address or port information inside the packet, requiring special handling for examination.

Application inspection allows a firewall to dig inside the packets used by certain applications. The firewall can find and use the embedded information in its stateful adaptive security algorithm.

Embedded address information can also become confusing when you use NAT. If the packet addresses are being translated, the firewall must also perform the same translation on any corresponding embedded addresses.

Application inspection also monitors any secondary channels or "buddy ports" that are opened as a part of an application connection. Only the primary or well-known port needs to be configured for the application inspection. In addition, only the primary port needs to be permitted in an access list applied to a firewall interface.

This becomes important for inbound connections, where permitted ports must be explicitly configured in the access list. Any secondary connections that are negotiated are tracked, and the appropriate access (additional xlate and conn entries) is added automatically.

To illustrate how this works, consider a simple example with the passive FTP application protocol, as shown in Figure 6-16. An FTP client is located on the outside of a firewall, and the FTP server is inside. The access list applied to the outside interface only permits inbound connections to TCP port 21, the FTP control channel. As soon as the client opens a connection to port 21, the server responds with the port number of the data channel the client should use next.

Figure 6-16. An Example of FTP Application Inspection

When the client initiates the inbound data connection to the server's negotiated port number, the firewall doesn't have an explicit access list statement to permit it. In fact, because the new connection port is negotiated within a previous FTP exchange over the control channel, the port number can't be known ahead of time. However, the FTP application inspection understands the FTP protocol and listens to the packet exchange between the client and server. The firewall overhears the data channel port negotiation and can automatically create xlate and conn entries for it dynamically.

In releases before PIX 7.0, application inspection is called a fixup. If a fixup is enabled, it is used to examine all traffic passing through the firewall. Beginning with PIX 7.0, application inspection is much more flexible. Inspection engines can be used to examine specific types of traffic.

Table 6-9 lists the applications and well-known ports supported for application inspection on Cisco firewall platforms running PIX software.

Table 6-9. Application Inspection: Applications and Ports Supported by PIX
Application Protocol	Keyword	PIX 6.x	PIX 7.x
CTIQBE	ctiqbe	TCP 2748 (disabled)	TCP 2748
CU-SeeMe		UDP 7648 (always enabled)	UDP 7648
DNS	dns	UDP 53	UDP 53
ESMTP	esmtp		TCP 25
ESP-IKE	esp-ike	(disabled)
FTP	ftp	TCP 21	TCP 21
GTP version 1	gtp		3386 (disabled)
H.323: H225 H.323: RAS	h323 h225 h323 ras	TCP 1720 UDP 1718 to 1719	TCP 1720 UDP 1718 to 1719
HTTP	http	TCP 80	TCP 80 (disabled)
ICMP	icmp	(no port)	(no port)
ILS/LDAP	ils	TCP 389	TCP 389 (disabled)
MGCP	mgcp	2427, 2727 (disabled)	2427, 2727
NBDS	netbios	UDP 138 (always enabled)	UDP 138
NBNS	netbios	UDP 137 (always enabled)	UDP 137
PPTP	pptp	TCP 1723 (disabled)	TCP 1723 (disabled)
RSH	rsh	TCP 514	TCP 514
RTSP	rtsp	TCP 554	TCP 554
SIP	sip	UDP/TCP 5060	UDP/TCP 5060
Skinny/SCCP	skinny	TCP 2000	TCP 2000
SMTP	smtp	TCP 25
SNMP	snmp	UDP 161, 162 (disabled)	UDP 161, 162
SQL*Net	sqlnet	TCP 1521	TCP 1521
SunRPC	sunrpc	TCP/UDP 111 (always enabled)	TCP/UDP 111
TFTP	tftp	UDP 69	UDP 69
VDOLive		TCP 7000 (always enabled)
Windows Media (Netshow)		TCP 1755 (always enabled)	TCP 1755
XDMCP	xdmcp	UDP 177 (always enabled)	UDP 177

Configuring Application Inspection

By default, PIX 6.x enables only the CU-SeeMe, DNS, FTP, H.323, HTTP, ILS/LDAP, NetBIOS, RSH, RTSP, SIP, SKINNY/SCCP, SMTP, SQL*Net, SunRPC, TFTP, VDO Live, Windows Media, and XDMCP fixups.

Beginning with PIX 7.0, the default policy map asa_global_fw_policy enables the DNS, ESMTP, FTP, H.323, HTTP, NetBIOS, RSH, RTSP, SIP, Skinny, SQL*Net, SunRPC, TFTP, and XDMCP inspection engines.

Most of the application inspection engines use predefined values to determine the default primary port. They also inspect traffic according to templates that are based on the RFCs that define the application. Beginning with PIX 7.0, you can tailor the inspection of several applications for more granular control over the security policy. The following inspection engines can support an additional "map" or template configuration:

HTTP

SNMP

MGCP

You can configure any of the supported application inspection engines by using the configuration command syntax listed in Table 6-10.

Table 6-10. Configuring Application Inspection Engines
Application for Inspection	Command
CTIQBE	FWSM 2.x
	6.x	Firewall(config)# fixup protocol ctiqbe 2748
	7.x	Firewall(config-pmap-c)# inspect ctiqbe
CU-SeeMe	FWSM 2.x
	6.x	Always enabled. Supported by the H.323 fixup.
	7.x
DNS	FWSM 2.x	Firewall(config)# fixup protocol dns [maximum-length max_pkt_length]
	6.x	Firewall(config)# fixup protocol dns [maximum-length max_pkt_length]
	7.x	Firewall(config-pmap-c)# inspect dns [maximum-length max_pkt_length]
	Packets larger than max_pkt_length bytes (the default is 512 bytes) are dropped.
ESMTP	FWSM 2.x
	6.x
	7.x	Firewall(config-pmap-c)# inspect esmtp
ESP with PAT (IPSec)	FWSM 2.x
	6.x	Firewall(config)# fixup protocol esp-ike
	7.x
	The IKE source port is preserved when PAT is in use. As a result, ISAKMP cannot be used on any interface when this fixup is enabled.
FTP	FWSM 2.x	Firewall(config)# fixup protocol ftp [strict] [port]
	6.x	Firewall(config)# fixup protocol ftp [strict] [port]
	7.x	Firewall(config-pmap-c)# inspect ftp [strict [ftp_map_name]]
	FTP is expected to use TCP port number port. If strict is given, each FTP command must be acknowledged before a new command is allowed; no embedded commands are allowed.
GTP	FWSM 2.x
	6.x
	7.x	Firewall(config-pmap-c)# inspect gtp [gtp_map_name]
H.323	FWSM 2.x	Firewall(config)# fixup protocol h323 {h225 \| ras} port[-port]
	6.x	Firewall(config)# fixup protocol h323 {h225 \| ras} port[-port]
	7.x	Firewall(config-pmap-c)# inspect h323 {h225 \| ras}
	The control port uses port for H.225 and a range port-port for RAS. The command can be repeated to enable both types. H.323 versions 1 to 4 are supported.
HTTP	FWSM 2.x	Firewall(config)# fixup protocol http [port[-port]
	6.x	Firewall(config)# fixup protocol http [port[-port]
	7.x	Firewall(config-pmap-c)# inspect http [http_map_name]
	HTTP is expected to use port (TCP 80) or a range of port-port. When enabled, Websense, N2H2, Java, ActiveX filtering, and URL logging are all available.
ICMP	FWSM 2.x	Firewall(config)# inspect icmp [error]
	6.x	Firewall(config)# fixup protocol icmp error
	7.x	Firewall(config-pmap-c)# inspect icmp [error]
	When error is included, the firewall enables NAT for ICMP error messages.
ILS/LDAP	FWSM 2.x	Firewall(config)# fixup protocol ils [port[-port]]
	6.x	Firewall(config)# fixup protocol ils [port[-port]]
	7.x	Firewall(config-pmap-c)# inspect ils
	Internet Locator Service (ILS) and Lightweight Directory Access Protocol (LDAP)
MGCP	FWSM 2.x	Firewall(config)# fixup protocol mgcp [port[-port]]
	6.x	Firewall(config)# fixup protocol mgcp [port[-port]]
	7.x	Firewall(config-pmap-c)# inspect mgcp [mgcp_map_name]
	MGCP is expected to use port or a range port-port. Define at least two portsone for gateways and one for call agents.
NBDS	FWSM 2.x
	6.x	Always enabled.
	7.x	Firewall(config-pmap-c)# inspect netbios
	NetBIOS Datagram Service (NBDS)
NBNS	FWSM 2.x
	6.x	Always enabled.
	7.x	Firewall(config-pmap-c)# inspect netbios
	NetBIOS Name Service (NBNS). NAT is not available for name resolution through WINS.
PPTP	FWSM 2.x
	6.x	Firewall(config)# fixup protocol pptp port
	7.x	Firewall(config-pmap-c)# inspect pptp
	PAT xlates and GRE connections are created for PPTP.
RSH	FWSM 2.x	Firewall(config)# fixup protocol rsh [port]
	6.x	Firewall(config)# fixup protocol rsh [port]
	7.x	Firewall(config-pmap-c)# inspect rsh
	When enabled, RSH is expected to use control port TCP 514.
RTSP	FWSM 2.x	Firewall(config)# fixup protocol rtsp [port]
	6.x	Firewall(config)# fixup protocol rtsp [port]
	7.x	Firewall(config-pmap-c)# inspect rtsp
	RTSP is expected to use TCP port as a control port (the default is 554). You can repeat the 6.x command to define additional ports.
SIP	FWSM 2.x	Firewall(config)# [no] fixup protocol sip udp 5060 Firewall(config)# fixup protocol sip [port[-port]
	6.x	Firewall(config)# [no] fixup protocol sip udp 5060 Firewall(config)# fixup protocol sip [port[-port]
	7.x	Firewall(config-pmap-c)# inspect sip
	The UDP SIP port cannot be configured in 6.x; it can only be enabled or disabled.
Skinny (SCCP)	FWSM 2.x	Firewall(config)# fixup protocol skinny [port[-port]
	6.x	Firewall(config)# fixup protocol skinny [port[-port]
	7.x	Firewall(config-pmap-c)# inspect skinny
	SCCP connections are handled through NAT and PAT. These are expected to use TCP port number port (the default is 2000) or a range port-port.
SMTP	FWSM 2.x	Firewall(config)# fixup protocol smtp [port[-port]]
	6.x	Firewall(config)# fixup protocol smtp [port[-port]]
	7.x	Firewall(config-pmap-c)# inspect esmtp
	SMTP is expected to use TCP port number port or a range port-port.
SNMP	FWSM 2.x
	6.x	Firewall(config)# fixup protocol snmp 161-162
	7.x	Firewall(config-pmap-c)# inspect snmp [snmp_map_name]
SQL*Net	FWSM 2.x	Firewall(config)# fixup protocol sqlnet [port[-port]]
	6.x	Firewall(config)# fixup protocol sqlnet [port[-port]]
	7.x	Firewall(config-pmap-c)# inspect sqlnet
	SQL*Net is expected to use port (the default is 1521) or a range port-port.
SunRPC	FWSM 2.x	Firewall(config)# fixup protocol rpc
	6.x	Always enabled.
	7.x	Firewall(config-pmap-c)# inspect sunrpc
	Port 111 is expected.
TFTP	FWSM 2.x
	6.x	Firewall(config)# fixup protocol tftp [port[-port]]
	7.x	Firewall(config-pmap-c)# inspect tftp
	TFTP is expected to use UDP port number port (the default is 69) or a range port-port. DoS prevention and secondary channel inspection are used.
VDO Live	FWSM 2.x
	6.x	Always enabled.
	7.x
	TCP port 7000 and UDP source port 7001 are expected. The UDP destination port is negotiated.
Windows Media	FWSM 2.x
	6.x	Always enabled.
	7.x
	Also known as Netshow. TCP port 1755 and negotiated UDP ports (1024 to 5000) are expected.
XDMCP	FWSM 2.x
	6.x	Always enabled.
	7.x	Firewall(config-pmap-c)# inspect xdmcp
	UDP port 177 is expected as a control port. For PIX 6.x, a supporting established command must also be configured to allow related connections to be initiated in the inbound direction.

Notice that beginning with PIX 7.0, none of the inspection engine configuration commands accepts a port number. This is because PIX 7.0 must first identify traffic to send to an inspection engine. If a nondefault port is needed, traffic must be matched against the nondefault port in a class map and then sent to an inspection engine specified in a policy map.

For the five PIX 7.0 inspection engines that support an additional map template, the configuration steps are discussed in the following sections.

NOTE

The additional inspection tests configured in the map templates (http-map, ftp-map, and so on) might be confusing at first. Remember that you are defining criteria for messages or packets that are allowed to pass through the firewall.

Most of these tests also have an action that must be defined. The action (allow the packet, drop the packet, or reset the connection) occurs only if the packet doesn't meet or fails the test.

Configuring ICMP Inspection

Internet Control Message Protocol (ICMP) is used in a variety of ways to test and exchange network parameters between devices. For example, the ping "application" can be used to send echo requests from one host to another; the target host is expected to return echo replies. This tests the hosts' livelihood and the network's connectivity.

In PIX releases before 7.0, a firewall can allow ICMP traffic to pass through, but only if interface access lists are configured to explicitly permit it. As ICMP packets cross from one firewall interface to another, a special ICMP xlate entry is created. However, this xlate is used only to provide the translationnot to provide ICMP inspection. ICMP xlate entries have a fixed idle time of about 30 seconds.

Outbound pings might be allowed, but the return traffic is blocked at the outside interface unless that access list permits it to enter. It becomes difficult to know which outside addresses will return legitimate ICMP traffic, so a permit icmp any any is often added to the outside access list. Obviously, such a broad rule leaves the door open for malicious users to abuse inbound ICMP into a network.

Beginning with FWSM and PIX 7.0, an ICMP inspection engine is available. Rather than explicitly configuring access list rules to permit inbound ICMP traffic, the firewall can selectively (and automatically) permit return traffic based on the original outbound requests.

For example, as an inside host sends an ICMP echo packet toward an outside host, the firewall builds the ICMP xlate entry. The source and destination addresses are examined, along with the ICMP message type and code, the ICMP identifier, and the ICMP sequence number fields. This forms a five-tuple of information that can be inspected and matched.

For example, the following output represents the ICMP xlate entry that was created when inside host 192.168.198.199 (translated to global address 10.10.1.1) sent one ICMP echo request packet to outside host 10.10.10.10:

%PIX-6-305011: Built dynamic ICMP translation from inside:192.168.198.199/512 to outside:10.10.1.1/1 Firewall# show xlate 5 in use, 12 most used PAT Global 10.10.1.1(1) Local 192.168.198.199 ICMP id 512 [output omitted]

Here, /512 and ICMP id 512 represent the inside host's ICMP identifier field value. During the dynamic address translation, the firewall creates a dynamic ICMP identifier for the outside target. This is shown as /1 and (1) after the 10.10.1.1 address lines.

The ICMP inspection engine examines return ICMP traffic, looking for packets that are expected in response to a prior request. ICMP is IP protocol 1. It doesn't include any mechanisms for establishing a connection or tracking the state of a message exchange. The ICMP inspection engine must use the five-tuple of ICMP information gathered from request and response packets to approximate a connection state.

In fact, after an ICMP xlate is created and a request packet goes out, the firewall creates a special ICMP connection entry apart from the normal conn table entries. The following Syslog message was generated when the special connection was created:

%PIX-6-302020: Built ICMP connection for faddr 10.10.10.10/0 gaddr 10.10.1.1/1 laddr 192.168.198.199/512

Finally, the ICMP inspection engine permits only one response to return for every request that is sent out. The ICMP sequence numbers must also match between a request and a reply packet. With "stateful" ICMP inspection, the ICMP connections and xlate entries can be quickly torn down as soon as the appropriate reply is received.

You can see this in the following Syslog output, which resulted from one ICMP echo request packet being sent from inside host 192.168.198.199 (translated to global address 10.10.1.1) to outside host 10.10.10.10. (Message ID 711001 was produced because the debug icmp trace command was also used.)

%PIX-6-609001: Built local-host outside:10.10.10.10 %PIX-6-305011: Built dynamic ICMP translation from inside:192.168.198.199/512 to outside:10.10.1.1/2 %PIX-6-302020: Built ICMP connection for faddr 10.10.10.10/0 gaddr 10.10.1.1/2 laddr 192.168.198.199/512 %PIX-7-711001: ICMP echo request (len 32 id 512 seq 25344) 192.168.198.199 > 10.10.10.10 %PIX-7-711001: ICMP echo reply (len 32 id 2 seq 25344) 10.10.10.10 > 10.10.1.1 %PIX-6-302021: Teardown ICMP connection for faddr 10.10.10.10/0 gaddr 10.10.1.1/2 laddr 192.168.198.199/512 %PIX-6-609002: Teardown local-host outside:10.10.10.10 duration 0:00:00

The time from when the xlate entries were first created until the ICMP connection entry was deleted and the xlates torn down is shown to be 0:00:00 (less than 1 second)! The ICMP inspection engine allows the connectionless and stateless ICMP protocol to be used through a firewall while maintaining a high level of security.

By default, ICMP inspection is not enabled in PIX 7.0. To enable it, you can add the following command to a policy map as an action:

Firewall(config-pmap-c)# inspect icmp

For example, you might want to add ICMP inspection to the default service policy that is applied to all firewall interfaces. To do so, you only need to add the inspect icmp command to the default asa_global_fw_policy policy map that is already defined. This policy map is already applied as a global service policy, so you don't need to define it separately. You can use the following commands to add the inspection to the default policy map:

Firewall(config)# policy-map asa_global_fw_policy Firewall(config-pmap)# class inspection_default Firewall(config-pmap-c)# inspect icmp Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)#

By default, ICMP inspection does not permit any ICMP error packets to return through an address translation. This is because an ICMP error message can be sent from an address other than the original ICMP target. For example, if the IP time-to-live (TTL) value expires on an ICMP echo request that was sent to an outside host, an intervening router sends an ICMP error message back to the inside host. That packet uses the router's own IP address as the source addressnot the ICMP echo target host's address.

When a router replies with an ICMP error packet, it must also include the first 64 bytes of the original IP packet as the error message payload. When a host receives the error packet, it can look inside the payload to see the original source and destination addresses, protocol, port numbers, and so on.

You can use the following command to enable ICMP error processing as part of the ICMP inspection:

Firewall(config-pmap-c)# inspect icmp error

Now the firewall examines ICMP error packet payloads to find the original packet details. If it can match those to known ICMP "connections" and xlate entries, it can work out the address translation and permits the ICMP error packet to reach the original sender.

Configuring Enhanced HTTP Inspection (http-map)

HTTP is used to exchange data between a client and a server. Most often, this is used between a client's web browser and a web server. HTTP is defined in RFC 1945 (HTTP v1.0) and RFC 2616 (HTTP v1.1). The basic HTTP inspection engine (beginning with PIX 6.x fixup http) performs URL logging and Java and ActiveX filtering and enables the use of Websense or N2H2 for URL filtering.

Beginning with PIX 7.0, HTTP application inspection can be enhanced with any of the following criteria:

HTTP traffic must conform to RFC 2616 (HTTP 1.1)

Allowed message body or content length size

Message content type matches the HTTP header

Allowed request and response header size

Allowed URI length

Allowed use of port 80 for non-HTTP applications

Allowed request methods

To configure enhanced HTTP inspection, you can follow these steps to configure an HTTP map for use with the inspect http command:

Define the HTTP map name:

Firewall(config)# http-map http_map_name

The HTTP map is named http_map_name (up to 64 characters). The HTTP map must be applied with the following command in a policy map before it can be used:

inspect http http_map_name

(Optional) Check the message content length:

Firewall(config-http-map)# content-length {[min minimum] [max maximum]} action {allow | drop | reset} [log]

If the HTTP message content is larger than minimum (1 to 65535 bytes) and smaller than maximum (1 to 50,000,000 bytes), it is allowed to pass. If it fails this test, one of the following actions is taken: allow the packet to pass, drop the packet, or reset the HTTP connection.

If the min keyword is omitted, the content length must be less than maximum. If max is omitted, the length must be greater than minimum. You can also use the log keyword to generate Syslog messages based on the action taken.

You can configure only one content-length command in an HTTP map.

For example, the following commands allow message lengths greater than 256 bytes to pass. Packets smaller than 256 bytes fail the test, triggering the action to reset the TCP connection and generate a Syslog message:

Firewall(config)# http-map Filter_http Firewall(config-http-map)# content-length min 256 action reset log Firewall(config-http-map)# exit

(Optional) Verify the message content type:

Firewall(config-http-map)# content-type-verification [match-req-rsp] action {allow | drop | reset} [log]

Each HTTP message is examined to make sure the content type stated in the HTTP header matches the message's actual content and that the content is an acceptable type. You can add the match-req-rsp keyword to verify that the content type in each HTTP request header matches the content type returned in the corresponding HTTP response header.

Table 6-11 lists the acceptable content types.

Table 6-11. Acceptable HTTP Message Content Types
Content	Type
application/	msword, octet-stream, pdf, postscript, vnd.ms-excel, vnd.ms-powerpoint, x-gzip, x-java-arching, x-java-xm, zip
audio/	*, basic, midi, mpeg, x-adpcm, x-aiff, x-ogg, x-wav
image/	*, cgf, gif, jpeg, png, tiff, x-3ds, x-bitmap, x-niff, x-portable-bitmap, x-portable-greymap, x-xpm
text/	*, css, html, plain, richtext, sgml, xmcd, xml
video/	*, -flc, mpeg, quicktime, sgi, x-avi, x-fli, x-mng, x-msvideo

If all these tests pass, the packet is allowed to pass. If a packet fails the tests, one of the following actions is taken: allow the packet to pass, drop the packet, or reset the HTTP connection.

For example, the following commands allow verified messages to pass. If the verification fails, those packets are also allowed (action allow), but a Syslog message is generated:

Firewall(config)# http-map Filter_http Firewall(config-http-map)# content-type-verification match-req-rsp action allow log Firewall(config-http-map)# exit

(Optional) Check the header length:

Firewall(config-http-map)# max-header-length {[request length] [response length]} action {allow | drop | reset} [log] If you use the request keyword, the HTTP request header length must be less than length (0 to 65535 bytes). If you use the response keyword, the corresponding HTTP response header must be less than length (0 to 65535 bytes).

If a packet fails this test, one of the following actions is taken: allow the packet to pass, drop the packet, or reset the HTTP connection.

For example, the following commands allow HTTP request messages with header lengths of less than 200 bytes. The corresponding HTTP response headers must also be less than 200 bytes. Otherwise, the HTTP connection is reset.

Firewall(config)# http-map Filter_http Firewall(config-http-map)# max-header-length request 200 response 200 action reset log Firewall(config-http-map)# exit

(Optional) Check the Uniform Resource Identifier (URI) length:

Firewall(config-http-map)# max-uri-length length action {allow | drop | reset} [log]

The length of the URI in an HTTP request message must be less than length (1 to 65535) bytes. If its length is greater, one of the following actions is taken: allow the packet to pass, drop the packet, or reset the HTTP connection.

For example, the following commands allow HTTP requests with URIs shorter than 256 bytes to pass. If the URIs are longer, the HTTP connection is reset:

Firewall(config)# http-map Filter_http Firewall(config-http-map)# max-uri-length 256 action reset log Firewall(config-http-map)# exit

(Optional) Test for HTTP port cloaking:

Firewall(config-http-map)# port-misuse {default | im | p2p | tunnelling} action {allow | drop | reset} [log]

HTTP port cloaking is used to transport traffic from a non-HTTP application over the standard HTTP port. These applications appear to use regular HTTP, as if they were Web-based applications. The firewall can detect some misuses of the HTTP port by examining the entire contents of each HTTP packet. You can use one of the following keywords to detect a specific tunneling application:

im Instant messaging applications. In PIX 7.0, only Yahoo Messenger is detected.

p2p Peer-to-peer applications. In PIX 7.0, Kazaa and Gnutella can be detected.

tunnelling Data from arbitrary applications is tunneled inside HTTP request messages to bypass normal firewalls. In PIX 7.0, the following tunneling applications can be detected:
- HTTPort/HTTHost http://www.htthost.com
- GNU Httptunnel http://www.nocrew.org/software/httptunnel.html
- GotoMyPC http://www.gotomypc.com
- Firethru Fire Extinguisher http://www.firethru.com
- Http-tunnel.com Client http://www.http-tunnel.com

If the application is detected, the corresponding action is taken: allow the packet to pass, drop the packet, or reset the HTTP connection.

You can also use the default keyword to define an action to be taken for any HTTP port misuse application that is not one of the keywords listed.

You can repeat this command to define multiple applications to detect.

For example, the following commands reset connections if a peer-to-peer application, a tunneling application, or any other unrecognized port-cloaking application is detected. Only instant messaging applications are allowed to pass through.

Firewall(config)# http-map Filter_http Firewall(config-http-map)# port-misuse im action allow Firewall(config-http-map)# port-misuse default action reset log Firewall(config-http-map)# exit

(Optional) Check the HTTP request method:

Firewall(config-http-map)# request-method {rfc | ext} {method | default} action {allow | drop | reset} [log]

By default, all HTTP request methods are allowed. You can define a policy for a specific request method based on whether it is a request method defined in RFC 2616 (rfc) or an HTTP extension method (ext).

For rfc, you can use one of the following method keywords: connect, delete, get, head, options, post, put, or trace.

For ext, you can use one of the following method keywords: copy, edit, getattribute, getattributenames, getproperties, index, lock, mkdir, move, revadd, revlabel, revlog, revnum, save, setattribute, startrev, stoprev, unedit, or unlock. You can also use the default keyword to define an action to be taken for any request method not explicitly configured.

If the specified method is detected, the corresponding action is taken: allow the packet to pass, drop the packet, or reset the HTTP connection. You can repeat this command to define multiple request method policies.

For example, the following commands allow any of the RFC 2616 request methods to pass. If any of the extension's request methods is detected, the HTTP connection is reset:

Firewall(config)# http-map Filter_http Firewall(config-http-map)# request-method rfc default action allow Firewall(config-http-map)# request-method ext default action reset log Firewall(config-http-map)# exit

(Optional) Check for RFC 2616 compliance:

Firewall(config-http-map)# strict-http action {allow | drop | reset} [log]

By default, HTTP packets that are not compliant with RFC 2616 are dropped. You can specify a different action to take when noncompliant traffic is detected: allow the packet to pass, drop the packet, or reset the HTTP connection.

You can add the log keyword to generate Syslog messages when the action is taken.

For example, the following commands allow noncompliant HTTP messages to be forwarded. As an audit trail, Syslog messages are sent when this occurs:

Firewall(config)# http-map Filter_http Firewall(config-http-map)# strict-http action allow log Firewall(config-http-map)# exit

(Optional) Check the transfer encoding type:

Firewall(config-http-map)# transfer-encoding type {type | default} action {allow | drop | reset} [log]

Transfer encoding is used to convert a document into a form that can be transported over HTTP. You can specify a transfer encoding type as one of the keywords listed in Table 6-12.

Table 6-12. Transfer Encoding Types for HTTP
Transfer Encoding type	Description
chunked	The message is sent as a series of "chunks"
compress	UNIX file compression
deflate	zlib format (RFC 1950) and deflate compression (RFC 1951)
gzip	GNU zip (RFC 1952)
identity	No transfer encoding is used

You can also use the default keyword to match all transfer encoding types other than the ones you explicitly configure.

When this transfer encoding type is detected in an HTTP message, the specified action is taken: allow the packet to pass, drop the packet, or reset the HTTP connection.

For example, the following commands allow the identity and gzip encodings, and all other types cause the HTTP connection to be reset:

Firewall(config)# http-map Filter_http Firewall(config-http-map)# transfer-encoding type identity action allow Firewall(config-http-map)# transfer-encoding type gzip action allow Firewall(config-http-map)# transfer-encoding type default action reset log Firewall(config-http-map)# exit ! Firewall(config)# class-map _MyClass Firewall(config-cmap)# match any Firewall(config-cmap)# exit Firewall(config)# policy-map MyPolicy Firewall(config-pmap)# class MyClass Firewall(config-pmap-c)# inspect http Filter_http Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)# service-policy MyPolicy interface outside

Configuring Enhanced FTP Inspection (ftp-map)

FTP can be used to exchange files between a client and a server. FTP is defined in RFC 959. By default, the regular FTP inspection engine maintains any secondary connections negotiated by FTP clients and servers. FTP commands and responses are also tracked.

You can use the following steps to configure enhanced FTP inspection. An FTP map is used with the inspect ftp command to define additional parameters for inspection.

Define the FTP map name:

Firewall(config)# ftp-map ftp_map_name

The FTP map is named ftp_map_name (up to 64 characters). The FTP map must be applied with the following command in a policy map before it can be used:

inspect ftp ftp_map_name

(Optional) Deny specific FTP request commands:

Firewall(config-ftp-map)# deny-request-cmd request_list

The firewall drops FTP commands listed in request_list before they reach the server. You can list one or more of the commands shown in Table 6-13, separated by spaces.

Table 6-13. FTP Request Commands
Command	Description
appe	Appends to a file
cdup	Changes the directory to the parent of the current directory
dele	Deletes a file
get	Retrieves a file
help	Gets help information from the FTP server
mkd	Makes a new directory
put	Stores a file
rmd	Removes a directory
rnfr	Renames a file from
rnto	Renames a file to
site	A server-specific command
stou	Stores a file with a unique name

(Optional) Mask the reply to a syst command:

Firewall(config-ftp-map)# mask-syst-reply

An FTP client can send the syst command to find out which operating system the FTP server uses. When the mask-syst-reply command is used, the firewall masks the server's reply with Xs so that the information remains hidden. For example, suppose an FTP map is configured to deny any FTP command operation that would alter files or directories on the FTP server. The FTP map is then applied to a policy map where the inspect ftp command is configured. You could use the following commands to accomplish this purpose:

Firewall(config)# ftp-map MyFTPfilter Firewall(config-ftp-map)# deny-request-cmd appe dele mkd put rmd rnfr rnto stou Firewall(config-ftp-map)# exit ! Firewall(config)# class-map _MyClass Firewall(config-cmap)# match any Firewall(config-cmap)# exit Firewall(config)# policy-map MyPolicy Firewall(config-pmap)# class MyClass Firewall(config-pmap-c)# inspect ftp strict MyFTPfilter Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)# service-policy MyPolicy interface outside

Configuring Enhanced SNMP Inspection (SNMP Map)

Simple Network Management Protocol (SNMP) is used to monitor and manage devices with an SNMP agent from a management station. By default, all versions of SNMP are allowed to pass through a firewall, as long as SNMP itself (UDP port 161) is permitted.

You can use the following steps to configure enhanced SNMP inspection, which allows specific versions of SNMP to be denied. For example, SNMPv1 has no mechanisms for security, so your network security policies might not allow that type of traffic to be used.

An SNMP map is used with the inspect snmp command to define additional parameters for inspection.

Define the SNMP map name:

Firewall(config)# snmp-map snmp_map_name

The SNMP map is named snmp_map_name (up to 64 characters). The SNMP map must be applied with the following command in a policy map before it can be used:

inspect snmp snmp_map_name

Deny a specific SNMP version:

Firewall(config-snmp-map)# deny version {1 | 2 | 2c | 3}

You can repeat this command to deny more than one SNMP version.

For example, the following commands define an snmp-map that denies packets using SNMP versions 1 and 2 during SNMP inspection. The SNMP map is then applied to the inspect snmp command in a policy map.

Firewall(config)# snmp-map Filter_snmp Firewall(config-snmp-map)# deny version 1 Firewall(config-snmp-map)# deny version 2 Firewall(config-snmp-map)# exit ! Firewall(config)# class-map _MyClass Firewall(config-cmap)# match any Firewall(config-cmap)# exit Firewall(config)# policy-map MyPolicy Firewall(config-pmap)# class MyClass Firewall(config-pmap-c)# inspect snmp Filter_snmp Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)# service-policy MyPolicy interface outside

Configuring an MGCP Map

Media Gateway Control Protocol (MGCP) is used by call agents to control media gateways (devices that convert telephone circuit audio to data packets).

You can follow these steps to configure an MGCP map for use with the inspect mgcp command:

Define the MGCP map name:

Firewall(config)# mgcp-map mgcp_map_name The MGCP map is named mgcp_map_name (up to 64 characters). You must apply the MGCP map in a policy map with the following command map before it can be used:

inspect mgcp mgcp_map_name

Customize MGCP options:

You can use any of the commands listed in Table 6-14 to set a specific MGCP inspection parameter in MGCP map configuration mode.

Table 6-14. Setting MGCP Inspection Parameters
Parameter Description	Command Syntax
Defines a call agent (ip_address) as part of a group (group_id, 0 to 4294967295).	`Firewall(config-mgcp-map)#` `call-agent` `ip_address group_id`
Permits call agents in a group (group_id, 0 to 4294967295) to manage the gateway at ip_address.	`Firewall(config-mgcp-map)#` `gateway` `ip_address group_id`
Sets the maximum number of requests to be queued waiting for a response (1 to 4294967295; the default is 200).	`Firewall(config-mgcp-map)#` `command-queue` `limit`

For example, suppose an MGCP map is configured to allow call agents at 192.168.77.10 and 192.168.77.11 to control the gateway at 192.168.100.1. Those call agents are defined as group 1. The call agents at 192.168.77.12 and 192.168.77.13 are defined as group 2 and are allowed to control a different gateway at 192.168.100.2. The MGCP map is then applied to the inspect mgcp command in a policy map. The following commands are used:

Firewall(config)# mgcp-map MyMGCPMap Firewall(config-mgcp-map)# call-agent 192.168.77.10 1 Firewall(config-mgcp-map)# call-agent 192.168.77.11 1 Firewall(config-mgcp-map)# gateway 192.168.100.1 1 Firewall(config-mgcp-map)# call-agent 192.168.77.12 2 Firewall(config-mgcp-map)# call-agent 192.168.77.13 2 Firewall(config-mgcp-map)# gateway 192.168.100.2 2 Firewall(config-mgcp-map)# exit ! Firewall(config)# class-map _MyClass Firewall(config-cmap)# match any Firewall(config-cmap)# exit Firewall(config)# policy-map MyPolicy Firewall(config-pmap)# class MyClass Firewall(config-pmap-c)# inspect mgcp MyMGCPMap Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)# service-policy MyPolicy interface outside

Configuring Enhanced GTP Inspection (GTP Map)

GPRS Tunneling Protocol (GTP) is used to tunnel multiprotocol packets through a General Packet Radio Service (GPRS) network between different GPRS Support Nodes (GSNs). A Cisco firewall running PIX 7.0 or later can inspect GTP traffic and provide security measures for it.

Follow these steps to configure a GTP map for use with the inspect gtp command:

Define the GTP map name:

Firewall(config)# gtp-map gtp_map_name The GTP map is named gtp_map_name (up to 64 characters). You must apply the GTP map in a policy map with the following command before it can be used:

inspect gtp gtp_map_name

(Optional) Add a GTP map description:

Firewall(config-gtpmap)# description string

You can add an arbitrary text string (up to 200 characters) as a description of the GTP map.

Customize GTP options.

You can use any of the commands listed in Table 6-15 to set a specific GTP inspection parameter in GTP map configuration mode.

Table 6-15. Setting GTP Inspection Parameters
Parameter Description	Command Syntax
Allows only international mobile system identifier (IMSI) prefixes: Mobile Country Code (mcc_code, three digits) and Mobile Network Code (mnc_code, three digits).	`Firewall(config-gtp-map)#` `mcc` `mcc_code` `mnc` `mnc_code`
Allows packets with errors.	`Firewall(config-gtp-map)#` `permit errors`
Drops an access point.	`Firewall(config-gtp-map)#` `drop apn` `access_point_name`
Drops a message ID (1 to 256).	`Firewall(config-gtp-map)#` `drop message` `message_id`
Drops the GTP version (0 to 255).	`Firewall(config-gtp-map)#` `drop version` `version`
Sets the maximum number of requests to be queued waiting for a response (1 to 4294967295; the default is 200).	`Firewall(config-gtp-map)#` `request-queue` `max_requests`
Permits messages within min (1 to 65536) and max (1 to 65536) bytes.	`Firewall(config-gtp-map)#` `message-length min` `min` `max` `max`
Permits no more than max tunnels (1 to 4294967295; the default is 500).	`Firewall(config-gtp-map)#` `tunnel-limit` `max`

For example, the following commands configure a GTP map that allows GTP packets only from Mobile Country Code 310, Mobile Network Codes 001 and 002. All others are dropped. In addition, GTP messages must be between 1 and 2048 bytes in length. Up to 100 GTP tunnels are allowed to pass through the firewall. The GTP map is then applied to the inspect gtp command as part of a policy map.

Firewall(config)# gtp-map Secure_gtp Firewall(config-gtp-map)# mcc 310 mnc 001 Firewall(config-gtp-map)# mcc 310 mnc 002 Firewall(config-gtp-map)# message-length min 1 max 2048 Firewall(config-gtp-map)# tunnel-limit 100 Firewall(config-gtp-map)# exit ! Firewall(config)# class-map _MyClass Firewall(config-cmap)# match any Firewall(config-cmap)# exit Firewall(config)# policy-map MyPolicy Firewall(config-pmap)# class MyClass Firewall(config-pmap-c)# inspect gtp Secure_gtp Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)# service-policy MyPolicy interface outside

6-6. Application Inspection

Figure 6-16. An Example of FTP Application Inspection

Table 6-9. Application Inspection: Applications and Ports Supported by PIX

Configuring Application Inspection

Table 6-10. Configuring Application Inspection Engines

Configuring ICMP Inspection

Configuring Enhanced HTTP Inspection (http-map)

Table 6-11. Acceptable HTTP Message Content Types

Table 6-12. Transfer Encoding Types for HTTP

Configuring Enhanced FTP Inspection (ftp-map)

Table 6-13. FTP Request Commands

Configuring Enhanced SNMP Inspection (SNMP Map)

Configuring an MGCP Map

Table 6-14. Setting MGCP Inspection Parameters

Configuring Enhanced GTP Inspection (GTP Map)

Table 6-15. Setting GTP Inspection Parameters

Категории