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

Also:

A 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 hide their IP address at all. As a result of the attacker using a single source device with a real IP address to create the attack, the attacker is highly vulnerable to discovery and mitigation. In order to create a half-open state on the targeted device, the hacker prevents their machines from responding to the server’s SYN-ACK packets. This is often achieved through firewall rules that block outgoing packets other than SYN packets, or by filtering any incoming SYN-ACK packets before they reach the malicious user’s machine. In practice, this method is rarely (if ever) used, as mitigation is fairly straightforward – simply block the IP address of each malicious system. If the attacker is using a botnet such as the Mirai botnet, they will not care about hiding the IP address of the infected device.
2. Spoofed Attack: A malicious user can also spoof the IP address on every SYN packet they send in order to hamper mitigation efforts and make it harder to discover their identity. While the packets may be spoofed, those packets can potentially be traced back to their source. It is difficult but not impossible to do this kind of investigative work, 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 tracing the attack back to its source is low. For an additional layer of obfuscation, the 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 will generally not bother hiding the IP address of the infected device.

Using a SYN flood attack, a bad actor can attempt to create a denial of service in a targeted device or service with significantly less traffic than other DDoS attacks.

Rather than 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.

If the attacker can determine the size of the backlog and how long each connection is left open before timing out,

the attacker can target the exact parameters needed to disable the system,

thereby reducing the total traffic to the minimum required to create the denial of service.

How is a SYN Flood Attack Mitigated?

Vulnerability to SYN floods has been known for a long time and a number of mitigation paths have been used. Some of the methods include:

Increasing the Backlog Queue

Each operating system on a targeted device has a certain number of half-open connections it will allow.

One response to large volumes of SYN packets is to increase the maximum

number of possible half-open connections that the operating system will allow.

In order to successfully increase the maximum backlog, the system must reserve additional memory resources to handle all the new requests.

If the system does not have enough memory to be able to handle the increase in backlog queue size,

system performance will be negatively affected, but this may still be preferable to a 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 legitimate connections are able to be fully established in less time than it takes to fill the backlog with malicious SYN packets.

This particular defense fails when the attack volume increases, or if the backlog size is too small to be practical.

SYN Cookies

This strategy involves the creation of a cookie by the server.

In order to avoid the risk of dropping connections when the backlog fills up,

the server responds to each connection request with a SYN-ACK packet but then drops the SYN request from the backlog, removing the request from memory and leaving the port open and ready for a new connection.

If the connection is a legitimate request, and a final ACK packet is sent from the client machine to the server, the server will then (with some limitations) reconstruct the SYN backlog queue entry.

Although these mitigation efforts lose some information about the TCP connection, they are better than allowing a denial of service to occur for legitimate users as a result of the attack.

How Do You Mitigate SYN Flood Attacks?

By standing between the targeted server and the SYN flood. When an initial SYN request is made, the handshake process is handled in the cloud, while the connection to the targeted server is blocked until the TCP handshake is complete. This strategy takes the resource cost of maintaining connections with bogus SYN packets away from the targeted server.