In the previous chapters, you’ve seen the mandatory configuration commands used to configure the zone-based policy firewall feature of Cisco IOS and how they can be used to implement various firewall designs. In this chapter, we focus on optional and advanced topics, including the following:
Tuning the stateful inspection
Tuning denial-of-service protection
Identifying applications masquerading as other well-known applications
Configuring application layer inspection policies
Configuring user-defined application protocols
Throughout most of this chapter, we discuss the firewall with a perimeter network from the previous chapter and incrementally fine-tune its configuration.
The zone-based policy firewall shares a number of features with Cisco IOS firewall stateful inspection, one of them being the capability to generate an audit log of interesting sessions. The audit log can be enabled for an individual traffic class in a policy map with the help of a global parameter-map object that defines the inspection parameters. To configure auditing of inspected sessions, use the configuration commands in Table 5-1.
Table 5-1. Configuring Session Auditing
Command Syntax | Description |
|---|---|
parameter-map type inspect name | Creates or modifies the specified parameter map. |
alert on | off | Enables or disables syslog alerts (default: on). |
audit-trail on | off | Enables or disables a session audit trail written to the router’s log (default: off). |
inspect parameter-map-name | Within a policy-map class definition, attaches a predefined parameter map to the inspect action to modify its default behavior. |
For example, in the firewall setup from the preceding chapter, we might want to log all incoming SMTP sessions as shown in Figure 5-1.
To configure the audit trail for the SMTP session, we need to do the following:
Configure a parameter map with the audit trail.
Assign SMTP to a separate traffic class. (Currently, it’s bundled with all other public protocols, and you can apply auditing only to an entire class.)
Reconfigure the OutsideToPerimeter policy map to include the new traffic class. Because the new traffic class is a subset of the existing traffic class, we need to put it at the beginning of the policy map. There is no way to insert class commands in a policy map (they are always appended), so all class definitions have to be erased and reentered.
Warning
Do not delete and re-create a policy map as you would do with an access list. Deleting a policy map silently removes all references to it, thus potentially modifying your router configuration.
Listing 5-1 includes the step-by-step configuration process.
Example 5-1. Configuring the Audit Trail of Inbound SMTP Sessions
fw#conf t Enter configuration commands, one per line. End with CNTL/Z fw(config)#class-map type inspect PublicSMTP fw(config-cmap)#match class-map SMTP fw(config-cmap)#match access-group name ExternalServer fw(config-cmap)#exit fw(config)#parameter-map type inspect audit fw(config-profile)#audit-trail on fw(config-profile)#exit fw(config)#policy-map type inspect OutsideToPerimeter fw(config-pmap)#no class type inspect PublicTraffic fw(config-pmap)#class type inspect PublicSMTP fw(config-pmap-c)#inspect audit fw(config-pmap-c)#class type inspect PublicTraffic fw(config-pmap-c)#inspect fw(config-pmap-c)#^Z fw#
After this configuration change, the router generates a line in the syslog for every session establishment and termination event. Sample log messages are displayed in Listing 5-2.
Example 5-2. SMTP Session Audit Trail
%FW-6-SESS_AUDIT_TRAIL_START: (target:class)-(OutsideToPerimeter:PublicSMTP):Start smtpsession: initiator (172.18.25.10:1044) -- responder (192.168.0.2:25) %FW-6-SESS_AUDIT_TRAIL: (target:class)-(OutsideToPerimeter:PublicSMTP) :Stop smtp session: initiator (172.18.25.10:1044) sent 31 bytes -- responder (192.168.0.2
The stateful firewall inspection in Cisco IOS contains inherent denial-of-service (DoS) protection mechanisms. The router constantly monitors the number of established and half-open connections and the connection creation rate and issues warnings or alerts when they exceed configured thresholds. The router also tries to cope with a DoS attack (primarily SYN attacks in which the intruder sends a large number of TCP SYN packets, also called SYN floods) by aggressively deleting half-open sessions when their number exceeds the threshold or when the session establishment rate exceeds the threshold.
Note
Half-open TCP connections are connections where the SYN packet has been received, but the first non-SYN packet hasn’t been seen yet.
The Cisco IOS Firewall Stateful Inspection (CBAC) feature enables you to configure only the global thresholds. The zone-based policy firewall uses parameter maps that can be attached to every inspect statement in a policy map, resulting in a very granular solution that can be fine-tuned to the actual network environment and traffic patterns.
The commands described in Table 5-2 are used to configure the inspect thresholds in a parameter map. (The parameter-map syntax is described in Table 5-1.) Remember that all parameters apply to a single traffic class between a pair of zones.
Table 5-2. Configuring Inspect Thresholds
Command Syntax | Description |
|---|---|
alert on | off | Enables or disables syslog alerts (default: on). |
audit-trail on | off | Enables or disables the session audit trail written to the router’s log (default: off). |
sessions maximum number | Configures the maximum number of sessions in this traffic class. |
dns-timeout seconds | Configures the maximum time between the DNS query and response packet. |
icmp idle-timeout seconds | Configures the maximum time between ICMP request and reply. |
max-incomplete high number | low number | Configures the threshold at which the Cisco IOS firewall starts the DoS protection (high parameter) and when the DoS protection stops (low parameter). While the DoS protection is active, the firewall resets one half-open connection for every new connection attempt. |
one-minute high number | low number | Configures the per-minute session establishment threshold that triggers the DoS protection. The process starts after the high threshold has been exceeded and stops when the session establishment rate drops below the low threshold. |
tcp max-incomplete host threshold [ block minutes ] | Configures the maximum number of half-open sessions from a single IP host. The offending host could be (optionally) blocked for the specified duration. |
tcp synwait-time seconds tcp finwait-time seconds tcp idle-time seconds | Configures TCP timers—the maximum time between packets in session establishment, the maximum time between packets in session termination and the session idle timer. |
udp idle-time seconds | Configures the idle timer for non-DNS UDP sessions. |
You can display the default values of all these parameters with the show parameter-map type inspect default command, which displays the values in Listing 5-3.
Example 5-3. Default Stateful Packet Inspection Thresholds
fw#show parameter-map type inspect default
parameter-map type inspect default values
audit-trail off
alert on
max-incomplete low 400
max-incomplete high 500
one-minute low 400
one-minute high 500
udp idle-time 30
icmp idle-time 10
dns-timeout 5
tcp idle-time 3600
tcp finwait-time 5
tcp synwait-time 30
tcp max-incomplete host 50 block-time 0
You would usually need to modify the inspect thresholds in high-volume environments when the router starts issuing warning and alert messages (similar to Listing 3-9). For example, it’s quite easy to get more than 500 HTTP requests per minute on a popular website.
Before changing the thresholds, it might be beneficial to reduce the various timeouts (which will by itself reduce the number of half-open sessions). For example, many host DNS resolvers time out in 2 seconds. Thus, having a 5-second DNS timeout is overkill. Similarly, a 30-second synwait-time is useful only if there is a dialup connection in the outbound session establishment path; otherwise, you should use a timeout of a few seconds. The 10-second icmp idle-timeout can also be reduced unless you have very slow-speed congested links.
After you have adapted the timeouts to your environment, perform the following steps to fine-tune the half-open session thresholds:
Make sure your network is not infected with a worm or a target of a DoS attack. (In both cases, tuning DoS protection will obviously not help.)
Create a new parameter map that considerably increases the current thresholds (for example, by a factor of 10). Apply the new parameter map to the inspect statement in the policy map that triggers the DoS protection. (The alert message indicates the policy map and the class within it.)
After a statistically significant time period (at least a day), review the inspect counters (see Listing 5-4).
Example 5-4. Displaying Session Inspection Parameters of a Zone Pair
fw#sh policy-map type inspect zone-pair OutsideToPerimeter Zone-pair: OutsideToPerimeter Service-policy inspect : OutsideToPerimeter ... service policy printout deleted ... Inspect Session creations since subsystem startup or last reset 15480 Current session counts (estab/half-open/terminating) [6:2:0] Maxever session counts (estab/half-open/terminating) [73:7:0] Last session creation rate 37 Last half-open session total 0 ... rest of printout deleted ...
Set the max-incomplete low parameter to the Maxever session counts half-open value. Set the max-incomplete high parameter to a value at least 25 percent above that. Increase the parameter to an even higher value if you expect a significant increase in network traffic (for example, increased website traffic due to a marketing campaign).
The Cisco IOS printout gives you no reliable information that would allow you to set the one-minute thresholds. As a starting point, set the one-minute low value to 3 times the Maxever session counts estab value and the one-minute high value to a 50 percent higher value.
Repeat the process for every traffic class that needs adjusted DoS protection behavior.
Perform ongoing firewall DoS protection monitoring, and log all related events to a syslog server. The logged events will help you perform additional fine-tuning of the parameters.
Some applications (most notably, instant messaging and peer-to-peer applications) are extremely aggressive in their attempts to establish connections with their servers. For example, Yahoo Messenger first tries to connect to Yahoo! servers using its standard port numbers (5050 for instant messaging, 5061 for voice; see Listing 5-5 for details), but if that fails, it uses any TCP port number that the firewall permits (for example, Telnet or HTTPS; see Listing 5-6 for an example). To be fair, other instant messaging (IM) applications are no better, and Yahoo! even documents this behavior.
The applications that can adapt their TCP or UDP port usage or use well-known ports reserved for other applications as a disguise are effectively trying to bypass firewall policies. For example, in the sample firewall designed in Chapter 4, “Case Study: Firewall with a Perimeter Network,” the internal clients were only allowed to browse the web and use FTP for file transfer. However, they could still use IM applications, because the inside clients have unlimited access to outside web servers, giving the IM applications a TCP port they can use, as shown in Figure 5-2.
The masquerading applications fall into two categories:
They use any TCP port permitted by the firewall, but only toward a well-known range of servers. For example, all IM applications have to connect to well-known servers as they exchange the chat traffic through them.
Some peer-to-peer applications use any TCP port (or a fixed range of ports, such as web only) toward a wide range of IP addresses. The only means of identifying these applications is by looking for their specific signatures in the data stream (similar to the way virus scanners identify new viruses).
Cisco IOS can identify both types of applications starting in Release 12.4(9)T.
To identify the peer-to-peer applications by their signature, use the signature option in the match command of a class map. For example, to match all peer-to-peer applications in our sample firewall, you could use the traffic class definition in Listing 5-7.
The signature-based classification bypasses the order of classes in a policy map, so the peer-to-peer sessions misusing ports from other applications are detected regardless of the order of class maps in a policy map.
Instant messaging applications (and other applications that use unspecified ports to connect to their server) are identified with the help of the protocol-info parameter-map using the syntax in Table 5-3.
Table 5-3. Configuring a Protocol Information Parameter Map
Command Syntax | Description |
|---|---|
parameter-map type protocol-info name | Creates or modifies the specified parameter map |
server{name name | ip address} | Specifies a single server by its name or IP address |
server ip range start end | Specifies a range of servers between start and end IP addresses |
Note
Domain name resolution must be enabled in the router with the ip domain lookup command and an external DNS server configured with the ip name-server command before you can use the server name name command.
The name of the protocol-info parameter-map can then be appended to the match command in a class mapdefinition. For example, to identify Yahoo Messenger, you could use the parameter map and class mapconfiguration in Listing 5-8.
Note
The router allows you to attach a protocol-info parameter-map to any match protocol statement in a class map (with the exception of peer-to-peer applications, where the signature keyword follows the protocol name), but it only works correctly for instant messaging applications in Cisco IOS Release 12.4(9)T.
When you use protocol-info-based traffic classification in a policy map, you don’t have to worry about the order of the class commands. The destination IP address match with the parameter map is done before the sequential scan of the policy map, so the IM applications are correctly identified regardless of their position in the policy map.
If you want to disable access to Yahoo Messenger in our sample firewall from Chapter 4, you have to augment the InsideToOutside policy map with the commands from Listing 5-9.
You can monitor the protocol-info parameter maps with two show commands (both printouts are included in Listing 5-10):
show parameter-map type protocol-info {name} displays the definition of the parameter map (so you don’t have to browse the router configuration).
show parameter-map type protocol-info dns-cache zone-pair name displays the IP addresses used in traffic classification in the specified zone pair; all parameter-maps used in the policy map attached to the zone pair with IP addresses to which the hostnames specified in them resolve to.
Example 5-10. protocol-info-Related show Commands
fw#show parameter-map type protocol-info parameter-map type protocol-info YMServers server name scs.msg.yahoo.com server name insider.msg.yahoo.com server name sip.yahoo.com fw#show parameter-map type protocol-info dns-cache zone-pair InsideToOutside Application im-yahoo. Server DNS Name: 'scs.msg.yahoo.com'. Updates: 0 failed, 328 succeeded, next after 5.866 secs Number of IP Addresses: 8 216.155.193.138 (0D:00H:00M) 216.155.193.139 (0D:00H:00M) 216.155.193.140 (0D:00H:00M) 216.155.193.141 (0D:00H:00M) 216.155.193.142 (0D:00H:00M) 216.155.193.143 (0D:00H:00M) 216.155.193.136 (0D:00H:00M) 216.155.193.137 (0D:00H:00M) Application im-yahoo. Server DNS Name: 'insider.msg.yahoo.com'. Updates: 0 failed, 17 succeeded, next after 0.942 secs Number of IP Addresses: 2 68.142.194.14, 68.142.231.252 (0D:00H:00M) Application im-yahoo. Server DNS Name: 'sip.yahoo.com'. Updates: 0 failed, 2 succeeded, next after 3.086 secs Number of IP Addresses: 8 68.142.233.179 (0D:00H:00M) 68.142.233.180 (0D:00H:00M) 68.142.233.181 (0D:00H:00M) 68.142.233.182 (0D:00H:00M) 68.142.233.183 (0D:00H:00M) 68.142.233.176 (0D:00H:00M) 68.142.233.177 (0D:00H:00M) 68.142.233.178 (0D:00H:00M)
In addition to the transport layer stateful inspection (which, for protocols with separate control and data sessions such as FTP and H.323, includes some processing of an application data stream), the zone-based policy firewall feature supports application layer inspection (also called deep packet inspection [DPI]) of several popular protocols, including the following:
Internet Mail Access Protocol (IMAP) and Post Office Protocol (POP). You can check whether the users are trying to use cleartext authorization.
Simple Mail Transfer Protocol (SMTP). You can check maximum message length.
Sun Remote Procedure Call (SUNRPC). You can block access to specific programs over the RPC mechanism.
Peer-to-peer applications (eDonkey, FastTrack, Gnutella, and Kazaa). You can match and block transfer of files matching the specified regular expression.
Instant messaging (AOL, MSN, Yahoo!). You can block the entire messaging service or just the text chat within it.
Hypertext Transport Protocol (HTTP). You can match on a large number of parameters, including web address (Universal Resource Locator [URL]), content type, or any other component of the HTTP request or response header. You can also identify applications misusing HTTP for tunneling, instant messaging, or peer-to-peer applications.
All application layer inspections are configured using application-specific class maps and policy maps that are then attached with the service-policy command as children of Layer 4 policy maps.
Application-specific class maps are configured with the class-map type inspect protocol name configuration command. The list of protocols supported is displayed in Listing 5-11.
Example 5-11. Application Layer Protocol Inspection in Cisco IOS Release 12.4(9)T
fw(config)#class-map type inspect ?
WORD class-map name
aol Configure CBAC class-map for IM-AOL protocol
edonkey eDonkey
fasttrack FastTrack Traffic - KaZaA, Morpheus, Grokster...
gnutella Gnutella Version2 Traffic - BearShare, Shareeza, Morpheus ...
http Configure CBAC class-map for HTTP protocol
imap Configure CBAC class-map for IMAP protocol
kazaa2 Kazaa Version 2
match-all Logical-AND all matching statements under this classmap
match-any Logical-OR all matching statements under this classmap
msnmsgr Configure CBAC class-map for IM-MSN protocol
pop3 Configure CBAC class-map for POP3 protocol
smtp Configure CBAC class-map for SMTP protocol
sunrpc Configure CBAC class-map for RPC protocol
ymsgr Configure CBAC class-map for IM-YAHOO protocol
Note
The match commands available in the class map configuration are protocol-specific; you can find a detailed list in the Cisco IOS documentation. The extensive set of HTTP match commands is described in the next section.
Within each class map definition, you can use the match commands to match supported features of the protocol. After the class maps have been defined, you can configure the application-specific policy maps with the policy-map type inspect application name command. The set of applications is a bit shorter (see Listing 5-12) because you can use any instant-messaging class-map (aol, msnmsgr, and ymsgr) in im policy-map and similarly any peer-to-peer class map (edonkey, fasttrack, gnutella) in p2p policy-map. For all other protocols, the type of the class-map has to match the type of the policy map within which it’s used.
Example 5-12. Configuring the Application Layer Policy Map
fw(config)#policy-map type inspect ?
WORD policy-map name
http Configure CBAC policy-map for HTTP protocol
im Configure CBAC policy-map for IM protocol
imap Configure CBAC policy-map for IMAP protocol
p2p Configure CBAC policy-map for P2P protocols
pop3 Configure CBAC policy-map for POP3 protocol
smtp Configure CBAC policy-map for SMTP protocol
sunrpc Configure CBAC policy-map for RPC protocol
Note
Not all the actions are available in all policy maps. The allow action is not available in IMAP and POP3 policy maps, and the reset action is not available in the SUNRPC policy map (because you cannot reset a UDP connection).
Within application layer policy maps, you can use the following actions:
log—. Logs the session
allow—. Allows the traffic matching the class map
reset—. Resets the connection
After the application layer policy maps are configured, you can attach them as a service policy to existing traffic classes in the Layer 4 policy maps.
Note
Some of these issues could be solved with other mechanisms. For example, peer-to-peer services could be prohibited, and secure POP3 and IMAP could be deployed instead of forcing the users to use non-clear-text authentication on regular POP3/IMAP sessions.
Let’s illustrate these concepts with an example. We’ll use the very simple LAN-to-Internet firewall from Chapter 3 “Configuring Zone-Based Policy Firewalls in Cisco IOS,”, where there were no restrictions on traffic from inside clients to outside server. To control the Internet access link utilization, the IT manager would like to prevent download of MP3 files with peer-to-peer services and limit the size of e-mails the users can send. Furthermore, because the e-mail is hosted on external servers, the users shall be forced to use non-clear-text authentication methods to prevent a potential intruder or an external wiretap from collecting the passwords (Figure 5-3).
To implement these requirements, a large number of class maps and policy maps must be configured:
A class map and a policy map have to be configured for POP3, IMAP, and SMTP DPI (Listing 5-13).
Four class maps must be configured to cover all four supported peer-to-peer services together with a P2P policy map (Listing 5-14).
Inspect class maps have to be configured to match individual protocols for which we want to perform DPI (Listing 5-15).
Finally, a policy map (InsideToOutside) is configured tying together all the previously configured objects (Listing 5-16). From there onward, use the remainder of the configuration from the beginning of Chapter 3.
Example 5-13. Application-Level Inspection of E-mail–Related Protocols
class-map type inspect imap match-any imapMail match invalid-command match login clear-text ! policy-map type inspect imap imapPolicy class type inspect imap imapMail log reset ! class-map type inspect pop3 match-any pop3Mail match invalid-command match login clear-text ! policy-map type inspect pop3 pop3Policy class type inspect pop3 pop3Mail reset log ! class-map type inspect smtp match-any smtpMail match data-length gt 5000000 ! policy-map type inspect smtp smtpPolicy class type inspect smtp smtpMail reset
Example 5-14. Application-Level Inspection of Peer-to-Peer Traffic
class-map type inspect gnutella match-any noMP3gnutella match file-transfer mp3 ! class-map type inspect fasttrack match-any noMP3fasttrack match file-transfer mp3 ! class-map type inspect edonkey match-any noMP3edonkey match file-transfer mp3 match search-file-name mp3 ! class-map type inspect kazaa2 match-any noMP3kazaa match file-transfer mp3 ! policy-map type inspect p2p noMP3transfer class type inspect edonkey noMP3edonkey log reset class type inspect fasttrack noMP3fasttrack log reset class type inspect gnutella noMP3gnutella log reset class type inspect kazaa2 noMP3kazaa log reset
Example 5-15. Class Maps Matching Individual Deeply Inspected Application Protocols
class-map type inspect match-any getMail match protocol pop3 class-map type inspect match-any sendMail match protocol smtp extended class-map type inspect match-any readMail match protocol imap class-map type inspect match-any peer2peer match protocol gnutella signature match protocol edonkey signature match protocol kazaa2 signature match protocol fasttrack signature
Example 5-16. Inside-to-Outside Firewall Policy
policy-map type inspect InsideToOutside class type inspect peer2peer inspect service-policy p2p noMP3transfer class type inspect getMail inspect service-policy pop3 pop3Policy class type inspect readMail inspect service-policy imap imapPolicy class type inspect sendMail inspect service-policy smtp smtpPolicy class class-default inspect
Cisco IOS Firewall software offers only rudimentary packet-matching features for most protocols for which deep packet inspection is supported. Hypertext Transfer Protocol (HTTP), the protocol used to exchange content between the web server and its clients, is a notable exception. You can use a number of different match conditions (introduced in Cisco IOS Release 12.3(14)T with the HTTP Application Inspection Engine) to classify the web traffic, from extremely helpful ones (identifying HTTP misuse for unauthorized traffic) to arcane ones (for example, the number of header fields in the request or response header).
Note
HTTP packet inspection works only on non-encrypted HTTP sessions. If the data exchange takes place over Secure Sockets Layer (SSL, also known as HTTPS), the firewall cannot inspect the packet content.
HTTP packet inspection is configured using the same configuration syntax as any other DPI:
The class-map type inspect http name command is used to define traffic classes.
The policy-map type inspect http name command defines the HTTP inspection policy. You can use allow, reset, and log action commands within it.
The HTTP inspection policy is attached to a class within a type inspect policy map with the service-policy http name command. The class within which service-policy http is configured can match only the HTTP packets (and it has to match them with the match protocol http command).
The match commands that you can use in the class-map type inspect http command follow these rules:
You can match on a condition in the HTTP request only (match request …), in the HTTP reply only (match reply …), or in request or reply (match req-resp …).
You can match the fields in the HTTP request or response header (match … header) or body (match … body).
You can match header or body length (match … length gt size or match … length lt size) or inspect its contents and match it with a regular expression (match … regex parameter-name).
You can also test individual fields in the request or response header, comparing them with a regular expression (match … header fieldname regex parameter-name), checking whether the response values match the request values, or checking for potential protocol violations.
Finally, several generic match commands are listed in Table 5-4.
Table 5-4. Matching HTTP Requests and Responses
Command Syntax | Description |
|---|---|
match request uri regex name | Matches the web address (URI) with a regular expression |
match request arg regex name | Matches the HTTP request arguments with a regular expression |
match request method http-method-name | Matches the HTTP method in the request (GET, POST …) |
match request port-misuse im | p2p | tunneling | any | Identifies potential misuses of HTTP by tunneling, peer-to-peer, or instant-messaging applications |
match response status-line regex name | Matches the status of the HTTP response (for example, 200 = OK, 403 = forbidden, 404 = not found) |
Contrary to many other Cisco IOS features where you just enter the regular expression you need, the HTTP-specific match commands use a new object named regex parameter-map, which is configured with the commands in Table 5-5.
The extensive set of match commands would let you believe that you can easily match almost any web-related condition on the firewall. The reality is a bit different due to very limited syntax of the class-map and policy-map commands:
Hierarchical HTTP-specific class maps are not supported. You can thus only match on all conditions (match-all) or any of them (match-any). There is no mechanism to build more complex logical expressions with the class maps.
Negation in a class map is not supported. It’s thus impossible to identify an HTTP request not matching a condition.
You cannot attach an action to the class-default of the HTTP-specific policy map. You are thus forced to define a bogus match-all class to be able to attach an action to it.
Effectively, the configuration syntax only allows you to specify a logical condition that is an OR of multiple conditions, each of those being an OR or an AND of the various match conditions.
Consider, for example, the simple LAN-to-Internet firewall with no traffic restrictions (from Chapter 3) that was improved in the previous section (Figure 5-3). Now the IT manager would like to implement a simple HTTP inspection policy: HTTP misuses and uncommon HTTP commands (anything but GET, POST, and HEAD) shall be denied. To configure this requirement, you have to perform the following configuration steps (final configuration is in Listing 5-17):
class-map validHttpCommands is defined to match all allowed HTTP request methods.
class-map httpPortMisuse is defined to match any misuses of TCP port 80.
class-map anyOtherHttp matches all HTTP traffic, effectively replacing the class-default.
policy-map validHttp defines the HTTP inspection policy. The TCP session is reset when a port misuse is detected or when the HTTP request method does not match one of the allowed methods.
A new inspect class-map is defined to match the HTTP traffic and is appended at the end of the existing InsideToOutside policy map (just in front of the class-default line).
Note
Adding an unrelated condition (for example, allowing only the three request methods and only the content types text/* and image/*) would result in a large set of class maps and a complex policy map, because you would have to match each combination of method and content type individually with a separate match-all class map and then list all of them in the policy map.
Example 5-17. Implementing Simple HTTP Inspection
class-map type inspect http match-any validHttpCommands match request method get match request method post match request method head ! class-map type inspect http match-any httpPortMisuse match request port-misuse any ! class-map type inspect http match-any anyOtherHttp ! policy-map type inspect http validHttp class type inspect http httpPortMisuse reset log class type inspect http validHttpCommands allow class type inspect http anyOtherHttp reset ! class-map type inspect match-any httpTraffic match protocol http ! policy-map type inspect InsideToOutside class type inspect httpTraffic inspect service-policy http validHttp
In many firewall scenarios, you have to identify nonstandard protocols (or protocols not yet recognized by Cisco IOS) or standard protocols operating on nonstandard port numbers. A common requirement is the support for HTTP proxy servers, which usually operate on TCP port 8080. For example, to implement a firewall with proxy server in the perimeter network, the firewall policy configuration shall allow TCP sessions to port 8080 of the proxy server (Figure 5-4).
You could solve this challenge with existing configuration commands by defining an extended IP access list and a class map based on the access list (similar to how we’ve recognized ICMP echo packets in previous configurations), or you could define a user-defined protocol with the ip port-map command (see the syntax in Table 5-6).
Table 5-6. Defining Nonstandard TCP or UDP Port Use
Command Syntax | Description |
|---|---|
ip port-map user- protocol-name port {tcp | udp} port-number | Specifies port usage for a user-defined protocol. The protocol name must start with the user- prefix to ensure there is no overlap with future protocol additions to Cisco IOS. |
ip port-map protocol port {tcp | udp} port-number | Specifies a nonstandard TCP or UDP port for a protocol recognized by Cisco IOS. |
In the sample firewall, you could define your own protocol on TCP port 8080 and use it in a class map in a configuration similar to the one in Listing 5-18.
Example 5-18. Configuring a User-Defined Protocol
ip port-map user-proxyhttp port tcp 8080 ! class-map type inspect match-all proxyhttp match protocol user-proxyhttp ! policy-map type inspect InsideToPerimeter class type inspect proxyhttp ! matches TCP port 8080 inspect ! cannot use HTTP service policy class type inspect ping inspect
When you define your own protocol, you cannot use extended features Cisco IOS supports for standard protocols. For example, if you configure FTP on a nonstandard port as a user-defined protocol, Cisco IOS will not recognize its data sessions. You also cannot use DPI for a user-defined protocol. In both cases, specifying additional port numbers for standard protocols is preferred. So, if you want to use DPI of requests made from inside clients to the proxy server, you should define an additional port for the HTTP protocol (Listing 5-19).
Example 5-19. Configuring Additional Port Numbers for a Standard Protocol
ip port-map http port tcp 8080 ! class-map type inspect match-all web match protocol http ! policy-map type inspect InsideToPerimeter class type inspect web ! matches TCP port 80 and port 8080 inspect ! can use HTTP service policy class type inspect ping inspect
Note
Adding TCP or UDP ports to standard protocols with the ip port-map command affects other Cisco IOS features that use the port map functionality (for example, Network-Based Application Recognition [NBAR]).
After you define additional port numbers for standard protocols, any match protocol command will match these port numbers as well. If you want to limit a traffic class to the standard port number (for example, when matching inbound traffic for the public web server), you have to combine the match protocol command with an access list (Listing 5-20).
In this chapter, you’ve seen how you can use advanced configuration commands of the zone-based policy firewall configuration to do the following:
Generate an audit log of inspected sessions with a parameter-map type inspect containing the audit on parameter.
Configure DoS-prevention parameters with a parameter map.
Identify peer-to-peer and instant-messaging applications even when they use port numbers reserved for other applications.
Configure firewall policies for POP3, IMAP, SMTP, HTTP, peer-to-peer, and instant-messaging applications.
Configure user-defined protocols or add nonstandard TCP or UDP port numbers to protocols already recognized by Cisco IOS with the ip port-map command.