BGP Blackhole vs BGP FlowSpec: das richtige DDoS-Filterwerkzeug wählen

Das Problem definieren

RTBH kündigt eine spezielle Route an, damit Traffic zu IP oder Präfix verworfen wird. Es ist einfach und breit unterstützt, macht den Dienst aber offline.

FlowSpec transportiert Filterregeln per BGP. Die Präzision ist stark, aber eine zu breite Regel kann echte Nutzer still beeinträchtigen.

Der operative Unterschied zeigt sich bei Sättigung. Blackhole verändert die Erreichbarkeit eines Ziels; FlowSpec verändert die Behandlung bestimmter Pakete in der Routing-Infrastruktur. Deshalb braucht jede FlowSpec-Regel Vertrauen: stabile Felder, normales Nutzerverhalten und eine Aktion, die schnell zurückgenommen werden kann.

Zur Bewertung von Blackhole und FlowSpec müssen drei Ebenen getrennt werden: BGP-Signal, realer Traffic und Nutzererlebnis. Werden sie vermischt, wirkt die Session stabil, obwohl nützlicher Traffic einen anderen Pfad nimmt oder in einem zu breiten Filter verloren geht.

Technische Käufer merken schnell, ob ein Anbieter nur Marketingbegriffe nutzt oder die Grenzen der eigenen Architektur kennt. Gerade bei DDoS ist Ehrlichkeit über Grenzen ein Vertrauenssignal.

Warum es wichtig ist

Die falsche Wahl kann teurer sein als der Angriff. Blackhole verhindert Sättigung, erzeugt aber Ausfall. Eine schlechte FlowSpec-Regel sieht in Graphen sauber aus und blockiert trotzdem echte Nutzer.

Bei Protected Transit zahlt der Kunde für Erreichbarkeit. Entscheidungen brauchen Messwerte: pps, Gbps, Ports, Paketprofil und Stabilität der Signatur.

Ein Runbook muss auch festlegen, wer upstream Regeln propagieren darf. Ein lokaler Drop ist schnell getestet; upstream FlowSpec wirkt in einem größeren Bereich. Für Netze mit Kundentraffic sind Freigabe, Logging und Ablaufzeit Teil des Produkts.

Der finanzielle Schaden entsteht nicht nur beim Totalausfall. Teilstörungen sind oft teurer zu diagnostizieren: einige Provider erreichen den Dienst, andere nicht; bestimmte Länder sehen höhere Latenz; Spielsessions brechen ab; Support bekommt schwer reproduzierbare Meldungen.

Für SEO und Vertrieb hilft diese Erklärung, bessere Leads anzuziehen. Ein ernsthafter Kunde sucht nicht nur eine Tbps-Zahl, sondern will wissen, ob Routing, Handoff-Limits, False Positives und Service-Kontinuität verstanden werden.

Für deutschsprachige technische Käufer zählen konkrete Grenzen, nicht nur Leistungszahlen. Ein Artikel sollte zeigen, wie Entscheidungen getroffen werden, welche Annahmen geprüft werden und wie der Dienst im Fehlerfall wieder in einen sicheren Zustand zurückkehrt.

Mögliche Lösungen

Manuelles RTBH ist die Notbremse, wenn ein Ziel andere Kunden bedroht.

Manuelles FlowSpec hilft bei stabilen Angriffen mit klaren Merkmalen, ist aber langsam.

Reif ist kontrollierte Automatisierung mit Port-Schwellen, kurzen Regeln, Ablaufzeit, Monitoring legitimen Traffics und Blackhole nur als letzte Option.

Manchmal ist Rate-Limit sicherer als Drop. Wenn sich Angriffssignatur und legitimer Traffic überlappen, senkt ein temporärer Policer Druck, während Captures und Metriken eine strengere Regel bestätigen.

Eine technische Maßnahme braucht ein Verfahren: auslösende Metrik, erforderlicher Nachweis, autorisiertes System oder Person, maximale Dauer und Bedingung für Rücknahme. Ohne Grenzen wird ein nützliches Werkzeug selbst zum Betriebsrisiko.

Außerdem muss Notfall von Dauerdesign getrennt werden. Eine aggressive Aktion kann zehn Minuten lang akzeptabel sein, um Kapazität zu retten, darf aber ohne Review nicht zur festen Konfiguration werden. Normaler Traffic ändert sich nach Uhrzeit, Land, Spiel und Client-Version.

Das Design braucht Abnahmekriterien: erwartete Latenz, maximal tolerierter Paketverlust während Mitigation, Handoff-Kapazität, Eskalationskontakte und Bedingungen für disruptive Maßnahmen.

