Auf dieser Seite
Das operative Problem
TCP-Flags wirken ausdrucksstark, aber FlowSpec hält keinen Verbindungszustand. SYN, ACK und RST haben Bedeutungen, beweisen isoliert jedoch nicht, ob ein Paket legitim ist.
Bei asymmetrischem Routing verschärft sich das Problem. Die Upstream-Regel sieht möglicherweise keinen vollständigen Handshake, keinen Rückverkehr, NAT oder Load Balancer. Ein zu breiter ACK- oder RST-Filter kann echte Sessions treffen.
Warum es vor dem Angriff zählt
TCP-Floods können SYN-Backlog, Verbindungstabellen oder Anwendungen erschöpfen, ohne die gesamte Bandbreite zu füllen. Flags helfen, offensichtliche Muster upstream zu entfernen.
False Positives sind bei TCP teuer: eingefrorene Sessions, nicht ladende Ressourcen, instabile APIs. Deshalb brauchen Flag-Regeln Ziel, Port, Rate und Laufzeit.
Mögliche technische Ansätze
Bei SYN-Floods kann eine enge Regel auf Host oder Port sinnvoll sein, besonders mit Downstream-Validierung. Bei ACK-Floods ist Vorsicht nötig, weil legitimer etablierter Traffic existieren kann.
Robust ist die Kombination aus FlowSpec für Upstream-Entlastung und state-aware Filtern oder Proxy-Logik für Kontext. Kein einzelnes Flag sollte dauerhafte Policy werden.
Ein SYN-Match beweist keinen Angriff
Eine API auf TCP-Port 443 erhält eine SYN-Flut. Eine Regel, die alle SYN-Pakete an dieses Ziel verwirft, verwirft auch legitime Verbindungsversuche. Die Eingrenzung des Ziels macht diese Regel für die Nutzer des Dienstes nicht sicher.
Ermitteln Sie vor einem Drop ein zusätzliches Merkmal, das unerwünschte Pakete von gültigen Verbindungsaufbauten unterscheidet. Prüfen Sie es anhand repräsentativen legitimen Verkehrs. Fehlt dem Router diese Unterscheidungsmöglichkeit, ist eine passende nachgelagerte TCP-Validierung nötig. Ein Policer begrenzt sämtlichen passenden Verkehr; Angriffspakete können sein Kontingent ebenfalls aufbrauchen.
Geben Sie Match und Aktion an, prüfen Sie die Interpretation der TCP-Flag-Maske am empfangenden Router und beobachten Sie neue sowie bestehende Verbindungen. Legen Sie Rücknahme und Verantwortlichkeit für den Ablauf fest. FlowSpec beweist keine Zugehörigkeit zu einer gültigen TCP-Sitzung.
Häufige Fehler vermeiden
- Provider-Grenzen ignorieren.
