SYN flood

from Wikipedia, the free encyclopedia
Successful TCP handshake
The attacker (green) sends many SYN but no ACK packets. Due to the half-open connections, the server is so busy that the request from a normal user (purple) cannot be processed.

A SYN flood is a form of denial-of-service attack (DoS) on computer systems. The attack uses the connection establishment of the TCP - transport protocol to make inaccessible to individual services or entire computers from the network.

functionality

When a client wants to establish a TCP connection to a server , the client and the server carry out a so-called threeway handshake to establish the connection. The normal process, as shown in the figure, is as follows:

  1. Client to server: Package with flag SYN , synchronize .
  2. Server to client: Package with flags SYN, ACK , synchronization confirmed (synchronize acknowledge) .
  3. Client to server: Package with flag ACK , confirmed (acknowledge) ; The connection is now established.

A malicious client can suppress the last ACK message. The server waits some time for a corresponding packet because it could also arrive late due to delays.

During this time, both the address of the client and the status of the still half-open connection are held in the memory of the network stack so that the connection can be fully established later. In all operating systems, this so-called half-open connection occupies resources on the server. Since resources are always limited, it is possible to use up all of these resources by "flooding" the server with SYN messages. As soon as this is the case, no new connections can be established to the server, which leads to a denial of service . The fact that SYN packets are very small and can also be generated without a great deal of computing effort makes this attack particularly unbalanced. The defender needs more resources for defense than the attacker for the attack itself.

SYN flood reflection attack

One variant is the SYN flood reflection attack, which is a distributed denial of service (DDoS) attack. In this attack, the focus is not on the load on a server with many half-open TCP connections, but rather a large number of servers with a SYN flood that is rather weak per server is misused by the attacker in order to avoid the responses triggered in this way (SYN-ACK packets). to send to the supposed sender. In principle, it is sufficient for this attack if one or more TCP ports are generally accessible on many servers, regardless of which service is offered on them. Since the number of TCP-SYN packets per server is usually deliberately kept low by the attacker, the SYN flood reflection attack may not even be noticed on the server misused as a reflector.

For the SYN flood reflection attack, the attacker must be able to specifically falsify the sender address of the SYN packets. He has to choose his IP sender addresses from the actual IP range to be attacked. If the number of servers misused as reflectors is large enough, a high number of SYN-ACK packets will be concentrated in the attacked network. The goal is to cause general network congestion.

The advantage of the SYN flood reflection attack for the attacker lies in the fact that there is an amplification factor. Each of the many individual servers that are misused as reflectors generally not only replies to an initial SYN packet with a single SYN-ACK packet, but repeats this process. The usual values ​​are five to seven repetitions, sometimes higher values ​​can be achieved. In this way, an attacker can achieve a gain in the actual target network to be attacked by a factor well above one and thus paralyze the attacked network more efficiently through overloading than would be possible with a direct attack.

Affected resources

The main resources that can be affected are the table in which the TCP connections are stored. The main memory of the server can also be affected by secondary effects. The so-called backlog queue of the TCP stack, which steps in as a queue in the event of too many simultaneously active connections, also requires memory.

Countermeasures

Possible measures against SYN floods on the server side are:

  • The SYN cookies mechanism
  • RST cookies
  • Real-time analysis of the attack by an intelligent firewall , which automatically detects suspicious attack patterns.
  • Proxy server
  • Recycle the oldest half-open TCP connection
  • SYN cache

However, these measures may not protect against distributed denial of service attacks (DDoS). In general, effective defense methods are to be implemented on the higher-level network levels such as the backbone , such as the use of ingress filters .

variants

Some of the above countermeasures can be bypassed. This is mostly done by random values ​​in the TCP / IP header.

Possible methods:

  • Use a different sender IP address for each packet (through IP spoofing )
  • Pauses of different lengths between the individual packages
  • Random sender ports
  • Randomly adding other TCP flags

Web links

Individual evidence

  1. ↑ a b Marc Kührer, Thomas Hupperich, Christian Rossow, Thorsten Holz: Hell of a Handshake: Abusing TCP for Reflective Amplification DDoS Attacks. Horst Görtz Institute for IT-Security, Ruhr-University Bochum, accessed on November 1, 2019 .