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.

Der SYN-Cookie-Mechanismus läuft vollständig auf Server-Seite ab. Da das Verfahren für den Client transparent abläuft, wird keine Unterstützung durch den Client benötigt und der Server kann SYN-Cookies flexibel ein- und ausschalten. Des Weiteren kann die Implementierung auf verschiedene Art und Weise erfolgen. Bernstein schlägt folgendes Verfahren vor:

• 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:

1. 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.
2. 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.
3. 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, damit ein Angreifer den Wert nicht erraten kann. Dies kann durch eine kryptographische Hashfunktion erreicht werden, die als zusätzlicher Eingabeparameter einen geheimen Schlüssel des Servers erhält.

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.

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.

Weblinks

• Website des Entwicklers
• W. Eddy: RFC 4987 – TCP SYN Flooding Attacks and Common Mitigations. August 2007 (englisch).

Einzelnachweise

1. SYN cookies. cr.yp.to – Website des SYN-Cookies Entwicklers; abgerufen am 18. Dezember 2009.
2. S. Bellovin: RFC 1948 – Defending Against Sequence Number Attacks. Mai 1996, S. 5 (AT&T Research, englisch).
3. RFC 4987 – TCP SYN Flooding Attacks and Common Mitigations. 14. August 2007, Abschnitt 7: Informative References. ([cr.yp.to], englisch).
4. 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.