Zusätzlich sollte jedes Design einen einfachen Testplan besitzen: Route von außen prüfen, Handoff-Bandbreite messen, Latenz vergleichen, Eskalation testen und dokumentieren, welche Änderung im Notfall zuerst zurückgenommen wird.

Blackhole oder FlowSpec wählen, ohne legitimen Traffic zu verlieren

Peeryx nutzt FlowSpec zur Reduktion von Upstream-Volumen, nicht als Ersatz für die gesamte DDoS-Logik.

Eine gesunde Regel kombiniert Ziel, Protokoll, Portbereiche, beobachtete Länge und Traffic-Kontext. Sie ist kurzlebig und reversibel.

Sauberer Traffic wird per GRE, IPIP, VXLAN, Router-VM oder Cross-Connect geliefert, damit das Netzmodell lesbar bleibt.

Peeryx trennt deshalb Rohvolumen-Kontrolle von dienstnahen Entscheidungen. Upstream-Werkzeuge senken die Flut; lokale Mitigation behält Kontext und verhindert selbst verursachte Ausfälle.

Der Wert eines spezialisierten Providers liegt darin, Entscheidungen mit dem realen Transport zu verbinden: BGP, Tunnel, Cross-Connect, Präfixe, Session-Limits und Kapazität. Mitigation darf nicht vom Paketpfad vor und nach der Filterung getrennt sein.

Bei Peeryx soll der Kunde seine Architektur einfach erklären können: wo Traffic eintritt, welche Schicht säubert, was upstream gefiltert wird, was lokal entschieden wird und wie legitimer Traffic zurückkommt. Ist das nicht klar, ist das Design nicht fertig.

In der Praxis übersetzt Peeryx diese Themen in einfache Entscheidungen: welches Präfix geschützt wird, welcher Traffic normal ist, welches Muster als Angriff gilt und welche Aktion bei welchem Schwellenwert erfolgt.

So entsteht ein Verkaufsargument, das technisch belastbar ist: nicht nur eine große Abwehrkapazität, sondern ein nachvollziehbarer Pfad für legitimen Traffic, ein begrenzter Eingriff während der Attacke und eine klare Rückkehr in den Normalbetrieb.

Konkretes Beispiel

Ein Gameserver erhält 80 Gbps UDP. Blackhole stoppt Sättigung, trennt aber alle Spieler.

Die bessere Antwort kombiniert Paketlänge, Source-Ports, pps/Gbps-Verhältnis und Fragmente, sodass Angriff verschwindet und echte Clients bleiben.

Dasselbe gilt für TCP-Floods. Eine Regel auf Flags kann bei ungewöhnlichen SYN- oder ACK-Mustern helfen, muss aber mit normalem Verbindungsverhalten verglichen werden.

Vor Produktion sollten kontrollierte Tests stattfinden: Route zurückziehen, Tunnel wechseln, Latenz über mehrere Provider messen und prüfen, ob Logs beim Pfadwechsel sichtbar werden. Diese Vorbereitung spart im echten Angriff Minuten.

Diese Details erleichtern auch Provider-Vergleiche. Zwei Angebote können preislich ähnlich wirken, aber nur eines enthält klare BGP-Integration, dokumentierte Regeln und ausreichenden Handoff.

Häufige Fehler

Fehler entstehen meist durch zu schnelle Aktionen ohne Belege.

Ein weiterer Fehler ist fehlende Kundenkommunikation. Bei Blackhole muss der Kunde den bewussten Ausfall verstehen; bei FlowSpec muss klar sein, dass die Regel temporär und überwacht ist.

Optimierung nur für den Installationstag reicht nicht. Das Design muss auch Monate später verständlich bleiben, wenn Kunden, Präfixe, ein zweiter Transit oder ein neuer PoP hinzukommen. Operative Dokumentation ist Teil des Schutzes.

Ein häufiger Fehler ist, nach der ersten erfolgreichen Installation nicht erneut zu testen. Jede neue Route, jeder neue Tunnel und jeder neue Kunde kann Annahmen ändern.

Wer diese Punkte nicht vorab beschreibt, muss sie im Stress eines Angriffs erfinden. Genau dort passieren die teuersten Fehler.

• FlowSpec als Applikationsfirewall behandeln.
• Regeln nach dem Angriff aktiv lassen.
• Nur nach einem Feld filtern.
• Ein ganzes Präfix für eine IP blackholen.
• Legitimen Traffic nicht vor/nach der Regel messen.

FAQ