Der Wilde Westen im Internet: BGP-Communities

Internet-Router sind dafür verantwortlich, ankommende Datenpakete in Richtung ihres Ziels weiterzuleiten. Für die dazu notwendigen Entscheidungen müssen sie wissen, wer mit wem verbunden ist. Das bedeutet, sie halten eine stetig aktualisierte Karte des Netzes vor. Diese Karte kann nicht jeden einzelnen Host erfassen und beschränkt sich auf ganze Adressbereiche, sogenannte Autonomous Systems (AS). Ein Vergleich: Das Reisebüro, das für einen Kunden eine Fahrt von München zur Familie Meier, Hauptstraße 17, in Bielefeld plant, interessiert sich nur für die Möglichkeiten, wie man von München nach Bielefeld kommt. Wie man in Bielefeld zur Hauptstraße 17 gelangt, weiß dann der dortige Taxifahrer.

Nun kann es aber sein, dass Familie Meier an dem Tag keinen Besuch haben möchte. Alle Reisebüros darüber zu informieren kommt offensichtlich nicht in Frage. Aber man könnte am Bielefelder Hauptbahnhof einen Rundruf veranlassen: "Bitte heute keine Besucher in die Hauptstraße 17".

Zugegeben, der Vergleich fängt hier heftig an zu hinken. Aber genau das ist es, was BGP-Communities machen: Sie geben Detailinformationen an den vorgelagerten Router, vielleicht auch an dessen Vorstationen, auf dem Datenreiseweg weiter, die zum Beispiel in der New Yorker Central Station niemanden interessieren. Die Alternative mit herkömmlichen (Routing-)Mitteln wäre, Bielefeld komplett aus allen Landkarten zu tilgen.

The Good

In letzter Zeit werden Communities zum Beispiel für das Advanced Blackholing bei Denial of Service (DoS)-Angriffen eingesetzt, ein Bereich, zu dem wir bereits mehrere Forschungsarbeiten [1, 3]. veröffentlichen konnten. Dabei versucht ein Angreifer große Datenmengen etwa an einen Webserver zu senden, der daraufhin seinen Dienst einstellen muss. Eine für den Betreiber des Servers nicht nur ärgerliche, sondern unter Umständen sogar existenzbedrohende Situation.

Mit klassischen Routingmethoden könnte man nur das gesamte Rechenzentrum, in dem der Server steht, aus den Routingkarten verschwinden lassen – offensichtlich keine optimale Lösung. Mittels Advanced BGP Blackholing hingegen kann das Rechenzentrum eine BGP-Community an seine Upstream-Provider schicken, zum Beispiel "666:50:123":

• "666" bitte ein Blackhole installieren, also den nachfolgend beschriebenen Traffic nicht weiterleiten
• "50" ist die AS-Nummer des Empfängers – wahrscheinlich immer noch das gesamte Rechenzentrum
• "123" ist die Portnummer des "bösen Traffics", in diesem Fall das Network Time Protokoll, was immer wieder für sogenannte Amplifikationsattacken benutzt wird.

Gibt der Upstream-Provider diese Community an alle seine Verbindungen, von denen er Datenpakete zu dieser Adresse erhalten kann, weiter, wäre die Folge: Der unerwünschte Traffic gelangt nicht einmal in die Nähe des Opfers, aber alle anderen Verbindungen bleiben unbeeinträchtigt.

Ein weiterer Anwendungsfall sind sogenannte Location-Informationen. Ein Router kann mit Hilfe einer Community mitteilen, dass er zum Beispiel in New York  steht. Das könnte ein Router in Europa benutzen um zu entscheiden: "Nicht-europäisches Ausland: Da dürfen diese Daten wegen der DSGVO nicht hin."

The Bad

Eines der Kernprobleme wirksamer Communities ist, dass ihr Absender nicht verifiziert werden kann. Betrachten wir folgende Situation: Ein Angreifer befindet sich im Autonomous Systems (AS) A. Sein Opfer im AS C. A und C kommunizieren nicht direkt, sondern über das AS B, ersatzweise auch über die AS D, E und Z. Wenn es nun dem Angreifer gelingt, eine Blackhole-Community (siehe "The Good") upstream zu verschicken, in der um das Blockieren allen Traffics an sein Opfer (im AS C) gebeten wird, dann werden die Router im AS B (sofern sie überhaupt Communities beachten, siehe "The Ugly") das AS C sozusagen von der Außenwelt abschneiden. Wird die Community von B auch an D, E und Z oder vielleicht gar weltweit weitergeleitet, kommt beim AS C, also dem Opfer, kaum noch etwas an: Der Angreifer muss nur ein kleines Routingpaket schicken, um sein Opfer fast vollständig zu isolieren.

Natürlich wird so etwas auffallen –  irgendwann. Dann muss jemand manuell eingreifen. Und vielleicht ist es möglich, dass das verursachende AS identifiziert wird, dass die Verantwortlichen dort den Übeltäter ausfindig machen, den der Betreiber von C dann gerichtlich zur Rechenschaft ziehen kann.

Vielleicht. Und damit kommen wir auch schon zu.

The Ugly

Communities können, wie beschrieben, ein machtvolles Werkzeug sein, um auf das Routingverhalten Einfluss zu nehmen. Allerdings haben sie – wenigstens derzeit noch – drei wesentliche Schwächen, die wir auch untersucht haben [3]:

• Jeder BGP-Router kann Communities verschicken. Es gibt keine Möglichkeit, die Authentizität des Absenders festzustellen. Kommt eine Community von jemandem, der dazu berechtigt ist, oder nicht? Das lässt sich nur im Nachhinein feststellen. Wie man eine solche Authentizitätsprüfung vornehmen könnte, wird Gegenstand weiterer Forschungen sein müssen.
• Damit zusammen hängt das Fehlen anerkannter und verbindlicher Policies. Bei unserem Beispiel in "The Bad" könnte ja B eine Community, die C beeinflusst, auch nur von C annehmen. Andererseits gibt es Anwendungsfälle, in denen eine "Fremdsteuerung" durchaus gewünscht ist. Überhaupt steht es jedem frei zu entscheiden, was er mit erhaltenen Communities macht.
• Die Bedeutung einer bestimmten Community ist nicht verbindlich definiert. 666 ist als BGB-Blackhole bekannt (siehe "The Good") – aber niemand könnte ein AS daran hindern, zum Beispiel allen Traffic von und zu Website(-AS) mit kriminellen Inhalten als 666 zu flaggen.

 Die letzten beiden Schwächen können vielleicht durch verbindliche Regeln in den entsprechenden Internet-Regelwerken (Request for Comment, RFC) aufgefangen werden. Für die Frage der Authentifizierung gibt es dagegen heute noch keine zufriedenstellenden Lösungsansätze.

Literaturhinweise