Zusammenfassung

  • Ein SYN Cookie kodiert prüfbaren provisorischen TCP-Zustand in der anfänglichen Sequenznummer des Servers. Ein ausdrücklicher SYN-RECEIVED-Eintrag entsteht erst, wenn das dritte ACK zurückkehrt.
  • Der zurückgebrachte Beleg weist jüngsten Zugang zum Antwortpfad dieses Vierertupels nach. Er authentisiert keine Person, berechtigt keine Anwendung und reserviert keine nachgelagerte Kapazität.
  • Die 32-Bit-Sequenznummer ist ein begrenztes Informationsbudget. Auslöser, rekonstruierbare Optionen, Verlustverhalten und verbleibende Engpässe müssen an der tatsächlich laufenden Kette belegt werden.

Beim normalen passiven Öffnen geht der Server in Vorleistung. Ein SYN versetzt ihn in SYN-RECEIVED; er erzeugt einen SYN-ACK und merkt sich genug über den unfertigen Versuch, um das letzte ACK zu erkennen. Der Absender hat noch nicht gezeigt, dass ihn Antworten an der behaupteten Adresse erreichen. Trotzdem belegt seine Behauptung bereits einen Platz in einer endlichen Warteschlange.

Ein SYN Flood vervielfacht diese Vorleistung. Anfänge ohne Abschluss warten auf Wiederholung und Ablauf. Sobald die embryonale Tabelle voll ist, verlieren legitime Clients ihren Zugang, obwohl Leitung, Anwendung oder bestehende Verbindungen noch Reserven haben können. RFC 4987 grenzt den klassischen Angriff deshalb auf den Verbindungsaufbauzustand ein; er beweist nicht automatisch die Erschöpfung jeder Bandbreiten- und Rechenressource.

Die Gegenmaßnahmen verteilen Verluste unterschiedlich. Ein größeres Backlog gewinnt Zeit und setzt mehr Speicher aufs Spiel. Kürzere Timer räumen schneller auf, benachteiligen aber langsame oder verlustreiche Pfade. Das Wiederverwenden des ältesten Eintrags lässt Alter statt Gültigkeit entscheiden. Ein SYN Cache hält eine kleinere Akte. Ein Proxy beendet den Handshake an anderer Stelle und verschiebt sowohl Semantik als auch Risiko.

Das SYN Cookie verzichtet ganz auf die Akte. Der Server wählt seine anfängliche Sequenznummer so, dass sie eine verdichtete Beschreibung des Versuchs und eine von einem lokalen Geheimnis abhängige Prüfung trägt. Historische Verfahren verbinden Adressen und Ports, die erste Client-Sequenznummer, einen langsam laufenden Zeitzähler, eine MSS-Klasse und Servergeheimnisse. RFC 4987 dokumentiert Entwürfe und Abwägungen, schreibt aber keinen einheitlichen Algorithmus vor.

Der Client muss davon nichts wissen. Er empfängt einen gewöhnlichen SYN-ACK und bestätigt die Servernummer plus eins. Beim dritten Paket gewinnt der Server den Wert zurück, prüft noch zulässige Zeitfenster und berechnet seine geheime Funktion über das beobachtete Tupel erneut. Stimmt sie, rekonstruiert er genügend Zustand für ESTABLISHED. Andernfalls verwirft er das Paket, ohne nach einem embryonalen Datensatz zu suchen, den es nie gab.

Das Cookie ist daher eher eine vom Antragsteller getragene Quittung als ein Ausweis. Der Server stellt einen nur von ihm prüfbaren Beleg aus, ohne ein Konto zu eröffnen. Seine Rückkehr zeigt, dass jemand den jüngsten SYN-ACK für diesen Pfad empfangen, beobachtet oder anderweitig erfahren hat. Für eine lokale Speicherzulassung kann das genügen. Name, Organisation, Absicht und künftiger Arbeitsaufwand bleiben unbekannt.

Das Geheimnis erschwert blindes Raten außerhalb des Pfades, macht TCP aber nicht zur Identitätsprüfung. Ein Beobachter auf dem Pfad sieht den Austausch. Reale Bot-Adressen können gültige Cookies massenhaft zurückgeben. Nach der Zulassung verbrauchen die Verbindungen weiterhin Socket-Speicher, TLS-Rechenzeit, Worker, Datenbanken und fachliche Kontingente. Verschoben wird eine Verpflichtung, nicht jede spätere Ausgabe.

Der Verzicht auf Erinnerung verlangt Kompression. Die Sequenznummer umfasst 32 Bit und behält ihre TCP-Aufgabe. Ein normaler Eintrag könnte sämtliche Optionen des ersten SYN sichern. Ein einfaches Cookie muss denselben Raum für Frische, Integrität und notwendige Parameter teilen. Ältere Schemata legten etwa nur einen kleinen Index für häufige MSS-Werte ab. Was weder kodiert noch aus dem ACK abgeleitet werden kann, steht der Rekonstruktion nicht zur Verfügung.

Window Scale macht die Folge sichtbar. RFC 7323 lässt die Option nur in SYN-tragenden Segmenten aushandeln und fixiert den Faktor je Richtung beim Öffnen. Hat der zustandslose Server das Angebot vergessen und besitzt keine Cookie-Erweiterung dafür, kann er es später nicht nachholen. RFC 4987 beschreibt entsprechende historische Einschränkungen bei Window Scale, SACK und weiterem Zustand, aber auch ein FreeBSD-Verfahren, das zurückgespiegelte Timestamp-Bits für zusätzliche Information nutzte.

