BGP-FlowSpec-Grenzen: was es filtern kann und wo es gefährlich wird

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.

Wie Peeryx diese Schicht entwirft

Peeryx nutzt FlowSpec als Upstream-Entlastung, wenn ein Flood Ports oder Filterkapazität bedroht. Die Regel ersetzt keine vollständige Mitigation, sondern reduziert Lärm für die feinere Schicht.

Für Hosting und Gaming ist diese Trennung entscheidend. Eine generische Regel kann wirksam aussehen und dennoch legitime Sessions beschädigen. Peeryx bevorzugt erklärbare, temporäre und messbare Regeln.

Operative Checkliste vor dem Produktiveinsatz

Vor dem Einsatz in Produktion sollte das Team das normale Profil des Dienstes dokumentieren: Ports, Protokolle, Paketgrößen, übliche Rate, Spitzenzeiten, externe Abhängigkeiten und Verhalten legitimer Nutzer. Ohne diese Referenz wirkt in einer Krise fast jede Regel plausibel, kann aber den Dienst verschlechtern, ohne dass die Mitigationsgrafik das Problem klar zeigt.

Während eines Angriffs sollte jeweils nur eine Variable geändert werden: zuerst der Zielumfang, dann die Match-Komponente, danach Laufzeit und schließlich die Downstream-Anpassung. Diese Disziplin verhindert zu aggressive Regeln und macht erklärbar, warum ein Muster blockiert wurde und warum legitimer Traffic weiter funktionieren sollte.

Nach dem Incident sollte dieselbe Logik erneut bewertet werden. Entscheidend ist nicht nur, ob der Angriff kleiner wurde, sondern ob Kunden, Spieler, APIs oder Monitoring weiterhin stabil funktionierten. Diese Nachanalyse macht aus einer Notfallregel eine wiederverwendbare Betriebsregel und verhindert, dass alte Filter unbemerkt in Produktion bleiben.

• Eine Traffic-Baseline vor dem Incident speichern.
• Festlegen, wer Regeln erstellen, ändern oder zurückziehen darf.
• Die Wirkung auf echte Nutzer prüfen, nicht nur Angriffsgrafiken betrachten.
• Einen sofortigen Rollback-Pfad bereithalten.
• Regeln erneut prüfen, sobald der Angriff seine Form ändert.
• Nach dem Angriff akzeptierten Traffic mit Logs und Kundensignalen vergleichen.
• Temporäre Regeln in dokumentierte Betriebsentscheidungen oder in einen vollständigen Rückbau überführen.
• Für den nächsten Incident klare Schwellenwerte für Aktivierung und Deaktivierung festlegen.

Fragen, die vor dem Kauf gestellt werden sollten

Vor einer Bestellung sollte der Anbieter nicht nur Kapazität nennen, sondern auch erklären, wie Regeln erzeugt, begrenzt, überwacht und zurückgezogen werden. Wichtig sind konkrete Antworten zu Quoten, Aktivierungslogik, False-Positive-Kontrolle, Handoff, Eskalation und zu den Grenzen des Upstreams.

Ein Kunde sollte außerdem prüfen, ob das Angebot zur eigenen Topologie passt. Ein ASN-Kunde, ein einzelner Spieleserver, eine Hosting-Plattform und eine SaaS-API brauchen nicht dieselbe Delivery. Gute Mitigation beginnt deshalb mit Netzwerkdesign, nicht mit einem generischen Paketnamen.

• Welche Komponenten und Aktionen unterstützt der Upstream wirklich?
• Wie schnell kann eine Regel zurückgezogen werden?
• Wie wird legitimer Traffic während der Regel beobachtet?
• Passt die Delivery zu BGP, Tunnel, Cross-Connect oder Router-VM?

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

• Globale Regeln aus einem kurzen Sample ableiten.
• Ablaufzeit oder Rollback einer temporären Regel vergessen.
• Nur gedroppte Gbps messen und nicht die Nutzererfahrung.
• Provider-Grenzen ignorieren.
• Denselben Filter ungeprüft für Web, Gaming und Tunneltraffic nutzen.

FAQ