system toolbox » router

http://en.wikipedia.org/wiki/SYN_cookies

SYN Cookies are the key element of a technique used to guard against SYN flood attacks. Daniel J. Bernstein, the technique's primary inventor, defines SYN Cookies as "particular choices of initial TCP sequence numbers by TCP servers." In particular, the use of SYN Cookies allows a server to avoid dropping connections when the SYN queue fills up. Instead, the server behaves as if the SYN queue had been enlarged. The server sends back the appropriate SYN+ACK response to the client but discards the SYN queue entry. If the server then receives a subsequent ACK response from the client, the server is able to reconstruct the SYN queue entry using information encoded in the TCP sequence number.

http://en.wikipedia.org/wiki/SYN_flood

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:

1. The client requests a connection by sending a SYN (synchronize) message to the server.
2. The server acknowledges this request by sending SYN-ACK back to the client.
3. 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.

This 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, the server sends the SYN-ACK to the falsified IP address, and never receives the ACK. In both cases the server will wait for the acknowledgement for some time, and also 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.