Daraus folgt keine plattformübergreifende Behauptung. Nicht jede Implementierung verliert dieselben Optionen; neuere Kodierungen gewinnen mehr zurück. Ebenso wenig überlebt jede Option, nur weil ein System zusätzliche Bits fand. Maßgeblich sind Kernel, Version, Offload, Load Balancer, Proxy und Listener auf dem produktiven Pfad.

Der Verlust des dritten ACK zeigt einen weiteren Preis bei serverseitig beginnenden Protokollen. RFC 4987 nennt SMTP: Der Client sendet sein letztes ACK, hält die Verbindung für offen und wartet auf die Begrüßung. Geht das ACK verloren, besitzt der zustandslose Server keinen Eintrag für seine Wiederholungslogik und hat die Anwendung noch nicht informiert. Die Erholung hängt von weiteren Retransmits und der konkreten Implementierung ab. Speicherschutz verändert, welche Seite das Schweigen zuerst bemerkt.

Ein hybrider Betrieb begrenzt diesen Preis. Unter gewöhnlicher Last bewahrt ein normales Backlog oder ein SYN Cache reicheren Aushandlungszustand und gewohntes Wiederholungsverhalten. Erst beim lokalen Überlauf wechselt die Implementierung zu Cookies, statt bereits gespeicherte Versuche auszuwerfen. Der Modus wird so zu einer Notfallpolitik mit messbarem Eintritt, messbaren Nebenwirkungen und einem Ausgang.

Die aktuelle Linux-Dokumentation zieht genau diese Grenze. tcp_syncookies ist ein Fallback bei Überlauf des SYN-Backlogs eines Sockets, nicht ein Mittel, um einen überlasteten Server eine legitime Verbindungsrate tragen zu lassen. tcp_max_syn_backlog beschreibt getrennt, wie viele SYN_RECV-Anfragen ein Listener merkt. Wenn normale Nachfrage dauerhaft den Fallback aktiviert, sind Kapazität, Warteschlangen und Dienstleistung zu untersuchen.

Selbst ein perfektes Cookie schützt weder Paketempfang noch Analyse, geheime Berechnung, SYN-ACK-Ausgabe oder ACK-Prüfung. Leitung, Interrupts, Queues und CPU können weiterhin sättigen. Nach dem Handshake bleiben Accept Queue, etablierte Sockets, Kryptografie, Worker und Abhängigkeiten knapp. Einen Engpass weiterzuschieben kann korrekt sein; ihn unsichtbar und eigentümerlos zu lassen, ist es nicht.

Quelladressvalidierung ergänzt diese Grenze. BCP 38 und BCP 84 erschweren es Netzen, gefälschte Absender zu exportieren, und verringern Antworten an erfundene Ziele. Reale Angreifer und legitime Spitzen schließen Handshakes dennoch ab. Das Ursprungsnetz entscheidet, welche Quellen es hinauslässt; der Endpunkt entscheidet, wann er Zustand bindet. Beide Kontrollen sind notwendig und verschieden.

Die Beobachtung muss die Evidenz ersetzen, die nicht mehr als Zeile existiert. RFC 4898 trennt embryonale Ereignisse, vollständige Ressourcenbindung und Anwendungsannahme. Es weist darauf hin, dass ein SYN-Cookie-System den kodierten SYN-RCVD-Zustand nicht ausdrücklich darstellt. Eine leere Halböffnungstabelle kann Ruhe bedeuten – oder dass der Server aufgehört hat, sich zu erinnern.

Darum gehören SYN-Eingang, SYN-ACK, Wiederholungen, Belegung und Überlauf, erzeugte Cookies, gültige, ungültige und alte Rückgaben, etablierte Verbindungen, Accept Queue und Anwendungsannahmen in eine Kette. MSS, Window Scale, SACK, Timestamp, ECN und Fast Open müssen bei normalen und rekonstruierten Verbindungen verglichen werden. Fehlt der Moduswechselzähler, verschwindet mit dem Zustand auch das Warnsignal.

TCP Fast Open kann unter einem anderen Cookie-Vertrag und anderen Replay-Annahmen Anwendungsdaten im SYN tragen. RFC 7413 erlaubt nicht die Annahme, ein klassischer SYN-Cookie-Fallback bewahre diese Daten. Frontend, Load Balancer, Offload und Kernel sind gemeinsam zu testen. Die gleiche Bezeichnung „Cookie“ schafft keine gleiche Semantik.

SCTP bietet den architektonischen Kontrast. RFC 9260 reserviert in seinem Vier-Schritte-Aufbau ein variables State Cookie mit Assoziationsinformation, MAC, Zeitstempel und Lebensdauer. Es ist weder TCP-kompatibel noch der kompakte TCP-Algorithmus. Es zeigt lediglich, dass zustandslose Zulassung mehr Verhandlung erhalten kann, wenn das Protokoll einen eigenen Behälter vorsieht, statt alles in ein altes Feld zu pressen.

Eine gemeinsame Spezifikation kann Handshake-Invarianten und bekannte Abwägungen beschreiben. Sie kennt nicht Speicher, Latenz, notwendige Optionen und nachgelagerte Kosten jedes Listeners. Heng Lus Prinzip der minimalen Anfangsspezifikation lässt Schwelle und akzeptierbaren Verlust beim Betreiber. Running-Code Primacy liefert die Prüfung: Der gesetzte Wert ist Absicht; die beobachteten Verbindungen beweisen, welcher Dienst tatsächlich blieb.

Quellen