.....update soon ......

---------------------------------------------------------------------------------------------------------

Chapter 7: Inspecting Traffic

Overview

Refer to the following sections for information about these topics:

7-1: Filtering Content— Covers third-party web content-filtering applications you can use to control outbound access through a firewall.
7-2: Defining Security Policies in a Modular Policy Framework— Explains the modular approach to configuring and enforcing security policies. Traffic can be matched with one type of policy module and acted on within another policy module. The whole hierarchy of policies is then applied to firewall interfaces and traffic inspection.
7-3: Application Inspection— Provides an overview of the mechanisms a Cisco firewall uses to inspect specific application traffic. Some applications embed information about their connections within normal UDP or TCP traffic, requiring additional inspection by the firewall.

A firewall maintains the state of connections passing through it to provide effective security. Connection state involves parameters such as address translation, connection direction and flow, and limits on the connection itself. In addition, a firewall must be able to inspect various protocols as they pass through, so that the protocols themselves meet criteria defined in the security policies.

This chapter covers the tools and features you can use to gain a more thorough inspection of traffic content. Your firewall can filter traffic based on its content, inspect traffic based on a hierarchical policy definition, and inspect many application layer protocols.

7-1: Filtering Content

A firewall normally allows outbound HTTP or HTTPS connections to any URL, provided that the outbound access list permits the connection. An audit trail of URL activity is available only through the firewall Syslog records, using Syslog message 304001 at the default severity level, 5 (notifications).

Cisco firewalls can use third-party web content-filtering applications to enforce URL policies. These content filters run on a local server but download periodic updates of web content databases. Web content is categorized, and content rules can be applied to corporate users or groups of users.

When a user sends a URL request, the firewall relays the request to the content-filtering server. If the server determines that the user is allowed to view the URL and its content, the firewall permits the connection to proceed.

If the content-filtering server denies the URL request, the firewall redirects the user’s browser to a “block” page, indicating that the server blocked or denied the request.

The content-filtering server can apply its policies on a per-user basis if necessary. It obtains the user’s credentials (username, IP address, destination URL, and address) directly from the user’s host PC. This also provides an accounting log of user activity.

The following commercial content-filtering applications are compatible with Cisco firewalls:

