The client generates a SYN packet requesting a new session from the server. Since the TCP session is open (“TCP 3-way handshake” is complete), the host will trace and process each client session till it gets closed. During SYN flood, the server under attack is bombarded with fabricated SYN requests containing fake source IP addresses. A SYN Flood attack affects the server by occupying the entire memory of the Transmission Control Block (TCB) table, which is usually used to store and process the incoming packets. This considerably undermines productivity, which entails server failure.
There are several protection techniques that can – at least in part – protect from SYN Floods:
Micro-Blocks Allocation: as the administrator, you can allocate the server memory for each incoming SYN packet.
SYN Cookies: using cryptographic hashing, the server sends a SYN ACK reply with the number of the sequence, which contains the client’s IP address, port number, and other unique information identifying the client. When the client replies, this hash is already included in the ACK packet. The server then checks the ACK and, if the check is successful, allocates memory for the connection. For this technique to be used, it has to be supported by all the servers involved in the traffic exchange.
Stack Tweaking: as a temporary safety measure, you can tweak the TCP stack settings – decrease the timeout for releasing memory allocated for the connection, as well as the timeout for blocking the incoming connections. These settings, however, can have the unwanted side effect of losing a percentage of legitimate transmissions because of delays and unstable channels.