This chapter describes how to configure connection settings for connections that go through the ASA, or for management connections that go to the ASA.
Connection settings comprise a variety of features related to managing traffic connections, such as a TCP flow through the ASA. Some features are named components that you would configure to supply specific services.
Connection settings include the following:
Connection limits, timeouts, TCP Normalization, TCP sequence randomization, and decrementing time-to-live (TTL) have default values that are appropriate for most networks. You need to configure these connection settings only if you have unusual requirements, your network has specific types of configuration, or if you are experiencing unusual connection loss due to premature idle timeouts.
TCP Intercept, TCP State Bypass, and Dead Connection Detection (DCD) are not enabled. You would configure these services on specific traffic classes only, and not as a general service.
The following general procedure covers the gamut of possible connection setting configurations. Pick and choose which to implement based on your needs.
Step 1 Configure Global Timeouts. These settings change the default idle timeouts for various protocols for all traffic that passes through the device. If you are having problems with connections being reset due to premature timeouts, first try changing the global timeouts.
Step 2 Protect Servers from a SYN Flood DoS Attack (TCP Intercept). Use this procedure to configure TCP Intercept.
Step 3 Customize Abnormal TCP Packet Handling (TCP Maps, TCP Normalizer), if you want to alter the default TCP Normalization behavior for specific traffic classes.
Step 4 Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass), if you have this type of routing environment.
Step 5 Disable TCP Sequence Randomization, if the default randomization is scrambling data for certain connections.
Step 6 Configure Connection Settings for Specific Traffic Classes (All Services). This is a catch-all procedure for connection settings. These settings can override the global defaults for specific traffic classes using service policy rules. You also use these rules to customize TCP Normalizer, change TCP sequence randomization, decrement time-to-live on packets, and implement TCP Intercept, Dead Connection Detection, or TCP State Bypass.
You can set the global idle timeout durations for the connection and translation slots of various protocols. If the slot has not been used for the idle time specified, the resource is returned to the free pool. TCP connection slots are freed approximately 60 seconds after a normal connection close sequence.
Changing the global timeout sets a new default timeout, which in some cases can be overridden for particular traffic flows through service policies.
Step 1 Use the timeout command to set global timeouts.
All timeout values are in the format hh : mm : ss, with a maximum duration of 1193:0:0. Use the no timeout command to reset all timeouts to their default values. If you want to simply reset one timer to the default, enter the timeout command for that setting with the default value.
Use 0 for the value to disable a timer.
You can configure the following global timeouts.
A SYN-flooding denial of service (DoS) attack occurs when an attacker sends a series of SYN packets to a host. These packets usually originate from spoofed IP addresses. The constant flood of SYN packets keeps the server SYN queue full, which prevents it from servicing connection requests from legitimate users.
You can limit the number of embryonic connections to help prevent SYN flooding attacks. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination.
When the embryonic connection threshold of a connection is crossed, the ASA acts as a proxy for the server and generates a SYN-ACK response to the client SYN request using the SYN cookie method (see Wikipedia for details on SYN cookies). When the ASA receives an ACK back from the client, it can then authenticate that the client is real and allow the connection to the server. The component that performs the proxy is called TCP Intercept.
Note Ensure that you set the embryonic connection limit lower than the TCP SYN backlog queue on the server that you want to protect. Otherwise, valid clients can no longer access the server during a SYN attack. To determine reasonable values for embryonic limits, carefully analyze the capacity of the server, the network, and server usage.
The end-to-end process for protecting a server from a SYN flood attack involves setting connection limits, enabling TCP Intercept statistics, and then monitoring the results.
Step 1 Create an L3/L4 class map to identify the servers you are protecting. Use an access-list match.
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic, and identify the class map.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name. For the class map, specify the class you created earlier in this procedure.
Step 3 Set the embryonic connection limits.
Step 4 If you are editing an existing service policy (such as the default global policy called global_policy), you can skip this step. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
Step 5 Configure threat detection statistics for attacks intercepted by TCP Intercept.
The rate-interval keyword sets the size of the history monitoring window, between 1 and 1440 minutes. The default is 30 minutes. During this interval, the ASA samples the number of attacks 30 times.
The burst-rate keyword sets the threshold for syslog message generation, between 25 and 2147483647. The default is 400 per second. When the burst rate is exceeded, syslog message 733104 is generated.
The average-rate keyword sets the average rate threshold for syslog message generation, between 25 and 2147483647. The default is 200 per second. When the average rate is exceeded, syslog message 733105 is generated.
Step 6 Monitor the results with the following commands:
The TCP Normalizer identifies abnormal packets that the ASA can act on when they are detected; for example, the ASA can allow, drop, or clear the packets. TCP normalization helps protect the ASA from attacks. TCP normalization is always enabled, but you can customize how some features behave.
The default configuration includes the following settings:
To customize the TCP normalizer, first define the settings using a TCP map. Then, you can apply the map to selected traffic classes using service policies.
Step 1 Create a TCP map to specify the TCP normalization criteria that you want to look for.
Step 2 Configure the TCP map criteria by entering one or more of the following commands. The defaults are used for any commands you do not enter. Use the no form of a command to disable the setting.
– In the TCP connection SYN-ACK-received status, if the ACK number of a received TCP packet is not exactly the same as the sequence number of the next TCP packet sending out, it is an invalid ACK.
– Whenever the ACK number of a received TCP packet is greater than the sequence number of the next TCP packet sending out, it is an invalid ACK.
– Connections for application inspection (the inspect command), IPS (the ips command), and TCP check-retransmission (the TCP map check-retransmission command) have a queue limit of 3 packets. If the ASA receives a TCP packet with a different window size, then the queue limit is dynamically changed to match the advertised setting.
– For other TCP connections, out-of-order packets are passed through untouched.
If you set the queue-limit command to be 1 or above, then the number of out-of-order packets allowed for all TCP traffic matches this setting. For example, for application inspection, IPS, and TCP check-retransmission traffic, any advertised settings from TCP packets are ignored in favor of the queue-limit setting. For other TCP traffic, out-of-order packets are now buffered and put in order instead of passed through untouched.
The timeout seconds argument sets the maximum amount of time that out-of-order packets can remain in the buffer, between 1 and 20 seconds; if they are not put in order and passed on within the timeout period, then they are dropped. The default is 4 seconds. You cannot change the timeout for any traffic if the pkt_num argument is set to 0; you need to set the limit to be 1 or above for the timeout keyword to take effect.
You can allow the packet (without changing the options), clear the options and allow the packet, or drop the packet. The default for the three named options is to allow them; the default for all other options is to clear them. Note that clearing the timestamp option disables PAWS and RTT.
For example, an attacker can send a packet that passes policy with a very short TTL. When the TTL goes to zero, a router between the ASA and the endpoint drops the packet. It is at this point that the attacker can send a malicious packet with a long TTL that appears to the ASA to be a retransmission and is passed. To the endpoint host, however, it is the first packet that has been received by the attacker. In this case, an attacker is able to succeed without security preventing the attack.
The URG flag is used to indicate that the packet contains information that is of higher priority than other data within the stream. The TCP RFC is vague about the exact interpretation of the URG flag, therefore end systems handle urgent offsets in different ways, which may make the end system vulnerable to attacks.
The window size mechanism allows TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted too much data. From the TCP specification, “shrinking the window” is strongly discouraged. When this condition is detected, the connection can be dropped.
Step 3 Apply the TCP map to a traffic class using a service policy.
a. Define the traffic class with an L3/L4 class map and add the map to a policy map.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name. For information on matching statements for class maps, see Identify Traffic (Layer 3/4 Class Maps).
set connection advanced-options tcp-map-name
c. If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
For example, to allow urgent flag and urgent offset packets for all traffic sent to the range of TCP ports between the well known FTP data port and the Telnet port, enter the following commands:
If you have an asynchronous routing environment in your network, where the outbound and inbound flow for a given connection can go through two different ASA devices, you need to implement TCP State Bypass on the affected traffic.
However, TCP State Bypass weakens the security of your network, so you should apply bypass on very specific, limited traffic classes.
The following topics explain the problem and solution in more detail.
By default, all traffic that goes through the ASA is inspected using the Adaptive Security Algorithm and is either allowed through or dropped based on the security policy. The ASA maximizes the firewall performance by checking the state of each packet (is this a new connection or an established connection?) and assigning it to either the session management path (a new connection SYN packet), the fast path (an established connection), or the control plane path (advanced inspection). See the general operations configuration guide for more detailed information about the stateful firewall.
TCP packets that match existing connections in the fast path can pass through the ASA without rechecking every aspect of the security policy. This feature maximizes performance. However, the method of establishing the session in the fast path using the SYN packet, and the checks that occur in the fast path (such as TCP sequence number), can stand in the way of asymmetrical routing solutions: both the outbound and inbound flow of a connection must pass through the same ASA.
For example, a new connection goes to ASA 1. The SYN packet goes through the session management path, and an entry for the connection is added to the fast path table. If subsequent packets of this connection go through ASA 1, then the packets will match the entry in the fast path, and are passed through. But if subsequent packets go to ASA 2, where there was not a SYN packet that went through the session management path, then there is no entry in the fast path for the connection, and the packets are dropped. The following figure shows an asymmetric routing example where the outbound traffic goes through a different ASA than the inbound traffic:
Figure 11-1 Asymmetric Routing
If you have asymmetric routing configured on upstream routers, and traffic alternates between two ASAs, then you can configure TCP state bypass for specific traffic. TCP state bypass alters the way sessions are established in the fast path and disables the fast path checks. This feature treats TCP traffic much as it treats a UDP connection: when a non-SYN packet matching the specified networks enters the ASA, and there is not an fast path entry, then the packet goes through the session management path to establish the connection in the fast path. Once in the fast path, the traffic bypasses the fast path checks.
TCP State Bypass Unsupported Features
The following features are not supported when you use TCP state bypass:
TCP State Bypass NAT Guidelines
Because the translation session is established separately for each ASA, be sure to configure static NAT on both ASAs for TCP state bypass traffic. If you use dynamic NAT, the address chosen for the session on ASA 1 will differ from the address chosen for the session on ASA 2.
To bypass TCP state checking in asynchronous routing environments, carefully define a traffic class that applies to the affected hosts or networks only, then enable TCP State Bypass on the traffic class using a service policy. Because bypass reduces the security of the network, limit its application as much as possible.
Step 1 Create an L3/L4 class map to identify the hosts that require TCP State Bypass. Use an access-list match to identify the source and destination hosts.
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic, and identify the class map.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name. For the class map, specify the class you created earlier in this procedure.
Step 3 Enable TCP State Bypass on the class.
Step 4 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
The following is a sample configuration for TCP state bypass:
Each TCP connection has two ISNs: one generated by the client and one generated by the server. The ASA randomizes the ISN of the TCP SYN passing in both the inbound and outbound directions.
Randomizing the ISN of the protected host prevents an attacker from predicting the next ISN for a new connection and potentially hijacking the new session.
You can disable TCP initial sequence number randomization if necessary, for example, because data is getting scrambled. For example:
Step 1 Create an L3/L4 class map to identify the traffic whose TCP sequence numbers should not be randomized. The class match should be for TCP traffic; you can identify specific hosts (with an ACL) do a TCP port match, or simply match any traffic.
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic, and identify the class map.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name. For the class map, specify the class you created earlier in this procedure.
Step 3 Disable TCP sequence number randomization on the class.
If you later decide to turn it back on, replace “disable “with enable.
Step 4 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
You can configure different connection settings for specific traffic classes using service policies. Use service policies to:
You can configure any combination of these settings for a given traffic class, except for TCP State Bypass and TCP Normalizer customization, which are mutually exclusive.
Tip This procedure shows a service policy for traffic that goes through the ASA. You can also configure the connection maximum and embryonic connection maximum for management (to the box) traffic.
If you want to customize the TCP Normalizer, create the required TCP Map before proceeding.
The set connection command (for connection limits and sequence randomization) and set connection timeout commands are described here separately for each parameter. However, you can enter the commands on one line, and if you enter them separately, they are shown in the configuration as one command.
Step 1 Create an L3/L4 class map to identify the traffic for which you want to customize connection settings.
For information on matching statements, see Identify Traffic (Layer 3/4 Class Maps).
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic, and identify the class map.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name. For the class map, specify the class you created earlier in this procedure.
Step 3 Set connection limits and TCP sequence number randomization. (TCP Intercept.)
– If two servers are configured to allow simultaneous TCP or UDP connections, the connection limit is applied to each configured server separately.
– Because the limit is applied to a class, one attack host can consume all the connections and leave none for the rest of the hosts that are matched to the class.
Step 4 Set connection timeouts and Dead Connection Detection (DCD).
The defaults described below assume you have not changed the global defaults for these behaviors using the timeout command; the global defaults override the ones described here. Enter 0 to disable the timer, so that a connection never times out.
The default udp idle timeout is 2 minutes. The default icmp idle timeout is 2 seconds. The default esp and ha idle timeout is 30 seconds. For all other protocols, the default idle timeout is 2 minutes.
The retry-interval sets the time duration in hh : mm : ss format to wait after each unresponsive DCD probe before sending another probe, between 0:0:1 and 24:0:0. The default is 0:0:15. The max-retries sets the number of consecutive failed retries for DCD before declaring the connection as dead. The minimum value is 1 and the maximum value is 255. The default is 5.
Step 5 Decrement time-to-live (TTL) on packets that match the class.
This command, along with the icmp unreachable command, is required to allow a traceroute through the ASA that shows the ASA as one of the hops.
Step 6 Customize TCP Normalizer behavior by applying a TCP map.
set connection advanced-options tcp-map-name
Step 7 Implement TCP State Bypass.
set connection advanced-options tcp-state-bypass
Step 8 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
The following example sets the connection limits and timeouts for all traffic:
You can enter set connection commands with multiple parameters or you can enter each parameter as a separate command. The ASA combines the commands into one line in the running configuration. For example, if you entered the following two commands in class configuration mode:
The output of the show running-config policy-map command would display the result of the two commands in a single, combined command:
You can use the following commands to monitor connections:
Shows connection information. The “b” flag indicates traffic subject to TCP State Bypass.
Shows service policy statistics, including Dead Connection Detection (DCD) statistics.
View the top 10 protected servers under attack. The all keyword shows the history data of all the traced servers. The detail keyword shows history sampling data. The ASA samples the number of attacks 30 times during the rate interval, so for the default 30 minute period, statistics are collected every 60 seconds.