SYN flood attack

As a denial-of-service attack (DoS), a SYN flood aims to deprive an online system of its legitimate use. Conceptually, a DoS attack roughly compares to the mass mailing of meaningless letters to a governmental office. If the mailbox becomes overcrowded, the office will no longer receive the documents they need and they can no longer be processed. The attacker will have achieved their goal: the breakdown of regular operations.

A SYN flood is a DoS attack. The attacker sends a flood of malicious data packets to a target system. The intent is to overload the target and stop it working as it should.

Like the ping of death, a SYN flood is a protocol attack. These attacks aim to exploit a vulnerability in network communication to bring the target system to its knees. A SYN flood works differently to volumetric attacks like ping flood, UDP flood, and HTTP flood. The attacker’s focus with these attacks is on flushing the target from the network with as much bandwidth as possible.

Also known as a “half-open attack”, a SYN flood is a cyberattack directed against a network connection. The attacker abuses the three-way handshake of the Transmission Control Protocol (TCP). Instead of negotiating a connection between a client and a server as intended, many half-open connections are created on the server. This ties up resources on the server that are then no longer available for actual use.

Let’s look at how the normal TCP connection establishment works and how the principle is disturbed during a SYN flood attack.

The Transmission Control Protocol (TCP), together with the Internet Protocol (IP), is one of the cornerstones of the Internet. Since TCP is a connection-oriented protocol, the client and server must first negotiate a connection before they can exchange data with the other. The three-way handshake is used for this:

1. The client sends a SYN packet (“synchronise”) to the server. – “Hello, I would like to establish a connection with you.”
2. The server responds with a SYN/ACK packet (ACK = “acknowledge”), and creates a data structure known as a “Transmission Control Block” (TCB) for the connection in the SYN backlog. – “Okay, then please use the following connection parameters.”
3. The client answers the SYN/ACK packet with an ACK packet and completes the handshake. The connection is ready and data can be transmitted in both directions. On the server side, the Transmission Control Block is removed from the SYN backlog. – “Great, thank you. Let’s get started!”

This process runs in the background every time you connect to a server to visit a website or check your email.

An attacker uses special software to trigger a SYN flood. For example, the popular hping tool is used for conducting penetration tests. It can be used to simulate a range of network attacks. For security reasons, we will only show the approximate pattern of the hping code for a SYN flood with a spoofed IP address:

The options of the command are of interest:

• The ‘--syn’ option tells the tool to use TCP as the protocol and to send SYN packets.
• The ‘--flood’ option is important. According to the documentation of the hping command, this means that packages are sent as quickly as possible.
• The attacker spoofs their IP address with the option ‘--rand-source’. Instead of the actual address of the sender, a random IP address is entered.

There are several ways to perform a SYN flood attack. The common denominator between all of them is that the attacker aims to keep the server busy for as long as possible. To do so, the attacker has to ensure that the SYN/ACK packets sent by the server are not answered. If the attacker’s machine responds with an ACK packet, the corresponding entry on the server will be deleted from the SYN backlog.

If the attacker spoofs their IP address, the server’s SYN/ACK packets go to uninvolved parties. If a machine receives a SYN/ACK packet from a server without having previously sent a SYN packet to that server, the machine sends an RST packet (RST = "reset"), thereby ending the connection. A clever attacker also wants to prevent this in order to keep the largest possible number of connections half-open on the server.

In the case of a direct attack, the attacker starts the SYN flood attack under their own IP address. In order to ensure that incoming SYN/ACK packets are discarded, the attacker configures the firewall of their machine accordingly. Another approach is to limit network traffic to outgoing SYN packets.

Since the attacker operates under their own IP address during a direct attack, which is relatively easy to detect, this type of attack is rarely used.

Attacks with spoofed IP addresses are more common. The attacker enters a fake IP address in the sender field of the SYN packets, thereby obscuring their actual place of origin. Attackers prefer IP addresses that are not in use at the time of the attack. This ensures that accidentally affected systems do not respond to the SYN/ACK responses from the attacked server with an RST packet, which would thus terminate the connection.

