Quelltext der Seite SYN-Cookies

Unter '''SYN-Cookies''' versteht man einen im Jahr 1996 von [[Daniel J. Bernstein]] entwickelten Mechanismus zum Schutz vor [[SYN-Flood|SYN-Flood-Angriffen]]. Bei diesen handelt es sich um eine Form des [[Denial of Service|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 [[Transmission Control Protocol|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 (Signal)|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:<ref name="crypto">[http://cr.yp.to/syncookies.html ''SYN cookies''.] cr.yp.to – Website des SYN-Cookies Entwicklers; abgerufen am 18. Dezember 2009.</ref>

* '''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 [[Inkrement und Dekrement|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 [[Zufallszahl|zufällig]] sein, damit ein Angreifer den Wert nicht erraten kann.<ref name="RFC1948" /> Dies kann durch eine [[kryptographische Hashfunktion]] erreicht werden, die als zusätzlicher Eingabeparameter einen geheimen Schlüssel des Servers erhält.<ref>{{RFC-Internet |RFC=4987 |Titel=TCP SYN Flooding Attacks and Common Mitigations |Datum=2007-08-14 |Abschnitt=7 |Abschnittstitel=Informative References |Kommentar=[cr.yp.to]}}</ref>

== 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 „[[TCP Receive Window#TCP Window Scale Option|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.<ref name="ComputerSecurity">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.</ref>

Aus diesen Gründen werden SYN-Cookies in der Praxis häufig, wie standardmäßig beispielsweise im [[Linux (Kernel)|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.<ref name="ComputerSecurity" />

== Weblinks ==
* [http://cr.yp.to/syncookies.html Website des Entwicklers]
* {{RFC-Internet |Autor=W. Eddy |RFC=4987 |Titel=TCP SYN Flooding Attacks and Common Mitigations |Datum=2007-08}}

== Einzelnachweise ==
<references>
<ref name="RFC1948">
{{RFC-Internet |Autor=S. Bellovin |RFC=1948 |Titel=Defending Against Sequence Number Attacks |Datum=1996-05 |Seite=5 |Kommentar=AT&T Research}}
</ref>
</references>

[[Kategorie:Transmission Control Protocol|Syncookies]]
[[Kategorie:IT-Sicherheit]]