imported>Rohde72: /* growthexperiments-addlink-summary-summary:2|0|0 */

2025-04-05T19:27:20Z

growthexperiments-addlink-summary-summary:2|0|0

Neue Seite

[[Datei:Tcp_normal.svg|mini|Erfolgreicher TCP-Handshake]]
[[Datei:Tcp_synflood.png|mini|Der Angreifer (grün) sendet viele SYN-, jedoch keine ACK-Pakete. Durch die halboffenen Verbindungen wird der Server so sehr ausgelastet, dass die Anfrage eines normalen Benutzers (lila) nicht bearbeitet werden kann.]]

Ein '''SYN-Flood''' ist eine Form der [[Denial of Service|Denial-of-Service]]-Attacke (DoS) auf Computersysteme. Der Angriff verwendet den Verbindungsaufbau des [[Transmission Control Protocol|TCP]]-[[Netzwerkprotokoll|Transportprotokolls]], um einzelne Dienste oder ganze Computer aus dem Netzwerk unerreichbar zu machen.

== Funktionsweise ==
Wenn ein [[Client]] eine TCP-[[Verbindungsorientiert|Verbindung]] zu einem [[Server]] aufbauen möchte, führen der Client und der Server einen so genannten [[Drei-Wege-Handschlag|Threeway-Handshake]] durch, um die Verbindung einzurichten. Der normale Ablauf, wie in der Abbildung zu sehen, ist dabei folgender:
# Client an Server: Paket mit Flag ''SYN'', Abgleichen ''(synchronize)''.
# Server an Client: Paket mit Flags ''SYN, ACK'', Abgleichen bestätigt ''(synchronize acknowledge)''.
# Client an Server: Paket mit Flag ''ACK'', Bestätigt ''(acknowledge)''; Die Verbindung ist nun hergestellt.

Ein böswilliger Client kann die letzte ''ACK''-Nachricht unterschlagen. Der Server wartet einige Zeit auf ein entsprechendes Paket, da es auch aufgrund von Verzögerungen verspätet eintreffen kann.

Während dieser Zeit werden sowohl die Adresse des Clients als auch der Status der noch halb offenen Verbindung im Speicher des [[Protokollstapel|Netzwerkstacks]] vorrätig gehalten, um die Verbindung später vollständig etablieren zu können. Bei allen [[Betriebssystem]]en belegt diese so genannte ''halb offene'' Verbindung Ressourcen auf dem Server. Da Ressourcen immer begrenzt sind, ist es durch „Flutung“ des Servers mit ''SYN''-Nachrichten möglich, alle verfügbaren Ressourcen zu blockieren. Sobald dies der Fall ist, können zum Server keine neuen Verbindungen mehr aufgebaut werden, was zur Zugriffsverweigerung ([[Denial of Service]]) führt. Die Tatsache, dass SYN-Pakete sehr klein sind und auch ohne großen Rechenaufwand erzeugt werden können, macht diesen Angriff besonders effizient: Der Verteidiger benötigt erheblich mehr Ressourcen zur Abwehr als der Angreifer für den Angriff selbst.

== SYN-Flood-Reflection-Attacke ==
Eine Variante stellt die SYN-Flood-Reflection-Attacke dar, welche zu den [[Distributed Denial of Service|Distributed-Denial-of-Service]]-Angriffen (DDoS) zählt.<ref name="use1"/> Bei diesem Angriff steht nicht die Auslastung eines Servers mit vielen halboffenen TCP-Verbindungen im Vordergrund, sondern es wird eine Vielzahl von Servern mit einer pro Server eher schwachen SYN-Flood vom Angreifer missbraucht, um die so ausgelösten Antworten (SYN-ACK-Pakete) an die vermeintlichen [[Absender]] zu schicken. Im Prinzip ist es für diesen Angriff ausreichend, wenn auf vielen Servern jeweils ein oder mehrere TCP-Ports allgemein erreichbar sind, egal welcher Dienst darauf angeboten wird. Da die Anzahl der TCP-SYN-Pakete pro Server meist vom Angreifer bewusst gering gehalten wird, kann unter Umständen die SYN-Flood-Reflection-Attacke an dem als Reflektor missbrauchten Server gar nicht auffallen.

