SYN-Cookies
Unter SYN-Cookies versteht man einen im Jahr 1996 von Daniel J. Bernstein entwickelten Mechanismus zum Schutz vor SYN-Flood-Angriffen. Bei diesen handelt es sich um eine Form des Denial-of-Service-Angriffs, bei der der anzugreifende Rechner durch massives Öffnen von Verbindungen dazu provoziert wird, die eigenen Ressourcen auf das Offenhalten der Verbindungen zu verwenden.
Verbindungsaufbau mit TCP
Beim Herstellen einer herkömmlichen TCP-Verbindung, dem sogenannten Drei-Wege-Handshake, schickt ein Client zuerst ein SYN-Paket an den Server. Dieser speichert diese Nachricht und antwortet mit einem SYN/ACK-Paket. Schließlich sendet der Client ein ACK-Paket an den Server und die Verbindung ist hergestellt.
Erweiterung um SYN-Cookies
Das Transmission Control Protocol (TCP) macht keine Vorgaben zum initialen Wert der Sequenznummer der SYN/ACK-Pakete. Also kann der Server sie nutzen, um Informationen zu kodieren, die er sonst in einer Tabelle halboffener TCP-Verbindungen speichern müsste. Da bei aktiven SYN-Cookies die Tabelle der halboffenen Verbindungen nicht verwendet wird, kann es bei dieser Tabelle zu keiner Blockade kommen, womit ein SYN-Flood-Angriff abgeschwächt wird.
Im Detail können folgende Regeln angewendet werden:
- t ist ein langsam ansteigender Zeitstempel, der empfohlenerweise alle 64 Sekunden inkrementiert wird
- m ist die maximale Paketgröße des Clients
- s ist ein Hashwert aus den folgenden Werten: Der Zeitstempel t, IP-Adressen und Portnummern von Client und Server. Der Hashwert muss 24 Bit lang sein.
Der Server sendet sein SYN/ACK-Paket mit einer speziell generierten Sequenznummer. Diese Sequenznummer ist laut TCP-Spezifikation jedoch auf 32 Bit beschränkt und kann folgendermaßen generiert werden:
- Die ersten 5 Bits: t mod 32
- Mittlere 3 Bits: Eine individuelle Kodierung von m (nur acht verschiedene Möglichkeiten)
- Die letzten 24 Bits: s
Da der Client die Sequenznummer des TCP-SYN/ACK bei Empfang um eins hochzählt, enthält sein TCP-ACK-Paket die vom Server generierte initiale Sequenznummer um eins inkrementiert. Der Server dekrementiert diese also wieder um eins und vergleicht sie anschließend mit dem Hashwert des Pakets. Stimmen die beiden Hashes nicht überein, muss die Verbindung neu aufgebaut werden, wozu der Server dem Client ein TCP RST-Paket sendet.
Im Detail passiert am Server Folgendes, nachdem das Paket dekrementiert wurde:
- Die ersten 5 Bits müssen mit der aktuellen Berechnung von t (oder einen Zeitstempel davor) übereinstimmen. Somit kann herausgefunden werden, ob bereits eine Zeitüberschreitung eingetreten ist.
- Der Wert s wird erneut aus Zeitstempel t (oder einem Zeitstempel davor), IP-Adressen und Portnummern von Client und Server berechnet und mit den letzten 24 Bit verglichen. Nur bei Übereinstimmung wird die Verbindung zugelassen.
- Die mittleren 3 Bits werden dekodiert und die Verbindung mit der gewünschten maximalen Paketgröße aufgebaut.
Weil die Überprüfung des Verbindungsaufbaus auf dem Server passiert, kann die Hashfunktion der Implementierung grundsätzlich beliebig definiert sein; sie sollte jedoch möglichst zufällig sein, um Sicherheitsrisiken zu vermeiden.[1] Dieses Verfahren läuft für den Client transparent ab, weswegen Verbindungen zwischen Gegenstellen unabhängig davon aufgebaut werden können, ob sie SYN-Cookies verwenden.
Inhalt der initialen Sequenznummer
- Zeitstempel mit einer Auflösung von 64 Sekunden
- maximale Segmentgröße
- Hashfunktion über:
- Sender- und Empfänger-IP-Adresse
- Ports
- Zeitstempel mit einer Auflösung von 64 Sekunden
- Ein nur dem Server bekannter geheimer Wert, der sich (wenn überhaupt) in großen Abständen ändert
Die Hashfunktion ist im zugehörigen RFC 4987 nicht spezifiziert und kann daher frei gewählt werden.[2][3]
Vor- und Nachteile der Verwendung von SYN-Cookies
SYN-Cookies können Denial-of-Service-Angriffe abmildern oder bei kleineren Angriffen diese sogar verhindern. Wie gut sie vor einem Angriff schützen ist dabei abhängig von dessen Art und Ausmaß. Denn während der Einsatz von SYN-Cookies ein Überlaufen der Tabelle halboffener TCP-Verbindungen wirksam verhindert, so kostet der Einsatz aufgrund der hierzu nötigen Berechnungen mehr Rechenleistung als wenn keine SYN-Cookies verwendet werden, wodurch möglicherweise der Server überlastet werden könnte. In einem solchen Fall wäre dann der SYN-Flood-Angriff trotzdem erfolgreich, jedoch aufgrund der benötigten längeren Rechenzeit, nicht aufgrund des vollen Speicher. Die DOS-Attacke an sich wäre so dennoch erfolgreich, da dem Server sprichwörtlich „die Puste ausgeht“. Außerdem ist es beim Einsatz von SYN-Cookies nicht möglich, gewisse TCP-Erweiterungen, wie beispielsweise große Fenster zu nutzen, da für die hierfür benötigten Informationen nicht genügend Platz im SYN-Cookie zur Verfügung steht.[4]
Aus diesen Gründen werden SYN-Cookies in der Praxis häufig, wie standardmäßig beispielsweise im Linux-Kernel, nur dann eingesetzt, wenn die Tabelle der halboffenen TCP-Verbindungen droht überzulaufen. Zwar können die Clients, die per SYN-Cookie bedient werden, gewisse TCP-Erweiterungen nicht nutzen, doch ist dies immer noch besser als wenn der Server ihre Verbindungsanfrage aufgrund von Platzmangel komplett ablehnen müsste. Sobald wieder genügend Platz in der Tabelle vorhanden ist, werden die SYN-Cookies auf Serverseite deaktiviert. Auf diese Weise kann der Server die Vorteile der SYN-Cookies bei aktiven Angriffen nutzen, ohne deren Nachteile im normalen Betriebsfall in Kauf nehmen zu müssen.[4]
Weblinks
- Website des Entwicklers
- W. Eddy: RFC 4987. – TCP SYN Flooding Attacks and Common Mitigations. August 2007. (englisch).
Einzelnachweise
- S. Bellovin: RFC 1948 – Defending Against Sequence Number Attacks. Mai 1996. S. 5. (AT&T Research – englisch).
- SYN cookies. Website des SYN-Cookies Entwicklers. Abgerufen am 18. Dezember 2009.
- RFC 4987 – TCP SYN Flooding. Belegangabe zu SYN-Cookies, S. 14. August 2007.
- William Stallings, Lawrie Brown: Computer Security - Principles and Practice. 2. Auflage. Kapitel 7: Denial-of-Service-Attacks. Pearson Verlag, ISBN 0-273-76449-7, S. 263–264.