[Code] SYN Flooding — From Principle to Practice
Last Update:
Word Count:
Read Time:
Introduction
This article introduces one of the most common stress-testing methods——SYN flooding——from its underlying principles to practical implementation. A hands-on flooding experiment is also included.
Disclamer
The scripts provided in this article are for educational purposes and authorized stress testing only. Do NOT use them for illegal activities.
Anyone who abuses this knoeledge mut take full responsibility for their actions.
What Is SYN
Before understanding what SYN is, you should first understand how TCP handshaking works.
TCP is a reliable, connection-oriented protocol. Its connection establishment process is called the three-way handshake.
The client sends a SYN (Synchronize) packet to the server.
The server replies with a SYN+ACK (Synchronize + Acknowledgement) packet.
After receiving the SYN+ACK, the client responds with an ACK packet.
Once these steps are completed, a TCP connection between the client and server is successfully established.
How SYN Flooding Happens.
TCP was originally designed to provide reliable communication. Security considerations were not a primary concern at that time.
SYN flooding exploits the initial stage of the TCP handshake.
When a server receives a SYN packet, the corresponding socket enters the SYN_RECEIVED state. The server then sends a SYN+ACK packet and waits for the final ACK from the client.
If 1,000 clients attempt to connect, the server must maintain 1,000 half-open connections.
If millions of clients do the same, the server may be unable to handle such a large number of pending connections.
This situation is commonly referred to as TCP flooding.
Now, what happens if the server never receives the final ACK packet?
The answer is simple:
The half-open connection will eventually be terminated after a timeout
(usually around 1 minute, sometimes longer).
However, during this waiting period, the connection still occupies server resources.
Since each listening port has a limited backlog queue, once all slots are filled, the server can no longer accept new incoming connections—even from legitimate users.
A simple analogy:
Imagine someone occupying a bathroom while playing on their phone.
As long as they stay inside, others cannot use it.
This is known as resource exhaustion.
Why SYN Flooding is a headache
SYN flooding is particularly problematic because:
Half-open connections consume resources for a relatively long time.
IP and TCP headers can be easily spoofed.
As a result, an attacker can construct SYN packets with fake source IP addresses, meaning the server will never receive the final ACK packet.
Additionally, a SYN flooding attack does not necessarily require a botnet, making it easier to execute compared to other types of DDoS attacks.
Lab
Environment setting up
| Device | IP | Description |
|---|---|---|
| Ubuntu 64-bit(VM) | 172.20.10.2 | Target device. |
| Windows 10 | 172.20.10.3 | Attacker device. |
Tool
| Name | Introduction |
|---|---|
| LaserGunDDoS | Flooding script. |
Stress testing
Attacker:1
python main.py "Wi-Fi"
1 | |
1 | |
- Notice: The target port that you want to attack must be open.
1 | |
Target:1
$ netstat -ano | grep "SYN_RECV"
Notice that the source hosts are all fake.
Mitigation & Modern Defenses
Modern operating systems implement several mechanisms to mitigate SYN flooding attacks.
One common approach is SYN cookies, which allow the server to avoid allocating resources
until the final ACK packet is received.
Other mitigations include increasing the TCP backlog size, rate limiting incoming SYN packets,
and deploying firewall or IDS/IPS rules.
Conclusion
This articles describes the underlying priciples of SYN flooding. Furthermore, it demonstrates the implementations, it also provides the modern defnese of this kind of flooding.