Für den SYN-Flood-Reflection-Angriff muss der Angreifer über Möglichkeiten verfügen, seine Absenderadresse der SYN-Pakete gezielt fälschen zu können, wobei er die Absender-[[IP-Adresse]]n aus dem eigentlichen, anzugreifenden IP-Bereich wählen muss. Ist die Anzahl der als Reflektoren missbrauchten Server groß genug, kommt es zu einer Konzentration einer großen Anzahl von SYN-ACK-Paketen im attackierten Netzwerk. Das Ziel ist dabei eine allgemeine Netzwerküberlastung zu bewirken.

Der Vorteil der SYN-Flood-Reflection-Attacke für den Angreifer besteht in dem Umstand, dass es zu einem Verstärkungsfaktor kommt. Jeder der vielen einzelnen Server, welche als Reflektor missbraucht werden, antwortet im Regelfall auf ein initiales SYN-Paket nicht nur mit einem einzigen SYN-ACK-Paket, sondern wiederholt diesen Vorgang. Übliche Werte sind fünf bis sieben Wiederholungen, teilweise sind auch höhere Werte erzielbar.<ref name="use1"/> Damit kann ein Angreifer im eigentlichen anzugreifenden Zielnetz eine Verstärkung um einen Faktor deutlich über eins erzielen und somit effizienter das attackierte Netzwerk durch Überlastung lahm legen als es mit einem direkten Angriff möglich wäre.

== Betroffene Ressourcen ==
Zu den Ressourcen, die betroffen sein können, gehört vor allem die Tabelle, in der die TCP-Verbindungen gespeichert werden. Durch sekundäre Effekte kann ferner der Hauptspeicher des Servers betroffen sein. Die sogenannte ''backlog queue'' des TCP-Stacks, die im Falle von zu vielen gleichzeitig aktiven Verbindungen als Warteschlange einspringt, benötigt ebenfalls [[Arbeitsspeicher]].

== Gegenmaßnahmen ==
Mögliche Maßnahmen gegen SYN-Floods auf Serverseite sind:

* Der [[SYN-Cookies]]-Mechanismus
* RST-Cookies
* Eine Echtzeitanalyse des Angriffs durch eine intelligente [[Firewall]], welche verdächtige Angriffsmuster automatisch erkennt.
* [[Proxy Server]]
* Recyceln der ältesten halb-offenen [[TCP/IP|TCP]]-Verbindung
* SYN Cache

Gegen Distributed-Denial-of-Service-Angriffe (DDoS) schützen diese Maßnahmen jedoch unter Umständen nicht. Generell müssen effektive Abwehrmethoden auf den übergeordneten Netzwerkebenen wie dem [[Backbone (Telekommunikation)|Backbone]], wie beispielsweise der Einsatz von [[Ingress-Filter]]n, umgesetzt werden.

== Varianten ==
Manche der oben genannten Gegenmaßnahmen können umgangen werden. Dies geschieht meist durch zufällige Werte im [[TCP/IP]]-Header.

Mögliche Methoden:
* Bei jedem Paket jeweils andere Absender-IP-Adresse verwenden (durch [[IP-Spoofing]])
* Unterschiedlich lange Pausen zwischen den einzelnen Paketen
* Zufällige Absenderports
* Zufälliges Hinzufügen anderer [[Transmission Control Protocol|TCP]]-Flags

== Weblinks ==
* {{Webarchiv | url=http://www.grc.com/dos/drdos.htm | wayback=20080109175206 | text=Analyse einer auf SYN-Flood basierenden Distributed-Reflection-Denial-of-Service-Attacke}}

== Einzelnachweise ==
<references>
<ref name="use1">{{Internetquelle | url = https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf | titel = Hell of a Handshake: Abusing TCP for Reflective Amplification DDoS Attacks | autor = Marc Kührer, Thomas Hupperich, Christian Rossow, Thorsten Holz | hrsg = Horst Görtz Institute for IT-Security, Ruhr-University Bochum | zugriff = 2019-11-01 }}</ref>
</references>

[[Kategorie:Sicherheitslücke|Synflood]]

SYN-Flood - Versionsgeschichte

imported>Rohde72: /* growthexperiments-addlink-summary-summary:2|0|0 */