6-5. 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 doesn't offer a way to fine-tune or vary the policies according to differing requirements. Beginning with PIX 7.0, 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. Send traffic to an intrusion protection system (IPS) Certain firewall platforms can divert specific traffic to an embedded IPS with a rich signature database. 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 6-12, 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. 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 6-12. The Modular Policy Framework for Applying Security Policies 
NOTE The MPF is available only beginning with PIX release 7.0. Therefore, PIX 7.x is the only command syntax shown in this section.
Classifying 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. Then a different policy can be applied to each traffic class if necessary. You can use the following steps to configure a class map for identifying a specific type of traffic. The modular policy framework is available only in PIX 7.0 and later. Therefore, this is the only command syntax shown in these steps. 1. | Define a 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 exception is match tunnel-group, described in Step 7.
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
| 2. | (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.
| 3. | (Optional) Match against a destination port number:
Firewall(config-cmap)# match port {tcp | udp} {eq port | range start end}
The destination tcp or udp port in IP packets moving into or out of a firewall interface is examined. 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
| 4. | (Optional) Match against an access list.
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. 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. 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
Section 6-3 covers access list configuration in detail. 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
| 5. | (Optional) Match against QoS parameters.
Quality of service 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 PIX 7.0, 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 PIX 7.0, 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 6-13. Specifically, IP Precedence is a 3-bit value (P2 to P0), and DSCP is a 6-bit value (DS5 to DS0).
Figure 6-13. ToS and DSCP Byte Formats 
The DSCP value is broken 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 6-5 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. (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 quality of service 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
Table 6-5. Mapping of IP Precedence and DSCP ValuesIP 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.
| 6. | (Optional) Match against a range of Real-Time Transport Protocol (RTP) port numbers:
Firewsall(config-cmap)# match rtp starting_port range
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.
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
| 7. | (Optional) Match against a VPN tunnel group:
Firewall(config-cmap)# match tunnel-group name
If the firewall is configured to support and terminate 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.
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 each traffic flow within a tunnel group can be policed to a certain data rate.
| 8. | (Optional) Match all traffic:
Firewall(config-cmap)# match any
All packets passing into or out of a firewall interface are matched and identified with the class map. This is a handy way to subject all types of traffic to an action in a policy map.
| 9. | (Optional) Match default traffic:
Firewall(config-cmap)# match default-inspection-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.
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.
|
Defining a Policy After 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: 1. | 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
| 2. | (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.
| 3. | 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.
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 hasn't 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
| 4. | 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 6-6 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 6-6. Policy Map Actions Per Supported Traffic DirectionBidirectional Action | Unidirectional Action |
|---|
Application inspection (inspect) | Policers (police) | Connection options (set connection) | Low-Latency Queuing (priority) | Intrusion protection (ips) | |
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 protection system (IPS) Police the traffic to a rate limit Use LLQ for priority handling
These policy actions are discussed in the following sections.
| 5. | Repeat Steps 3 and 4 to define other policies.
| 6. | Apply the policy map as a service policy:
Firewall(config)# service-policy policy_map_name {global | interface if_name}
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 asa_global_fw_policy is applied globally.
|
Submit Matched Traffic for Application Inspection Application inspection occurs only on traffic that has been classified and applied to a policy. When you use the inspect command, as in the following command syntax, only that specific inspection engine is used to examine traffic identified by the class map: Firewall(config-pmap-c)# inspect inspect_name [options]
The application inspection engine inspect_name is given as one of the names shown in Table 6-7. Some inspections can accept additional options. Refer to section 6-6, "Application Inspection," for more information about each inspection engine. Table 6-7. Application Inspection Engines and Their CommandsApplication | Command Syntax |
|---|
Computer Telephony Interface Quick Buffer Encoding (CTIQBE) | Firewall(config-pmap-c)# inspect ctiqbe | Domain Name Service (DNS) | Firewall(config-pmap-c)# inspect dns [maximum-length max_pkt_length] | Extended SMTP (ESMTP) | Firewall(config-pmap-c)# inspect esmtp | File Transfer Protocol (FTP) | Firewall(config-pmap-c)# inspect ftp [strict [ftp_map_name]] | GPRS Tunneling Protocol (GTP) | Firewall(config-pmap-c)# inspect gtp [gtp_map_name] | H.323 | Firewall(config-pmap-c)# inspect h323 {H225 | ras} | Hypertext Transfer Protocol (HTTP) | Firewall(config-pmap-c)# inspect http [http_map_name] | Internet Control Message Protocol (ICMP) | Firewall(config-pmap-c)# inspect icmp [error] | Internet Locator Server (ILS)/Lightweight Directory Access Protocol (LDAP) | Firewall(config-pmap-c)# inspect ils | Multimedia Gateway Control Protocol (MGCP) | Firewall(config-pmap-c)# inspect mgcp [mgcp_map_name] | NetBIOS | Firewall(config-pmap-c)# inspect netbios | Point-to-Point Tunneling Protocol (PPTP) | Firewall(config-pmap-c)# inspect pptp | Remote Shell (RSH) | Firewall(config-pmap-c)# inspect rsh | Real-Time Streaming Protocol (RTSP) | Firewall(config-pmap-c)# inspect rtsp | Session Initiation Protocol (SIP) | Firewall(config-pmap-c)# inspect sip | Cisco Skinny IP Telephony Control Protocol | Firewall(config-pmap-c)# inspect skinny | Simple Network Management Protocol (SNMP) | Firewall(config-pmap-c)# inspect snmp [snmp_map_name] | Oracle SQL*Net | Firewall(config-pmap-c)# inspect sqlnet | Sun Remote Procedure Call (RPC) | Firewall(config-pmap-c)# inspect sunrpc | Trivial File Transfer Protocol (TFTP) | Firewall(config-pmap-c)# inspect tftp | X Display Manager Control Protocol (XDMCP) | Firewall(config-pmap-c)# inspect xdmcp |
TIP Only the following application inspection engines can operate on either IPv4 or IPv6 traffic. No additional configuration is required beyond the command syntax shown in Table 6-7:
TIP In releases before PIX 7.0, the fixup command is used to configure application inspection and default port numbers. Although this command is still accepted in PIX 7.0, it is considered deprecated and should not be used. Instead, use the inspect command, as shown in Table 6-7. Notice that the inspect command does not accept any port numbers for the case in which the default application port needs to be changed. The default port numbers are defined by the match default-inspection-traffic command, which is configured by default. You can change the default port by matching traffic based on the new port number and then using a policy to subject that traffic to the inspection engine. For example, the inspect http command uses default TCP port 80 for its inspection. If you need to use TCP 8080 instead, use the following commands: Firewall(config)# class-map http_8080 Firewall(config-cmap)# match port tcp eq 8080 Firewall(config-cmap)# exit Firewall(config)# policy-map MyPolicies Firewall(config-pmap)# class http_8080 Firewall(config-pmap-c)# inspect http Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)# service-policy MyPolicies interface inside
As soon as an inspection policy is configured, you can monitor its activity with the following command: Firewall# show service-policy
This command displays each active service policy, along with the class map and action breakdown. If inspect commands are configured as part of a service policy, each one is listed, along with counters for packets inspected and dropped and connections reset. The inspection engines configured in the default global policy asa_global_fw_policy are shown in the following example: Firewall# show service-policy Global policy: Service-policy: asa_global_fw_policy Class-map: inspection_default Inspect: dns maximum-length 512, packet 10, drop 0, reset-drop 0 Inspect: ftp, packet 39, drop 0, reset-drop 0 Inspect: h323 h225, packet 0, drop 0, reset-drop 0 Inspect: h323 ras, packet 0, drop 0, reset-drop 0 Inspect: rsh, packet 0, drop 0, reset-drop 0 Inspect: rtsp, packet 0, drop 0, reset-drop 0 Inspect: esmtp, packet 28, drop 0, reset-drop 0 Inspect: sqlnet, packet 0, drop 0, reset-drop 0 Inspect: skinny, packet 0, drop 0, reset-drop 0 Inspect: sunrpc, packet 0, drop 0, reset-drop 0 Inspect: xdmcp, packet 0, drop 0, reset-drop 0 Inspect: sip, packet 0, drop 0, reset-drop 0 Inspect: netbios, packet 27, drop 0, reset-drop 0 Inspect: tftp, packet 0, drop 0, reset-drop 0 Inspect: icmp error, packet 0, drop 0, reset-drop 0 Inspect: icmp, packet 76800, drop 13628, reset-drop 0
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: Firewall(config-pmap-c)# set connection [timeout [embryonic {hh:mm:ss | 0}] [half-closed {hh:mm:ss | 0}] [tcp {hh:mm:ss | 0}]
For matched packets, you can adjust the TCP connection timeout limits and set them as the appropriate conn entries are dynamically created. You can use the embryonic keyword to set the embryonic (not completely opened) timeout. Use the half-closed keyword to automatically close connections that are left partially closed (incomplete FIN-FIN handshakes). Use the tcp keyword to set the timeout for TCP connections that have become idle. In each case, the timeout value is set to hh:mm:ss (24-hour format) or 0 for unlimited time. Set connection volume limits: Firewall(config-pmap-c)# set connection [conn-max max] [embryonic-conn-max max] [random-sequence-number {enable | disable}]
By default, an unlimited number of simultaneous UDP and TCP connections are allowed across an address translation. This command can be used in a policy that matches traffic to and from specific hosts. Use the conn-max keyword to limit the number of connections to max (1 to 65535). Use the embryonic-conn-max keyword to limit the number of embryonic connections allowed to form. As soon as max (1 to 65535) of them have occurred, the firewall begins intercepting them and acting as a proxy for the connection target. You can also use the random-sequence-number keyword to enable or disable randomization of the initial sequence number (ISN) when TCP connections are established.
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: 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 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. First, define the TCP map with the following command: Firewall(config)# tcp-map tcp_map_name
Next, use one or more of the commands listed in Table 6-8 to specify actions to take on the TCP header. Table 6-8. TCP Header ActionsAction 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 can't 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 isn't 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. End the TCP map configuration with the exit command. Finally, 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
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 matchedsomething 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 Adaptive Security Appliance (ASA) platform has a Security Services Module (SSM) slot that can be populated with a hardware module to handle intrusion protection system (IPS) functions. The ASA firewall must first match packets that are candidates for IPS inspection. Those packets are then offloaded to the SSM for IPS analysis. NOTE With an SSM installed, an ASA platform can take advantage of the more than 1000 available IPS signatures. However, if an SSM 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 SSM: inline The SSM operates inline with the firewall so that matched packets flow from the firewall to the SSM, are inspected and acted upon by the SSM, and flow back to the firewall. promiscuous Matched packets are duplicated and sent to the SSM 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}
or 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 SSM IPS 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 IPS module with the following command: Firewall# show service-policy ips
Use a Policer to Limit the Matched Traffic Bandwidth Beginning with PIX 7.0, 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] 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-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.
Policers can examine and limit traffic rates in the outbound direction only as of PIX 7.0. You can use the output keyword to police traffic being output on an interface, but this isn't really necessary, because that is the default and the only direction possible. 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 policy_outbound Firewall(config-pmap)# class class_http Firewall(config-pmap-c)# police 8000 conform-action transmit exceed-action drop Firewall(config-pmap-c)# exit Firewall(config-pmap)# exit Firewall(config)# service-policy policy_outbound interface outside
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 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 Firewall#
Notice that the output includes current estimates of the bits per second for the "conformed" and "exceed" traffic based on the policer's actions. 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 policer using the following command: Firewall(config-pmap-c)# police 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 doesn't 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 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 6-14 shows this graph during the time that the sample 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 6-14. 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 Matched Traffic Priority Service (LLQ) 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 quality of service requirements. In other words, packets exit a firewall in a best-effort fashion. Beginning with PIX 7.0, 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, "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 A firewall running PIX 7.0 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 6-15 shows the default modular policies. Figure 6-15. The Default Modular Policy Definitions in PIX 7.0 
The default class map is named inspection_default. It matches against default-inspection-traffic. This is a "catchall" case that matches against the default primary ports for every possible inspection engine. The default policy map is named asa_global_fw_policy. It references only the inspection_default class map. It also has a set of predefined actions, which invoke the 15 inspection engines shown in Figure 6-15. The default service policy references policy map asa_global_fw_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 15 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 don't 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. 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.
|
