Applies To:

Show Versions Show Versions

Archived Manual Chapter: BIG-IP 4.5 PTF-04 Features Guide: Preventing SYN Flood Attacks
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.



4

Preventing SYN Flood Attacks


Introducing SYN Check

Before you read about the SYN CheckTM feature, it is helpful to understand the type of denial-of-service attack known as a SYN flood.

Understanding SYN flood attacks

A SYN flood is an attack against a system for the purpose of exhausting that system's resources. An attacker launching a SYN flood against a target system attempts to occupy all available resources used to establish TCP connections by sending multiple SYN segments containing incorrect IP addresses. Note that the term SYN refers to a type of connection state that occurs during establishment of a TCP/IP connection.

More specifically, a SYN flood is designed to fill up a SYN queue. A SYN queue is a set of connections stored in the connection table in the SYN-RECEIVED state, as part of the standard three-way TCP handshake. A SYN queue can hold a maximum number of connections in the SYN-RECEIVED state.

Connections in the SYN-RECEIVED state are considered to be half-open and waiting for an acknowledgement from the client. When a SYN flood causes the maximum number of allowed connections in the SYN-RECEIVED state to be reached, the SYN queue is said to be full, thus preventing the target system from establishing other legitimate connections. A full SYN queue therefore results in partially-open TCP connections to IP addresses that either do not exist or are unreachable. In these cases, the connections must reach their timeout before the server can continue fulfilling other requests.

Alleviating SYN flooding

The BIG-IP system includes a feature designed to alleviate SYN flooding. Known as SYN Check, this feature sends information about the flow, in the form of cookies, to the requesting client, so that the SYN-RECEIVED state normally stored in the connection table for the initiated session does not need to be kept. Because the SYN-RECEIVED state is not kept for a connection, the SYN queue cannot be exhausted, and normal TCP communication can continue.

The SYN Check feature complements the existing adaptive reaper feature in the BIG-IP system. While the adaptive reaper handles established connection flooding, SYN Check prevents connection flooding altogether. That is, while the adaptive reaper must work overtime to flush connections, the SYN Check feature prevents the SYN queue from becoming full, thus allowing the target system to continue to establish TCP connections.

Configuring SYN Check activation

To activate the SYN Check feature, you can configure two basic settings: a setting at the global level, and a setting for each virtual server. These values are the global variable syncookie_threshold and the virtual server attribute syncookie_threshold. The threshold numbers that you assign to the global variable and the virtual server attribute specify the number of concurrent connections that can be made to one or more virtual servers prior to the SYN Check feature being activated.

You can configure either a global threshold or a virtual server threshold, or both. When both the global and virtual server thresholds are defined, the lower threshold always takes precedence. Thus, if a virtual server's SYN Check threshold is set to 10,000, and the global threshold is set to 2,000, the BIG-IP system generates SYN cookies when 2,000 concurrent connections have been established.

Activating SYN Check based on a connection threshold

You can configure the BIG-IP system to activate the SYN Check feature when some threshold of connections has been reached on one or all virtual servers. To set the threshold on an individual virtual server, you use the bigpipe virtual command. To set the threshold on all virtual servers, you use the bigpipe global command.

The default global value for the SYN Check threshold is 150,000. For individual virtual servers, SYN Check thresholds are disabled by default.

For example, to set the SYN Check threshold on a global basis to 300,000 concurrent connections, you type the following command:

bigpipe global syncookie_threshold 300000

Running this command causes the BIG-IP system to activate SYN Check when the number of concurrent connections on all virtual servers exceeds 300,000.

To set the SYN Check threshold on an individual virtual server to 10,000 concurrent connections, you type the following command:

bigpipe virtual 10.1.2.3:80 syncookie_threshold 10000

Typing this command causes the BIG-IP system to activate SYN Check when the number of concurrent connections for that virtual server exceeds 10,000.

Activating SYN Check for all connections

Rather than activating SYN Check by defining a specific threshold of connections, you can configure the BIG-IP system to activate SYN Check for all connections, for an individual virtual server only.

You do this by setting the virtual server SYN Check threshold to 0. For example:

bigpipe virtual 10.1.2.3:80 syncookie_threshold 0

By setting the SYN Check threshold on virtual server 10.1.2.3:80 to 0, you effectively cause the BIG-IP system to always send SYN cookies after the very first connection is established.

Tip


While activating SYN Check for all concurrent connections seems to have its advantages, system performance is improved if you define a threshold other than 0. This is because when SYN Check is activated, the client, in response to the target system, is required to return the SYN cookie, incremented by 1, as the acknowledgement number in the ACK flag. This causes some latency that can be avoided if you set a threshold of connections that is considerably higher than 0.

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)