N2H2 (http://www.n2h2.com)
Websense (http://www.websense.com)

Configuring Content Filters

You can use the following steps to configure content filtering on a Cisco firewall. The command syntax is basically the same across the FWSM, PIX, and ASA platforms, so only a single syntax form is shown for each command.

Tip

Content filtering is triggered by the HTTP inspection engine, which must be enabled before any content servers can be contacted. If you are about to configure content filtering, make sure you have the fixup protocol http (PIX 6.x) or inspect http (ASA and FWSM) command in the running configuration.

Likewise, if this command is disabled, Websense and N2H2 content filtering is disabled too.

Identify the filter servers:
```
Firewall(config)# url-server [(if_name)] vendor n2h2 host local_ip
[port number] [timeout seconds] [protocol {tcp | udp}]
```
or
```
Firewall(config)# url-server [(if_name)] vendor websense host local_ip
[timeout seconds] [protocol {tcp | udp} version]
```
The filtering server is located on the firewall interface named (if_name) (the parentheses must be included) at the IP address local_ip. By default, the inside interface is assumed. For security best practice, the server should not be located on the outside or a public interface.

By default, N2H2 uses TCP/UDP port 4005 to filter information exchanges. You can specify a nondefault port number with the port keyword.

You can repeat this command to define up to 16 servers using the same filtering software. The firewall waits until a timeout period of seconds expires (the default is 5 seconds) if a filtering server does not respond. In that case, the same request is sent to the next server configured.

TCP connections are used by default for both N2H2 and Websense servers. You can use either tcp or udp, depending on your requirements. Websense also allows a software version to be specified: 1 (using TCP or UDP) or 4 (using UDP only).

In ASA and FWSM, you can add connections num_conns after the tcp keyword. This limits the number of simultaneous TCP connections the firewall can open to the content filter server to num_conns (1 to 100; the default is 5).
Define a filtering policy:
```
Firewall(config)# filter url [http | port[-port]] local_ip local_mask
foreign_ip foreign_mask [allow] [proxy-block] [longurl-truncate |
longurl-deny] [cgi-truncate]
```
You can define one or more broad filtering policies with this command and then make specific exceptions in the next step. Web traffic is defined as http (port 80), port (a single port number), or port-port, a range of ports.

You can provide the local (source) and foreign (destination) IP addresses and subnet masks. When web clients using local addresses send HTTP requests to web servers with foreign addresses, those requests are subject to filtering. In most cases, you can define the policy to use any local address and any foreign address. To do this, specify the local and foreign values as 0s (0 0 0 0).

For example, you could use the following command to filter the content of HTTP connections from inside hosts on the 192.168.100.0/24 subnet destined for any outside address. Here, the “any” destination address is given as 0 0:
```
Firewall(config)# filter url http 192.168.100.0 255.255.255.0 0 0
```
By default, if none of the filtering servers is available, the HTTP requests are dropped. This assumes that the filtering policies must be strictly enforced, requiring filtering servers to make decisions at all times. If this is too restrictive for your environment, you can add the allow keyword so that HTTP requests are allowed by the firewall if no filtering servers respond.

To prevent web clients from using an HTTP proxy server to relay HTTP requests, add the proxy-block keyword.

You can also define how the firewall reacts when very long URLs (longer than the URL buffer defined in Step 7) are used in HTTP requests. The longurl-truncate keyword sends only the source address or host name to the filtering server. The longurl-deny keyword causes the firewall to reject the HTTP request directly, without consulting the filtering server. In the case of CGI scripts, the cgi-truncate keyword causes CGI scripts to be sent to the filtering server as regular URLs. In other words, the CGI portion of the original URL is removed from the filtering server’s decision process.
(Websense only) Define a filtering policy for HTTPS:
```
Firewall(config)# filter https dest-port local_ip local_mask foreign_ip
foreign_mask [allow]
```
You can also allow HTTPS traffic to be filtered by a Websense server. Identify the HTTPS port as dest-port (usually port 443). Connections that are subject to filtering have clients using local (source) addresses defined by local_ip and local_mask and web servers using foreign (destination) addresses defined by foreign_ip and foreign_mask.

Add the allow keyword if you want the firewall to go ahead and allow connections when all the Websense servers are unresponsive. Otherwise, HTTPS connections are dropped if they are not explicitly allowed by a filtering server.
(Websense only) Define a filtering policy for FTP:
```
Firewall(config)# filter ftp dest-port local_ip local_mask foreign_ip
foreign_mask [allow] [interact-block]
```
If you have a Websense server, you can filter FTP connections based on GET commands. The FTP port is given as dest-port (usually port 21).

Add the allow keyword if you want the firewall to allow FTP connections when all the Websense servers are unresponsive.

The interact-block keyword causes connections coming from interactive FTP clients to be rejected. In an interactive FTP client, a user can initiate the connection and then change directories at will. When files are requested from the FTP server, the full path name is not sent in the request. The filenames are relative to the current directory path, so the filtering server cannot correctly determine if the user is requesting something that should be denied.

For example, you could use the following command to require Websense approval for all FTP GET commands initiated through the firewall. Interactive FTP clients are blocked:
```
Firewall(config)# filter ftp 21 0 0 0 0 allow interact-block
```
Make exceptions to the filtering policy:
```
Firewall(config)# filter {url | https | ftp} except local_ip local_mask
foreign_ip foreign_mask
```
You might have some web clients, users, or automated processes that need to send different types of requests without a filtering server’s inspection or intervention. You can define exceptions to the overall filtering policy by giving the protocol (url, https, or ftp), as well as the local (source) and foreign (destination) addresses and subnet masks.

Clients using a matching local address are allowed to complete a transaction with a server using a matching foreign address. You can use 0 to indicate an “any” or wildcard-matching condition for any of the address and mask values.

For example, inside host 10.10.1.100 and hosts on the entire 10.10.2.0/24 subnet should be exempt from HTTP (URL) filtering. Inside host 10.10.3.14 also should be exempt from FTP filtering. You could use the following commands to accomplish this:
```
Firewall(config)# filter url except 10.10.1.100 255.255.255.255 0 0
Firewall(config)# filter url except 10.10.2.0 255.255.255.0 0 0
Firewall(config)# filter ftp except 10.10.3.14 255.255.255.255 0 0
```
(Optional) Use an HTTP response buffer to return web content faster:
```
Firewall(config)# url-block block block_buffer_limit
```
When a web client requests web content from a foreign site, the firewall relays the request toward the website and sends a request to the filtering server—all in parallel. By default, if the web server responds before the filtering server, the content is dropped at the firewall. If the filtering server responds first with its permission data, the web content is allowed through when it arrives.

You can use an HTTP response buffer in the firewall to store web content until the filtering server has time to respond. As soon as the server approves the URL for the web client, the buffered contents are read and relayed to the client.

The HTTP response buffer can be enabled to store up to block_buffer_limit (0 to 128) 1550-byte blocks in memory.
(Optional; Websense only) Adjust the maximum acceptable URL length.
1. Buffer URLs before sending Websense requests:
```
Firewall(config)# url-block url-mempool memory_pool_size
```
  By default, a firewall accepts URLs that are up to 1159 bytes long before sending a request to either Websense or N2H2. You can adjust the URL buffer so that several large URLs can be gathered and sent to a Websense server. The URL buffer limit can be set to memory_pool_size (2 to 10240 kilobytes).
2. Set the maximum acceptable URL length:
```
Firewall(config)# url-block url-size long_url_size
```
  To allow URLs longer than 1159 bytes to be sent to a Websense server, set the URL length to long_url_size (2, 3, or 4 kilobytes). You need to adjust this limit only if you have cases in which very long URLs (greater than 1159 bytes) are being rejected.

(Optional) Use a cache to store filtering permissions:

Firewall(config)# url-cache {dst | src_dst} kbytes

As a firewall sends requests to a filtering server, it can also cache the results that are returned. For subsequent requests for the same web client and target website, the firewall can quickly retrieve the cached permissions rather than waiting for the filtering server to respond again.

By default, the URL cache is disabled. The firewall sends each request to the filtering server and waits for each response before passing the return web content.

You can use the dst keyword to cache permission results based on the URL destination address only. If every web client behind the firewall shares the same policy on the filtering server, there is no need to cache the source information too. If web clients have different policies on the filtering server, you should use the src_dst keyword to gather source and destination information in the cache.

You can also set the size of the URL cache to kbytes (1 to 128 kilobytes).

Tip

During normal requests to the filtering server, the server keeps a record of user activity in its accounting logs. When a URL cache is used (except with Websense version 1), these logs can still be collected, because the firewall still sends each request to the server, even though it might have a matching entry in its cache. The filtering requests and cache lookups happen in parallel so that a cache hit produces a quick permission result. In this case, any reply from the server is simply dropped. If an entry is not in the cache, no time is wasted, because the filtering server will have already sent a reply.

You can monitor the status of the URL cache with the show url-cache statistics command. If the cache is performing efficiently, you should see a large percentage of hits in relation to the number of lookups.

For example, the following output shows that 432 URL lookups occurred; 396 of those resulted in a cache hit, where the result was already in the cache. This represents a high hit percentage, indicating that the cache is doing its job.

Firewall# show url-cache statistics
URL Filter Cache Stats
----------------------
  Size :      128KB
Entries :      219
In Use :      105
Lookups :      432
   Hits :      396
Firewall#

(Optional) Filter ActiveX content:
```
Firewall(config)# filter activex {port[-port] | except}local_ip local_mask
foreign_ip foreign_mask
```
ActiveX objects that are found on connections using destination port number port (or a range of ports port-port) are subject to being blocked by the firewall. The connections must be initiated by clients using matching local (source) addresses toward servers using matching foreign (destination) addresses. You can substitute 0s as a wildcard “any” for any address or mask field.

The firewall blocks ActiveX objects by looking for the HTML tags. The tags are commented out before the content is forwarded to the client. The client cannot interpret the result as a valid ActiveX object. Nested objects are also blocked, because the first-level objects are commented out.

You can also use the except keyword to define address pairs where ActiveX filtering should not be performed.
(Optional) Filter Java content:
```
Firewall(config)# filter java {port[-port] | except} local_ip mask
foreign_ip mask
```
Java applets that are found on connections using destination port number port (or a range of ports port-port) are subject to being blocked by the firewall. The connections must be initiated by clients using matching local (source) addresses toward servers using matching foreign (destination) addresses. You can substitute 0s as a wildcard “any” for any address or mask field.

The firewall blocks Java objects by looking for the HTML and tags. The tags are commented out before the content is forwarded to the client.

You can also use the except keyword to define address pairs where Java filtering should not be performed.

Tip

You can monitor the performance of the URL buffer with the show url-block block stats command, as in the following example:

Firewall# show url-block block stats
URL Pending Packet Buffer Stats with max block  0
-----------------------------------------------------
Cumulative number of packets held:              0
Maximum number of packets held (per URL):       0
Current number of packets held (global):        0
Packets dropped due to
     exceeding url-block buffer limit:        0
     HTTP server retransmission:              0
Number of packets released back to client:      0
Firewall#

If you are using content-filtering servers, you can monitor their activity with the show url-server stats (PIX 6.3) or show url-server statistics (ASA and FWSM) command. In the following example, two Websense servers are used. A total of 447,869 URL requests have been sent to the servers, 394,410 of those were permitted, and 53,459 of them were denied because of the local content policies configured on the servers. Notice that one server is up, but the other is unresponsive.

Firewall# show url-server stats
URL Server Statistics:
----------------------
Vendor                           websense
URLs total/allowed/denied        447869/394410/53459
URL Server Status:
------------------
172.16.10.50              UP
172.16.10.55             DOWN

You can also get an idea about the rate at which the firewall is sending URL requests to the content-filtering servers. Use the show perfmon command, and look for the URL Access row to see how many new URLs are being requested per second. The URL Server Req row shows the rate at which the requests are being sent to the content-filtering servers.

Firewall# show perfmon
PERFMON STATS:    Current      Average
Xlates              39/s          0/s
Connections        110/s          1/s
TCP Conns           80/s          0/s
UDP Conns           29/s          0/s
URL Access          57/s          0/s
URL Server Req      50/s          0/s
TCP Fixup         5033/s          0/s
TCPIntercept         0/s          0/s
HTTP Fixup        2293/s          0/s
FTP Fixup            4/s          0/s
AAA Authen           0/s          0/s
AAA Author           0/s          0/s
AAA Account          0/s          0/s
pix#

Content-Filtering Examples

A corporation has two Websense servers located on the firewall’s DMZ interface at 192.168.199.10 and 192.168.199.11. The firewall intercepts every HTTP request and relays them to the Websense servers. If neither server responds within the default 5-second period (for each server), the firewall allows the request.

The only exceptions to this policy are with all hosts on the 192.168.4.0/24 subnet, which are allowed to request any URL with no Websense intervention. Inside host 192.168.7.33 is allowed to request any URL as well. Inside host 192.168.7.40 is allowed to request URLs from outside server 172.24.1.10 without Websense intervention. If the inside host requests URLs from any other address, Websense is consulted.

All HTTPS and FTP requests are subject to the local Websense server policies.

To improve filtering server response, 128 blocks of memory are dedicated to buffering web content that arrives before the filtering server can respond. A cache is also configured so that repeated URL requests can be serviced immediately without waiting for further filtering server replies. This cache uses 128 KB of memory and is based on the source and destination address combinations.

The configuration for this example is as follows:

Firewall(config)# url-server (dmz) vendor websense host 192.168.199.10 protocol TCP
version 4
Firewall(config)# url-server (dmz) vendor websense host 192.168.199.11 protocol TCP
version 4
Firewall(config)# filter url http 0 0 0 0 allow proxy-block
Firewall(config)# filter url except 192.168.4.0 255.255.255.0 0 0
Firewall(config)# filter url except 192.168.7.33 255.255.255.255 0 0
Firewall(config)# filter url except 192.168.7.40 255.255.255.255 172.24.1.10
255.255.255.255
Firewall(config)# filter https 443 0 0 0 0 allow
Firewall(config)# filter ftp 21 0 0 0 0 allow
Firewall(config)# url-block block 128
Firewall(config)# url-cache src_dst 128

Using a Web Cache for Better HTTP Performance

Beginning with ASA 7.2(1), an ASA platform can redirect inbound HTTP connections to an external web cache server if the web page has been accessed before. The Web Cache Communication Protocol version 2 (WCCPv2) is used to identify a request for a previously viewed web page and to redirect the client to the web cache server.

If a connection is redirected to the cache server, it bypasses some of the normal inspection processes such as URL filtering, TCP intercept, Intrusion Prevention System (IPS), and so on.

The client and the web cache server must be located on the same firewall interface for the WCCP redirect feature to work. As soon as the firewall redirects the client from the requested destination to the web cache server, the client can then communicate with the web cache server directly.

You can use the following steps to configure WCCP redirect:

Enable WCCP:
```
Firewall(config)# wccp {web-cache | service_number} [redirect-list access-list]
[group-list access-list] [password password]
```
WCCP can participate in the web cache service or in service group number service_number (0 to 255). You can repeat this command to identify more than one service number. To control the traffic that is redirected to the service group, configure an access list that permits traffic to be redirected. Then apply the access list here with the redirect-list keyword.

You can limit the web caches that can participate in the service group with the group-list keyword. The access list should permit cache IP addresses that are allowed to participate.

If your service group uses MD5 authentication, you can use the password keyword to define a password string of up to seven characters.

Enable WCCP redirection on an interface:

Firewall(config)# wccp interface interface_name service redirect in

7-2: Defining Security Policies in a Modular Policy Framework

Traditionally, Cisco firewalls have supported security policies that are applied to all traffic passing through them. Although that does offer a common level of security to all the protected networks and hosts, it does not offer a way to fine-tune or vary the policies according to differing requirements.

Beginning with ASA 7.0(1) and FWSM 3.1(1), a Cisco firewall can be configured to provide security policies that are tailored for various traffic types, quality of service (QoS), or inspection requirements. This is known as the modular policy framework (MPF).

With the MPF feature, you can define policies to identify a specific set of traffic and take any of the following actions on it:

Apply application inspection engines— You can tailor the stateful inspection process that is performed on a very specific type of traffic. Different sets of traffic can be inspected differently.
Set connection limits— The firewall can control the volume of UDP and TCP connections that are initiated for matched traffic.
Adjust TCP parameters— Values carried in the TCP header can be inspected, changed, or normalized in very specific ways. This can be done differently for each set of traffic identified.
Limit management traffic— Connections that terminate on the firewall itself can be limited, just like other types of connections that pass through the firewall. Configuring limits on management traffic can help prevent unnecessary strain on the firewall CPU.
Send traffic to a Security Services Module (SSM)— The ASA platform can divert specific traffic to an embedded Advanced Inspection and Prevention (AIP) module or an embedded Content Security and Control (CSC) module.
Limit the bandwidth used— You can tailor traffic policers to limit the bandwidth used by predefined sets of traffic. For example, mission-critical applications might be allowed to use any available bandwidth, whereas peer-to-peer file-sharing applications are limited to a small portion of interface bandwidth.
Provide priority handling— Specific types of traffic can be given priority over other types as packets are sent out a firewall interface. This allows time-critical applications to receive premium service as those packets are inspected and passed through the firewall.

As shown in Figure 7-1, you can configure security policies in a modular fashion. Traffic is classified according to an arbitrary type, and a policy can take some arbitrary action on it. The policy is actually carried out on a firewall interface or globally on all interfaces. This whole process is configured in scalable pieces, according to the following model:

Class map— A template that uses a match command to classify or identify types of traffic.
Policy map— A list of policies, each referencing a class map to match or identify traffic and an action to take on that traffic.
Service policy— A policy map is applied to one or all firewall interfaces, defining an entire set of match/action policies.

Figure 7-1: The Modular Policy Framework for Applying Security Policies

The Modular Policy Framework is a bit of a double-edged sword. On one hand, it is a very versatile means of defining robust security policies. On the other hand, it is so versatile that it can be confusing to configure.

As you begin to configure your security policies, you should outline the structure of the policy map as a list of the individual policies. Each policy needs a class map to identify the traffic and an action to perform on the traffic.

In a sense, you have to work backward first, because you need to configure class maps to identify traffic before the policy map can reference those class maps.

Classifying Layers 3 and 4 Traffic

As traffic moves through the firewall, it can be identified or classified according to the matching conditions defined in a class map. You can configure multiple class maps to identify several different classes of traffic, if needed. Then a different policy can be applied to each traffic class.

The following sections discuss how you can configure a class map for identifying a specific type of traffic according to parameters found in Layers 3 and 4, or the IP and UDP or TCP packet headers, respectively.

Tip

A class map can also match against other conditions that are based on parameters further inside an IP, UDP, or TCP packet. This type of class map is used in conjunction with application layer inspection policies and is discussed in Section “7-3: Application Inspection.”

The class map is defined and described by the following configuration commands. In addition, you add more commands to identify specific traffic, as described in the sections beginning with “Match Against...” that follow. Finally, the class map is used to identify traffic as part of the policy map configuration in the section titled “Defining a Layer 3/4 Policy.”

Define the class map:
```
Firewall(config)# class-map class_map_name
```
The class map is named class_map_name (an arbitrary string of up to 40 characters).

You can define only one matching condition in a class map. The only exceptions are match tunnel-group and match default-inspection-traffic, which are described in further detail in the “Match Against a VPN Tunnel Group” and “Match Default Traffic” sections, respectively.

After creating a class map, you can change its name without deleting it and reconfiguring it. To do this, use the following command while in class map configuration mode:
```
Firewall(config-cmap)# rename name
```
(Optional) Add a description to the class map:
```
Firewall(config-cmap)# description text
```
You can add a string of descriptive text (up to 200 characters) to a class map. This description can help firewall administrators identify or understand the class map’s purpose.

Match Against a Destination Port Number

You can set up a class map to examine the destination TCP or UDP port in IP packets moving into or out of a firewall interface. Use the following command to set up the matching condition:

Firewall(config-cmap)# match port {tcp | udp} {eq port | range start end}

The matching protocol is either tcp or udp. You can define an exact match with the eq keyword as port, either a supported keyword or a decimal number 1 through 65535. Otherwise, you can use the range keyword to define a match against a range of port values, from start to end.

For example, the following commands define class maps that match HTTP and SIP traffic, respectively:

Firewall(config)# class-map class_http
Firewall(config-cmap)# match port tcp eq http
Firewall(config-cmap)# exit
Firewall(config)# class-map class_sip
Firewall(config-cmap)# match port udp eq sip
Firewall(config-cmap)# exit

Match Against an Access List

You can use the access list to match several different protocols, ports, or address pairs. This is a convenient way to classify disparate types of traffic into a single class that ultimately has an action applied. The following steps show how to configure and then apply an access list in a class map.

Define the access list:

Firewall(config)# access-list acl_id [line line-num] [extended]
 {permit | deny} {protocol | object-group protocol_obj_group}
 {source_addr source_mask | object-group network_obj_group}
 [operator sport | object-group service_obj_group]
   {destination_addr destination_mask | object-group network_obj_group}
 [operator dport | object-group service_obj_group]
 [time-range name]

Any traffic that matches a permit statement in the access list becomes matched traffic in the class map. You can have deny statements in the access list, but they never result in a match for the class map.

Section “6-3: Controlling Access with Access Lists” in Chapter 6, “Controlling Access Through the Firewall,” covers access list configuration in detail.

Tip

If you need to match against source and/or destination addresses in the access list, you need to consider any address translations that are occurring. Specify IP addresses with the values they will have after address translation. In other words, the match operation in a class map is handled after any relevant address translations.

For example, suppose a static NAT entry is configured so that inside host 192.168.198.17 appears as 128.163.93.134 on the outside. If an access list is used to match inbound traffic to that host, the inside or local address (after translation) should be specified, as demonstrated here:

Firewall(config)# static (inside,outside) 128.163.93.134 192.
168.198.17 netmask 255.255.255.255 0 0
Firewall(config)# access-list test extended permit tcp any host
192.168.198.17 eq http
Firewall(config)# class-map test_class
Firewall(config-cmap)# match access-list test

Apply the access list as the matching condition:

Firewall(config-cmap)# match access-list acl_name

The access list named acl_name is used as a template to match traffic. Only one access list can be defined for matching in a class map.

For example, the following commands enable a single class map and match command to match several different types of traffic:

Firewall(config)# access-list MyTraffic extended permit tcp any
any eq http
Firewall(config)# access-list MyTraffic extended permit tcp any
any eq https
Firewall(config)# access-list MyTraffic extended permit tcp any
any eq 8080
Firewall(config)# class-map MyClass
Firewall(config-cmap)# match access-list MyTraffic

Match Against QoS Parameters

Quality of service (QoS) is a device’s capability to forward packets in an efficient, predictable, and reliable manner. Some types of traffic, such as voice and video applications, require data to be delivered without delay and without jitter (variations in delay).

In releases before ASA 7.0(1), a firewall could handle traffic only on a “best-effort” basis, in which packets were inspected and forwarded in the order in which they were received. Beginning with ASA 7.0(1), a firewall can classify packets and place them in a priority queue. This interface queue is serviced ahead of any other queue so that any priority packets are sent first.

You can use class maps to match against two types of QoS parameters: IP Precedence and Differentiated Services Code Point (DSCP). These values are included in every IP packet header. They indicate the QoS level that is needed for each packet’s delivery. IP Precedence is included in the type of service (ToS) byte.

ToS and DSCP are two different interpretations of the same 1-byte field in the IP header, as shown in Figure 7-2. Specifically, IP Precedence is a 3-bit value (P2 to P0), and DSCP is a 6-bit value (DS5 to DS0).

Figure 7-2: ToS and DSCP Byte Formats

The DSCP value is broken down into the following components:

Class selector (3 bits)— Classifies packets into eight classes: class 0 (best effort, the default), classes 1 through 4 (assured forwarding [AF]), class 5 (expedited forwarding [EF]), and classes 6 and 7 (used for network control traffic).
Drop precedence (3 bits)— Within a class, packets are marked according to the tolerance for being dropped: High (3), Medium (2), and Low (1). Packets with a lower drop precedence need better service.

When DSCP values are written as a codepoint name, the format is class (AF or EF), followed by the class level (1 to 4), followed by the drop precedence. For example, DSCP AF21 is assured forwarding class 2, drop precedence 1. The best-service value is EF, which has no class or drop precedence.

Table 7-1 compares the IP Precedence and DSCP fields with their possible values. You can use this table as a quick reference when defining or interpreting values from either field.

Table 7-1: Mapping of IP Precedence and DSCP Values
Open table as spreadsheet
IP Precedence (3 Bits)			DSCP (6 Bits)
Name	Value	Bits	Per-Hop Behavior	Class Selector	Drop Precedence	Codepoint Name	DSCP Bits (Decimal)
Routine	0	000	Default	—	—	Default	000 000 (0)
Priority	1	001	AF	1	1: Low 2: Medium 3: High	AF11 AF12 AF13	001 010 (10) 001 100 (12) 001 110 (14)
Immediate	2	010	AF	2	1: Low 2: Medium 3: High	AF21 AF22 AF23	010 010 (18) 010 100 (20) 010 110 (22)
Flash	3	011	AF	3	1: Low 2: Medium 3: High	AF31 AF32 AF33	011 010 (26) 011 100 (28) 011 110 (30)
Flash Override	4	100	AF	4	1: Low 2: Medium 3: High	AF41 AF42 AF43	100 010 (34) 100 100 (36) 100 110 (46)^[1]
Critical^[1]	5	101	EF	—	—	EF	101 110 (46)^[1]
Internetwork Control	6	110	—	—	—	—	(48 to 55)
Network Control	7	111	—	—	—	—	(56 to 63)
^[1]IP Precedence value 5 (DSCP EF) corresponds to the range of DSCP bits 101000 through 101111, or 40 through 47. However, only the value 101110 or 46 is commonly used and is given the EF designation.

You can use the following steps to configure a QoS parameter to match against. You can use either IP Precedence or DSCP values.

(Optional) Match against the IP Precedence value:
```
Firewall(config-cmap)# match precedence value1 [value2 [value3
[value4]]]
```
The IP precedence field in the ToS byte of the IP header is examined in each packet going into or out of a firewall interface. You can specify up to four different precedence values to match against. These can be given as any of the following decimal numbers or keywords: routine (0), priority (1), immediate (2), flash (3), flash-override (4), critical (5), internet (6), or network (7).

As a rule of thumb, a higher precedence means a better QoS should be used. IP precedence is usually set by the originating host, or it can be set or overridden by a router along the traffic path. In other words, before you can depend on matching an IP precedence value, you should be confident that some other device is setting the values properly.

For example, the following commands configure a class map that matches against the critical and flash-override values:
```
Firewall(config)# class-map high_precedence
Firewall(config-cmap)# match precedence 4 5
Firewall(config-cmap)# exit
```
(Optional) Match against the DSCP value:
```
Firewall(config-cmap)# match dscp value1 [value2 ...[value8]]
```
The DSCP value in the IP header is examined in each packet going into or out of a firewall interface. You can specify up to eight different DSCP values to match against. These can be given as a decimal number (0 to 63) or as one of the following keywords: default (0), cs1 (8), af11 (10), af12 (12), af13 (14), cs2 (16), af21 (18), af22 (20), af23 (22), cs3 (24), af31 (26), af32 (28), af33 (30), cs4 (32), af41 (34), af42 (36), af43 (38), cs5 (40), ef (46), cs6 (48), or cs7 (56).

DSCP is usually set by the originating host, or it can be set or overridden by a router along the traffic path. In other words, before you can depend on matching a certain DSCP value, you should be confident that some other device is setting the values properly.

For example, the following commands define class maps that match against the EF DSCP value and all AF4 values:
```
Firewall(config)# class-map dscp_ef
Firewall(config-cmap)# match dscp ef
Firewall(config-cmap)# exit
Firewall(config)# class-map dscp_af4
Firewall(config-cmap)# match dscp af41 af42 af43
Firewall(config-cmap)# exit
```

Match Against a Range of Real-Time Transport Protocol (RTP) Port Numbers

RTP is most often used for audio or video streams, where data is sent in one direction using a range of UDP port numbers. You can match RTP by defining the port range beginning at starting_port (2000 to 65535) and continuing for range (0 to 16383) ports with the following configuration command:

Firewall(config-cmap)# match rtp starting_port range

For example, to match against RTP ports 2000 through 2100, you could use the following commands:

Firewall(config)# class-map rtp
Firewall(config-cmap)# match rtp 2000 100
Firewall(config-cmap)# exit

Match Against a VPN Tunnel Group

If the firewall is configured to support and terminate Virtual Private Network (VPN) tunnels, you can match the traffic passing through a tunnel belonging to a specific tunnel group name. In this way, firewall service policies can be applied on a per-tunnel group basis:

Firewall(config-cmap)# match tunnel-group name

You can also add a second match condition to classify each traffic flow (connections using a common destination address) within a tunnel group:

Firewall(config-cmap)# match flow ip destination-address

This is most often used in conjunction with the police action in a policy map so that traffic flows to unique destination addresses within a tunnel group can be policed to a certain data rate.

Match All Traffic

All packets passing into or out of a firewall interface can be matched and identified with a class map. This is a handy way to subject all types of traffic to an action in a policy map. Use the following configuration command to match any traffic:

Firewall(config-cmap)# match any

Match Default Traffic

To perform the default application inspections, a firewall must first match the various traffic types. This command sets up this default arrangement by matching against predefined protocols and port numbers for the respective applications:

Firewall(config-cmap)# match default-inspection-traffic

This command is configured in the inspection_default class map as part of the default firewall configuration. See the section “Default Policy Definitions” for more details.

Classifying Management Traffic

Beginning with ASA 8.0(1), you can define a special “mananagement” class map type to match specific traffic that terminates on the firewall itself. For example, you might want to match against HTTP traffic so that you can limit the number of ASDM connections users can attempt to start.

By classifying management traffic as a special case, you can configure specific policies to help prevent denial-of-service attacks on the firewall itself. Otherwise, once you enable the firewall’s HTTP server to offer the ASDM management interface, malicious users might also make use of the HTTP service and perhaps cripple the firewall’s CPU.

You can define a management class map with the following configuration command:

Firewall(config)# class-map type management mgmt_cmap_name

Then define matching conditions that will identify the specific management traffic. You can match against an access list with the following commands:

Firewall(config-cmap)# match access-list acl_name

A previously configured access list will permit the management traffic so that it is matched here. The access list does not actually permit or deny the management traffic from reaching or being interpreted by the firewall—it is only used to match the management traffic for further handling.

You can also match against the TCP or UDP port numbers used in the management traffic with the following command:

Firewall(config-cmap)# match port {tcp | udp} {eq port_number | range low high}

The protocol is identified as tcp or udp. Use the eq keyword to give a specific port number, or the range keyword to give a range of port numbers (low to high). Port numbers can be any number 1-65535. You cannot use any other keywords that represent port numbers, such as www, ssh, and so on. Also, the port numbers represent the destination port for the management service that is running on the firewall.

You can repeat the match commands to define other management traffic that should be classified.

Once the management class map has been configured, you can reference it with the class command, as you would a normal Layer 3/4 class map. The only difference is that management traffic terminating on the firewall itself will be classified and handled as a unique policy, separate from any other regular traffic policy.

Defining a Layer 3/4 Policy

After Layer 3 or 4 traffic has been identified or classified, the firewall can take some action on it. You can define a policy map that contains one or more class maps, followed by an action for each. The entire policy map is then applied to one or all firewall interfaces, where the classifications and actions are carried out.

You can follow these steps to configure a policy map and apply it to a firewall interface:

Define a policy map:
```
Firewall(config)# policy-map policy_map_name
```
The policy map is named policy_map_name (an arbitrary string of up to 40 characters).

As soon as you create a policy map, you can change its name without deleting it and reconfiguring it. To do this, use the following command while in policy map configuration mode:
```
Firewall(config-pmap)# rename name
```
(Optional) Add a description to the policy map:
```
Firewall(config-pmap)# description text
```
You can add a string of descriptive text (up to 200 characters) to a policy map that can help firewall administrators identify or understand the policy map’s purpose.
Match traffic with a class map:
```
Firewall(config-pmap)# class {class_map_name | class-default}
```
You can specify the class map named class_map_name to identify a specific type of traffic. This can be a Layer 3/4 class map configured with the class-map cmap_name command, or a management class map configured with the class-map type management cmap_name command.

You also can use the class-default keyword to use the default class map. This is a handy way to identify all the traffic that has not been classified in any other class map. The class-default class map is automatically configured in a firewall by default, and it contains only the match any command. Therefore, this class map should be the last one defined in a policy.

For example, a class map named MyClass is configured and used in a policy map in the following commands:
```
Firewall(config)# class-map MyClass
Firewall(config-cmap)# match any
Firewall(config-cmap)# exit
Firewall(config)# policy-map MyPolicy
Firewall(config-pmap)# class MyClass
```

Take an action on the matched traffic.

After class maps are defined in a policy map, the policy map is applied to a firewall interface as a service policy, independent of traffic direction. In other words, traffic can be matched and acted on in a bidirectional manner, whether it is inbound or outbound. Some restrictions do apply, however.

Table 7-2 lists each policy map action according to its supported traffic direction. Policing and Low-Latency Queuing (LLQ) are typically techniques performed on packets that are leaving the firewall on an interface. Therefore, those two actions are unidirectional, in the outbound direction only.

Table 7-2: Policy Map Actions per Supported Traffic Direction
Open table as spreadsheet
Bidirectional Action	Unidirectional Action
Application inspection (inspect)	Policers (police)
Connection options (set connection)	Low-Latency Queuing (priority)
Intrusion Prevention System module (ips)	—
Content Security and Control module (csc)	—

You can configure one or more of the following actions to take on the matched traffic:

Inspect the traffic with an application inspection engine
Set connection limits
Adjust TCP options
Inspect the traffic with an Intrusion Prevention System (IPS) module (ASA platform only)
Inspect the traffic with a Content Security and Control (CSC) module (ASA platform only)
Police the traffic to a rate limit
Use LLQ for priority handling

These policy actions are discussed in the following sections.

Repeat Steps 3 and 4 to define other policies.
Apply the policy map as a service policy:
```
Firewall(config)# service-policy policy_map_name {global | interface if_name}
```
After you have finished adding class commands and their corresponding actions, you can apply the completed policy map so that it can be used.

The policy map named policy_map_name is applied as a service policy to one or more firewall interfaces. You can specify a single interface with the interface keyword and the interface name if_name (outside, for example). Only one policy map can be applied to a service policy, and only one service policy can be applied to an interface.

You can also use the global keyword to apply the service policy to all firewall interfaces simultaneously. You can configure only one global service policy. By default, only the global_policy policy map is applied globally.

Set Connection Limits on the Matched Traffic

You can configure one or more actions within a policy map to limit various aspects of TCP connections, as discussed in the following tasks:

Set TCP connection timeouts:

FWSM


Firewall(config-pmap-c)# set connection timeout [embryonic {hh:mm:ss |
0}] [half-closed {hh:mm:ss | 0}] [tcp {hh:mm:ss | 0}

ASA


Firewall(config-pmap-c)# set connection timeout [embryonic {hh:mm:ss |
0}] [half-closed {hh:mm:ss | 0}] [tcp {hh:mm:ss | 0} [dcd [retry_interval
[max_retries]]

Open table as spreadsheet

For matched packets, you can adjust the TCP connection timeout limits and set them as the appropriate conn entries are dynamically created.

Refer to Table 7-3 for each type of connection timeout and its associated keyword.

Table 7-3: TCP Connection Timeout Limit Options
Open table as spreadsheet
Description	Keyword for set connection timeout command	Timeout values
Automatically close embryonic (not completely opened) connections after a timeout	embryonic {hh:mm:ss \| 0}	Default: 30 seconds Minimum: 5 seconds
Automatically close half-closed (partially closed, or incomplete FIN-FIN handshake) connections after a timeout	half-closed {hh:mm:ss \| 0}	Default: 10 minutes Minimum: 5 minutes
Automatically close TCP connections that have been idle after a timeout	tcp {hh:mm:ss \| 0}	Default: 1 hour Minimum: 5 minutes
Use Dead Connection Detection (DCD) to probe for defunct idle connections	dcd [retry_interval [max_retries]]	retry_interval = 15 seconds max_retries = 5

In each case, the timeout value is set to hh:mm:ss (24-hour format) or 0 for unlimited time.

With the tcp keyword, the firewall identifies any TCP connection that has been idle for longer than the timeout value and automatically closes it. While this is a handy housekeeping function, it closes any TCP connection that has been idle more than a fixed amount of time.

Some TCP connections can remain idle for an extended period of time, but still be valid. For example, suppose the TCP idle timeout is set to 5 minutes. A Telnet session through the firewall to a host could very easily stay idle for more than 5 minutes, while the user answered a telephone call or got up to do something else. Closing idle, but valid, connections would become a nuisance to the end users.

Beginning with ASA 7.2(1), you can add the dcd keyword in conjunction with the tcp timeout function. After a TCP connection has been idle for the tcp timeout duration, the firewall begins to send probes to the client and server. The probes stimulate the hosts to answer; if they both answer, the connection must still be valid and should not be closed for being idle.

DCD probes are sent at retry_interval seconds. If no response is received, the probes are resent for max_retries times. If there still is no response at that point, the connection is presumed to be idle and is automatically closed.

Tip

What sort of probes does a firewall send for DCD? It sends a minimum size packet with the ACK bit set, using the same IP addresses and TCP ports that the actual TCP connection uses. In this way, the client and server each think it is simply answering a TCP ACK sent by its peer. No data changes hands, other than basic acknowledgments.

Set connection volume limits:

FWSM


Firewall(config-pmap-c)# set connection [conn-max n] [random-sequence-
number {enable | disable}]

ASA


Firewall(config-pmap-c)# set connection [conn-max n] [embryonic-conn-
max n] [per-client-embryonic-max n] [per-client-max n] [random-
sequence-number {enable | disable}]

