What’s a SYN Flood Attack?
What’s SYN?
You are probably aware of SYN, which stands for synchronize but here’s a quick recap of what it is. So, every time your browser requests for a web page from the web server, they must establish a connection between each other. So they just shake hands, verify themselves and set up a connection i.e. they follow the TCP 3-way Handshake mechanism.
Your machine sends the first message — SYN which is TCP packet along with a sequence number, let’s say m. Once the server receives it, it replies with a SYN + ACK packet acknowledging the received message. Along with this, it tags along its sequence number and the ack number which is the next expected sequence number from the client. The ack number is simply computed by adding the previous sequence number and the received packet’s size. Now, if the ack is verified, the client replies with ACK and sends its ack number along with it. If the ack sent is verified, the server starts the actual data transfer. The connection stays open till the FIN packets are exchanged.
Server’s side of the story
Here’s what happens at the server during this handshake process. When client sends the first SYN, a half open connection is established. Meanwhile, the server process adds this request in the TCB queue. TCP keeps information regarding each of the requests in TCB — Transmission Control Block, a complex data structure which stores the socket numbers, buffers, sequence numbers and the current segment. Only once the server receives the ACK, it dequeues the entry from TCB making space for new requests while converting the half open connection to a fully established connection.
Now, what is the attack and how it is carried on?
SYN flood is basically as DoS / DDoS attack on the server. The attacker floods the server with SYN packets making the server unresponsive. So the attacker sends multiple SYN requests to the server. The server stores the request in the TCB and establishes a half open connection, filling up the whole TCB queue. It replies with SYN + ACKs to all the SYN requests. But, the attacker machine doesn’t reply back with the ACK message. So the server won’t be able to empty it’s TCB queue and is stuck in the half open connection state as the confirmation for the client is still not received. So, this blocks the TCB queue completely and puts the server in a state where it can not accept any more SYN packets from legitimate users thus making the server completely unresponsive. This is how the server ends up in a Denial of Service state.
But, with the usage of firewalls this could be avoided for a while as the firewall blocked the IPs which sends continuous SYN requests in high numbers. However, attackers started using the DDos technique — Distributed Denial of Service i.e. they use multiple machines or just multiple IPs to send the SYN. This way the firewall will not be able to block those IPs, thinking they are legitimate requests.
Countermeasures or Recovery?
Fixing the server after the attack is only possible if the attackers send their ACK responses thus emptying the queue or if the server is reachable, RST packet can be sent where the whole TCB queue will be dropped. However, there are quite a few prevention methods available.
Get ganupp’s stories in your inbox
Join Medium for free to get updates from this writer.
Using SYN cookies is a prevention method where the server computes H the SYN cookie after receiving SYN. This time the request is still not accommodated in the TCB queue. Now, the server responds with this specially crafted SYN + ACK message. Only when the client responds with an ACK packet, the server reveals the SYN cookie and verifies if the received value is valid. This is then reused to construct the TCB record.
But here’s the hitch, if the attacker is capable of spoofing SYN packets, he can easily spoof the ACK packets as well. In order to mitigate that, the server waits until the ACK before allocating resources. So only if the valid packet is received in time, the resources are allocated.
That’s not all, the attacker can flood with ACK packets and the server considers it to be valid and makes it a fully open connection and allocates resources.
Here’s what the server does now. Instead of using a random sequence number, the server computes a secret hash value keyed from the information in the packet received thus minimizing the risk.
To prevent this, you can just turn on the SYN cookie countermeasure on your Linux machine with the following command,
sudo sysctl -w net.ipv4.tcp_syncookies = 1That’s pretty much about the TCP SYN Flood Attack, the process and its mitigation techniques.
Thanks for stopping by this article and I really hope you did find out something new and useful today 😊!
Have fun learning. See you next time! Until then check out my other stories at AskPranaviSree.
Byee!
