A very popular denial of service attack involves a cracker sending many(possibly forged) SYN packets to your server, but never completing theTCP three-way handshake. This quickly uses up slots in the kernel'shalf-open queue, preventing legitimate connections from succeeding.Since a connection does not need to be completed, no resources needto be used on the attacking machine; therefore, this is easy to performand maintain.
If the "tcp\_syncookies" variable is set (only available if your kernel wascompiled with CONFIG\_SYNCOOKIES), then the kernel handles TCP SYNpackets normally until the queue is full, at which point the SYN cookiefunctionality kicks in.
SYN cookies do not work by using a SYN queue. Instead, the kernel will reply to any SYN packet with aSYN|ACK normally, but it will present a specially-crafted TCP sequence number that encodes the source anddestination IP address, as well as the port number and the time the packet was sent. An attacker performingthe SYN flood would never have gotten this packet at all if they're spoofing, so they wouldn't respond. Alegitimate connection attempt would send the third packet of the three-way handshake, which includes thissequence number, and the server can verify that it must be in response to a valid SYN cookie and allows theconnection, even though there is no corresponding entry in the SYN queue.
Enabling SYN cookies is a very simple way to defeat SYN flood attacks, while using only a bit more CPU time for the cookiecreation and verification. Since the alternative is to reject all incoming connections, enabling SYN cookies is the obvious choice.
tcp\_syncookies can be enabled with the following:
# /sbin/sysctl -w net.ipv4.tcp_syncookies=1
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
You can find more information about Linux Firewall-related
/proc entries here: