Speicher: Achillesverse von IPv6 – Sicherheit

Kommentieren Drucken
Teil 3 von 3 aus der Serie "Speicher: Achillesverse von IPv6"

Ein 64er Präfix, wie es bei IPv6 pro Subnetz vorgesehen ist, bedeutet, dass es 264 Interface-Adressen gibt. Das sind etwas mehr als 18 * 1818, sprich 18 Trillionen Adressen. Jede davon ist 16 Byte lang, macht also 296 Trillionen Byte, wenn man sie alle abspeichern wollte. Das sind übrigens rund 295.147.905 Terrabyte. Da liegt doch die Überlegung nahe, IPv6 für alle möglichen Arten Memory Overflow von Angriffen zu nutzen.

Wie bei Memory Overflow Angriffen üblich, handelt es sich meist um einen Denial of Service. Dabei kann man zwischen lokalen und remote Angriffen unterscheiden. Im ersten Fall muss der Angreifer im selben Netz sein wie der Angegriffene, im zweiten ist das nicht nötig.

Lokaler Angriff
Ein typischer Vertreter für diese Variante ist ein RA Flooding.

Beim RA Flooding gibt sich ein beliebiger Rechner als Router aus und sendet Router Advertisements in das Lokale Netzwerk. Dabei ändert er bei jedem Paket seine IPv6-Absendeadresse. Alle angeschlossenen Clients gehen nun hin und tragen bei jedem neuen Paket diesen „neuen“ Router in ihre Liste ein.

Die schiere Menge von IPv6 Adressen führt dazu, dass man so sehr leicht auch den speicherstärksten Client problemlos über seine Grenzen hinaus treiben kann.

Wie kann man sich dagegen wehren?

Zum einen gibt es die eher theoretische Möglichkeit, ein sicheres Verfahren zu nutzen. Im Normalfall akzeptieren Clients alle RAs, die sie bekommen. Besser wäre es, wenn sie sich sicher sein könnten, dass der Absender wirklich ein Router ist. Von der IETF gibt es dafür SEND, also das Secure Neighbor Discovery Verfahren. Eine flächendeckende Implementierung ist jedoch weder bei Routern noch bei Client-Betriebssystemen in Sicht. Fazit: keine Lösung.

Eine andere Möglichkeit wäre es, die Anzahl der RA Einträge auf den Client zu begrenzen. Damit verhindert man zwar erfolgreich einen Memory Overflow, nicht jedoch den eigentlichen Angriff, den Denial of Service. Ein Angreifer muss einfach nur alle verfügbaren RA-Plätze mit unsinnigen Einträgen besetzten. Da ein Client keine Möglichkeit hat, echte von falschen RAs zu unterscheiden, sollte dem Angreifer das über kurz oder lang auch gelingen.

Eine Alternative aus der Netzwerkwelt wäre, was bspw. Cisco RA Guard nennt. Bei diesem Verfahren weiß die Layer 2 Komponente, an die die Clients und Router angeschlossen sind, an welchen Ports Router, resp. Layer 3 Switches, angeschlossen sind. Der Verkehr wird von dem Layer 2 Switch überwacht und alle Router Advertisements auf anderen Ports werden verworfen.

Diese Lösung hat eine Reihe von Vorteilen:

  • Sie ist verfügbar.
  • Sie ist für Clients und Router transparent.
  • Sie schützt auch vor anderen Angriffen, die mittels RAs in lokalen Netzen möglich sind.

Allerdings müssen die Layer 2 Switches ein entsprechendes Verfahren auch unterstützen. Das wiederum bedeutet, dass sie nicht nur Pakete weiterleiten, sondern die Inhalte auch „on the fly“ auswerten müssen. Naturbedingt sind das nicht die kostengünstigen.

Remote Angriff
Muss man bei RA Flooding noch im selben Netz sein, so kann man das Neighbor Solicitation sogar für einen Angriff auf entfernte Netze anwenden.

Will man beispielsweise die DMZ eines Unternehmens angreifen, so reicht es ein öffentliches Präfix eines DMZ Netzes zu kennen. Nun sendet der Angreifer, oder wahrscheinlicher die von ihm kontrollierten Zombis, irgendwelche erlaubten Pakete in Richtung dieses Präfixes an IPv6 Adressen, die es gar nicht gibt. Der Router / Layer 3 Switch, der an diesem Subnetz angeschrieben ist, versucht nun die MAC Adresse zu den fingierten IPv6 Adressen aufzulösen. Dazu sendet er SNMA Pakete in das lokale DMZ Netz und merkt sich, von wo noch keine Antwort erfolgt ist. Das kostet Zeit und vor allem auch Speicher. Viele Router haben auch einen „negativ“ Cache, d.h. sie merken sich, welche IP Adressen sie (gerade) nicht erreichen können, damit sie beim nächsten Paket an diese Adresse nicht sofort wieder nachfragen müssen. Abbildung 3 zeigt das Vorgehen.

Wie nun kann man sich dagegen wehren?

Es gibt Hersteller, die schlagen vor, nur einen stark begrenzten Bereich der Interface-Adressen zu nutzen. So beschränkt man die Anfragen, die der Router stellen muss, und den Speicher, den er maximal benötigt.

Ähnliches kann man aber auch mit Firewalls erreichen, die jede gute DMZ schützen sollten. Diese Firewalls kennen alle internen Systeme und wissen, welche Dienste auf welchen Systemen verfügbar sind. Nur diese Anfragen werden auch durchgelassen. Ganz nebenbei löst man so auch den Speicherüberlauf auf den Layer 3 Switches, da dort nur noch Pakete ankommen, die für real existente Systeme sind.

Fazit: Artikel
Natürlich ist es problemlos möglich sich weitere Varianten einfallen zu lassen, wie bspw. ein Sync-Flooding auf TCP Ebene mit wechselnden IPv6 Adressen. Wie diese beiden Beispiele aber bereits zeigen, kann die schiere Adressmenge genutzt werden, um sowohl lokale wie auch entfernte Netze lahm zu legen oder zumindest zu stören.

Fazit: Serie
Der Segen von IPv6, genügend Adressen für die Ewigkeit bereit zu stellen, ist gleichzeitig der Fluch von IPv6. Die Anzahl möglicher Routen, die Anzahl der Interface-Adressen pro Subnetz und die benötigten Speicherkapazitäten für mehr und längere Adressen in Microsystemen sind drei Schwachstellen. Jedoch sind alle davon beherrschbar. Die Voraussetzung ist jedoch, dass man sich der jeweiligen Probleme bewusst ist und aktiv dagegen arbeitet. Für Betreiber gilt das insbesondere beim IP Design und der Konfiguration der Komponenten. Kleine Fehler können hier gigantische Auswirkungen haben.

« Teil 2: Speicher: Achillesverse von IPv6 – Microsysteme


zugeordnete Kategorien: IP und IPv6, IT-Sicherheit
zugeordnete Tags: ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.