MPLS-Sicherheit - Teil 2
Angriffe aus dem MPLS-Core
MPLS wird von fast allen Carriern in ihren Backbone-Netzen eingesetzt und findet zunehmend Verwendung in Campus-LANs. Der zweiteilige Artikel beleuchtet Sicherheitsaspekte beim MPLS-Einsatz. Im zweiten Teil geht es um Attacken, die vom MPLS-Core ausgehen.
MPLS (Multi-Protocol Label Switching) ist samt seinen zugehörigen Diensten die vielleicht
wichtigste Backbone-Technologie der letzten und nächsten Jahre. Unter bestimmten Bedingungen können
mit MPLS allerdings erhebliche Sicherheitsprobleme auftreten. Vor dem Einsatz von MPLS-basierten
VPNs oder Backbone-Strukturen sollten daher in einem Unternehmen daher Risiko-Analysen insbesondere
hinsichtlich des dort transportierten Verkehrs stattfinden.
Modifikation des MP-BGP-Routings
Wenn ein Angreifer in den initialen Multiprotocol BGP basierten Informationsaustausch eingreifen
kann, könnte er einem VPN beispielsweise "weitere Standorte" hinzufügen, um von dort einen
unautorisierten Zugang zu Systemen herzustellen. Dies setzt neben einer Position im Backbone
zusätzlich entsprechende Tools zum punktgenauen Eingriff in den BGP-Verkehr voraus, was aktuell
noch einen durchaus hohen Aufwand auf Angreiferseite bedeutet.
Modifikation von Labels innerhalb des Backbones
Auch diese Angriffsart setzt eine Position des Angreifers innerhalb des Backbones voraus.
Gelingt es einem Angreifer, das Label eines Pakets zu verändern, kann das Paket in ein anderes VPN
umgeleitet werden. Es können auch beliebige Pakete in die existierenden VPNs eingebracht
werden.
Ein Angriff könnte exemplarisch wie in Bild 1 ablaufen: Hier ist zu sehen, dass in zwei
verschiedenen VPNs ("alpha" und "beta") derselbe IP-Adressraum verwendet wird. Die beim PE
(Provider-Edge-Device) für den Adressraum 172.31.1.0 jeweils eingehenden Pakete werden anhand ihrer
Labels unterschieden (17 für alpha und 20 für beta):
pe_7204vxr>sh ip vp vpnv4 vrf alpha labels
Network Next HopIn label/Out label
Route Distinguisher: 100:1 (alpha)
20.20.20.21/32 10.10.10.25 nolabel/17
20.20.20.40/32 172.31.2.2 19/nolabel
172.31.1.0/29 10.10.10.25 nolabel/18
172.31.2.0/29 0.0.0.0 17/aggregate(alpha)
192.168.5.0 10.10.10.25 nolabel/19
pe_7204vxr>sh ip bgp vpnv4 vrf beta labels
Network Next Hop In label/Out label
Route Distinguisher: 100:2 (beta)
172.31.1.0/29 10.10.10.25 nolabel/20
172.31.2.0/29 0.0.0.0 16/aggregate(beta)
Wenn nun der Angreifer Pakete mitlesen kann (im Bild 2 ein simpler Ping), kann er problemlos das
Label ändern, die Pakete erneut einspeisen und sie damit in ein VPN einbringen.
Das Paket wird nun an ein Device im "falschen VPN" weitergeleitet (Ausgabe der eingehenden
Ping-Pakete bei einem Device im VPN beta).
01:55:45.993783 IP 172.31.1.2 > 172.31.2.2: icmp 40: echo request seq 17408
01:55:45.993815 IP 172.31.2.2 > 172.31.1.2: icmp 40: echo reply seq 17408
01:55:46.995175 IP 172.31.1.2 > 172.31.2.2: icmp 40: echo request seq 17664
01:55:46.995211 IP 172.31.2.2 > 172.31.1.2: icmp 40: echo reply seq 17664
01:55:47.996723 IP 172.31.1.2 > 172.31.2.2: icmp 40: echo request seq 17920
01:55:47.996756 IP 172.31.2.2 > 172.31.1.2: icmp 40: echo reply seq 17920
01:59:14.136855 IP 172.31.1.2 > 172.31.2.2: icmp 80: echo request seq 5725
01:59:14.136906 IP 172.31.2.2 > 172.31.1.2: icmp 80: echo reply seq 5725
Der Angreifer kann somit problemlos VPN-Grenzen überspringen. Dies funktioniert zwar zunächst
nur unidirektional, und potentieller Antwortverkehr wird wieder im VPN alpha landen. Der Angreifer
kann jedoch den rückläufigen Verkehr ebenso modifizieren und damit eine vollwertige bidirektionale
Verbindung zwischen einem Server in VPN "beta" und einem von ihm kontrollierten Client im VPN alpha
etablieren.
Auch wenn uns für diesen Angriff (noch!) kein Tool bekannt ist, so kann auch die nur einseitige
Injektion von Paketen in ein VPN gravierende Folgen haben. Sie kann zum Beispiel für SNMP-basierte
Angriffe - darunter das Abziehen der Konfig-Datei von Devices - oder für UDP-basierte Würmer
(SQL-Slammer) völlig ausreichend sein.
Ein solcher Austausch des Labels würde überdies von IDS-Systemen im Netz des Kunden "beta" nicht
bemerkt, da die Pakete dort schon ohne Label eintreffen und die Veränderung des Labels (im
Gegensatz zur einfachen Änderung einer IP-Adresse) auch keine Checksummen-Fehler nach sich
zieht.
Layer-2-VPNs
Mit dem Terminus "Layer 2 VPN" wird im MPLS-Kontext üblicherweise die Technik "Any Transport
over MPLS" (AToM) umschrieben. Hier werden nicht IP-Pakete über den MPLS-Backbone geschickt,
sondern komplette Layer-2-Einheiten, also etwa ATM-Zellen, Frame Relay oder Ethernet-Frames.
Mithilfe von Labels werden dabei so genannte "pseudo wires" etabliert, die gewissermassen
logische Kanäle formen, über die dann die entsprechenden Frames transportiert werden. Für einen
Angreifer mit Backbone-Zugriff ergeben sich daher zunächst die gleichen Angriffsmöglichkeiten wie
bei den weiter vorn in diesem Beitrag beschriebenen Schwachstellen von Layer-3-VPNs.
Es existieren jedoch zwei verschiedene Spielarten der AToM-Technologie, die aus Design-Gründen
für eine weitere Sicherheitsdiskussion besonders interessant sind: Ethernet over MPLS (EoMPLS) und
der Virtual Private LAN Service (VPLS).
Bei EoMPLS konnektieren zwei Standorte Switches an den Backbone und übergeben entsprechend
Ethernet-Frames. Für beide Seiten sieht es dann so aus, als wäre ein direkter Layer2-Link ohne
zwischengeschaltete WAN-Infrastruktur zur jeweils anderen Seite vorhanden. Alle Systeme könnten zum
Beispiel gemeinsame VLANs oder IP-Subnetze nutzen.
EoMPLS ist eine Punkt-zu-Punkt-Verbindungstechnik. Die Anbindung eines weiteren Standorts würde
die Einrichtung weiterer Tunnel vom neuen Standort zu allen vorhandenen Sites nach sich ziehen.
Dies beschränkt die Skalierbarkeit von EoMPLS. Genau dieses Manko adressiert der "Virtual Private
LAN Service". Hier bilden beliebig viele Standorte ein gemeinsames "Ethernet"-Netz mit
Multipunktverbindungen. Beim Hinzufügen eines weiteren Standorts werden durch eine geeignete
Signalisierung, deren genaue Protokollbasis noch nicht final spezifiziert ist, die notwendigen "
pseudo-wires" automatisch erstellt. Alle Standorte scheinen aus ihrer Sicht direkt miteinander
verbunden zu sein, weshalb die zugrundeliegende MPLS/VPLS-Wolke oft auch als ein "großer virtueller
Switch" dargestellt wird. Die Autoren betrachten die MPLS/VPLS-Wolke hingegen lieber als "großen
virtuellen Trunk" (in der Cisco-Bedeutung des Worts), da die VPLS-Devices im allgemeinen nicht an
Infrastruktur-Protokollen wie STP, DTP oder VTP teilnehmen, sondern sich völlig transparent
verhalten. Die CE-Devices sind bei EoMPLS oder VPLS meist Switches.
Wenn sich die Wolke aber tatsächlich völlig transparent verhält, was etwa auch der Arbeitsweise
der Juniper VPLS-Implementierung entspricht, können interessante Effekte mit hoher Auswirkung auf
die Netzwerk-Sicherheit auftreten.
Spanning Tree
Da verschiedene Standorte jetzt ein gemeinsames (Ethernet-)Netz bilden, wird auch gegebenenfalls
pro VLAN insgesamt nur eine STP-Root (in genau einer Site) gewählt. Dies hat bei einer (etwa aus
Gründen verbesserter Verfügbarkeit) redundanten Anbindung eines Standorts potenziell zur Folge,
dass die Standort-internen Links zwischen den Switches in den Blocking-State gehen. Dieses
Verhalten entspräche zwar absolut standard-konformem Spanning-Tree-Verhalten - möglicherweise ist
aber den Sicherheitsbeauftragten der Organisation oder auch der Revision nicht klar, dass in diesem
Fall vermeintlich Standort-interner Verkehr unverschlüsselt über den Provider-Backbone
transportiert wird und dabei je nach Netzstruktur auch Länder passiert, in denen es Lawful
Interception (staatliches Mitlesen) gibt und/oder ein "anderes Verständnis von geistigem Eigentum"
vorherrscht.
VLANs
Auch in Hinsicht auf VLANs können Sicherheitsprobleme auftreten. Werden etwa an zwei Standorten
dieselben VLAN-Nummern verwendet, werden sich diese VLANs nach Verbindung der Standorte mit
EoMPLS/VPLS "sehen". Gibt es an einem Standort ein VLAN 10 für die Server und an einem anderen ein
VLAN 10 für das WLAN, werden alle WLAN-Teilnehmer des zweiten Standorts die Windows-Broadcasts des
ersten Standorts empfangen und ein im WLAN platzierter Angreifer hätte potenziell Durchgriff auf
die Server eines anderen Standorts.
Diese Technologien sind aus Netzwerker- oder Design-Sicht hochinteressant - wer wollte nicht
schon immer Standort-übergreifende VLANs oder eine transparente WAN-Anbindung ohne Routing und/oder
NAT und allen Auswirkungen etwa auf den Replikationsverkehr von Verzeichnisdiensten und
Applikationen?
Die oben skizzierten Aspekte entsprechen durchaus einem ganz und gar üblichem Netzwerk- oder
Protokollverhalten, haben aber auf die Netzwerksicherheit große Auswirkung. Sie sollten beim
Einsatz von MPLS-basierten Layer-2-VPNs im Rahmen der Risikoabschätzung immer mitbedacht
werden.
Lesen Sie mehr zum Thema
