20.02.2014 Aufrufe

TCP SYN Flood - Attack

TCP SYN Flood - Attack

TCP SYN Flood - Attack

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

<strong>TCP</strong> <strong>SYN</strong> <strong>Flood</strong> - <strong>Attack</strong><br />

• Beschreibung<br />

• Auswirkungen<br />

• Zuordnung zu Gefährdungskategorie und <strong>Attack</strong>en-Art<br />

• Gegenmaßnahmen<br />

• Quellen


<strong>TCP</strong> <strong>SYN</strong> <strong>Flood</strong> - Beschreibung<br />

• <strong>TCP</strong> <strong>SYN</strong> <strong>Flood</strong> Denial of Service <strong>Attack</strong>e<br />

• <strong>Attack</strong>e nutzt <strong>TCP</strong> Verbindungsaufbau<br />

• Dienste, oder ganze Systeme werden<br />

blockiert<br />

• In Verbindung mit IP-Spoofing (fälschen der<br />

IP-Absendeadresse) sehr effektiver!


<strong>TCP</strong> Verbindungsaufbau – 3-way<br />

Handshake<br />

1. Client an Server: Paket mit<br />

Flag <strong>SYN</strong> (synchronize)<br />

2. Server an Client: Paket mit<br />

Flags <strong>SYN</strong>, ACK<br />

(synchronize, acknowledge)<br />

3. Client an Server: Paket mit<br />

Flag ACK (acknowledge)<br />

Danach ist die Verbindung<br />

hergestellt!


<strong>TCP</strong> Verbindungsaufbau – 3-way<br />

Handshake – <strong>TCP</strong> <strong>SYN</strong> <strong>Flood</strong><br />

1. Client an Server: Paket mit<br />

Flag <strong>SYN</strong> (synchronize)<br />

2. Server an Client: Paket mit<br />

Flags <strong>SYN</strong>, ACK<br />

(synchronize acknowledge)<br />

Bereits zu diesem Zeitpunkt,<br />

muss der Server Ressourcen für<br />

die Verwaltung der halb offenen<br />

Verbindung Reservieren!<br />

3. Der Client schickt kein Paket<br />

mit Flag ACK (acknowledge)<br />

ggf ein neues <strong>SYN</strong> Paket


<strong>TCP</strong> <strong>SYN</strong> <strong>Flood</strong> - Auswirkungen<br />

• Timeout für halb offene Verbindungen normalerweise 60 Sekunden<br />

(Dies kann je Betriebssystem variieren und ist auch manuell konfigurierbar)<br />

• <strong>TCP</strong>-Stack im Kernel versucht nach Verbindungsfehler standardmäßig fünf Mal erneut<br />

eine Verbindung herzustellen. (Auch dies kann manuell konfiguriert werden)<br />

• Während dieser Zeit werden sowohl die Adresse des Clients als auch der Status<br />

der noch halb offenen Verbindung im Speicher des Netzwerkstacks gespeichert, um die<br />

Verbindung später vervollständigen zu können.<br />

• Dies belegt Ressourcen auf dem Server. Sind alle Ressourcen des Servers<br />

aufgebraucht, können keine neuen Verbindungen mehr aufgebaut werden, was zur<br />

Zugriffsverweigerung (Denial of Service) führt.<br />

• Da <strong>SYN</strong>-Pakete sehr klein sind und auch ohne großen Rechenaufwand erzeugt<br />

werden können, ist dieser Angriff besonders unausgewogen. Der Verteidiger<br />

benötigt mehr Ressourcen zur Abwehr als der Angreifer für den Angriff selbst.<br />

Betroffene Ressourcen:<br />

Tabelle für <strong>TCP</strong> Verbindungen, Hauptspeicher, Backlog queue des <strong>TCP</strong>-Stacks<br />

(springt als Warteschlange ein, wenn zu viele Verbindungen gleichzeitig offen sind)


<strong>TCP</strong> <strong>SYN</strong> <strong>Flood</strong> - Zuordnung zu<br />

Gefährdungskategorie und <strong>Attack</strong>en-Art<br />

Gefährdungskategorie:<br />

• Störung (disruption) – Gefährdung der<br />

Verfügbarkeit und Integrität<br />

<strong>Attack</strong>en – Art:<br />

• Obstruktion – Systembehinderung<br />

Systemüberlastung mittels Denial-of-Sevice<br />

(DOS) <strong>Attack</strong>e


<strong>TCP</strong> <strong>SYN</strong> <strong>Flood</strong> - Gegenmaßnahmen<br />

• Eine Echtzeitanalyse des Angriffs durch eine<br />

intelligente Firewall (Paketfilter für IP-<br />

Spoofing) – Problem: Auch guter Traffic wird<br />

für die Zeit des Angriffs geblockt!!!<br />

• Der <strong>SYN</strong>-Cookie - Mechanismus


Der <strong>SYN</strong> Cookie Mechanismus im Detail<br />

Bei dem Prinzip der <strong>SYN</strong>-Cookies speichert der Server keine Informationen über die<br />

halboffene <strong>TCP</strong>-Verbindung. Daher müssen keine Ressourcen belegt werden.<br />

Es wird zwar wie beim 3-way-Handshake üblich, ein <strong>SYN</strong>/ACK-Paket vom Server<br />

Zurückgeschickt, dieses ist allerdings mit einer speziell generierten Sequenznummer<br />

versehen.<br />

Dieses <strong>SYN</strong> Cockie ist eine MD5 Prüfsumme über:<br />

• Zeitstempel<br />

• Sender- und Empfänger - IP-Adresse<br />

• Port<br />

• Geheimnis<br />

Im Normalfall antwortet der Client, was bei <strong>SYN</strong>-<strong>Flood</strong>-Angriffen nicht der Fall ist, und schickt<br />

den Cookie im ACK-Paket wieder zurück. Der Server prüft nun die Sequenznummer des ACK,<br />

dekrementiert diese um 1 und bildet erneut die MD5-Prüfsumme. Ist die Prüfung erfolgreich, so<br />

stellt er die Verbindung her. Ein Vorteil der <strong>SYN</strong>-Cookies ist, dass auf Client-Seite keine<br />

spezielle Implementierung vorhanden sein muss, da das Cookie im üblichen <strong>SYN</strong>/ACK-Paket<br />

gesendet wird.


<strong>TCP</strong> SYS <strong>Flood</strong><br />

Danke für Eure Aufmerksamkeit


Quellen<br />

• http://de.wikipedia.org/wiki/<strong>SYN</strong>-<strong>Flood</strong><br />

• http://burnachurch.com/60/syn-flood-kurzerklaert<br />

• http://tools.ietf.org/html/rfc4987

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!