Cloudflares BGP-Test legt die falsche Spur offen

Der Trick sitzt am Anfang des Pfads

Eine BGP-Route kann sauber aussehen und trotzdem an der falschen Haustür klingeln. Cloudflare nimmt genau diese Lücke ins Visier: Ein Angreifer baut einen AS_PATH so um, dass Verkehr einen ungewohnten Weg nimmt und seine Herkunft schlechter zu erkennen ist. Der Beitrag des Unternehmens erschien am 3. Juni 2026; Anlass waren laut Cloudflare jüngere, von Spamhaus gemeldete Route Hijacks.

Das Angriffsmuster ist unerquicklich schlicht. Cloudflare schreibt, dass Akteure in vielen Fällen ungenutzte autonome Systemnummern verwenden und gefälschte AS_PATHs zu Zielen ankündigen. Ein AS_PATH ist die Liste der autonomen Systeme, die eine Route durchlaufen haben soll. Wer diese Liste manipuliert, versucht nicht, BGP neu zu erfinden. Er nutzt aus, dass Nachbarn Angaben akzeptieren können, die sie bereits am ersten Eintrag hätten stoppen können.

Die Folge bleibt nicht bei einer unschönen Routing-Tabelle. Cloudflare beschreibt, dass ein Hijacker genügend Pfadinformationen entfernen könnte, um selbst als Ursprung eines BGP-Präfixes zu erscheinen. Dann kann Verkehr abgefangen oder umgeleitet werden. Das ist kein Hollywood-Hack mit grünem Text auf schwarzem Bildschirm. Es ist schlimmer: eine fehlerhafte Annahme zwischen Netzen, die einander routinemäßig vertrauen.

BGP First AS setzt genau an diesem überprüfbaren Punkt an. Der Check sagt nichts über die Absicht eines Peers aus; er vergleicht eine behauptete Pfadhistorie mit dem Nachbarn, der sie gerade liefert. Das genügt, um eine ganze Klasse plumper Fälschungen früh auszusortieren. Sicherheit darf gelegentlich erfreulich langweilig sein.

BGP First AS prüft den direkten Nachbarn

Der BGP-First-AS-Check ist keine komplizierte Magie, und das ist sein Vorteil. Bei einer externen BGP-Sitzung kontrolliert ein Router, ob die AS-Nummer seines Peers am linken Anfang des angekündigten AS_PATH auftaucht. Fehlt sie, passt die behauptete Herkunft der Route nicht zum direkten Nachbarn. Die Route darf dann nicht gemütlich weiterfahren.

Cloudflare fasst die Regel als einfache Prüfung zusammen: Das autonome System eines BGP-Peers muss sein Netz als „First AS“ in einer angekündigten Route enthalten. RFC 4271 erlaubt diese Kontrolle für Updates von externen Peers. RFC 7606 beschreibt für fehlerhafte AS_PATH-Attribute den Umgang per treat-as-withdraw. Gemeint ist: die betroffene Route verwerfen, nicht gleich die ganze Sitzung mit dramatischem Türknallen beenden.

RPKI bleibt dabei nützlich, aber es erledigt diese Aufgabe nicht automatisch. Cloudflare trennt die Themen ausdrücklich: RPKI hilft gegen einen Teil der Routing-Probleme; bei bestimmten manipulierten Pfaden braucht es zusätzlich die Prüfung des ersten AS. Wer RPKI als Generalschlüssel verkauft, hält anschließend einen Schlüsselbund in der Hand und wundert sich über die verschlossene Seitentür.

Für BGP First AS ist diese Regel deshalb so wertvoll, weil sie vor der Auswahl und Verbreitung einer Route greift. Sie ersetzt keine Filter für Präfixe, keine RPKI-Validierung und keine sorgfältige Peering-Policy. Sie ergänzt sie an einer Stelle, an der ein direkter Widerspruch ohne langes Rätselraten sichtbar wird.

Cloudflare testet große Transitnetze

Cloudflare hat die Frage nicht bei einer Konfigurationsanleitung gelassen. Das Unternehmen testete mehrere große Netze und untersuchte deren BGP-Implementierungen. Für die Messung kündigte Cloudflare Testpräfixe so an, dass sie die First-AS-Regel absichtlich verletzten. Öffentliche BGP-Route-Views sollten zeigen, ob ein Netz die Route verwarf oder für die Weiterleitung installierte.

