Protect Servers from a SYN Flood DoS Attack (TCP Intercept)

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 threat defense acts as a proxy for the server and generates a SYN-ACK response to the client SYN request using the SYN cookie method, so that the connection is not added to the SYN queue of the targeted host. The SYN cookie is the initial sequence number returned in the SYN-ACK that is constructed from MSS, time stamp, and a mathematical hash of other items to essentially create a secret. If the threat defense receives an ACK back from the client with the correct sequence number and within the valid time window, 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.

Setting connection limits can protect a server from a SYN flood attack. You can optionally enable TCP Intercept statistics and monitor the results of your policy. The following procedure explains the end-to-end process.

Before you begin

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.
Depending on the number of CPU cores on your Secure Firewall Threat Defense device model, the maximum concurrent and embryonic connections can exceed the configured numbers due to the way each core manages connections. In the worst case scenario, the device allows up to n-1 extra connections and embryonic connections, where n is the number of cores. For example, if your model has 4 cores, if you configure 6 concurrent connections and 4 embryonic connections, you could have an additional 3 of each type. To determine the number of cores for your model, enter the show cpu core command in the device CLI.

Procedure

Step 1

Create the extended ACL that defines the traffic class, which is the list of servers you want to protect.

For example, to define a traffic class to protect the web servers with the IP addresses 10.1.1.5 and 10.1.1.6:

Choose Objects > Object Management.
Choose Access List > Extended from the table of contents.
Click Add Extended Access List.
Enter a Name for the object, for example, protected-servers.
Click Add to add a rule.
Keep Allow for the action.
Leave the Source list empty, enter 10.1.1.5 beneath the Destination list, and click Add.
Also enter 10.1.1.6 beneath the Destination list and click Add.
Click Port, select HTTP in the available ports list, and click Add to Destination. If your server also support HTTPS connections, also add that port.
Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
Click Save on the Extended Access List Object dialog box to save the ACL object.

Step 2

Configure the service policy rule that sets embryonic connection limits.

For example, to set the total concurrent embryonic limit to 1000 connections, and the per-client limit to 50 connections, do the following:

Choose Policies > Access Control, and edit the policy assigned to the devices that require this service.
Click Advanced Settings from the More drop-down arrow at the end of the packet flow line, and click Edit () for the Threat Defense Service Policy.
Click Add Rule.
Select Apply Globally > Next.
Select the extended ACL object you created for this rule and click Next.
Enter 1000 for Connections > Maximum Embryonic.
Enter 50 for Connections Per Client > Maximum Embryonic.
(Optional.) Adjust the other connection options as needed.
Click Finish to add the rule. If necessary, drag and drop the rule to the desired position in the service policy.
Click OK to save the changes to the service policy.
Click Save on Advanced to save the changes to the access control policy.

Step 3

(Optional.) Configure the rates for TCP Intercept statistics.

TCP Intercept uses the following options to determine the rate for collecting statistics. All options have default values, so if these rates suit your needs, you can skip this step.

Rate Interval—The size of the history monitoring window, between 1 and 1440 minutes. The default is 30 minutes. During this interval, the system samples the number of attacks 30 times.
Burst Rate—The threshold for syslog message generation, between 25 and 2147483647. The default is 400 per second. When the burst rate is exceeded, the device generates syslog message 733104.
Average Rate—The average rate threshold for syslog message generation, between 25 and 2147483647. The default is 200 per second. When the average rate is exceeded, the device generates syslog message 733105.

If you want to adjust these options, do the following:

Choose Objects > Object Management.
Choose FlexConfig > Text Object.
Click Edit () for the threat_defense_statistics system-defined object.
Although you can directly change the values, the recommended approach is to open the Override section and click Add to create a device override.
Select the devices to which you will assign the service policy (through the access control policy assignment) and click Add to move them to the selected list.
Click Override.
The object must have 3 entries, so click Count as needed until you get 3.
Enter the values you need, in order from 1-3, as rate interval, burst rate, and average rate. Consult the object description to verify you enter the values in the right order.
Click Add in the Object Override dialog box.
Click Save in the Edit Text Object dialog box.

Step 4

Enable TCP Intercept statistics.

You must configure a FlexConfig policy to enable TCP Intercept statistics.

Choose Devices > FlexConfig.
If you already have a policy assigned to the devices, edit it. Otherwise, create a new policy and assign it to the affected devices.
Select the Threat_Detection_Configure object in the Available FlexConfig list and click >>. The object is added to the Selected Append FlexConfigs list.
Click Save.
(Optional.) You can verify that you have the right settings by clicking Preview Config and selecting one of the devices.
The system generates the CLI commands that will be written to the device during the next deployment. These commands will include those needed for the service policy as well as those needed for threat detection statistics. Scroll to the bottom of the preview to see the appended CLI. The TCP Intercept statistics command should look something like the following, if you use the default values (line break added for clarity):
```
###Flex-config Appended CLI ###

threat-detection statistics tcp-intercept rate-interval 30 
       burst-rate 400 average-rate 200
```

Step 5

You can now deploy the changes to the affected devices.

Step 6

Monitor the TCP Intercept statistics from the device CLI using the following commands:

show threat-detection statistics top tcp-intercept [all | detail] —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 system samples the number of attacks 30 times during the rate interval, so for the default 30 minute period, statistics are collected every 60 seconds.

Note

You can use the shun command to block attacking host IP addresses. To remove the block, use the no shun command.
clear threat-detection statistics tcp-intercept —Erases TCP Intercept statistics.

Example:


hostname(config)# show threat-detection statistics top tcp-intercept
Top 10 protected servers under attack (sorted by average rate)
Monitoring window size: 30 mins    Sampling interval: 30 secs
<Rank> <Server IP:Port> <Interface> <Ave Rate> <Cur Rate> <Total> <Source IP (Last Attack Time)>
----------------------------------------------------------------------------------
1    10.1.1.5:80 inside 1249 9503 2249245 <various> Last: 10.0.0.3 (0 secs ago)
2    10.1.1.6:80 inside 10 10 6080 10.0.0.200 (0 secs ago)