SYN Flood

SYN-Flut

Eine SYN-Flood ist eine Form eines DoS-Angriffs, bei dem ein Angreifer eine Reihe von SYN -Anfragen an den Server eines Ziels sendet, um so genügend Serverressourcen zu verbrauchen, dass das System nicht mehr auf legitimen Datenverkehr reagiert ^[1] .

Eine SYN -Anfrage und ein SYN Paket sind dasselbe

Wie funktioniert ein SYN-Flood-Angriff?

SYN-Flood-Angriffe nutzen den Handshake-Prozess einer TCP-Verbindung aus. Unter normalen Bedingungen weist TCP drei unterschiedliche Prozesse auf, um eine Verbindung herzustellen (Abbildung 1a).

1. Der Client fordert eine Verbindung an, indem er ein SYN Paket ( Synchronisieren ) an den Server sendet.
2. Der Server antwortet dann mit einem SYN-ACK Paket, um die Kommunikation zu bestätigen ACK
3. Der Client sendet ein ACK Paket, um den Empfang des Pakets vom Server zu bestätigen und die Verbindung wird hergestellt.

Nach Abschluss dieser Sequenz des Sendens und Empfangens von Paketen ist die TCP-Verbindung geöffnet und kann Daten senden und empfangen. Dies wird als TCP-Drei-Wege-Handshake bezeichnet. Diese Technik ist die Grundlage für jede über TCP hergestellte Verbindung.

Um einen DoS zu erzeugen, nutzt ein Angreifer die Tatsache aus, dass der Server nach dem Empfang eines ersten SYN Pakets mit einem oder mehreren SYN-ACK Paketen antwortet und auf den letzten Schritt im Handshake wartet. Cloudflare ^[2] beschreibt die Funktionsweise (Abbildung 1b):

1. Der Angreifer sendet eine große Menge SYN Pakete an den Zielserver, oft mit gefälschten IP-Adressen.
2. Der Server antwortet dann auf jede einzelne Verbindungsanfrage und lässt einen offenen Port offen, der für den Empfang der Antwort bereitsteht.
3. Während der Server auf das letzte ACK Paket wartet, das nie eintrifft, sendet der Angreifer weiterhin weitere SYN Pakete. Das Eintreffen jedes neuen SYN Pakets führt dazu, dass der Server vorübergehend für eine bestimmte Zeit eine neue offene Portverbindung aufrechterhält, und sobald alle verfügbaren Ports genutzt wurden, kann der Server nicht mehr normal funktionieren.

Netzwerk-Setup

Der Angriff auf dieses Repository wurde in einer VM durchgeführt. Zur Durchführung des Angriffs werden drei Maschinen benötigt. Eine Maschine wird als Angreifer verwendet, eine andere Maschine wird als Opfer (dh der Server) verwendet und die dritte Maschine wird als Beobachter (dh der Client) verwendet.

Um den Angriff einzurichten, können drei VMs auf demselben Host-Computer eingerichtet werden. Alternativ können zwei VMs auf einem Host-Rechner eingerichtet werden, wobei der Host-Rechner selbst als dritter Rechner fungiert.

Dieser Angriff wurde unter der Annahme durchgeführt, dass sich die Angreifer im selben physischen Netzwerk wie die Opfer befinden – was die Aufgabe vereinfacht, TCP-Sequenznummern und Quellportnummern zu ermitteln. Um die notwendigen Informationen zu sammeln, können Sniffer-Tools eingesetzt werden.

Angriff

Der Angriff auf dieses Repository wurde mit dem Tool netwox durchgeführt. Anschließend wurde ein Sniffer-Tool wie Wireshark ^[3] verwendet, um die angreifenden Pakete abzufangen. Während der Angriff andauerte, wurde netstat -na auf dem Computer des Opfers ausgeführt, um das Ergebnis mit dem vor dem Angriff zu vergleichen.

 # check the size of the queue for holding half-open connections
sudo sysctl -q net.ipv4.tcp_max_syn_backlog

# check the current usage of the queue;
# i.e., the number of half-open connections associated with some listening port
netstat -na

# one netwox tool that may be useful is tool number 76: synflood
netwox 76 --help

Gegenmaßnahmen

SYN-Cookie:

Der Angriff auf dieses Repository wurde durch die Manipulation von SYN-Cookies durchgeführt.

Durch die Verwendung von SYN-Cookies kann ein Server verhindern, dass Verbindungen unterbrochen werden, wenn die SYN-Warteschlange voll ist. Anstatt zusätzliche Verbindungen zu speichern, wird der SYN-Warteschlangeneintrag in die in der SYN-ACK-Antwort gesendete Sequenznummer codiert. Wenn der Server dann vom Client eine nachfolgende ACK-Antwort mit der erhöhten Sequenznummer erhält, ist der Server in der Lage, den SYN-Warteschlangeneintrag anhand der in der TCP-Sequenznummer kodierten Informationen zu rekonstruieren und wie gewohnt mit der Verbindung fortzufahren.

Bei dieser Abhilfemaßnahme gehen zwar einige Informationen über die TCP-Verbindung verloren, sie ist jedoch besser, als zuzulassen, dass DoS als Folge eines Angriffs legitime Benutzer befällt.

SYN-Cookies wurden von DJ Bernstein ^[4] als direkte Reaktion auf SYN-Flooding erstellt.

Verwenden Sie den Befehl sysctl um den SYN-Cookie-Mechanismus zu aktivieren/deaktivieren:

sudo sysctl -a | grep cookie                 # Display the SYN cookie flag
sudo sysctl -w net.ipv4.tcp_syncookies=0     # turn off SYN cookie
sudo sysctl -w net.ipv4.tcp_syncookies=1     # turn on SYN cookie

SYN-Cookies sind eine von vielen Gegenmaßnahmen, die implementiert werden können, um SYN-Flooding zu stoppen. Weitere Abhilfemaßnahmen umfassen die Erhöhung der maximalen Größe der Warteschlange, die Reduzierung des SYN-RECEIVED -Timers und die Wiederverwendung der ältesten halboffenen TCP-Verbindung.

---

Referenzen

1. ^ „CERT Advisory CA-1996-21 TCP SYN Flooding und IP-Spoofing-Angriffe“ Carnegie Mellon University

2. ^ „SYN-Flutangriff“ Cloudflare

3. ^ „Über Wireshark“ Wireshark Foundation

4. ^ „SYN-Cookies“ DJ Bernstein

---

Vielen Dank für Ihr Interesse, dieses Projekt hat Spaß gemacht und war aufschlussreich!