IPv6 Tunneling-Protokolle: Anwender sollten die Risiken kennen

Original Artikel von Ben April (Advanced Threat Researcher)

Mit steigendem Einsatz von IPv6 wird auch die Nutzung von Tunneling-Protokollen zunehmen — gut für die Verbreitung von IPv6 , aber weniger gut für die Sicherheit. Ich will bestimmt niemand davon abhalten, IPv6 auszuprobieren. Im Gegenteil, ich rate jedem, das Protokoll jetzt zu testen, um sich dann damit genügend auszukennen, wenn ICANN bekannt gibt, die IPv4-Pools seien ausgeschöpft. Dennoch möchte ich sicherstellen, dass jeder die mit der Nutzung verbundenen Risiken kennt, um entsprechende Vorkehrungen treffen zu können.

Dieser Beitrag behandelt lediglich 6to4 (Wikipedia/ RFC 3506). Der Tunnelmechanismus sollte nicht mit 6in4 und Teredo-Protokollen (Wikipedia/RFC 4380) verwechselt werden. Ein direkter Tunnel zu den IPv6-Systemen des eigenen Providers verursacht nicht vor dieselben Probleme und Risiken wie öffentliche Protokolle.

Beide Protokolle sind darauf ausgerichtet, den Übergang zu IPv6 zu erleichtern, und keines der beiden gibt vor, einen besonderen Schutz zu bieten. Im Gegenteil, der Teredo RFC geht sogar so weit, sich selbst als „IPv6-Provider des letzten Auswegs“ zu bezeichnen. Der Grund für dieses Label sind die verrückten Kunststücke, die erforderlich sind, um erfolgreich die vielen NAT-Gateways zu passieren. Es lohnt sich aber, auch andere Faktoren zu bedenken. Ein ganzer RFC für 6to4 ist ausschließlich Sicherheitsüberlegungen gewidmet.

Man sollte nicht vergessen, dass IPv4-Firewall Regeln den IPv6-Verkehr nicht berücksichtigen. 6to4-Tunneling setzt voraus, dass sich der Benutzer-Endpunkt in einem öffentlich routing-fähigen IP-Raum befindet und von jedem 6to4-Servicegerät direkt zu erreichen ist. Als Vorteil dabei gilt, dass Anwender mehr als ein 6to4-Gateway nutzen können. Die Kehrseite der Medaille aber ist, dass sie dem Verkehr von jeder Adresse aus trauen müssen, die vorgibt, das Protokoll zu unterstützen.

6to4 kann auch Netzwerkrouten hinter dem Endpunkt unterstützen. Die Endpunkte erhalten eine IPv6-Adresse vom Präfix 2002::/16. Die 4 Bytes direkt hinter 2002: stellen die in hexadezimale Darstellung übersetzte IPv4-Adresse des Endpunkts dar. Entsprechend würde 192.168.25.200 der Darstellung 2002:c0a8:19c8::/48 entsprechen (RFC 1918 IP wird nur exemplarisch verwendet und ist für den tatsächlichen Betrieb ungültig). Es ist nur vernünftig, beim Aufsetzen eines Servers und dem Publizieren im IPv6-Internet, diesen sowohl gegen IPv4- als auch gegen IPv6-Bedrohungen abzusichern. Ein Nebeneffekt beim Publizieren einer 2002::/16 IPv6-Adresse besteht nämlich darin, dass man dann auch die IPv4-Adresse des Endpunkts kennt.

Teredo ist darauf ausgerichtet, mit den Remote-Endpunkten hinter einem oder mehreren NAT-Gateways gut zu funktionieren. Anders als im Fall von 6to4 kann es lediglich einen Host hinter dem Endpunkt geben. Anwender müssen sich von Anfang an Gedanken über das Tunneling vom öffentlichen Internet zu einem Host innerhalb einer NAT-Umgebung machen. Ist der Host nicht gut geschützt, so braucht man nicht weiter zu gehen. Anwender müssen sich auch mit Adressdurchlässigkeit auseinandersetzen. Teredo geht noch weiter als 6to4 und codiert sowohl die IPv4-Austrittspunkte am NAT-Gateway als auch den UDP-Port für die externe NAT-Session und die IPv4-Adresse des Tunnel-Endpunkts des Clients. Eine gewisse Verschleierung wird zwar verwendet, XORing UDP-Port und NAT IP mit 1s. Diese Tatsache ist in entsprechenden Kreisen jedoch hinlänglich bekannt und schützt lediglich vor Leuten, die Angst vor Wikipedia haben.

Der Basispräfix für eine Teredo IP Adresse ist 2001:0000::/32. Teredo Client Adressen werden folgendermaßen zusammengestellt:

  1. 2001:0000::/32 — base prefix
  2. 2001:0000:c0a8:19c8::/64 — add IP address of the tunnel server (192.168.25.200 -> c0a8:19c8)
  3. 2001:0000:c0a8:19c8:0000::/80 — add 16 bits of flags (0×00)
  4. 2001:0000:c0a8:19c8:0000:8888::/96 — add external NAT port number XORd with 0xFFFF ( 30583 -> 0×7777 ^ 0xFFFF = 0×8888)
  5. 2001:0000:c0a8:19c8:0000:8888:F537:76C8/128 — add external IP of NAT gateway XORd with 0xFFFFFFFF (10.200.137.55 -> 0×0AC88937 ^ 0xFFFFFFFF = 0xF53776C8)

Ich wiederhole: Jeder, der IPv6 ausprobiert, sollte die Risiken kennen und angemessene Vorkehrungen gegen die Gefahren treffen. Viel Glück!

Schreibe einen Kommentar

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

*