In this “distributed” attack variant of the SYN flood, the attack is carried out simultaneously by many computers. It is usually a combination of hijacked machines, called a botnet. The botnet’s zombie computers are under the control of the attacker and send SYN packets to the target on their command.

A server usually responds to a single SYN packet with multiple SYN/ACK packets. An attacker could take advantage of this to trigger a reflection SYN flood attack. The attacker spoofs the victim’s IP address, and starts a DDoS SYN flood against one or more uninvolved servers. Each of the servers responds to each incoming SYN packet with several SYN/ACK packets that are sent to the victim. The result is that network traffic is multiplied. The victim’s machine is bombarded with a flood of SYN/ACK packages and collapses under the load.

The general principle of action of a SYN flood has been known since approximately 1994. Therefore, a number of effective countermeasures now exist. However, some have negative side effects or only work under certain conditions. In general, it is no trivial matter to distinguish malicious SYN packets from legitimate ones. Most known countermeasures are used on the server, but there are also cloud-based solutions.

The SYN backlog mentioned previously is part of the operating system. Conceptually, you can think of the SYN backlog as a spreadsheet. Each line contains the information for establishing a single TCP connection. The operating system first manages the connections. Only when a connection has been established by completing the three-way handshake is it then passed on to the application waiting at the port and removed from the SYN backlog.

One of the simplest ways to reinforce a system against SYN flood attacks is to enlarge the SYN backlog. Since each entry in the SYN backlog consumes a certain amount of memory on a computer, the number of entries is limited. By default, this limit on Linux is a few hundred entries. However, that value can easily be increased. In principle, the SYN backlog can contain thousands of entries. That way, smaller SYN flood attacks can be buffered.

A related approach is to delete the oldest half-open connection from the SYN backlog when it is full. This creates space for a new half-open connection. In combination with a sufficiently large SYN backlog, this approach can lead to the system remaining accessible during a SYN flood attack. However, this method is ineffective for high-volume attacks.

The idea behind the SYN cache is simple: Instead of storing a complete Transmission Control Block (TCB) in the SYN backlog for each half-open connection, only a minimal TCB is kept. The technique uses cryptographic hashing to prevent the attacker from guessing critical information about the connection. The SYN cache has proven to be an effective technique. Connection data can only be lost in a few special cases.

The concept of the SYN cache continued with the invention of SYN cookies in 1996. The Transmission Control Block is not used as a data structure in this case. Instead, the relevant connection parameters are encoded in the sequence number of the SYN/ACK packet. Cryptographic hashing ensures that the attacker cannot simply guess the sequence number.

A legitimate client replies to the SYN/ACK packet with an ACK packet and uses the specially prepared sequence number. The server uses the sequence number of the ACK packet to cryptographically verify the connection establishment and to establish the connection. The use of SYN cookies offers effective protection against SYN flood attacks. However, under certain circumstances, it can lead to performance losses.

A combination of both techniques can also be used. The SYN cache is used in normal operation. If the SYN cache is full, the system switches to SYN cookies. The positive aspects of both techniques are thus combined.

The fight against DoS attacks is as old as the Internet itself. However, modern attackers have far more firepower at their disposal thanks to botnets. The resulting DDoS attacks, with their enormous flood of data, can bring even the strongest systems to their knees. Therefore, the services of large, globally-distributed cloud providers are increasingly being used.

The idea is for the incoming DDoS data stream to be distributed across many individual systems. This disperses the total load of the attack and reduces the peak load on each individual system. As such, it enables the network to withstand even severe attacks.

In addition to filtering techniques, Anycast technology has established itself at the network level. Inquiries to systems that are connected via Anycast are automatically routed to a server that is closest geographically. A global DDoS attack thus has less of an impact at the local level. Anycast networks like the one from Cloudflare impress with their elegance and resilience.

The Cloudflare blog offers exciting insight into the ongoing developments to combat SYN flood attacks. In addition to bot-based mitigation strategies, SYN packet signatures seem very promising. Such signatures create human-readable fingerprints of the incoming SYN packets. Conclusions can be drawn from the fingerprint about the operating system of the machine that originally sent the SYN package. Packets sent during a SYN flood attack do not fit the pattern when the fingerprints are analysed and are filtered accordingly.