Open table as spreadsheet

By default, an unlimited number of simultaneous UDP and TCP connections are allowed across an address translation. The set connection command can be used in a policy map to set connection limits on traffic to and from specific hosts.

The connection limits configured with set connection are very similar to the limits set in address translation commands such as static and nat. See “Handling Connections Through an Address Translation” in Section “6-2: Handling Connections Through an Address Translation” in Section “Routed Firewall Mode and Address Translation,” for more information.

Tip

If connection limits are configured in a policy map (set connection) and an address translation (static or nat), and a traffic flow applies to both conditions, the lower connection limit is enforced.

Refer to Table 7-4 for each type of connection limit and its associated keyword:

Table 7-4: Connection Limiting Options
Open table as spreadsheet
Description	Keyword for set connection command	Values
Limit the total simultaneous connections in use by all traffic matching the policy	conn-max n	Default: 0 (unlimited) Maximum: 65535
Limit the total number of embryonic connections opened for all traffic matching the policy	embryonic-conn-max n	Default: 0 (unlimited) Maximum: 65535
Limit the total number of embryonic connections opened on a per-client or host basis	per-client-embryonic-max n	Default: 0 (unlimited) Maximum: 65535
Limit the total number of simultaneous connections in use on a per-client or host basis	per-client-max n	Default: 0 (unlimited) Maximum: 65535
Assign a random initial sequence number (ISN) for each new TCP connection	random-sequence-generator {enable \| disable}	Default: enable

