SYN flood attacks can wreak havoc on your server’s resources, potentially crippling its ability to respond to legitimate traffic. Safeguarding against such attacks is crucial for sites that are publicly accessible and want to achieve high uptime. But don’t worry—by the end of this blog, you’ll have a clear understanding of what SYN flood attacks are and how to safeguard your server against them. In this blog, we will talk about what a SYN flood attack is and how to protect your server from such attacks.
Let's first learn what system a SYN flood exploits. In order for a connection to be established, the server and the client machine need to perform a 3 way handshake. The client sends a SYN packet to the server. The server responds with a SYN-ACK, and the connection is finally established by the client sending an ACK packet. An attack exploits this mechanism by flooding the server with SYN packets, which causes the system to issue a SYN-ACK response. Then the system waits for ACK responses from the client, which are never received. The connections stay open, which hogs resources.
There are a couple of ways to protect against such attacks: SYN cookies, controlling the SYN ACK timers and iptabels. Let's discuss these options.
SYN cookies
How does this work?
Instead of allocating memory to track the half-open connection, the server encodes critical information (like the sequence number) into the SYN-ACK packet itself. If the client sends back the ACK as part of the handshake, the server can decode the information from the ACK without needing to have stored the state in memory. This approach allows the server to handle many SYN requests without being overwhelmed by uncompleted connections, as no memory is allocated until the handshake is fully completed.
To enable this you can use the following command
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
To make the change permanent, add the following line to /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1
To reload, issue the following command:
sysctl -pSYN ACK Timer
Resources are freed up quicker by shortening the time that the server waits for an ACK packet. There is no single configuration that controls the time that it takes; rather, it's derived from retransmission count and timeout intervals.
To control the retransmission attempts, you will need to edit the tcp_synack_retries file located in /proc/sys/net/ipv4/ . This value controls how many times the SYN-ACK packet is retransmitted before dropping the connection. The default value is 5. Each point added increases the time exponentially, starting from 1 second so the total timeout time is: ≈ 1 + 2 + 4 + 8 + 16 + 32 = ~63s when set to 5 .
To shorten the time, use the following command:
sysctl -w net.ipv4.tcp_synack_retries=2
To apply the changes, run the command:
sysctl -p
Iptables
We cannot just block SYN packets as this will block all connections to the server so we will need to apply a limit on how many SYN packets the server can receive before it starts dropping them.
Accept new connections
iptables -A INPUT -p tcp -m state --state NEW -m recent --set -j ACCEPT
Limit the connection rate to 20 per second
iptables -A INPUT -p tcp -m state --state NEW -m recent --update --seconds 1--hitcount 20 -j DROP-A INPUT: Appends the rule to the INPUT chain, which handles incoming packets.
-p tcp: Specifies that this rule applies to TCP packets.
-m state --state NEW: The rule applies only to packets that are starting a new connection (i.e., the first packet of a TCP connection).
-m recent --update: This uses the recent module, which tracks IP addresses that match certain conditions (like how many packets an IP has sent in a specified timeframe). The --update option checks if the source IP address has been seen recently.
--seconds 1: Specifies the timeframe in seconds during which the packet count is monitored. In this case, it's 1 second.
--hitcount 20: This defines how many packets are allowed from a single IP address during the specified timeframe (1 second). If 20 packets or more are detected in this time period, the rule is triggered.
-j DROP: This tells iptables to drop the packet if it matches the conditions.
You may need to adjust the hitcount and timeframe to better match your use case.
Conclusion
In this article, we went over what SYN flood attacks are and some configurations that you can do to protect yourself against them. It's important to note that even with these configurations, a large-scale SYN flood attack won't be easily stopped. In such cases, it may be necessary to work together with your ISP or use a third-party solution to get adequate protection.