SYN Flood Attack and SYN Cookies

SYN flood attacks can be used to take down servers by overwhelming their capacity for open connections.
Let’s suppose that there was a radio call-in show that you wanted to take off the air, and you know that they have a phone system capable of holding 7 callers on hold at the same time. So you go to the store and buy 7 cell phones. When the lines open up, you call the switchboard with all 7 phones simultaneously so that the show can’t accept any legitimate callers.
SYN floods work in a very similar manner.
When you contact a web server (or any other system), there is a standard “handshake” which takes place.

• First, you send a packet which contains a SYN or “Synchronize” flag. This signals the start of a conversation.
• If the server wants to start a conversation, it will issue a packet with an ACK or Acknowledgement flag.  This flag indicates that the server has opened a connection for your conversation. This connection will remain open until you close the connection or the connection times out.
• If the connection is refused, the server SHOULD send you a packet with a RST or Reset flag. But many systems and firewalls don’t reply at all to rejected connections for security reasons.
• Once the conversation has ended, you send a packet with a FIN or Finish flag to close the connection and free up these resources for others to use.

In a SYN attack, the attacker issues multiple packets with spoofed sender addresses. Each of these packets contains a SYN flag that lets the server know this spoofed user wants to open a connection.
Of course, the server will reply to each of these with an ACK flag, but the sender will never get this message because of the spoofed address. But that’s ok.
The server will hold these connections open until they time out. And since connections are a finite resource, the victim’s computer will temporarily become unable to accept new incoming connections.
Although this type of attack doesn’t cause any actual damage to the remote host, it can cause a major nuisance by making it temporarily unavailable to legitimate users.


As with traditional SYN proxying, SYN Cookie is activated when the SYN flood attack threshold is exceeded. However, because SYN Cookie is stateless, it does not set up a session or policy and route lookups upon receipt of a SYN segment, and it maintains no connection request queues. This dramatically reduces CPU and memory usage and is the primary advantage of using SYN Cookie over the traditional SYN proxying mechanism.
When SYN Cookie is enabled on JUNOS software with enhanced services and becomes the TCP-negotiating proxy for the destination server, it replies to each incoming SYN segment with a SYN/ACK containing an encrypted cookie as its Initial Sequence Number (ISN). The cookie is an MD5 hash of the original source address and port number, destination address and port number, and ISN from the original SYN packet. After sending the cookie, JUNOS software with enhanced services drops the original SYN packet and deletes the calculated cookie from memory. If there is no response to the packet containing the cookie, the attack is noted as an active SYN attack and is effectively stopped.
If the initiating host responds with a TCP packet containing the cookie +1 in the TCP ACK field, JUNOS software with enhanced services extracts the cookie, subtracts 1 from the value, and recomputes the cookie to validate that it is a legitimate ACK. If it is legitimate, JUNOS software with enhanced services starts the TCP proxy process by setting up a session and sending a SYN to the server containing the source information from the original SYN. When JUNOS software with enhanced services receives a SYN/ACK from the server, it sends ACKs to the server and to the initiation host. At this point the connection is established and the host and server are able to communicate directly.

This figure shows how a connection is established between an initiating host and a server when SYN Cookie is active on JUNOS software with enhanced services.