- SYN flood
A SYN flood is a form of
denial-of-service attack in which an attacker sends a succession ofSYNrequests to a target's system [RFC 4987 TCP SYN Flooding Attacks and Common Mitigations] .When a client attempts to start a TCP connection to a server, the client and server exchange a series of messages which normally runs like this:
#The client requests a connection by sending a
SYN("synchronize") message to the server.
#The server "acknowledges" this request by sendingSYN-ACKback to the client.
#The client responds with anACK, and the connection is established.This is called the TCP three-way handshake, and is the foundation for every connection established using the TCP protocol.
The SYN flood is a well known type of attack and is generally not effective against modern networks. It works if a server allocates resources after receiving a
SYN, but before it has received theACK.There are two methods, but both involve the server not receiving the
ACK. A malicious client can skip sending this lastACKmessage. Or by spoofing the sourceIP address in theSYN, it makes the server send theSYN-ACKto the falsified IP address, and thus never receive theACK. In both cases the server will wait for the acknowledgement for some time, as simple network congestion could also be the cause of the missingACK.If these "
half-open connection s" bind resources on the server, it may be possible to take up all these resources by flooding the server withSYNmessages. Once all resources set aside for half-open connections are reserved, no new connections (legitimate or not) can be made, resulting in denial of service. Some systems may malfunction badly or even crash if other operating system functions are starved of resources this way.The [http://www.cert.org/advisories/CA-1996-21.html technology often used in 1996 for allocating resources for half open TCP connections] involved a queue which was often very short (e.g., [http://www.sean.de/Solaris/soltune.html 8 entries long] ) with each entry of the queue being removed upon a completed connection, or upon expiry (e.g., after [http://tools.ietf.org/html/rfc1122#section-4.2.3.5 3 Minutes] ). When the queue was full, further connections failed. With the examples above, all further connections would be prevented for 3 minutes by sending a total of 8 packets. A well-timed 8 packets every 3 minutes would prevent all further TCP connections from completing. This allowed for a Denial of Service attack with very minimal traffic.
Proposed countermeasures include
SYN cookies or limiting the number of new connections from a source per timeframe, but because modernTCP/IP stack s do not have the above mentionedbottleneck , there should be little or no difference between a SYN flood and any otherchannel capacity -based attack.Reflector router s can also be used as attackers, instead of client machines.References
External links
* [http://www.cert.org/advisories/CA-1996-21.html Official CERT advisory on SYN Attacks]
Wikimedia Foundation. 2010.
