Analyse der in Venezuela aufgetretenen BGP-Anomalie

 (blog.cloudflare.com)
1 Punkte von GN⁺ 2026-01-09 | 1 Kommentare | Auf WhatsApp teilen
  • Im Netzwerk von CANTV (AS8048) in Venezuela kam es mehrfach zu BGP-Route-Leaks, wodurch einige Netzwerkpfade anormal weiterverbreitet wurden
  • Laut Daten von Cloudflare Radar wurden seit Dezember 11 Leak-Ereignisse bestätigt; als wahrscheinlichste Ursache gilt ein technischer Fehler durch unzureichende Routing-Richtlinien
  • In diesem Vorfall leitete AS8048 Pfade, die es vom Upstream-Provider AS6762 (Sparkle) erhalten hatte, an einen anderen Provider AS52320 (V.tal GlobeNet) weiter – eine typische Struktur eines Type-1-Hairpin-Leaks
  • RPKI-basierte Route Origin Validation (ROV) ist in diesem Fall nicht wirksam; zur Verhinderung solcher Leaks werden neue Standards wie ASPA (Autonomous System Provider Authorization) und RFC9234 benötigt
  • Aufgrund der vertrauensbasierten Struktur von BGP sind solche Vorfälle häufig; die Einführung von Technologien wie ASPA, Peerlock und RFC9234 ist entscheidend für einen sicheren Internetbetrieb

Das Konzept von BGP-Route-Leaks

  • BGP (Border Gateway Protocol) ist das Protokoll zum Austausch von Pfaden zwischen autonomen Systemen (AS) im Internet
    • Beziehungen zwischen Netzwerken sind als Customer-Provider oder Peer-Peer organisiert
  • Ein Route-Leak wird in RFC7908 als „Weiterverbreitung von Routing-Informationen über den beabsichtigten Geltungsbereich hinaus“ definiert
    • Beispiel: Wenn ein Kunde Pfade, die er von einem Provider erhalten hat, erneut an einen anderen Provider weiterverbreitet
  • Solche Leaks verstoßen gegen die Valley-Free-Routing-Regel, wodurch Traffic über anormale Pfade geleitet wird
    • Das führt zu Problemen wie Netzwerküberlastung, Latenz und Traffic-Verlust

Der Route-Leak-Fall von AS8048 (CANTV)

  • Cloudflare Radar bestätigte, dass AS8048 (CANTV) Pfade, die von AS6762 (Sparkle) empfangen wurden, an AS52320 (V.tal GlobeNet) weiterleitete
    • Das ist ein eindeutiger Route-Leak
  • Der Ursprung der geleakten Pfade war AS21980 (Dayco Telecom), ein Kundennetzwerk von AS8048
    • Die Beziehung zwischen beiden AS wird in Daten von Cloudflare Radar und bgp.tools als Provider-Kunde-Beziehung bestätigt
  • Im Pfad war AS8048 mehrfach prepended
    • Prepending ist eine Technik, um einen Pfad weniger attraktiv zu machen und Traffic auf andere Wege zu lenken
    • Daher ist die Wahrscheinlichkeit eines absichtlichen MITM-Angriffs (Man-in-the-Middle) gering
  • Die Leaks traten am 2. Januar 2026 zwischen 15:30 und 17:45 UTC mehrfach auf und sind wahrscheinlich auf Fehler in Netzwerkrichtlinien oder Konvergenzprobleme zurückzuführen
  • Laut Cloudflare-Radar-Aufzeichnungen haben sich seit Dezember 11 ähnliche Leaks wiederholt, was auf anhaltende Richtlinienmängel hindeutet

Technische Ursachen und Probleme bei Richtlinien

  • Es ist möglich, dass AS8048 die Routing-Export-Richtlinie gegenüber dem Provider AS52320 zu locker konfiguriert hatte
    • Falls statt Customer-BGP-Community-Tags nur IRR-basierte Prefix-Listen verwendet wurden, kann es zu einer fehlerhaften Weiterverbreitung von Pfaden kommen
  • Solche Richtlinienfehler lassen sich durch das Only-to-Customer-(OTC)-Attribut aus RFC9234 verhindern
    • OTC definiert BGP-Rollen (Kunde, Provider, Peer) explizit und blockiert falsche Pfadverbreitung

