TCP SYN Flood - Attack
TCP SYN Flood - Attack
TCP SYN Flood - Attack
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