Auf dieser Seite
Das operative Problem
FlowSpec sieht Header-Komponenten: Ziel, Protokoll, Ports, Paketlänge, TCP-Flags und ähnliche Felder je nach Provider. Es weiß nicht, ob eine Session zu einem echten Spieler, einer kritischen API oder einem Botnet gehört.
Jeder Upstream setzt Grenzen bei Regelzahl, Aktionen, Zielgranularität und unterstützten Feldern. Eine Architektur, die unbegrenzte FlowSpec-Präzision annimmt, versagt im Ernstfall.
Warum es vor dem Angriff zählt
Eine zu breite Regel greift, bevor der Kunde legitimen Traffic mit eigener Logik retten kann. Die Leitung wirkt sauber, aber echte Nutzer können ausgeschlossen sein.
Diese Grenzen verhindern falsche Erwartungen. FlowSpec ist am stärksten, wenn es schweren, offensichtlichen Traffic entfernt, damit Downstream-Mitigation mit weniger Druck arbeitet.
Mögliche technische Ansätze
Sicher ist FlowSpec als Entlastung: kurze Regeln, konkretes Ziel, klares Protokoll und Ablaufzeit. Wenn das Muster instabil ist, sollte nicht versucht werden, den ganzen Angriff in einer Regel zu beschreiben.
Entscheidungen mit Zustand, Baseline oder Anwendungswissen gehören in DPDK/VPP, XDP, Proxy, Post-Filter-Regeln oder gaming-spezifische Logik.
Konkreter Anwendungsfall
Ein 180-Gbit/s-UDP-Flood wiederholt Port und Größe gegen eine IP. Eine enge FlowSpec-Regel reduziert Druck vor dem Handoff. Eine globale UDP-Regel auf das ganze Präfix könnte DNS, Spiele oder Monitoring brechen.
Richtig ist ein schrittweises Vorgehen: offensichtliche Signatur filtern, erlaubten Traffic beobachten und gemischten Resttraffic einer kontextreicheren Downstream-Schicht überlassen.
Häufige Fehler vermeiden
- Provider-Grenzen ignorieren.
