SYN flood attack

An SYN flood exploits a TCP/IP handshake vulnerability in an attempt to disrupt a web service.

What is an SYN flood attack?

An SYN flood (half-open attack) is a denial-of-service (DDoS) attack aiming to make a server unavailable to legitimate traffic by consuming all available server resources. By repeatedly sending initial connection request (SYN) packets, the attacker can overwhelm all open ports on a targeted server machine, causing the targeted device to respond to legitimate traffic sluggishly.

How does an SYN flood attack work?

SYN flood attacks work by exploiting the handshake process of a TCP connection. Under normal conditions, a TCP connection exhibits three distinct processes to make a connection.

1. First, the client sends an SYN packet to the server to initiate the connection.
2. The server then responds to that initial packet with an SYN/ACK packet to acknowledge the communication.
3. Finally, the client returns an ACK packet to acknowledge the receipt of the packet from the server. After completing this packet sending and receiving sequence, the TCP connection is open and able to send and receive data.

To create denial-of-service, an attacker exploits the fact that after an initial SYN packet has been received, the server will respond with one or more SYN/ACK packets and wait for the final step in the handshake. Here’s how it works:

1. The attacker sends a high volume of SYN packets to the targeted server, often with spoofed IP addresses.
2. The server then responds to each one of the connection requests and leaves an open port ready to receive the response.
3. While the server waits for the final ACK packet, which never arrives, the attacker continues to send more SYN packets. The arrival of each new SYN packet causes the server to temporarily maintain a new open port connection for a specific time. Once all the available ports have been utilized, the server cannot function normally.

In networking, when a server leaves a connection open but the machine on the other side of the connection is not, the connection is considered half-open. In this type of DDoS attack, the targeted server is continuously leaving open connections and waiting for each connection to time out before the ports become available again. The result is that this type of attack can be considered a “half-open attack”.

An SYN flood can occur in three different ways:

1. Direct attack: A SYN flood where the IP address is not spoofed is known as a direct attack. In this attack, the attacker does not mask their IP address. As a result of the attacker using a single source device with an actual IP address to create the attack, the attacker is highly vulnerable to discovery and mitigation. The hacker prevents the machine from responding to the server’s SYN-ACK packets to create a half-open state on the targeted device. This is often achieved by firewall rules that stop outgoing packets other than SYN packets or by filtering out any incoming SYN-ACK packets before they reach the malicious user’s machine. In practice, this method is used rarely (if ever), as mitigation is relatively straightforward – block the IP address of each malicious system. If the attacker is using a botnet such as the Mirai botnet they won’t care about masking the IP of the infected device.
2. Spoofed Attack: A malicious user can also spoof the IP address on each SYN packet they send to inhibit mitigation efforts and make their identity more challenging to discover. While the packets may be spoofed, they can be traced back to their source. It’s challenging to do this sort of detective work, but it’s not impossible, especially if Internet service providers (ISPs) are willing to help.
3. Distributed attack (DDoS): If an attack is created using a botnet, the likelihood of tracking the attack back to its source is low. For an added level of obfuscation, an attacker may have each distributed device also spoof the IP addresses from which it sends packets. If the attacker is using a botnet such as the Mirai botnet, they generally won’t care about masking the IP of the infected device.

Using an SYN flood attack, a bad actor can attempt to create denial-of-service in a target device or service with substantially less traffic than other DDoS attacks. Instead of volumetric attacks, which aim to saturate the network infrastructure surrounding the target, SYN attacks only need to be larger than the available backlog in the target’s operating system. Suppose the attacker can determine the size of the backlog and how long each connection will be left open before timing out. In that case, the attacker can target the exact parameters needed to disable the system, thereby reducing the total traffic to the minimum necessary amount to create denial-of-service.

How is an SYN flood attack mitigated?

SYN flood vulnerability has been known for a long time, and several mitigation pathways have been utilized. A few approaches include:

Increasing Backlog queue

Each operating system on a targeted device has a certain number of half-open connections that it will allow. One response to high volumes of SYN packets is to increase the maximum number of possible half-open connections the operating system will allow. To successfully increase the full backlog, the system must reserve additional memory resources to deal with all the new requests. Suppose the system does not have enough memory to handle the increased backlog queue size. In that case, system performance will be negatively impacted, but that still may be better than denial-of-service.

Recycling the Oldest Half-Open TCP connection

Another mitigation strategy involves overwriting the oldest half-open connection once the backlog has been filled. This strategy requires that the legitimate connections can be fully established in less time than the backlog can be filled with malicious SYN packets. This defense fails when the attack volume is increased or the backlog size is too small to be practical.

SYN cookies

This strategy involves the creation of a cookie by the server. To avoid the risk of dropping connections when the backlog has been filled, the server responds to each connection request with an SYN-ACK packet but then drops the SYN request from the backlog, removing the request from memory and leaving the port open and ready to make a new connection. If the connection is a legitimate request, and a final ACK packet is sent from the client machine back to the server, the server will then reconstruct (with some limitations) the SYN backlog queue entry. While this mitigation effort does lose some information about the TCP connection, it is better than allowing denial-of-service to occur to legitimate users due to an attack.