Route Hijacking und DDoS: wie ein BGP-Vorfall zum Ausfall wird

Das Problem definieren

Ein Origin Hijack ist ein falscher AS-Origin für ein Präfix.

Ein More-Specific oder Route Leak kann Traffic anziehen und den Pfad brechen.

Gefährlich ist, dass der Dienst intern gesund wirken kann. Server und Firewalls zeigen normale Werte, weil Traffic bereits umgeleitet wurde.

Zur Bewertung von Route Hijacking und BGP-Security 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

Viele DDoS-Pläne setzen voraus, dass Traffic die Mitigation erreicht.

Wenn Routing fehlschlägt, zeigen Scrubbing-Graphen teils nichts, während Nutzer offline sind.

Ein Angreifer braucht keine riesige Paketmenge, wenn er Erreichbarkeit manipuliert. Ein kurzer Routing-Vorfall erzeugt sichtbare Downtime und verwirrt die Response.

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.

Dieser zusätzliche Aufwand lohnt sich, weil er spätere Ausfälle kürzer macht und dem Kunden zeigt, dass Schutz nicht nur aus Marketingzahlen besteht.

Damit wird aus Routing-Sicherheit ein echter Bestandteil der Verfügbarkeit.

Ohne diese Vorbereitung bleibt selbst eine starke DDoS-Plattform abhängig von externen Fehlankündigungen.

Mögliche Lösungen

Routing-Hygiene: IRR, AS-SET, Prefix-Limits und Filter.

RPKI/ROA reduziert ungültige Origins bei Validierung.

Externes Monitoring erkennt Origin Changes und More-Specifics.

RPKI braucht Monitoring. Ein gültiger ROA hilft wenig ohne Alert auf konkurrierende Origins, und Monitoring ohne Eskalationskontakte bestätigt nur schneller den Ausfall.

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.

Gerade bei Route Hijacking ist Geschwindigkeit entscheidend: eine saubere Kontaktliste, vorbereitete Nachweise und bekannte Routing-Objekte verkürzen Eskalationen deutlich.

Route Hijacks erkennen und begrenzen, bevor ein Ausfall entsteht

Peeryx integriert Routing-Security in Protected Transit.

Vor Aktivierung müssen ASN, AS-SET, Limits und ROA klar sein.

Im Incident muss die Diagnose auch den BGP-Control-Plane prüfen.

Peeryx nimmt Route Security in die Aktivierung auf. Präfixbesitz, AS-SET, Route-Objekte und erwartete Origins werden vor kritischer Produktion geprüft.

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 Hoster kündigt ein /24 über Mitigation an, aber ein anderes AS kündigt es fälschlich an.

Mit ROA, Filtern und Alerts wird der Vorfall schneller erkannt.

Dasselbe hilft bei geplanten Änderungen. Beim Wechsel zu Protected Transit bestätigt externe Sichtbarkeit, dass das Internet den erwarteten Origin sieht.

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

Der Fehler ist, BGP-Security von DDoS zu trennen.

Ein häufiger Fehler ist ein zu breiter ROA Max-Length. Das erleichtert Betrieb, schwächt aber Schutz gegen unerlaubte spezifischere Ankündigungen.

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.

• ROA Max-Length zu breit.
• IRR/AS-SET nicht pflegen.
• Keine Prefix-Limits.
• Nur Server überwachen.

FAQ