IPv6-Sicherheit: Diese Punkte sollten Sie nicht ignorieren

Es ist verlockend, IPv6 als Drop-in-Ersatz für IPv4 zu betrachten, der eben einen größeren Adressraum hat. Sicherheitstechnisch gibt es einige echte Unterschiede, die man verstehen sollte, statt anzunehmen, dass alles von IPv4 unverändert gilt.

Die Sperrliste muss separat aufgebaut werden – nicht nur länger sein

IPv6 hat eigene private, Loopback- und Link-Local-Bereiche, die anders aufgebaut sind als ihre IPv4-Gegenstücke. Eine Sicherheitsprüfung, die nur IPv4-Bereiche parsen und filtern kann, lässt auf der IPv6-Seite all diese Adressen stillschweigend durch – nicht weil IPv6 unsicherer wäre, sondern weil die entsprechenden Schutzmaßnahmen dafür schlicht nie gebaut wurden.

IPv4-mapped Adressen: ein leicht übersehener toter Winkel

IPv6 hat eine Schreibweise, um eine IPv4-Adresse in eine IPv6-Adresse einzubetten – etwa ::ffff:127.0.0.1, die dieselbe Loopback-Adresse bezeichnet wie das schlichte 127.0.0.1, nur in IPv6-Form geschrieben. Eine Prüfung, die IPv4-Loopback korrekt filtert, aber diese eingebettete Form nicht entpackt, lässt eine Adresse passieren, die funktional identisch mit einer ist, die sie sonst glatt blockiert hätte.

• Jedes System, das aufgelöste Adressen gegen eine Sperrliste prüft, braucht eine wirklich eigenständige, vollständige Logik für IPv6 – nicht die Annahme, IPv4-Regeln ließen sich automatisch übertragen.
• IPv4-mapped IPv6-Adressen müssen entpackt und gezielt gegen die IPv4-Regeln geprüft werden, nicht als undurchsichtige IPv6-Adressen bewertet.
• Dual-Stack-Systeme (die meisten modernen) müssen beide Prüfungen konsistent anwenden, denn ein Angreifer nutzt schlicht die Adressfamilie, auf der die schwächere Prüfung sitzt.

Nichts davon ist ein Grund, IPv6 zu meiden – eine breitere Verbreitung ist grundsätzlich gut, und die IPv6-spezifische Angriffsfläche ist nicht von Natur aus größer als die von IPv4. Es ist ein Grund, sicherzustellen, dass die Sicherheitslogik für Adressen tatsächlich für beide Adressfamilien gebaut und getestet wurde, statt für eine, an die die andere nachträglich drangeklebt wurde.

NAT64 fügt eine zweite Übersetzungsebene hinzu, die man kennen sollte

Manche reinen IPv6-Netze nutzen NAT64 und DNS64, damit ihre Clients dennoch das reine IPv4-Internet erreichen: DNS64 synthetisiert spontan einen AAAA-Record für eine Domain, die nur einen A-Record hat, und bettet die IPv4-Adresse in ein spezielles Präfix ein (64:ff9b::/96 ist der bekannte Standard), und NAT64 übersetzt den Traffic an diese synthetische Adresse am Netzwerkrand zurück in echtes IPv4. Es ist ein legitimer, nützlicher Mechanismus – aber er bedeutet, dass eine Adresse in genau diesem Bereich keine rohe IPv6-Adresse ist, die für sich bewertet wird; es ist IPv4 im IPv6-Kostüm und muss genauso wie eine IPv4-mapped Adresse entpackt und gegen IPv4-Regeln geprüft werden.

Sicherheitslogik zu testen heißt, beide Familien zu testen

Automatisierte Tests driften leicht unbemerkt Richtung IPv4 – die meisten Beispiel-Domains, die meisten Test-Fixtures, die meisten schnellen manuellen Prüfungen nutzen es standardmäßig, ohne dass jemand das bewusst entschieden hätte. Eine Testsuite für alles, was Adressen auflöst und filtert, ist nur so vertrauenswürdig wie ihre IPv6-Abdeckung: Fälle für die oben genannten privaten, Loopback- und Link-Local-Bereiche, für eine IPv4-mapped Adresse und für eine NAT64-artig synthetisierte Adresse verdienen jeweils eigene explizite Assertions, nicht bloß ein „es funktioniert wahrscheinlich genauso“. Sicherheitscode für die Adressverarbeitung ist genau die Art von Logik, bei der ein ungetesteter Codepfad und ein defekter erst dann zu unterscheiden sind, wenn ein Angreifer den Unterschied zuerst findet.