When the maximum number of connections is reached, the firewall begins dropping any new connections. As soon as one of the embryonic connection limits is reached, the firewall begins intercepting new connections and acting as a proxy for the connection target.

You can also use the random-sequence-generator keyword to enable or disable randomization of the initial sequence number (ISN) when TCP connections are established.

Tip

You can monitor the activity of set connection policy actions with the following command:

Firewall# show service-policy set connection

The following example shows the connection volume limits and timeout values that have been configured in a service policy named policy-outbound:

Firewall# show service-policy set connection
Global policy:
Service-policy: global_default
Interface outside:
Service-policy: policy-outbound
  Class-map: outbound
    Set connection policy: conn-max 100 embryonic-conn-max 10
      current embryonic conns 0, current conns 0, drop 0
      Set connection timeout policy:
      tcp 0:30:00
      DCD: enabled, retry-interval 0:01:0, max-retries 5
      DCD: client-probe 5, server-probe 5, conn-expiration 0
Firewall#

Adjust TCP Options for the Matched Traffic

You can define a TCP map that acts as a template for modifying various options in the TCP header of matched packets. Use the following configuration steps to create and use a TCP map:

Define the TCP map:
```
Firewall(config)# tcp-map tcp_map_name
```
The TCP map is given an arbitrary name tcp_map_name.

