IPsec ist kein Rund-um-Sorglos-Paket für IPv6 Teil 1
Sicherer als IPv4, aber nicht sicher genug – IPv6 braucht Filter
30.11.2007 | Autor / Redakteur: Wilhelm Dolle und Christoph Wegener / Ulrike Ostler
IPsec ist ein direkter Bestandteil von IPv6. Das erschwert zwar Lauschangriffe, doch insgesamt wurde die Sicherheit mit der neuen Protokoll-Version nicht wesentlich verbessert. Daher werden das Konfigurieren von Paketfiltern und das Filtern innerhalb einer DMZ noch wichtiger. Das zeigen ein paar Angriffs-Szenarien, in denen die Hacker die Header-Struktur ausnutzen.
IPv6 wurde bereits im Jahre 1998 in RFC 2460 spezifiziert und als Nachfolger von IPv4 re-designed. Dabei spielten vor allem die folgenden drei Aspekte eine herausragende Rolle: Performanz, Sicherheit und Usability (was in diesem Fall die Möglichkeit zur Mobilität meint).
Performanz lässt sich vor allem durch die Einführung einer festen Länge des IP-Basis Headers und der Extension Header erreichen. Zusätzlich erfolgt die Fragmentierung der Pakete nun ausschließlich an den Endgeräten. Diese beiden Aspekte führen – gerade auf gut ausgelasteten Routern – zu einer deutlich beschleunigten Verarbeitung der Pakete.
Nicht zuletzt ist auch das Thema Mobilität (von Geräten und kompletten Netzen) mit IPv6 mehr in den Mittelpunkt gerückt, mit RFC 3775 wurde hier bereits im Jahre 2004 der Grundstein gelegt.
Dem Punkt Sicherheit schließlich wird durch IPsec Rechnung getragen Im Gegensatz zur Internet-Protokoll-Version 4, in der IPSec gleichermaßen ein Add-on ist, ist die Sicherheitsarchitektur für die Kommunikation über IP-Rechnernetze in IPv6 integriert.
Neue Header – alte Probleme
Mit IPv6 wurde ein neues Header-Format eingeführt, das den Header nun in einen IP-Basis- und einen Extension-Header aufteilt. Die Länge eines Headers ist dabei auf ein Vielfaches von 64-Bit festgelegt, was zu einer deutlich beschleunigten Paketverarbeitung führt. Um die Geschwindigkeit weiter zu erhöhen, wurde die Fragmentierung nun ganz auf die Endgeräte verlagert.
Während die Performanz durch diese Maßnahmen enorm gesteigert werden kann, können diese neuen Eigenschaften aber in puncto Sicherheit Probleme mit sich bringen, zum Beispiel bei der fehlerfreien Konfiguration von Paketfiltern und Firewalls. Denn ein Angreifer kann den Datenstrom nach wie vor künstlich fragmentieren und dadurch Paketfilter und Intrusion Detection Systeme (IDS) austricksen.
Der Angreifer kann dazu beispielsweise einen Paketstrom erzeugen, in dem das erste Paket den Inhalt „us“, das zweite den Inhalt „er“, das dritte den Inhalt „ro“ und das vierte den Inhalt „ot“ hat. Nun muss zunächst der komplette Paketstrom wieder zusammengesetzt werden, um zu erkennen dass „user root“ sich einloggen möchte.
Noch komplexer wird es, wenn der Angreifer ein Pakte mit Inhalt „fo“ einschleust, denn nun ist die Frage: Handelt es sich um „user root“ oder „user foot“? Diese Form eines Angriffs ist gegenüber IPv4 nicht neu, allerdings wird die Analyse durch die per RFC 2460 vorgegebene Fragmentierung (auf den Quellgeräten) und die Defragmentierung (auf den Zielgeräten) erschwert.
Verwerfen oder durchschleusen?
Dass ein Router, den ein Paket auf seinem Weg passiert, nicht erkennen kann, ob er ein Paket verwerfen sollte, wenn der Routing-Header nach dem Fragmentation Header steht, ist ein ebenso gravierende Problem. Eine solche Reihenfolge der Extension Header ist nach RFC 2460 zwar nicht erwünscht („SHOULD NOT“), aber ein so geartetes Paket erfüllt trotzdem die Spezifikation.
Wenn somit ein Router Pakete mit Routing-Header generell verwerfen soll, muss er zunächst den gesamten Paketstrom re-assemblieren. Das kostet nicht nur Performanz, sondern kann unter Umständen auch für einen Denial-of-Service-Angriff („DoS-Angriff“) genutzt werden.
Ohnehin sollen Router und Gateways nicht mehr in die Fragmentierung der Pakete eingebunden werden. Doch damit wird das Filtern von ICMPv6-Nachrichten „Packet too big“ (RFC 4443; Type 2) ein unter Umständen problematisches Unterfangen: Wenn man diese Nachrichten komplett ausfiltert, kann der gesamte Datenstrom einer Verbindung verloren gehen.
Das korrekte Ausfiltern von ICMPv6-Nachrichten wird also komplexer, da auf der einen Seite einige ICMPv6-Nachrichten zu den Engeräten gelangen müssen. Auf der anderen Seite sind aber ICMPv6-Nachrichten wie „Redirect“ (RFC 2461; Typ 137) von Seiten der Sicherheit als problematisch einzustufen und werden daher oft komplett am Border Gateway ausgefiltert.
Noch mehr Spaß mit Routing-Header
Ein „Next Header“ vom Typ „Routing-Header“ (RFC 2460; Typ 43) muss von jedem Gerät, das in der Liste aller zu passierenden Geräte gelistet ist, verarbeitet werden. Ein Routing-Header hat darüber hinaus noch eine weitere Kodierung, den so genannten „Routing type“:
Typ „0“ steht hier für ein Feature, das unter IPv4 als „Loose Source Routing“ bekannt war, Typ „2“ steht für einen Routing-Header, der für „Mobile IPv6“ („MIPv6“; RFC 3775) genutzt wird. Absender eine Pakets können damit den Weg des Pakets bestimmen, indem sie einen Routing-Header vom Typ „0“ benutzen. Für die Diagnose von Fehlfunktionen mag das sehr hilfreich sein, aber die Funktion ist auch für potenzielle Angreifer ein nettes Feature.
Zunächst können Angreifer, die ein (Provider-)Netzwerk nutzen, mit Hilfe dieses Feature Informationen über das genutzte Netzwerk sammeln. Es wäre möglich, dazu ein „Boomerang“-Paket das das eigene Gerät als eigentliches Ziel angibt vom Sendegerät aus (also mit einer Quell-Adresse des Provider-Netzwerks) zu einem externen Server zu verschicken. Dies wird dadurch erreicht, dass die eigene IP-Adresse als letztes in der Liste der Routing-Adressen steht.
Der externe Server erkennt, dass das Paket einen Routing-Header enthält, wird diesen nach RFC 2460 behandeln und das Paket an das eigentliche Ziel, das Gerät des Angreifers, zurück senden. Wenn der Angreifer dieses Paket erhält, werden am Border Gateway eingehende Pakete mit einer Absenderadresse aus dem eigenen Netz nicht gefiltert, „ingress filtering“ heiß das. Dieses Vorgehen lässt sich vom Angreifer ausbauen, etwa um die Erreichbarkeit von Mail-Servern, Datenbank-Servern und vielem mehr zu testen.
Ausnutzen der entmilitarisierten Zone
Ausgefuchstere Angreifer können mit Routing-Headern vom Typ „0“ auch versuchen, Firewalls zu umgehen, etwa wie folgt: Eine Firma betreibt einen Web- und einen Datenbank-Server, die beide in der „Demilitarized Zone“ („DMZ“) platziert sind. Weiterhin soll angenommen werden, dass der Web-Server von außen erreichbar ist, während der Datenbank-Server nur innerhalb der DMZ oder von innen verfügbar ist.
Angreifer können ein Paket zum Web-Server schicken, das den Datenbank-Server als eigentliches (letztes) Ziel im Routing-Header listet. Der Web-Server wird dieses Paket annehmen und zum Datenbank-Server weiterleiten. Auf diese Weise lässt sich zumindest ein DoS-Angriff auf den Datenbank-Server ausführen.
Wenn der Angreifer mehr Glück hat, kann der den Datenbank-Server eventuell auch übernehmen. Der Erfolg eines solchen Angriffs hängt dann entscheidend davon ab, wie die Firewall beziehungsweise der Paketfilter mit dem Verbindungsaufbau zwischen Angreifer und Datenbank-Server umgeht.
Das SYN-Paket kommt von außen über den Web-Server zum Datenbank-Server, der Datenbank-Server wird mit einem SYN/ACK-Paket antworten. Die entscheidende Frage ist nun: Wie wird die Firewall mit diesem SYN/ACK-Paket umgehen? Wird sie es verwerfen oder wird sie dem Angreifer einen Kanal zum Datenbank-Server öffnen?
Über die Autoren
Christoph Wegener, promovierter Physiker und CObIT Basic Practitioner, ist seit 1999 mit der wecon.it-consulting freiberuflich in den Themen IT-Sicherheit und Open Source / Linux aktiv. Er ist Autor zahlreicher Fachbeiträge, Fachgutachter für verschiedene Verlage und Mitglied in mehreren Programmkomitees. Seit Anfang 2005 ist er zudem am europäischen Kompetenzzentrum für Sicherheit in der Informationstechnik (eurobits) tätig. Darüber hinaus ist er Gründungsmitglied der Arbeitsgruppe Identitätsschutz im Internet (a-i3) e.V. und dort, sowie in der German Unix User Group (GUUG), Mitglied des Vorstands.
Wilhelm Dolle ist Senior Security Consultant bei der HiSolutions AG in Berlin. Er hat unter anderem als Abteilungsleiter und Mitglied der Geschäftsleitung eines mittelständischen Unternehmens und freiberuflicher Berater mehr als 15 Jahre Erfahrung im IT-Sicherheitsmanagement, in Risiko- und Sicherheitsanalysen, in der Computer-Forensik sowie im Incident Management sammeln können. Wilhelm Dolle ist lizenzierter ISO 27001 / BSI IT-Grundschutzauditor, CISA, CISSP, Autor zahlreicher Artikel in Fachzeitschriften und hat Lehraufträge an einer Universität und an einer Berufsakademie inne.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2009404)