Zusammenfassung

  • Ein SYN-Flood nutzt einen zeitlichen Vorsprung: Der Server reserviert endlichen halboffenen Zustand, bevor der Initiator den Handshake beendet, sodass billige Anfragen die Warteschlange füllen können.
  • RFC 4987 vergleicht zwei wesentliche Endpunktabwehren: kleineren Zustand in einem begrenzten SYN-Cache halten oder Zustand in einem SYN-Cookie abbilden und erst nach einem gültigen ACK rekonstruieren.

Wenn ein SYN an einem lauschenden Server eintrifft, fällt eine scheinbar kleine Entscheidung. Der Server merkt sich den Versuch, sendet ein SYN-ACK und wartet. Für einen ehrlichen Client ist das gewöhnliches TCP. Für den Angreifer ist es ein Vorschuss: Der Server bezahlt Speicher und Timerarbeit, bevor der angebliche Client überhaupt gezeigt hat, dass er die Antwort hören kann.

RFC 4987 ordnet den Angriff um diesen Vorschuss. Eine herkömmliche TCP-Implementierung hält den Zustand SYN-RECEIVED, solange der Handshake unvollständig ist. Die Warteschlange halboffener Verbindungen ist endlich. Treffen Anfragen schneller ein, als Einträge zurückgewonnen werden, finden legitime neue Verbindungen keinen Platz mehr. Das Dokument behandelt die Erschöpfung von TCP-Zustand auf dem Endsystem und den Ausfall der lauschenden Anwendung. Ein Angriff, dessen Paketmenge zuerst die Netzleitung sättigt, liegt außerhalb dieser Schutzwirkung.

Gefälschte Quelladressen sind ein bequemer Weg, Antworten ins Leere laufen zu lassen, aber keine allgemeine Voraussetzung. Kompromittierte Rechner können mit gültigen, routbaren Adressen denselben Druck erzeugen. Entscheidend sind drei einfachere Bedingungen: Jedes SYN löst eine Zuweisung aus, die Menge halboffener Zustände ist begrenzt, und der Zufluss überholt die Rückgewinnung. Im vom RFC beschriebenen Mechanismus trifft der unmittelbare Schaden neue eingehende Verbindungen zum angegriffenen Port, nicht bereits etablierte oder ausgehende Verbindungen.

Naheliegende Gegenmaßnahmen verschieben häufig nur die Schwelle. Ein größeres Backlog zwingt den Verteidiger, mehr Speicher bereitzustellen, und gibt dem Angreifer eine größere Zahl zum Füllen. Ein kürzerer SYN-RECEIVED-Timer räumt früher auf, verwirft aber legitime Clients mit normaler Netzverzögerung; der Angreifer erhöht lediglich seine Rate. Das Recycling des ältesten halboffenen Kontrollblocks macht Alter zum Auswahlkriterium, ohne Echtheit zu erkennen. Eingangsfilter helfen gegen Spoofing, können aber nicht weltweit vorausgesetzt werden und stoppen keine Botnet-Quellen mit gültigen Adressen.

Weniger merken, aber die Grenze kontrollieren

Ein SYN-Cache senkt den Preis der ersten Nachricht. Statt sofort einen vollständigen TCP-Kontrollblock anzulegen, behält der Server einen kleineren Eintrag, der später zum Abschluss des Handshakes genügt. Der Cache ist begrenzt. RFC 4987 beschreibt außerdem eine Verteilung über Buckets durch einen Hash mit Geheimnis. Wäre die Funktion vorhersehbar, könnte der Angreifer einen einzelnen Bucket füllen, obwohl im übrigen Cache Platz bleibt. Das Geheimnis erschwert diese gezielte Konzentration; die Grenze deckelt Speicher und Sucharbeit.

Der Cache bleibt Zustand. Er muss Einträge verfallen lassen und die erneute Übertragung eines verlorenen SYN-ACK ermöglichen. Nur einmal zu antworten und die Wiederholungspflicht zu vergessen, würde gewöhnlichen Paketverlust in einen Verbindungsfehler verwandeln. Der Wert des Caches liegt nicht darin, TCP-Verhalten zu löschen, sondern das teure Objekt aufzuschieben und gerade genug Erinnerung bis zum letzten ACK zu bewahren.

