SYN Flooding is a type of DDoS attack that creates billions of fake connections to a server in order to take it offline. In this post, we will discuss how a SYN flood attack works, and how you can block a SYN flood using SYN Proxy.

What is a SYN Flood?

SYN flooding is when an attacker uses a botnet to send a large volume of SYN packets to a server. SYN floods usually don’t generate an excessive amount of bandwidth, but they do generate a high incoming packet rate. Such a high packet rate can be difficult for a server to handle. Additionally, because a SYN packet is the first packet in opening a connection, there is no easy way to distinguish a real client connecting for the first time from a bot in the botnet.

SYN floods are particularly dangerous because they always solicit a response from the server. A compliant server will reply with a SYN+ACK packet accepting the connection. Alternatively, the server can rely with a RST packet if the connection should not be opened (possibly due to no service listening on the port). Additionally, a Linux server will, by default, open a connection tracking entry when a SYN packet is received. The server will retry sending SYN+ACK packets multiple times until an ACK response is received. A Linux server can only have so many connection tracking entries in its conntrack table at any given time. SYN Flooding will fill up this table very quickly, preventing real connections from succeeding.

Why is spoofing dangerous?

Normally, you would be able to detect if an IP address is misbehaving and block that IP address. But because the SYN packet happens first in the TCP connection handshake, the source IP address can be spoofed. Because of this, IP blocks are ineffective, and can actually be used as an attack vector in and of itself.

Imagine that you are running a service that, in part, receives traffic from Cloudflare. An attacker could execute a SYN flood spoofed as Cloudflare’s IP ranges. If you were to block the attacking IPs, you would actually be blocking legitimate traffic. Because of this fact, IP blocking is an ineffective defense against SYN flooding. More sophisticated protection methods are required.

What about SYN Cookies?

SYN Cookies are a mitigation built into the Linux kernel that can help protect against small-scale SYN flooding attacks. It is generally a good idea to enable SYN cookies. You can do this on any modern Linux server by adding the following line to /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1

When your server detects a SYN flood, it will print a line to your kernel log and enable the SYN cookies mitigation. Upon receiving SYN packets, the server will calculate a special sequence number, instead of randomly generating one. Crucially, it will not create an entry in its connection table. If the server receives an acknowledgement back from the client, it uses the information in that acknowledgement packet to re-construct what the original SYN packet must have been, computes what its sequence number should have been, and then compares that against the acknowledgement number in the client’s ACK packet. If everything matches up, then it assumes that the client is real and accepts the connection. Otherwise, it drops the packet as invalid.

Unfortunately, this approach does not scale well. In the best case, it is limited to the maximum throughput that the server can handle, which is typically far less than even modest SYN flooding attacks are able to achieve.

Not only that, but even with SYN Cookies enabled, a SYN flood can still create conntrack entries! If you run SYN Cookies on a publicly-accessible port, these entries will still be created and can still fill up your conntrack tables. This can be partially mitigated by preventing connection tracking on inbound connections (-j NOTRACK in iptables). The better way is to use SYN Proxying.

How does SYN Proxy work?

Instead of executing the SYN Cookie logic on the client, SYN Proxy can move the logic to an external system. Such an external system can be horizontally scaled and can be implemented in a way that does not require the targeted server to ever see any dangerous levels attack traffic.

Such an approach is much more difficult than just implementing SYN Cookies locally. The DDoS filter has to pretend to be the server when talking to the client, and it has to pretend to be the client when talking to the server. Let’s go through an example to understand how this works in more detail.

First, the client sends a SYN packet to the server. This packet is intercepted by the DDoS filter which computes an acknowledgement number, creates a TCP SYN+ACK packet, creatively encodes some data about the connection in the TCP options fields, and then sends it back to the client.

Second, the client replies with an ACK packet back to the server. This packet is again intercepted by the DDoS filter, which does a similar verification process as in SYN Cookies.

Third, the DDoS filter now has to generate a SYN packet to send to the server. It sets the source IP address to the IP address of the client, and the sequence number to match the original sequence number sent by the client (computed from the ACK packet sent by the client in step 2). It also reconstructs the client’s original TCP options and passes those along to the server as well.

Fourth, the server sends back a SYN+ACK packet to the DDoS filter accepting the client’s connection. This stage is tricky because now the server has generated a random sequence number, but this does not match the sequence number of the client. The DDoS filter’s main role at this stage is to compute a translation factor. This translation factor is later used to translate sequence numbers between the client and server.

Lastly, the DDoS filter has to send an ACK packet back to the server, simulating the ACK packet that the client already sent, finalizing the connection.

At this point, both sides see a fully established TCP connection and can begin transferring data. The filter is still not done though. As the client’s acknowledgement number and the server’s sequence number are different, the filter’s job is to translate this number back and forth between the client and the server so that they can understand each other. Additionally, the filter needs to continue watching the connection as the client may still misbehave after this point.

How can I use SYN Proxy?

HelixNodes features a fully automatic, no-configuration-required transparent SYN Proxy implementation in our custom-built DPDK-based DDoS mitigation stack. This technology is built-in for all plans and services. Our implementation transparently watches all of your server’s network traffic to understand which services you are running on your server. Then, when an attack begins, we can immediately begin SYN proxying within 100ms.

Additionally, HelixNodes’ custom DDoS mitigation software will continue to monitor all connections to ensure that clients don’t establish an abnormal number of connections, send an abnormal amount of data over those connections, send invalid data, and much more. Our filters are each capable of handling over 100Gbps of traffic, and is infinitely horizontally scalable. This makes the system capable of handling astronomically high levels of attack traffic.

If you are interested in trying out HelixNodes’ DDoS mitigation, it is available on all VPS and Dedicated Server plans. We also sell IP transit services and on-premise DDoS mitigation services. Contact us using the chat button at the bottom of this page to learn more!