Use one or more of the commands listed in Table 7-5 to specify actions to take on the TCP header.

Table 7-5: TCP Header Actions
Open table as spreadsheet
Action Description	Command Syntax
Verifies that TCP retransmissions are consistent with the originals. Packets must arrive in sequential order.	Firewall(config-tcp-map)# check-retransmission
Verifies the TCP checksum and drops the packet if it fails.	Firewall(config-tcp-map)# checksum-verification
Takes action (the default is drop) if a packet’s maximum segment size (MSS) exceeds the value set when the TCP connection began.	Firewall(config-tcp-map)# exceed-mss {allow \| drop}
Takes action (the default is allow) on the reserved bits in the TCP header. This is a 3-bit field after the Data Offset field, which should always be cleared to 0.	Firewall(config-tcp-map)# reserved-bits {allow \| clear \| drop}
SYN packets are permitted to contain payload data, according to the TCP definition. By default, the firewall allows them. If end hosts cannot handle this properly, the firewall can drop those packets.	Firewall(config-tcp-map)# syn-data {allow \| drop}
Drops packets that masquerade as retransmissions of prior packets that passed inspection but were dropped because of time-to-live (TTL) expiration. (This is enabled by default.)	Firewall(config-tcp-map)# ttl-evasion-protection
Takes action (the default is clear) on the contents of the TCP URG (urgent) flag and pointer. URG can be used to request priority handling of a packet, but this is not well-defined.	Firewall(config-tcp-map)# urgent-flag {allow \| clear}
Takes action (the default is allow-connection) when the TCP window size is advertised as greatly disparate values for no apparent reason.	Firewall(config-tcp-map)# window-variation {allow-connection \| drop-connection}
Takes action (the default is allow) if Selective ACK (SACK, TCP option 4) is set.	Firewall(config-tcp-map)# tcp-options selective-ack {allow \| clear}
Takes action (the default is allow) if the time stamp (TCP option 8) is used. If clear is used, the Round-Trip Time Measurement (RTTM) and Protection Against Wrapped Sequences (PAWS) mechanisms are broken.	Firewall(config-tcp-map)# tcp-options timestamp {allow \| clear}
Takes action (the default is allow) if the window scale (TCP option 3) flag is set to expand the TCP window field from 16 to 32 bits.	Firewall(config-tcp-map)# tcp-options window-scale {allow \| clear}
Takes action on packets that use TCP option numbers within the range lower to upper. The lower and upper limit values can be 6, 7, or 9 to 255. TCP option 2 (MSS), option 3 (window scale), options 4 and 5 (SACK), and option 8 (time stamp) are not valid in this range because they are addressed with other tcp-options commands.	Firewall(config-tcp-map)# tcp-options range lower upper {allow \| clear \| drop}