Die Quittung in die Antwort legen

SYN-Cookies führen dasselbe Prinzip auf einen zustandslosen Pfad. Der Server behält für den Versuch keinen SYN-RECEIVED-Eintrag. Stattdessen konstruiert er seine Initial Sequence Number so, dass das abschließende ACK genügend Information zurückbringt, um den Austausch zu prüfen und den Verbindungszustand zu rekonstruieren. Erst nach einem gültigen ACK wird der vollständige Kontrollblock angelegt.

Anhang A zeigt eine Konstruktion aus der Sequenznummer des Initiators, einer Kodierung der maximalen Segmentgröße, einem Zeitzähler, Adressen und Ports sowie einer geheimen Funktion. Kehrt das ACK zurück, prüft der Server den Wert mit seinem Geheimnis und jüngeren Zählerständen. Das ist eine kompakte Quittung für genau diesen Handshake, keine Authentisierung einer Person oder Anwendung. Innerhalb der Ratefestigkeit der Konstruktion zeigt sie, dass der ACK-Sender Information aus dem SYN-ACK besitzt; eine dauerhafte Identität entsteht nicht.

Zustandslosigkeit hat einen semantischen Preis. Zwischen SYN und ACK merkt sich TCP gewöhnlich ausgehandelte Optionen. Der Platz in einem Cookie ist knapp, weshalb verbreitete Konstruktionen Window Scaling, SACK oder künftigen Optionszustand einschränken können. Der RFC nennt auch Daten im SYN. Geht das abschließende ACK verloren und wartet die Serveranwendung auf Clientdaten, bevor sie spricht, fehlt möglicherweise der Zustand für eine normale SYN-ACK-Wiederholung. Die Ressourcenzuweisung wurde verschoben, aber ein Teil des Protokollgedächtnisses ebenfalls.

Beide Verfahren lassen sich verbinden. Der Server verwendet den SYN-Cache, solange Kapazität vorhanden ist, und schaltet bei dessen Füllung auf Cookies um. Der Hybrid bewahrt unter normalen Bedingungen reichere Aushandlung und reserviert die zustandslose Quittung für Überlast. Firewalls oder Proxys können den Handshake vermitteln, verlagern aber die Zustandslast und können Ende-zu-Ende-Semantik verändern. Die Ressourcenentscheidung verschwindet nicht; sie wechselt den Eigentümer.

RFC 4987 erschien im August 2007 als Informational-Dokument, nicht als Standards-Track-Pflicht. Seine damalige Analyse bewertet SYN-Cache und SYN-Cookies als tragfähige Endpunktänderungen und sieht den Cache, wo möglich, als günstigeren Normalfall. Das ist eine historische Bewertung, kein Beleg für heutige Standardeinstellungen eines Betriebssystems.

Die dauerhafte Regel reicht weiter: Eine teure, knappe und vom Gegner steuerbare Verpflichtung sollte nicht mit der ersten ungeprüften Nachricht entstehen, wenn eine billigere und umkehrbare Darstellung den Austausch fortsetzen kann. Die Rückkehr von Information aus der Antwort liefert bessere Evidenz für Erreichbarkeit auf dem Rückweg. Sie authentisiert den Gegenüber nicht, und der Aufschub kann nützlichen Kontext verlieren. Eine ehrliche Abwehr muss deshalb sowohl die gesparte Ressource als auch die geschwächte Semantik offenlegen.

Die einzige Quelle ist RFC 4987, „TCP SYN Flooding Attacks and Common Mitigations“. Dieser Beitrag bleibt bei Endpunktzustand, den im RFC untersuchten Abwehren und deren erklärten Grenzen; er leitet daraus keine heutigen Defaults, Verbreitungsgrade oder Angriffshäufigkeiten ab.