Die erwartete Trennung war klar: Netze mit aktivem Enforcement sollten die Route über den RFC-7606-Mechanismus still zurückziehen. Netze ohne Enforcement würden sie laut Cloudflare akzeptieren und in Richtung der Testpräfixe weiterleiten. Cloudflare fand zugleich Netze, die bei fehlerhaften AS_PATHs Sitzungen zurücksetzten, statt nur die betroffene Route zu behandeln. Deshalb verzichtete das Unternehmen auf dauerhafte, breit ausgespielte Fehlankündigungen; reale Cloudflare-Verkehre sollten nicht zum Kollateralschaden eines Messaufbaus werden.

Für Betreiber ist das ein brauchbarer Warnhinweis, kein Anlass für Alarmismus. Ein Testpfad kann Sicherheitslücken sichtbar machen, aber er beschreibt keine pauschale Quote für das gesamte Internet. Entscheidend ist die eigene Nachbarschaft: Welche externen Sessions prüfen den ersten Eintrag bereits, welche Konfigurationen erben alte Defaults, und welche Router reagieren bei einem Fehler mit mehr als dem Verwerfen einer Route?

Die Messung trennt auch Theorie und Betrieb. BGP First AS lässt sich als Häkchen dokumentieren; erst eine absichtlich ungültige Ankündigung zeigt, ob der Router sie tatsächlich verwirft. Teams sollten solche Tests in einer kontrollierten Umgebung planen, mit Rückfallweg und klaren Beobachtungspunkten. Eine Route darf dabei Prüfobjekt sein, nicht Versuchskaninchen im Kundentraffic.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptIn a cool evening network classroom, three operators compare the first colored block in several plain routing chains before allowing each path onward. A documentary composition emphasizes practical consequences; every surface is blank and unbranded, with no readable text, words, numbers, labels, logos, screens, user interfaces, dashboards, or signs. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Route Server sind die Ausnahme mit Ansage

Es gibt einen legitimen Grund, den Check nicht blind auf jede externe Sitzung zu kleben: transparente Route Server an Internet Exchanges. Ein solcher Server verteilt Routen zwischen Teilnehmern, ohne sein eigenes AS in den AS_PATH einzufügen. Das spart den Teilnehmern viele einzelne Peerings. Er würde durch eine unbedachte First-AS-Prüfung allerdings wie ein Betrüger behandelt, obwohl er nur seinen Job macht.

Cloudflare nennt genau diesen Fall als gültige Ausnahme. Die Konsequenz ist angenehm unromantisch: Für Route-Server-Sessions kann „no enforce-first-as“ nötig sein, für normale Nachbarn dagegen nicht. In Produktionsnetzen gibt es laut Cloudflare meist deutlich mehr gewöhnliche Nachbarn als transparente IX-Route-Server. Eine restriktive Voreinstellung mit wenigen, dokumentierten Ausnahmen ist daher leichter zu prüfen als eine lange Liste manuell aktivierter Schutzschalter.

Diese Unterscheidung gehört in die Konfiguration und in den Betriebsalltag. Eine Ausnahme ohne Eigentümer, Zweck und Gegenprüfung wird schnell zum kleinen Museumsstück: historisch gewachsen, niemand fasst es an, und irgendwann bewacht es ausgerechnet den falschen Eingang. Ein Netzwerkteam sollte jede ausgenommene Session einem konkreten Route-Server- oder Partnerfall zuordnen können.

Für BGP First AS heißt das nicht, Ausnahmen zu verteufeln. Es heißt, sie klein zu halten. Eine Ausnahme für einen bekannten transparenten Route Server ist technisch begründet; eine Sammelausnahme für „Peerings, die früher mal schwierig waren“ ist eine Einladung, die Jahre später niemand mehr liest. Konfigurationen besitzen leider ein langes Gedächtnis.

Wo alte Defaults den Schutz ausbremsen

Die Sache scheitert oft nicht an BGP selbst, sondern an Gewohnheiten in Betriebssystemen und Vorlagen. Cloudflare berichtet, dass die Durchsetzung je nach Plattform und Implementierung unterschiedlich ausfällt. Daraus folgt keine Rangliste der „guten“ und „schlechten“ Router. Sie zeigt aber, dass ein Sicherheitsmerkmal nicht als aktiviert gelten darf, nur weil ein Handbuch eine passende Befehlszeile kennt.

Prüfen Sie daher pro externem Peer die tatsächliche Policy, nicht nur das globale Template. Die relevante Frage lautet: Kontrolliert der Router eingehende Ankündigungen auf das First AS, und behandelt er einen Verstoß als Route-Fehler statt als Sitzungsproblem? Dokumentieren Sie ebenso, wer eine Ausnahme freigegeben hat. Das ist weniger elegant als ein grünes Dashboard, aber Routing-Ausfälle lesen keine Dashboards.

