A SYN flood is perhaps one of the most common forms of DDoS attack seen today. SYN floods rely on exploiting how a basic TCP connection is formed, essentially. TCP connections take place in three stages (commonly known as the three-way handshake):
1. SYN. During this stage, a client (such as a desktop computer, laptop, or smartphone) initiates an outgoing connection to a server (such as a web or gaming server).
2. SYN-ACK. The server responds with an acknowledgement of the initial request, signaling it is ready to finish initiating the connection.
3. ACK. The client sends a final acknowledgment, signifying that both the client and server are ready to send and receive data.

Once these three steps have been successfully completed, application-specific data (such as a website, web app, or connection to a gaming server) can flow between the client and server machines. All servers have some sort of open connection limit, based on a number of factors like hardware limitations and configuration options. A SYN flood takes advantage of this process by sending an initial SYN request to a server, but never completing the final stage of the connection process, essentially leaving the server “hanging” with a half-open connection. If all of a server’s available connections are stuck in this half-open state, there’s no more room for legitimate requests to be processed, and the server can appear down.

Below is a packet capture of what a typical SYN flood looks like to an example IP address (10.100.101.102):
20:10:31.972125 IP (tos 0x0, ttl 63, id 33555, offset 0, flags [none], proto TCP (6), length 40) 194.19.245.45.1476 > 10.100.101.102.80: Flags [S], cksum 0x68c1 (correct), seq 1295468550, win 512, length 0 0x0000: 4500 0028 8313 0000 3f06 3c78 4814 160e E..(....?. 10.100.101.102.80: Flags [S], cksum 0x3b13 (correct), seq 1112583029, win 512, length 0 0x0000: 4500 0028 c3c6 0000 3f06 fbc4 4814 160e E..(....?...H... 0x0010: 4814 160f 05c5 0050 4250 ab75 0c1c b693 H......PBP.u.... 0x0020: 5002 0200 3b13 0000 0000 0000 0000 P...;......... 20:10:33.972235 IP (tos 0x0, ttl 63, id 64415, offset 0, flags [none], proto TCP (6), length 40) 115.84.242.84.1478 > 10.100.101.102.80: Flags [S], cksum 0xdf83 (correct), seq 1507020756, win 512, length 0 0x0000: 4500 0028 fb9f 0000 3f06 c3eb 4814 160e E..(....?...H... 0x0010: 4814 160f 05c6 0050 59d3 4fd4 5b65 06f7 H......PY.O.[e.. 0x0020: 5002 0200 df83 0000 0000 0000 0000 P............. 20:10:34.972280 IP (tos 0x0, ttl 63, id 10547, offset 0, flags [none], proto TCP (6), length 40) 125.69.132.100.1479 > 10.100.101.102.80: Flags [S], cksum 0x5b84 (correct), seq 1204241112, win 512, length 0 0x0000: 4500 0028 2933 0000 3f06 9658 4814 160e E..()3..?..XH... 0x0010: 4814 160f 05c7 0050 47c7 42d8 2a76 daec H......PG.B.*v.. 0x0020: 5002 0200 5b84 0000 0000 0000 0000 P...[.........

Note that each connection attempt is marked with the “Flags [S]” value. This indicates that the client is attempting to initiate a new connection by sending packets with the SYN flag set. Also note that, for the most part, each source IP address (shown on the left side of the capture) is different. Because SYN floods don’t require a full connection to be established, source IP addresses can be spoofed, making it impossible to track down and block specific IPs from connecting. Traffic patterns like this can quickly fill up a server’s available pool of connections, rendering it inoperable.

SYN floods are very easy to execute and can be quite devastating to servers that have no protection against it. At Staminus Communications, our patented technology easily protects against all types of DDoS attacks. To see how we work, and how we work differently from others in the industry, visit our technology page to learn more.