Article on other languages:
 |
del.icio.us |
 |
Digg |
 |
Furl |
 |
|
 |
Rojo |
| Add to OnlyWire |
A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target's system[1].
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 sending
SYN-ACKback to the client. - The client responds with an
ACK, 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 the ACK.
There are two methods, but both involve the server not receiving the ACK. A malicious client can skip sending this last ACK message. Or by spoofing the source IP address in the SYN, it makes the server send the SYN-ACK to the falsified IP address, and thus never receive the ACK. In both cases the server will wait for the acknowledgement for some time, as simple network congestion could also be the cause of the missing ACK.
If these half-open connections bind resources on the server, it may be possible to take up all these resources by flooding the server with SYN messages. 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 technology often used in 1996 for allocating resources for half open TCP connections involved a queue which was often very short (e.g., 8 entries long) with each entry of the queue being removed upon a completed connection, or upon expiry (e.g., after 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 modern TCP/IP stacks do not have the above mentioned bottleneck, there should be little or no difference between a SYN flood and any other channel capacity-based attack.
Reflector routers can also be used as attackers, instead of client machines.