If you have experimented with a command or its settings, you can use default command to set it back to its default configuration. For example, suppose you have entered the check-retransmission command but have decided to return the feature to its default state. Is the default on or off? No worries—just enter the following command to automatically choose the default:

Firewall(config-tcp-map)# default check-retransmission

End the TCP map configuration with the exit command.
Apply the TCP map as a template action with the following policy map configuration command:
```
Firewall(config-pmap-c)# set connection advanced-options tcp_map_name
```

Tip

You will not be able to move directly from the TCP map configuration mode into the policy map configuration mode. After you exit the TCP map configuration mode in Step 3, get back into the policy map configuration mode with the following commands:

Firewall(config)# policy-map policy_map_name
Firewall(config-pmap)# class class_map_name
Firewall(config-pmap-c)#

For example, a TCP map named conform_tcp is defined to drop TCP connections that try to use a nonzero value in the reserved bits field. As well, if TCP options 6, 7, or 9 through 255 are present, the connection is dropped.

You can use the following commands to accomplish this. Notice that to use the set connection advanced-options command in a policy map, you still have to configure a class map to match the relevant traffic. In this case, all TCP packets should be matched—something that can be done only by using an access list.

Firewall(config)# tcp-map conform_tcp
Firewall(config-tcp-map)# reserved-bits drop
Firewall(config-tcp-map)# tcp-options range 6 7 drop
Firewall(config-tcp-map)# tcp-options range 9 255 drop
Firewall(config-tcp-map)# exit
Firewall(config)# access-list acl_tcp permit tcp any any
Firewall(config)# class-map MyClass
Firewall(config-cmap)# match access-list acl_tcp
Firewall(config-cmap)# exit
Firewall(config)# policy-map MyPolicy
Firewall(config-pmap)# class MyClass
Firewall(config-pmap-c)# set connection advanced-options conform_tcp
Firewall(config-pmap-c)# exit
Firewall(config-pmap)# exit
Firewall(config)# service-policy MyPolicy interface outside

You can monitor the activity of any configured tcp-options policy commands with the following command:

Firewall# show service-policy set connection

In the following example, a TCP map named conform_tcp has been applied as a policy action in the policy-outbound service policy. Counters are displayed for each type of packet drop that can be configured regarding the TCP options field:

Firewall# show service-policy set connection
Global policy:
Service-policy: asa_global_fw_policy
Interface outside:
Service-policy: policy-outbound
  Class-map: outbound
    Set connection policy: conn-max 100 embryonic-conn-max 10
      current embryonic conns 0, current conns 0, drop 0
    Set connection timeout policy:
      tcp 0:30:00
      Set connection advanced-options: conform_tcp
      Retransmission drops: 0               TCP checksum drops : 0
      Exceeded MSS drops  : 0               SYN with data drops: 0
      Out-of-order packets: 0               No buffer drops    : 0
      Reserved bit cleared: 0               Reserved bit drops : 0
      IP TTL modified     : 0               Urgent flag cleared: 0
      Window varied resets: 0
      TCP-options:
        Selective ACK cleared: 0            Timestamp cleared  : 0
        Window scale cleared : 0
        Other options cleared:
        Other options drops:
