A SYN flood, aka TCP-SYN flood, is one of the oldest forms of DDoS attacks, whose goal is to make a server unavailable to legitimate traffic by consuming all the server’s available resources. The attacker repeatedly sends initial connection request (SYN) packets, thus overwhelming all available ports on a server, causing it to respond sluggishly or not at all to legitimate traffic.
A SYN flood exploits a vulnerability in the TCP three-way handshake. In a normal situation between client and server, the TCP three-way handshake looks like this:
- Client sends SYN (synchronize) message to the server, requesting a connection.
- Server sends back SYN-ACK (synchronize-acknowledge) message to the client, acknowledging their request.
- The client responds with an ACK (acknowledge) message, completing the sequence and leaving the TCP connection open to send and receive other data.
In a SYN flood attack, the attacker repeatedly sends SYN packets to every port on the targeted server, usually using a fake IP address. The unwitting server responds to each attempt with a SYN-ACK packet from each of its open ports. The malicious client either doesn’t receive the SYN-ACK because of using a spoofed IP address, or doesn’t reply with the expected ACK.
Either way, service will be disrupted while the server under attack leaves an open port ready to receive acknowledgement of its SYN-ACK packet. Before the connection times out, another SYN packet arrives. An increasing number of half-open connections build up and eventually the server’s connection overflow tables fill, denying service to legitimate traffic requests, and potentially leading to the server malfunctioning or crashing.
Essentially, with SYN flood DDoS, the attacker sends TCP connection requests more quickly than the targeted machine can process them, resulting in network saturation.
If an attacker works out the size of the backlog in the target’s operating system and how long each connection will stay open before it times out, they can determine the exact parameters required to disable the system, and only apply the minimum level of SYN packets to create denial-of-service. It’s therefore a highly leveraged attack despite being a relatively old attack, since only a small amount of bandwidth and CPU can exhaust the resources of a large number of servers. It is also often difficult to track back to the original attacker because of the volume of forged source addresses used in this type of DDoS.
As SYN floods have been around for some time, there are various approaches to mitigation:
(i) SYN cookies – The use of SYN cookies allows a server to avoid dropping connections when its SYN queue is overloaded with requests. The technique’s inventor, Daniel J. Bernstein, describes SYN cookies as “particular choices of initial TCP sequence numbers by TCP servers”. When employing SYN cookies, the server responds to every connection request with a SYN-ACK acknowledgement then immediately drops the request from the backlog, removing it from memory and leaving the port ready to receive a new connection. If the server does receive an ACK response from the client, the server can reconstruct the SYN queue entry by using information encoded in the TCP sequence number.
(ii) Increasing the backlog queue – Each operating system will only be able to handle a certain number of half-open connections. One response to SYN floods is to increase the maximum backlog. This involves additional memory resources to handle the volume of new requests. If the system doesn’t have enough memory to do so, system performance will diminish; however, this can be preferable to denial-of-service.
(iii) Recycling the oldest half-open TCP connection – This mitigation strategy involves overwriting the oldest half-open connection as soon as the backlog is filled. It requires that legitimate connections can be fully made before the backlog can re-fill with malicious SYN packets. It fails when the backlog size is too small or the attack volume increases.