SYN flood attack

As a denial-of-service attack (DoS), a SYN flood aims to deprive an online system of its le­git­im­ate use. Con­cep­tu­ally, a DoS attack roughly compares to the mass mailing of mean­ing­less letters to a gov­ern­ment­al office. If the mailbox becomes over­crowded, 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 op­er­a­tions.

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 vul­ner­ab­il­ity in network com­mu­nic­a­tion to bring the target system to its knees. A SYN flood works dif­fer­ently to volu­met­ric 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 cy­ber­at­tack directed against a network con­nec­tion. The attacker abuses the three-way handshake of the Trans­mis­sion Control Protocol (TCP). Instead of ne­go­ti­at­ing a con­nec­tion between a client and a server as intended, many half-open con­nec­tions 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 con­nec­tion es­tab­lish­ment works and how the principle is disturbed during a SYN flood attack.

The Trans­mis­sion Control Protocol (TCP), together with the Internet Protocol (IP), is one of the corner­stones of the Internet. Since TCP is a con­nec­tion-oriented protocol, the client and server must first negotiate a con­nec­tion before they can exchange data with the other. The three-way handshake is used for this:

1. The client sends a SYN packet (“syn­chron­ise”) to the server. – “Hello, I would like to establish a con­nec­tion with you.”
2. The server responds with a SYN/ACK packet (ACK = “ac­know­ledge”), and creates a data structure known as a “Trans­mis­sion Control Block” (TCB) for the con­nec­tion in the SYN backlog. – “Okay, then please use the following con­nec­tion para­met­ers.”
3. The client answers the SYN/ACK packet with an ACK packet and completes the handshake. The con­nec­tion is ready and data can be trans­mit­ted in both dir­ec­tions. On the server side, the Trans­mis­sion Control Block is removed from the SYN backlog. – “Great, thank you. Let’s get started!”

This process runs in the back­ground 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 con­duct­ing pen­et­ra­tion tests. It can be used to simulate a range of network attacks. For security reasons, we will only show the ap­prox­im­ate 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 doc­u­ment­a­tion 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 de­nom­in­at­or 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 cor­res­pond­ing 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 un­in­volved parties. If a machine receives a SYN/ACK packet from a server without having pre­vi­ously sent a SYN packet to that server, the machine sends an RST packet (RST = "reset"), thereby ending the con­nec­tion. A clever attacker also wants to prevent this in order to keep the largest possible number of con­nec­tions 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 con­fig­ures the firewall of their machine ac­cord­ingly. 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 re­l­at­ively 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 ac­ci­dent­ally affected systems do not respond to the SYN/ACK responses from the attacked server with an RST packet, which would thus terminate the con­nec­tion.

In this “dis­trib­uted” attack variant of the SYN flood, the attack is carried out sim­ul­tan­eously by many computers. It is usually a com­bin­a­tion 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 re­flec­tion SYN flood attack. The attacker spoofs the victim’s IP address, and starts a DDoS SYN flood against one or more un­in­volved 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 mul­ti­plied. 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 ap­prox­im­ately 1994. Therefore, a number of effective coun­ter­meas­ures now exist. However, some have negative side effects or only work under certain con­di­tions. In general, it is no trivial matter to dis­tin­guish malicious SYN packets from le­git­im­ate ones. Most known coun­ter­meas­ures are used on the server, but there are also cloud-based solutions.

The SYN backlog mentioned pre­vi­ously is part of the operating system. Con­cep­tu­ally, you can think of the SYN backlog as a spread­sheet. Each line contains the in­form­a­tion for es­tab­lish­ing a single TCP con­nec­tion. The operating system first manages the con­nec­tions. Only when a con­nec­tion has been es­tab­lished by com­plet­ing the three-way handshake is it then passed on to the ap­plic­a­tion 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 con­nec­tion from the SYN backlog when it is full. This creates space for a new half-open con­nec­tion. In com­bin­a­tion with a suf­fi­ciently large SYN backlog, this approach can lead to the system remaining ac­cess­ible during a SYN flood attack. However, this method is in­ef­fect­ive for high-volume attacks.

The idea behind the SYN cache is simple: Instead of storing a complete Trans­mis­sion Control Block (TCB) in the SYN backlog for each half-open con­nec­tion, only a minimal TCB is kept. The technique uses cryp­to­graph­ic hashing to prevent the attacker from guessing critical in­form­a­tion about the con­nec­tion. The SYN cache has proven to be an effective technique. Con­nec­tion 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 Trans­mis­sion Control Block is not used as a data structure in this case. Instead, the relevant con­nec­tion para­met­ers are encoded in the sequence number of the SYN/ACK packet. Cryp­to­graph­ic hashing ensures that the attacker cannot simply guess the sequence number.

A le­git­im­ate 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 cryp­to­graph­ic­ally verify the con­nec­tion es­tab­lish­ment and to establish the con­nec­tion. The use of SYN cookies offers effective pro­tec­tion against SYN flood attacks. However, under certain cir­cum­stances, it can lead to per­form­ance losses.

A com­bin­a­tion of both tech­niques 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 tech­niques 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-dis­trib­uted cloud providers are in­creas­ingly being used.

The idea is for the incoming DDoS data stream to be dis­trib­uted across many in­di­vidu­al systems. This disperses the total load of the attack and reduces the peak load on each in­di­vidu­al system. As such, it enables the network to withstand even severe attacks.

In addition to filtering tech­niques, Anycast tech­no­logy has es­tab­lished itself at the network level. Inquiries to systems that are connected via Anycast are auto­mat­ic­ally routed to a server that is closest geo­graph­ic­ally. A global DDoS attack thus has less of an impact at the local level. Anycast networks like the one from Cloud­flare impress with their elegance and re­si­li­ence.

The Cloud­flare blog offers exciting insight into the ongoing de­vel­op­ments to combat SYN flood attacks. In addition to bot-based mit­ig­a­tion strategies, SYN packet sig­na­tures seem very promising. Such sig­na­tures create human-readable fin­ger­prints of the incoming SYN packets. Con­clu­sions can be drawn from the fin­ger­print about the operating system of the machine that ori­gin­ally sent the SYN package. Packets sent during a SYN flood attack do not fit the pattern when the fin­ger­prints are analysed and are filtered ac­cord­ingly.