Firewall#

Send the Matched Traffic to an IPS Module

The Cisco ASA platform has a Security Services Module (SSM) slot that can be populated with a hardware module to handle Intrusion Prevention System (IPS) functions. This module is called the Advanced Inspection and Prevention (AIP) SSM. The ASA firewall must first match packets that are candidates for IPS inspection. Those packets are then offloaded to the AIP for IPS analysis.

Note

With an AIP SSM installed, an ASA platform can take advantage of the more than 1000 available IPS signatures. However, if an AIP is not installed (ASA or PIX platforms), only the basic IPS feature configured with the ip audit command can be used.

You can configure two different methods of handing off packets to the AIP:

inline— The AIP operates inline with the firewall so that matched packets flow from the firewall to the AIP, are inspected and acted upon by the AIP, and then flow back to the firewall.
promiscuous— Matched packets are duplicated and sent to the AIP for IPS inspection. However, the original packets are still handled normally by the ASA firewall.

You can configure a method by using one of the following commands:

Firewall(config-pmap-c)# ips inline {fail-open | fail-close}

Firewall(config-pmap-c)# ips promiscuous {fail-open | fail-close}

With either method, you can configure the firewall’s action if the IPS hardware has failed. Use the fail-open keyword to allow matched packets to move through the firewall normally.

Otherwise, you can use the fail-close keyword to have tighter control over IPS policy enforcement. The firewall drops the matched packets if the IPS hardware has failed, preventing a potential vulnerability from being propagated into the protected network.

For example, the following commands are used to configure a firewall to match any IP traffic and send it to the AIP module. The IPS process is to be inline with the firewall, and connections should be closed if the IPS module has failed. The whole policy is applied to the outside interface.

Firewall(config)# class-map IPS_Class
Firewall(config-cmap)# match any
Firewall(config-cmap)# exit
Firewall(config)# policy-map MyPolicy
Firewall(config-pmap)# class IPS_Class
Firewall(config-pmap-c)# ips inline fail-close
Firewall(config-pmap-c)# exit
Firewall(config-pmap)# exit
Firewall(config)# service-policy MyPolicy interface outside

You can monitor the activity of a service policy that sends matched packets to an AIP module with the following command:

Firewall# show service-policy ips

Tip

Chapter 12, “ASA Modules,” covers the AIP SSM configuration in greater detail.

Send the Matched Traffic to a CSC Module

You can populate the SSM slot in an ASA platform with a Content Security and Control (CSC) module. The CSC can perform anti-virus, anti-spam, anti-spyware, and anti-phishing functions on packets that are sent to it.

The CSC operates in an inline mode as follows:

The traffic matching a policy is sent to the CSC.
The CSC inspects and acts on malicious content.
The CSC sends the traffic back to the firewall.

You can configure the policy map action to send matching traffic to the CSC with the following command:

Firewall(config-pmap-c)# csc {fail-open | fail-close}

You can configure the firewall’s action if the CSC hardware has failed and cannot be reached. Use the fail-open keyword to allow matched packets to move through the firewall normally, without the CSC’s inspection.

Otherwise, use the fail-close keyword to have tighter control over the CSC’s policy enforcement. The firewall drops the matched packets if the CSC hardware has failed.

Tip

Chapter 12 covers the CSC SSM configuration in greater detail.

Use a Policer to Limit the Matched Traffic Bandwidth

Beginning with ASA 7.0(1), you can define traffic policers in a policy map to control the amount of interface bandwidth given to specific traffic. Packets that are identified with a match command in a class map can be applied to a policer.

You can configure a policer as an action within a policy map with the following command:

Firewall(config-pmap-c)# police {output | input} conform_rate [burst_bytes]
[conform-action {drop | transmit}] [exceed-action {drop | transmit}]

Matched packets are held to a strict bandwidth policy. They can use up to conform_rate bits per second, given as 8000 (8 kbps) to 2,000,000,000 (2 Gbps). While the conform_rate bandwidth is not being exceeded, the firewall takes the conform-action and either drops the conforming packets or transmits them (the default).

You can also specify an “instantaneous” amount of burst traffic that is allowed when the conform_rate is exceeded. This is given as burst_bytes, 1000 (1 KB) to 512,000,000 (512 MB); this is 1500 bytes by default. If the conform rate is exceeded by more than the burst size, the traffic is considered nonconforming, and the exceed-action is taken. The firewall can either drop (the default) or transmit the nonconforming packets.

Note

It might seem odd that the conform_rate is specified in bits per second while the burst is given in bytes. This is because of how the policer operates. A 10-millisecond (ms) clock interval is used to measure policed traffic. The byte counts of matching packets are added to a “bucket” whose “high water mark” is set to the amount of traffic that can be transmitted in one clock tick. In addition, the bucket is emptied at every interval of the policer clock (10 ms).

While the conform_rate is not exceeded, the bucket should never fill. If a burst size is configured, it is added to the bucket’s high water mark. Therefore, in one clock tick (10 ms), the amount of matching traffic can exceed the conforming amount by the burst size in bytes.

In releases prior to ASA 7.2(1), policers can examine and limit traffic rates in the outbound direction only. You can use the output keyword to police traffic being output on an interface, but this is not really necessary, because that is the default and the only direction possible.

Beginning with ASA 7.2(1), policers can be used to control the rates of incoming traffic as well. When you configure a policer, you have to select whether it operates in the input or output direction after it is applied to an interface.

For example, suppose a policer has been configured to limit outbound HTTP traffic to an aggregate rate of 8 kbps. Conforming traffic is transmitted, but traffic that exceeds the conform rate is dropped. The HTTP servers are located on the inside of the firewall, and all relevant clients are located outside. The following commands show this configuration:

Firewall(config)# access-list outbound_http extended permit tcp any eq http any
Firewall(config)# class-map class_http
Firewall(config-cmap)# match access-list outbound_http
Firewall(config-cmap)# exit
Firewall(config)# policy-map mypolicy
Firewall(config-pmap)# class class_http
Firewall(config-pmap-c)# police output 8000 conform-action transmit exceed-action drop
Firewall(config-pmap-c)# exit
Firewall(config-pmap)# exit
Firewall(config)# service-policy mypolicy interface outside

You could also add a policer to control the rate of inbound FTP traffic to an aggregate rate of 128 kbps. You could use the following commands to configure the FTP policer:

Firewall(config)# class-map class_ftp
Firewall(config-cmap)# match port tcp eq 20
Firewall(config-cmap)# exit
Firewall(config)# policy-map mypolicy
Firewall(config-pmap)# class class_ftp
Firewall(config-pmap-c)# police input 128000 conform-action transmit exceed-action drop
Firewall(config-pmap-c)# exit
Firewall(config-pmap)# exit

In effect, you just have to edit the policy map to add in a new policy for the inbound traffic. The policy map was already applied to the outside interface in the first part of the example.

You can monitor policer activity with the following command:

Firewall# show service-policy [interface ifc_name]

For example, the following output corresponds to the previous sample configuration:

Firewall# show service-policy interface outside
Interface outside:
Service-policy: policy-outbound
  Class-map: class_http
    Output police Interface outside:
      cir 8000 bps, bc 1500 bytes
      conformed 223 packets, 16502 bytes; actions:  transmit
      exceeded 377 packets, 27898 bytes; actions:  drop
      conformed 6320 bps, exceed 11744 bps
  Class-map: class_ftp
    Input police Interface outside:
      cir 128000 bps, bc 4000 bytes
      conformed 67 packets, 9120 bytes; actions:  transmit
        exceeded 34 packets, 3942 bytes; actions:  drop
      conformed 1298 bps, exceed 3114 bps
Firewall#

Notice that the command output includes current estimates of the bits per second for the “conformed” and “exceed” traffic based on the policer’s actions. For the policer in the output direction, the committed information rate (cir) is shown to be 8000 bps, and the committed burst (bc) is the default 1500 bytes (one packet).

As an extra step, a burst size of 12,000 bytes (eight 1500-byte packets) is then configured for the same output policer using the following command:

