MPLS-Sicherheit - Teil 1
MPLS-Technik und Angriffsszenarien
MPLS wird von fast allen Carriern in ihren Backbone-Netzen eingesetzt und findet zunehmend auch Verwendung in Campus-LANs. Der zweiteilige Artikel beleuchtet Sicherheitsaspekte beim Einsatz von MPLS. Ein Ausblick auf den Virtual-Private-LAN Service (VPLS) und seine Sicherheitsimplikationen ergänzt den Beitrag.
Multi-Protocol Label Switching (MPLS) ist eine in RFC 3031 und anderen Dokumenten spezifizierte
Technologie, deren Hauptzweck die Weiterleitung (das "Forwarding") von Paketen ist. Sie wurde
ursprünglich entwickelt, um ineffizientes IP-Routing zu vermeiden, bei dem jedes Paket auf Basis
seiner Zieladresse anhand umfangreicher Routing-Tabellen geroutet wird. Bei MPLS findet die
Weiterleitung mittels so genannter "Labels" statt. Hierzu werden den Paket-Headern 32 Bit lange
Einheiten hinzugefügt. Diese 32 Bits bestehen im Wesentlichen aus einem 20 Bit langen "Tag", dem
eigentlichen Label, das der Weiterleitungsentscheidung zugrunde liegt, und drei weiteren Feldern,
darunter ein "Time-to-live"-Feld (TTL).
Erreicht ein IP-Paket einen MPLS-basierten Backbone, wird es zunächst klassifiziert – etwa
anhand seiner Zieladresse oder aber auch anhand der Zugehörigkeit zu einem bestimmten Kunden-VPN –
und dann mit einem oder mehreren Labels versehen und weitergeleitet. Der jeweils nächste Hop
tauscht das oberste Label gegen ein neues aus und gibt das Paket an seinen zuständigen Nachbarn
weiter. Die Labels und ihre Bedeutung haben dabei grundsätzlich zwei jeweils benachbarte Router
mithilfe eines Protokolls ausgehandelt, wobei meist das "Label Distribution Protocol" (LDP) zum
Einsatz kommt. Durch die Abstimmung zwischen benachbarten Devices wird ein zentraler Mechanismus
zur Label-Verwaltung vermieden.
Verlässt das Paket schliesslich den Backbone, wird es gemäss traditioneller Routing-Mechanismen
weitergeleitet.
Bei der Sicherheitsdiskussion einer Forwarding/Routing-Technik könnte man zunächst an Spoofing-
oder Injektions-Attacken denken, also an die Veränderung oder Einspeisung von
Routing-Informationen. Diese Klasse von Angriffen würde aber in dem oben skizzierten elementaren
MPLS-Netz, in dem Labels anhand von Zieladressen der Pakete zugewiesen werden, wenig Sinn haben.
Schließlich haben Labels hier immer nur eine lokale Bedeutung zwischen zwei benachbarten Routern.
Ein Angreifer könnte also nie den Weg eines Pakets nach dem nächsten Hop beeinflussen.
Neben der Basisfunktion zur effizienten Paketbehandlung können die Labels jedoch auch noch
andere Aufgaben übernehmen. In MPLS-basierten Netzen gibt es eine Reihe weiterer Funktionen, die
oft "MPLS Services" genannt werden. Dazu zählen zum Beispiel:
MPLS-basierte VPNs (manchmal auch "Layer-3-VPNs" genannt),
MPLS-basierte "Layer-2-VPNs", in denen ganze L2-Frames transportiert werden
(dazu später mehr),
MPLS Traffic Engineering zur optimalen Nutzung vorhandener Bandbreite und
Bereitstellung von Backup-Pfaden und
Generalized MPLS (GMPLS) zur Signalisierung in optischen Netzen.
Einige dieser Techniken – etwa das "Traffic Engineering" – sind nur für Backbone-Betreiber oder
Carrier relevant. Andere, insbesondere die VPN-Techniken, spielen für viele Organisationen eine
große Rolle: Sei es, dass sie als Kunden eines Carriers einen solchen Dienst einkaufen, oder auch
zum Einsatz im eigenen Campus-LAN, beispielsweise zur Separierung des Verkehrs verschiedener
Konzerntöchter. Diese Techniken sollen daher in den folgenden Abschnitten vorgestellt und
diskutiert werden.
Grundlagen zu MPLS-VPNs
Bei MPLS-VPNs handelt es sich um eine eigenständige, Label-basierte Technik mit einer eigenen
Terminologie, die hauptsächlich in den RFCs 2547 und 2917 beschrieben ist. Die Technik wird oft mit
Frame Relay oder ATM verglichen, da sie auf einer gemeinsamen Netzwerkinfrastruktur separierte
logische Pfade etabliert, über die dann der Verkehr einzelner (Kunden-)VPNs transportiert wird. Die
Technologie ist hinsichtlich möglicher VPN-Topologien hochgradig flexibel, da sich durch die
Verwendung von so genannten "route targets" regeln lässt, welche Netze in welchen Routing-Tabellen
bekannt gemacht werden.
Man unterscheidet hier zunächst zwischen dem Provider-Netz ("P-Network"), in dem MPLS eingesetzt
wird, und dem Kunden-Netz ("Customer Network/C Network"), das einen entsprechenden Dienst in
Anspruch nimmt, aber beispielsweise mit der Vergabe von Labels oder der zugehörigen Weiterleitung
nichts zu tun hat und davon im Grunde auch nichts mitbekommt. Die Übergabepunkte zwischen Kunde und
Provider heißen Provider-seitig PE-Devices ("Provider Edge") und kundenseitig entsprechend
CE-Devices ("Customer Edge").
Ein PE bedient üblicherweise mehrere Kunden und führt zu diesem Zweck neben seiner normalen
Routing-Tabelle, die hier meist auch "globale" Routing-Tabelle genannt wird, noch weitere, jeweils
VPN-spezifische Routing-Tabellen, die so genannten "Virtual Routing and Forwarding Instances"
(VRFs). Es ist durch diese Virtualisierung auch problemlos möglich, dass verschiedene Kunden
denselben IP-Adressraum verwenden oder dass die Kunden unterschiedliche Routing-Protokolle
nutzen.
Die PEs, an die die Kunden angebunden sind, tauschen die Information, welches Netz ("Prefix")
von welchem Kunden sie bedienen, mithilfe des "Multiprotocol BGP" (MP-BGP) aus, einer erweiterten
Variante des Border Gateway Protocols. Die jeweils übertragene Information lautet ausformuliert
etwa: "Über mich (PE) kann mit folgendem Label dieses oder jenes Prefix [Netz] von diesem oder
jenem Kunden erreicht werden".
Die VPN-Funktionalität lässt sich wie folgt zusammenfassen:
Jedem Netz eines mithilfe des so genannten "Route Distiguishers" individuell
konfigurierten Kunden-VPNs wird von einem PE-Router ein Label zugewiesen,
Das Triple, bestehend aus dem "Route Distinguisher", Netz-Prefix und
zugehörigem Label, wird vom PE über MP-BGP propagiert.
Somit weiß jeder PE, welches Netz von welchem Kunden über welchen "PE-Kollegen" erreicht werden
kann und welches Label dafür verwendet werden soll – vorausgesetzt, es findet keine Filterung der
Routing-Informationen mittels eines Route Targets statt.
Erhält nun ein PE vom Kunden-Device ein Paket, wird es mit (mindestens) zwei Labels versehen und
weitergeleitet: Ein Label identifiziert, zu welchem anderen PE das Paket weitergeleitet werden
soll, und ein weiteres verrät, zu welchem Kunden(-netz) das Paket gehört. Die gesamte
VPN-Funktionalität wird also mithilfe der Labels realisiert.
Zur Bewertung der Sicherheit dieser VPN-Technologie wird häufig eine ältere Miercom-Studie
zitiert, deren Aussage im Wesentlichen ist, dass die Technologie als sicher betrachtet werden kann
und ein Angreifer keinen Zugang zu den Kunden-VPNs oder zum Backbone erhalten kann. Selbst wenn man
der Argumentation dieser Studie folgt – Miercom-Studien werden manchmal allzu großer Nähe zum
Auftraggeber Cisco vorgeworfen – sollten einige Besonderheiten beachtet werden:
Der Verkehr wird bei MPLS-VPNs nicht verschlüsselt. Sollte das
Leserverständnis des Begriffs "VPN" stets die Vorstellung einer Verschlüsselung implizieren, muss
diese Grundannahme hier korrigiert werden. VPN heißt in unserem Zusammenhang zunächst nichts
anderes als "Verkehrsseparierung".
Der PE-Router wird üblicherweise zwischen verschiedenen Kunden und
gegebenenfalls komplett anderen Aufgaben "geteilt". Angriffe – zum Beispiel DoS-Attacken – gegen
den PE-Router aus einem Kundennetz heraus oder – entsprechende Erreichbarkeit vorausgesetzt – aus
dem Internet können deshalb Seiteneffekte auf die Sicherheit oder Erreichbarkeit weiterer Kunden
haben. Die Autoren dieses Beitrags haben im Zuge einer Carrier-Evaluierung erlebt, dass eine von
Vertriebsseite zugesagte technische Prüfung (Scan) von PEs durch das technische Personal abgelehnt
wurde, "um die Verfügbarkeit anderer Kunden nicht zu gefährden".
Beide Aspekte und ihre jeweiligen Konsequenzen sind vielen Netzverantwortlichen nicht
hinreichend bekannt. In einigen Organisationen führt dies etwa dazu, dass beispielsweise
Revisionsanforderungen unterlaufen werden.
Angriffsmethoden
In den folgenden Abschnitten geht es nun um die Angriffsmethoden gegen MPLS-VPNs. Ziele eines
Angreifers sind bei VPNs in erster Linie das Mitlesen des Verkehrs oder der unautorisierte Zugang.
DoS-Angriffe sollen hier nicht betrachtet werden. Die Angriffe können in Attacken "von außen" (aus
einem Kundennetz oder vom Internet her) oder "von innen" (aus dem MPLS-Backbone heraus) unterteilt
werden.
Injektion (Einbringen) bereits gelabelten Traffics aus einem Kundennetz
Bei diesem Szenario könnte ein Angreifer, der sich in einem Kundennetz befindet, versuchen, in
ein anderes VPN einzudringen, indem er Pakete an "seinen" PE übergibt, die bereits ein Label haben.
Dabei muss es sich um ein Label handeln, das für die Weiterleitung in das andere VPN sorgt.
RFC 2547 spezifiziert jedoch: "Labeled packets are not accepted by backbone routers from
untrusted or unreliable sources?. Gelabelte Pakete von PEs sollen also nicht verarbeitet werden,
wenn sie aus einer nicht vertrauenswürdigen Quelle stammen. Ein Kundennetz ist aus Provider-Sicht
stets "untrusted"; solche Pakete sollten also vom PE-Router verworfen werden.
Die Autoren haben dies in einer Cisco-basierten Umgebung gegen verschiedene Devices getestet,
und die gelabelten Pakete wurden tatsächlich kommentarlos ohne jegliche Debug- oder Log-Meldung
verworfen.
Injektion (Einbringen) bereits gelabelten Traffics aus dem Internet
Bei dieser Attacke könnte ein Angreifer versuchen, vom Internet her an einen PE-Router bereits
gelabelte Pakete zu schicken, um deren Transport in ein Kunden-VPN zu erzwingen. Der Angreifer
müsste dazu die jeweils verwendeten Labels und IP-Adressen kennen oder raten, was meist mit
überschaubarem Aufwand möglich ist. Die IP-Adresse 10.1.1.1 etwa wird etwa in den meisten Netzen
anzutreffen sein, und je nach Herstellerimplementierung sind die Labels vergleichsweise leicht
vorhersehbar.
Inzwischen ist sogar ein Tool verfügbar, das dem "Label Bruteforcing" dient, also der
automatisierten Ermittlung von verwendeten Labels (erhältlich unter [1]). Das Tool selbst ist nur
aus dem Backbone heraus einsetzbar, also nicht aus dem Internet, und kann daher für gerade
beschriebenen Angriff nicht verwendet werden. Dennoch markiert die Verfügbarkeit des Tools einen
wichtigen Meilenstein: Angriffe gegen MPLS haben die Hacker-Szene und Tool-Autoren erreicht. In
naher Zukunft werden sicher weitere Werkzeuge zur automatisierten Durchführung mancher der hier
beschriebenen Angriffsmethoden verfügbar sein.
Für den Erfolg einer Attacke müssten die gelabelten Pakete mitsamt Label außerdem bis zum
attackierten Punkt transportiert werden (unwahrscheinlich), und der betroffene PE-Router müsste aus
dem Internet erreichbar sein (was vom konkreten Netzwerkdesign des Providers abhängig ist). Im Zuge
des Trends, immer mehr Funktionen auf immer weniger Multi-Funktions-Devices zu konzentrieren,
können solche Bedingungen jedoch keinesfalls ausgeschlossen werden.
Allerdings schreibt das RFC 2547 mmerhin vor, dass gelabelte Pakete aus nicht vertrauenswürdigen
Quellen, wozu das Internet sicher zählt, verworfen werden sollen. Dass dies funktioniert, konnten
wir in verschiedenen Tests bestätigen. Die Verfasser des Ciscopress-Buchs "MPLS VPN Security" [2]
halten jedoch fest, dass dieser Angriff gegen Router mit bestimmten (älteren) IOS-Versionen möglich
sein soll.
Im Gegensatz zu den beiden zuletzt beschriebenen Angriffen setzen die folgenden Attacken eine
Position des Angreifers innerhalb des Backbones voraus. Diese Voraussetzung soll zunächst kurz
diskutiert werden.
Angriffe aus einer Position innerhalb des Backbones
Kontrolliert ein Angreifer einen Punkt des MPLS-Backbones, sind eine ganze Reihe weiterer
Attacken denkbar. Natürlich kann zunächst der gesamte diesen Punkt passierende Verkehr aller
MPLS-VPNs mitgelesen werden, sofern er nicht zusätzlich verschlüsselt ist. Eine solche
Verschlüsselung ist meist problemlos machbar, läuft aber häufig den angestrebten Kosten- oder
Administrationsvorteilen eines MPLS-VPN gegenüber IPsec-basierten VPN-Strukturen zuwider – oft
sollen MPLS-VPNs bekanntlich IPsec-VPNs ersetzen.
Innerhalb der Diskussion über die Sicherheit von MPLS-VPNs wird der (Provider-betriebene)
Backbone üblicherweise als vertrauenswürdig und sicher vorausgesetzt. Die Autoren dieses Artikels
tun sich als erfahrene Sicherheitspraktiker zunächst einmal schwer damit, bestimmte Dinge als "
vertrauenswürdig und sicher" vorauszusetzen.
Bei den nun folgenden Szenarien kann es zu Eingriffen in MPLS-VPNs im Backbone kommen.
Kompromittierte Provider-Devices
Es sollte immer bedacht werden, dass durchaus auch Provider-Devices gehackt werden können; eine
2003 auf einem Meeting der North American Network Operators? Group (NANOG) veröffentlichte
Statistik [3] etwa spricht von über 5000 solcher Router innerhalb von ISP-Netzen.
Vom Kunden selbst betriebene PE- Devices Betreibt ein Kunde ein PE-Device selbst, wird damit das
gesamte Vertrauensmodell des Backbone unterlaufen. Einem solchen könnte es gelingen, auf VPNs
anderer Kunden zuzugreifen. Den Autoren sind durchaus Fälle bekannt, in denen finanzkräftigen
Kunden der Einsatz eigener PEs gestattet wurde.
Gehackte Managementstationen
Surft ein Provider-Mitarbeiter mit demselben Rechner im Internet, mit dem er auch auf das meist
GUI-basierte Verwaltungs-Tool zur VPN-Bereitstellung zugreift, kann ein Angreifer potenziell
Zugriff auf das Managementsystem erhalten – mit allen sich daraus ergebenden Folgen für die
Sicherheit der verwalteten VPNs.
Angriffe an Übergabepunkten zwischen Providern
Um weltweit MPLS-VPNs anbieten zu können, haben viele Carrier untereinander Verträge
abgeschlossen, mit denen sie über Provider-Grenzen hinweg MPLS-VPNs realisieren und dabei gelabelte
Pakete austauschen. RFC 2547 beschreibt hier verschiedene Modelle, von denen mindestens eines –
pikanterweise das am besten skalierbare – inhärent unsicher sein kann. Weiterhin werden
Querverbindungen zwischen Carriern oft in Ethernet-basierten Internet Exchange Points (IXPs)
realisiert, was möglicherweise Angriffe auf Layer 2 gegen die Datenschnittstelle ermöglicht.
Standort des PE in problematischen Ländern
Aus Sicht der Autoren gibt es durchaus Länder, in denen von der Vertrauenswürdigkeit und
Integrität von Devices in Provider-Netzen nicht ausgegangen werden sollte. Besonders problematisch
ist es, wenn in solchen Ländern zusätzlich eine wenig strenge Haltung zu geistigem Eigentum
besteht.
Fehlkonfigurierte Provider-Devices
Auch Provider-Devices werden von meist chronisch überlasteten Menschen bedient, denen Fehler
unterlaufen können. Insgesamt gibt es somit eine Reihe von Szenarien, in denen die vorausgesetzte
Integrität des MPLS-Backbone ausgehebelt werden kann.
Werden MPLS-VPNs innerhalb von Unternehmensnetzen eingesetzt, wie es in der Praxis zunehmend der
Fall ist, gibt es – zumindest was das betreibenden Personal angeht – ohnehin meist keinen
Unterschied mehr zwischen "Kunden-Devices" und "per se vertrauenswürdigen Provider-Geräten".
Hinsichtlich des an dieser Stelle oft vorgebrachten Einwands, dass auch Frame-Relay- oder
ATM-Strukturen "von innen" attackierbar waren oder sind, möchten die Autoren auf zwei wichtige
Unterschiede hinweisen:
Sowohl Frame Relay als auch ATM setzten üblicherweise dedizierte Devices
(Switches) voraus, die oft auch nicht aus dem Internet erreichbar waren. MPLS-VPNs werden –
Stichwort Konsolidierung und Kostenoptimierung – oft auf den vorhandenen Plattformen realisiert,
die darüber hinaus auch noch weitere Funktionen innerhalb des ISP-Netzes übernehmen (können) und
sogar potenziell aus dem Internet erreichbar sind.
Die Diversität verschiedener Protokolle auf verschiedenen Layern (Layer 2:
ATM/FR versus. Layer 3: IP) erhöhte zwar die Komplexität und damit den Betriebsaufwand, erschwerte
aber auch Angriffe. In der rein IP-basierten MPLS-Welt sind Angriffs-Tools tendenziell leichter
verfügbar. So unterstützt die meist zur Paketgenerierung verwendete und vielen Sicherheits-Tools
zugrundeliegende Libnet-Bibliothek mittlerweile auch MPLS. Das oben genannte Angriffs-Tool ist auf
Libnet-Basis entwickelt worden.
Nach diesem Exkurs sollen im nächsten Teil des Beitrags (LANline 06/06) Angriffe aus dem
MPLS-Core heraus beschrieben werden.
Lesen Sie mehr zum Thema
