My TCP relationship status? It’s complicated, SYN but no ACK!!
TCP SYN Flood Attack exploits the fundamental weakness in TCP’s three-way handshake mechanism. During normal TCP connection establishment, a client sends a SYN packet, the server responds with SYN-ACK, and the client completes the handshake with an ACK. The server maintains connection state in a backlog queue during this process.
In a SYN flood, which is a type of volumetric DDoS attack, the attackers send a large number of SYN packets with fake source IP addresses. These spoofed packets prevent the server’s SYN-ACK replies from reaching a real client, leaving many half-open connections. The server reserves memory and processing power for each attempt, quickly filling its connection queue.
Once the queue is full, new legitimate requests can’t get through, blocking access. The attack is efficient because it takes little effort to send spoofed SYNs, but the server has to commit real resources for each one. The method exploits TCP’s stateful design, where a server must track each incoming connection. Unlike bandwidth attacks, this one overwhelms the server’s ability to manage new connections.
Key Packet Indicators:
As mentioned above, in a SYN flood, the attacker sends a large number of TCP SYN packets, which are normally used to start a connection, but never completes the handshake. These packets often have fake or inconsistent source IP addresses and ports. The destination port is usually an open service port, like TCP port 80 on a web server, because open ports force the server to allocate resources for each request.
Normal TCP connections use a three-way handshake: SYN, SYN-ACK, and ACK. But in a SYN flood, most packets are SYNs without matching ACKs. The server replies with SYN-ACKs, then waits. Its backlog of half-open connections fills up quickly. Packet captures show many SYNs, lots of SYN-ACKs, and few or no final ACKs. On the server, many connections remain in the SYN_RECV state, visible with tools like netstat.
Since the SYNs often use spoofed IPs, filtering by source is hard. These packets might have odd TTL values or uncommon IP options, but that’s not always the case. The TCP headers may also contain abnormal values, like a sequence number of 0, but this varies.
The main indicator is the skewed traffic pattern: a flood of SYNs with few ACKs or RSTs in return. In normal traffic, SYNs make up a small share. In a SYN flood, they dominate. You might also see some RST packets, often from real IP owners reacting to unexpected SYN-ACKs.
TCP flag analysis helps too. A stream of packets with only the SYN flag and no matching ACK or RST from the client side stands out. Some real clients abort incomplete connections with RST, but spoofed IPs often trigger stray RSTs instead.
This lopsided SYN-to-ACK ratio and the lack of full handshakes are the core signs of a SYN flood.
Wireshark:
- To find all SYNs without ACK: tcp.flags.syn==1 and tcp.flags.ack==0
- Statistics → Conversations → TCP → Sort by “Packets”