Die Verbindung von Angriffsfläche und Wartung ist vertraut. Auch bei manipulierten Paketabhängigkeiten entscheidet eine kleine Vertrauensgrenze darüber, ob schädlicher Input weiterzieht. Bei BGP liegt diese Grenze nicht in einer Dependency-Datei, sondern zwischen zwei autonomen Systemen. Der Maßstab bleibt derselbe: Eingaben prüfen, bevor sie Reichweite bekommen.

BGP First AS gehört deshalb in Change-Reviews, Monitoring und die Baseline für neue Peers. Wer einen neuen Nachbarn aufnimmt, sollte die erwartete AS-Nummer, die relevante Policy und den Umgang mit fehlerhaften Pfaden im selben Vorgang festhalten. Das reduziert die Chance, dass ein sinnvoller Standard an einem alten Sonderfall leise zerbröselt.

Ein kontrollierter Rollout statt einer großen Schalterparty

Ein sauberer Rollout beginnt mit einer Inventur aller externen BGP-Sessions. Trennen Sie normale Transit-, Kunden- und Peering-Nachbarn von transparenten IX-Route-Servern. Für die erste Gruppe gehört BGP First AS in die gewünschte Baseline; für die zweite braucht es eine belegbare Ausnahme. Die Reihenfolge zählt, weil ein unmarkierter Route Server bei einem pauschalen Aktivieren plötzlich als fehlerhafter Nachbar erscheint.

Danach lohnt ein Test mit klarer Beobachtung: Policy aktivieren, eingehende und ausgehende Routen kontrollieren, Treat-as-withdraw-Ereignisse erfassen und die Session-Stabilität prüfen. Cloudflares Messung zeigt, warum dieser letzte Punkt nicht pedantisch ist. Manche Netze reagierten auf fehlerhafte AS_PATHs mit Session-Resets. Eine Sicherheitsregel, die den Fehler korrekt erkennt, aber dabei unnötig die Nachbarschaft stört, braucht eine andere Behandlung als ein sauberer Route-Withdraw.

Die zweite interne Perspektive liefert der Beitrag über automatisiertes Credential Stuffing nach einem Passwortmanager-Vorfall: Prävention funktioniert dort ebenfalls nur, wenn Kontrollen an der Eintrittsstelle greifen und Ausnahmen nicht stillschweigend wachsen. BGP ist technisch anders, die Betriebsdisziplin erstaunlich ähnlich.

Im Rollout zählt außerdem die Kommunikation mit Partnern. Eine Änderung an BGP First AS kann sichtbar machen, dass die Gegenstelle fehlerhafte Pfade ankündigt oder selbst bei Fehlern eine Sitzung trennt. Ein vereinbarter Testzeitraum, benannte Kontakte und ein Rücksetzplan machen aus diesem Fund eine behebbare Störung statt eines nächtlichen Ratespiels mit zu viel Kaffee.

Fünf Punkte für die nächste Routing-Runde

Cloudflares Befund verdient keine Panikmeldung, aber einen festen Platz in der nächsten Routing-Review. Gefälschte AS_PATHs nutzen eine Lücke aus, die sich direkt am Nachbarn prüfen lässt. Die Gegenmaßnahme ist präzise genug, um sie pro Session zu kontrollieren, und begrenzt genug, um echte Route-Server-Ausnahmen sauber abzubilden.

• Prüfen Sie für jede externe BGP-Session, ob der Peer als erstes AS im eingehenden Pfad verlangt wird.
• Führen Sie transparente IX-Route-Server als explizite Ausnahme mit Verantwortlichem und Zweck.
• Testen Sie, ob ein fehlerhafter AS_PATH nur die Route verwirft und keine gesamte Sitzung zurücksetzt.
• Vergleichen Sie die laufende Router-Policy mit Ihren Vorlagen; alte Defaults sind keine Sicherheitszusage.
• Beobachten Sie Route-Views und Logs nach Änderungen, damit ein fehlerhafter Pfad nicht unbemerkt weitergereicht wird.

Das Ergebnis ist kein Schutzschild gegen jede Routing-Panne. Es reduziert jedoch eine sehr konkrete Gelegenheit für Manipulation: dass ein direkter Nachbar einen Pfad behauptet, dessen erster Eintrag nicht zu ihm passt. Bei BGP ist das eine erfreulich kurze Prüfung. Gerade deshalb sollte sie nicht im Konfigurationskeller verstauben.

Wenn Sie nur eine Sache aus Cloudflares Test mitnehmen: BGP First AS ist kein Projekt für die nächste Großmigration. Es ist eine kleine, gezielte Kontrolle an externen Sessions. Genau solche Kontrollen fehlen oft, bis ein manipuliertes Update zeigt, wie weit eine falsche Behauptung im Netz noch reisen darf.