Die Rolle von RPKI und ASPA

  • Sparkle (AS6762) hat RPKI Route Origin Validation (ROV) nicht vollständig implementiert,
    • doch da es sich hier um eine Pfad-Anomalie handelt, kann ROV den Vorfall nicht verhindern
  • ASPA (Autonomous System Provider Authorization) bietet pfadbasierte Validierung
    • Jedes AS gibt eine Liste autorisierter Upstream-Provider an, sodass anormale Pfade automatisch blockiert werden können
    • Beispiel: Wenn AS6762 erklärt, dass es keine Upstream-Provider hat, können andere Netzwerke falsche Pfade, die AS6762 enthalten, ablehnen
  • ASPA arbeitet auf Basis von RPKI und hat direkte Wirkung bei der Verhinderung von Route-Leaks

Vorschläge für ein sicheres BGP

  • BGP ist seinem Wesen nach ein vertrauensbasiertes Protokoll, daher sind Leaks durch Richtlinienfehler oder Fehlkonfigurationen häufig
  • Wenn Technologien wie ASPA, RFC9234 und Peerlock/Peerlock-lite gemeinsam eingesetzt werden,
    • wird die Pfadvalidierung gestärkt
    • die Verbreitung falscher Pfade blockiert
    • und die Netzwerkstabilität verbessert
  • RIPE unterstützt bereits die Erstellung von ASPA-Objekten,
    • und Betreiber sollten von Netzwerkgeräteherstellern die Implementierung von RFC9234 einfordern
  • Die Einführung solcher kooperativen Standards ist ein zentraler Hebel zur Verhinderung von BGP-Vorfällen wie im Fall Venezuela

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-09
Hacker-News-Kommentare

  • Ich fand den Verlauf der Kommentare hier etwas überraschend. Alle reden über Angst vor US-Unternehmen, aber das scheint mit dem Inhalt des Artikels nicht viel zu tun zu haben.
    Der Cloudflare-Beitrag erklärt einfach nur, wie BGP funktioniert, und weist darauf hin, dass es bei dem venezolanischen ISP häufig zu Route Leaks gekommen ist.
    Natürlich könnte Cloudflare falschliegen oder etwas verbergen, aber nirgends im Text steht, dass sie selbst direkt eingegriffen hätten. Ich frage mich, worauf sich diese Gewissheit bei allen stützt.

    • Ich denke nicht, dass es in diesem Artikel Belege gibt, vor denen man sich fürchten müsste.
      Allerdings sollte man angesichts von Stuxnet oder Dual EC DRBG die Fähigkeit von Regierungen, 0-Days zu nutzen, nicht unterschätzen.
      Ein Freund von mir arbeitete bei einem FANG-Unternehmen und meinte, er habe gesehen, wie der Regierung direkt Datenströme bereitgestellt wurden. Backdoors bei ISPs sind ebenfalls Realität (Room 641A).
      Falls Cloudflare auf Grundlage eines richterlichen Beschlusses kooperiert hätte, hätten sie dann rechtlich überhaupt einen Text schreiben dürfen, der das abstreitet?
      Daher halte ich diese grundsätzliche Skepsis der Leute für nachvollziehbar. Cloudflares Schlussfolgerung „Das ist ein altes Problem und nichts Besonderes“ wirkt etwas schwach.
    • Ich habe dieselbe Frage. Ich verstehe nicht, wie man von diesem Artikel auf eine Beteiligung der US-Regierung kommt.
      Mich würde auch interessieren, ob es an der BGP-Struktur irgendetwas gibt, das den USA solche Aktionen leichter machen würde als anderen Ländern.
    • Vermutlich haben die meisten nur die Überschrift gelesen. Dazu kommt der historische Hintergrund, dass die USA solche Dinge in der Vergangenheit tatsächlich getan haben.
      Die Stimmung gegenüber der US-Regierung ist derzeit ohnehin so zynisch, dass schon kleine Vorfälle Misstrauen auslösen.
      Oder es sind einfach Social-Media-Accounts aus Russland oder China — wer weiß das schon.
    • Vor ein paar Tagen gab es schon einen ähnlichen Beitrag — den loworbitsecurity-Artikel, der Gerüchte über eine Invasion Venezuelas mit den BGP-Anomalien verknüpfte.
      Außerdem erwähnte ein CNN-Artikel, dass Trump sogar militärische Maßnahmen gegen Verbündete in Betracht ziehe.
      Bei der aktuellen Regierung hätte man so einen Angriff vermutlich eher öffentlich stolz verkündet. Deshalb glaube ich zunächst an die Erklärung „schlichter Konfigurationsfehler“.
      Trotzdem ist es nur natürlich, dass das Misstrauen wächst, wenn die USA in den Nachrichten zuletzt immer nur mit Drohungen, Rückzügen und Sanktionen auftauchen.

  • Ich war zwar müde, fand den Artikel aber interessant. Die Analyse des AS-Path Prepending stützt die „Unfallthese“ ziemlich gut.
    Wenn ein Staat absichtlich Traffic abfangen wollte, gäbe es keinen Grund, die Route absichtlich länger zu machen.
    Wahrscheinlich war es einfach ein Fehler in der Routing-Konfiguration. BGP ist immer noch ein vertrauensbasiertes System, deshalb kann schon ein kleiner Tippfehler globale Auswirkungen haben.
    Fehlende Export-Filter sind als Erklärung plausibler als böse Absicht.

    • Es gibt allerdings auch das Gegenargument: „Ein staatlicher Akteur könnte die Route absichtlich falsch gepolstert haben.“
      Tatsächlich gibt es auch nichtstaatliche Akteure, die versuchen, Werbetraffic zu manipulieren.
      Aus Sicht eines Netzwerkbetreibers sind solche Fehler trotzdem häufig, und automatisierte Skripte zur Traffic-Steuerung können das Problem noch verschärfen.
      Am Ende ist die strukturelle Verwundbarkeit von BGP das eigentliche Problem. Sicherheit und BGP passen weiterhin nicht gut zusammen.

  • Eines der Snowden-Dokumente, NSA Network Shaping 101, ist dazu lesenswert.
    Das Dokument stammt aus dem Jahr 2007 und erklärt ASIN sowie Traffic-Steuerung auf Layer 3.

    • Allerdings scheint dieses „layer 3 shaping“ in dem Dokument mit der BGP-Anomalie kaum etwas zu tun zu haben.
      Es erklärt eher nur die Struktur, bei der Traffic zu einer bestimmten IP über genau diesen Link läuft.
    • Lustig ist, dass selbst die NSA das Konzept von ASN falsch verwendet. Das ist ungefähr so, als würde man sagen: „Mein Nachbar wohnt in der Zeichenkette ‚123 Main Street‘.“

  • Nach dem Lesen des Artikels lief mir erneut ein Schauer über den Rücken, wie eng US-Unternehmen und Regierung verflochten sind.
    Das wusste ich zwar schon vorher, aber diesmal fühlt es sich an, als wäre das Vertrauen endgültig zerstört. Das wirkt wie ein Wendepunkt.

    • Ich erinnere mich an einen Freund, der einmal über legale Überwachung sprach, und daran, wie komplett ernst sein Gesicht dabei wurde.
      Solche Überwachungsinfrastrukturen existieren schon seit langer Zeit, und auch Japan hat 2003 Traffic in Echtzeit überwacht.
      Heute lässt sich DPI-Technologie viel zu leicht umsetzen.
    • Dieser Kreislauf aus Misstrauen scheint sich alle zehn Jahre zu wiederholen.
      Neue Leute in der Branche starten naiv, merken dann irgendwann, wie eng Staat und Unternehmen zusammenarbeiten, und verlieren das Vertrauen.
      Mit der Zeit kommt dann wieder eine neue Generation, die denselben Prozess erneut durchläuft.
    • Zu behaupten, Cloudflare habe eine Operation der US-Regierung vertuschen wollen, scheint mir eine überzogene Interpretation zu sein.
      Die Kernaussage des Artikels ist Hanlon’s razor — also lieber zuerst von einem Fehler als von böser Absicht ausgehen.
      Natürlich müsste Cloudflare kritisiert werden, wenn sie die Tatsachen verzerrt hätten, aber dafür gibt es bislang keine Belege.
    • Dass Unternehmen mit Regierungen verflochten sind, gilt in jedem Land. Das ist nichts Neues.

  • Wenn man an die veraltete Infrastruktur Venezuelas denkt, fragt man sich, ob dafür überhaupt ein ausgefeilter Cyberangriff nötig gewesen wäre.
    Die Realität ist eher, dass korrupte Auftragnehmer schlechte Systeme geliefert haben.

    • In solchen Ländern kann man für ein paar zehntausend Dollar wahrscheinlich jemanden bezahlen, der direkt am Switch herumstellt.
      Die Korruptionsstrukturen sind ein viel größeres Problem als Cyberangriffe.
    • Ich habe selbst CANTV genutzt, und die Installation einer Telefonleitung hat neuneinhalb Jahre gedauert.
      Am Ende habe ich einem Techniker auf der Straße Geld gegeben, damit es erledigt wird, und die Nummer entpuppte sich als Nummer eines Taxiunternehmens.
      In so einem Umfeld wirkt die Diskussion über einen BGP-Angriff etwas absurd.
    • Der tatsächliche Angriff auf das Stromnetz, der stattgefunden hat, hatte nichts mit BGP zu tun. Das sieht eher nach einem simplen Netzwerkfehler aus.

  • Dieser Artikel war eine gute BGP-Auffrischung.
    Als ich früher als Netzwerkingenieur gearbeitet habe, habe ich viel BGP-Community-Magie genutzt, und
    wenn BGP nur drei Arten ausdrücken könnte — Provider, Kunde und Peer — wäre vieles vielleicht deutlich einfacher.

    • Stimmt, das wäre viel einfacher, aber Einfachheit ist nicht immer besser.
      Das ist so, als würde man bei Google Maps Verkehrsdaten und Ampeln entfernen: Die Berechnung wäre leichter, aber das Ergebnis wäre miserabel.

  • Google Maps hat mich einmal von der Autobahn über den Parkplatz eines Walmart zu einer anderen Autobahn geführt.
    Damals dachte ich an einen simplen Algorithmusfehler, aber wenn die Route stattdessen durch den Drive-through von McDonald’s geführt hätte, hätte ich eine Verschwörung vermutet.
    Auch in diesem Fall ist die Erklärung als simpler Fehler überzeugender.

    • Dass BGP-Route-Leaks nicht noch häufiger passieren, liegt an den Filtern anderer ISPs. Fehler passieren überraschend leicht.

  • Dass die zentrale Infrastruktur des Internets stark von US-Unternehmen geprägt ist, wirkt etwas beunruhigend.
    Andere Länder sollten inzwischen ebenfalls unabhängige Strukturen aufbauen.

    • Aber das Internet selbst ist nun einmal ein von US-Militär, Universitäten und Unternehmen geschaffenes System, also ist das nicht wirklich überraschend.
      Wer genau sollte es stattdessen verwalten?
    • Auch Europa hätte ohne Weiteres ein Unternehmen wie Cloudflare hervorbringen können, aber Abwanderung von Talenten und fehlende Investitionen waren das Problem.
    • Das Internet ist im Kern dezentralisiert. Einen zentralen BGP-Router gibt es nicht.

  • Ich beobachte BGP-Zwischenfälle schon lange und habe immer das Gefühl, dass es schwer ist, beabsichtigte Änderungen, Fehler und strukturelle Ausfälle voneinander zu unterscheiden.
    Deshalb stelle ich zuerst drei Fragen: Wurde der Wirkungsbereich schrittweise größer, haben sich die Pfade symmetrisch verändert, und lief die Wiederherstellung sauber ab?
    Danach schaue ich mir zuerst Änderungen beim AS-Path Prepending an und vergleiche die Sichtbarkeit nach Regionen.
    Zum Schluss verfolge ich die Frage: „Wer profitiert davon?“ Mich würde interessieren, mit welchen Indikatoren andere solche Probleme erkennen.

  • Die globale Abdeckung von Cloudflare ist wirklich beeindruckend.

    • Ich halte genau das allerdings für eine gefährliche Konzentration auf globaler Ebene. Nicht-US-Unternehmen sollten unabhängiger werden.
    • In einem Anycast-Netzwerk kann man BGP von vielen Standorten aus beobachten, das ist also keine Fähigkeit, die nur Cloudflare hätte.
      Allerdings sind sie eine stark engineering-getriebene Organisation und veröffentlichen solche Analysen deshalb besonders gut.
    • Eigentlich kann jeder mit RIPE RIS eine ähnliche Analyse durchführen.
    • Cloudflare hat viele Ressourcen und ist ehrlich gesagt ein beeindruckendes Unternehmen.