Firewall(config-pmap-c)# police output 8000 12800 conform-action transmit exceed-action
drop

The idea is to add the capability for periodic bursts of traffic over the conform rate to get through unaltered, as long as the traffic rate stays below the conform rate. If the traffic rate is sustained at a high rate, where the policer must keep it rate-limited, only a single burst of excessive traffic is permitted.

Monitoring the policer from the command line shows the updated burst size and the estimated conformed and exceeded rates. However, notice that the following output does not really give an indication of the burst activity:

Firewall# show service-policy interface outside
Interface outside:
Service-policy: policy-outbound
  Class-map: outbound
    police Interface outside:
      cir 8000 bps, bc 12800 bytes
      conformed 2294 packets, 169756 bytes; actions:  transmit
      exceeded 3986 packets, 294964 bytes; actions:  drop
      conformed 5376 bps, exceed 11176 bps
  Class-map: class_ftp
    Input police Interface outside:
      cir 128000 bps, bc 4000 bytes
      conformed 67 packets, 9120 bytes; actions:  transmit
      exceeded 34 packets, 3942 bytes; actions:  drop
      conformed 1298 bps, exceed 3114 bps
Firewall#

To see the effects of the policer at work, you can use the ASDM application to display a graph of interface bit rates. Figure 7-3 shows this graph during the time that the example output policer was configured. On the left, where the bit rate averages around 20,000 bps, no policer was configured. This represents the true data rate through the outside firewall interface.

Figure 7-3: The Effects of a Policer on Interface Traffic

When the data rate falls off abruptly to about 7000 bps, the policer has just been configured, with a conform-rate of 8000 bps. No burst size has been configured other than the default. Notice a spike toward the right side of the graph. At that point, the policer was reconfigured with the addition of the 12,800-byte burst size. Because the traffic rate was already at a sustained level above the conform-rate, the policer allowed only a single burst of traffic to get through before throttling the rate back to the conform-rate value.

Give Priority Service (LLQ) to Matched Traffic

Ordinarily, packets are placed on the “normal” queue of a firewall interface after they are inspected. The contents of this queue are transmitted in the order that they were placed in the queue, with no regard for the packet contents or QoS requirements. In other words, packets exit a firewall in a best-effort fashion.

Beginning with ASA 7.0(1), a firewall also supports a strict priority queue that can be enabled on each interface. Packets in the priority queue are serviced and sent out before any packets from the normal queue. Therefore, the priority queue is not affected by the volume or types of traffic contained in the normal queue. The priority queue can be used to provide premium service to delay- and jitter-intolerant applications such as streaming video and voice.

You can use the following command to place the matched traffic in the priority queue on the egress interface:

Firewall(config-pmap-c)# priority

Refer to Chapter 3, “Building Connectivity,” Section “3-1: Building Connectivity,” Section “Configuring Interfaces,” for more information about priority queue operation.

For example, suppose a firewall is configured to place various types of voice-related packets in its priority interface queues. Class maps are configured to match control packets used for Cisco Skinny and Session Initiation Protocol (SIP). Another class map matches the RTP audio bearer packets. A final class map matches any packet that has its IP DSCP value set to EF (46), indicating the need for priority service. The following configuration commands are used to implement these requirements:

Firewall(config)# class-map Class_Skinny
Firewall(config-cmap)# match port tcp range 2000 2002
Firewall(config-cmap)# exit
Firewall(config)# class-map Class_RTP
Firewall(config-cmap)# match rtp 16384 16383
Firewall(config-cmap)# exit
Firewall(config)# class-map Class_SIP
Firewall(config-cmap)# match port udp eq sip
Firewall(config-cmap)# exit
Firewall(config)# class-map Class_DSCP
Firewall(config-cmap)# match dscp ef
Firewall(config-cmap)# exit
!
Firewall(config)# policy-map MyPolicy
Firewall(config-pmap)# class Class_Skinny
Firewall(config-pmap-c)# priority
Firewall(config-pmap-c)# exit
Firewall(config-pmap)# class Class_RTP
Firewall(config-pmap-c)# priority
Firewall(config-pmap-c)# exit
Firewall(config-pmap)# class Class_SIP
Firewall(config-pmap-c)# priority
Firewall(config-pmap-c)# exit
Firewall(config-pmap)# class Class_DSCP
Firewall(config-pmap-c)# priority
Firewall(config-pmap-c)# exit
Firewall(config)# service-policy MyPolicy interface outside
Firewall(config)# service-policy MyPolicy interface inside

Default Policy Definitions

An ASA running release 7.0(1) or later, or a FWSM running 3.1(1) or later, automatically configures a default class map and a default policy map. The default policy map is referenced by a service policy that is applied globally to all firewall interfaces. Figure 7-4 shows the default modular policies.

Figure 7-4: Default Modular Policy Definitions

The default class map is named inspection_default. It matches against a predefined set of protocols and port numbers called default-inspection-traffic. This is a “catchall” case that matches against the default primary ports for every possible inspection engine.

Tip

The default-inspection-traffic definition does not appear in the firewall configuration. To see how it is defined, use the context-based help within a class-map configuration, as in the following example:

Firewall(config)# class-map test
Firewall(config-cmap)# match ?
mpf-class-map mode commands/options:
access-list                 Match an Access List
any                         Match any packet
default-inspection-traffic  Match default inspection traffic:
                              ctiqbe----tcp--2748      dns-------udp--53
                              ftp-------tcp--21        gtp-------udp--2123,3386
                              h323-h225-tcp--1720      h323-ras--udp--1718-1719
                              http------tcp--80        icmp------icmp   
                              ils-------tcp--389       mgcp------udp--2427,2727
                              netbios---udp--137-138   radius-acct---udp--1646 
                              rpc-------udp--111       rsh-------tcp--514      
                              rtsp------tcp--554       sip-------tcp--5060  
                              sip-------udp--5060      skinny----tcp--2000
                              smtp------tcp--25        sqlnet----tcp--1521
                              tftp------udp--69        xdmcp-----udp--177

The default policy map is named global_policy. It references only the inspection_default class map. It also has a set of predefined actions, which invoke the inspection engines as shown in Figure 7-4.

The default service policy references policy map global_policy and applies it to “global,” or to every active firewall interface. The net effect of the default configuration is as follows:

All traffic is matched against the default inspection engine settings.
Only the 22 predefined inspection engines are active. Only traffic matching the default protocols and ports of these are inspected. All other traffic is denied unless other nondefault policies are configured.
Traffic matching the default inspection engines is inspected, regardless of the firewall interface.

You can add your own modular policies to the default policies in two ways:

You can configure the existing default class map and policy map to add additional matches and actions.

Although this simplifies the configuration because you do not have to configure new class maps and policy maps, any changes you make to the default policies are applied to all the firewall interfaces. In other words, you lose some ability to fully customize the security policies, because the global_policy policy map is applied globally by default.
You can configure new class maps and new policy maps and apply those to one or more interfaces with a service policy. This approach offers the most scalability and granularity.

You can apply only one policy map to an interface with a service policy. However, you can apply your own policy map to an interface, even if the default policy map is already applied in the default service policy. One service policy can overlay the default service policy on any interface because the default is used globally.

Chapter 7: Inspecting Traffic

Overview

7-1: Filtering Content

Configuring Content Filters

Content-Filtering Examples

Using a Web Cache for Better HTTP Performance

7-2: Defining Security Policies in a Modular Policy Framework

Classifying Layers 3 and 4 Traffic

Match Against a Destination Port Number

Match Against an Access List

Match Against QoS Parameters

Match Against a Range of Real-Time Transport Protocol (RTP) Port Numbers

Match Against a VPN Tunnel Group

Match All Traffic

Match Default Traffic

Classifying Management Traffic

Defining a Layer 3/4 Policy

Set Connection Limits on the Matched Traffic

Adjust TCP Options for the Matched Traffic

Send the Matched Traffic to an IPS Module

Send the Matched Traffic to a CSC Module

Use a Policer to Limit the Matched Traffic Bandwidth

Give Priority Service (LLQ) to Matched Traffic

Default Policy Definitions

0 comments

Post a Comment

About Me

Chat Box

Google Maps

Visitor Locations

Lunar Calendar

Link URL

Followers

Lưu Trữ - Archive

Others

Posted