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.
Dieser Hinweis gilt in erster Linie für den Tunnelmechanismus 6to4 (vgl. Wikipedia, RFC 3506). Er sollte nicht mit 6in4 und Teredo-Protokollen (Wikipedia/RFC 4380) verwechselt werden. Ein direkter Tunnel zu den IPv6-Systemen des eigenen Providers verursacht nicht dieselben Probleme und Risiken wie öffentliche Protokolle.
Beide Protokolle - sowohl 6to4 als auch Teredo - 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 (http://tools.ietf.org/...) 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. Somit 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, XOR-ing 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.
Mit diesem Hinweis auf Sicherheitsrisiken möchte ich allerdings niemanden davon abhalten, IPv6 auszuprobieren. Im Gegenteil, ich rate jedem, das Protokoll jetzt zu testen und es zu kennen und sicher anwenden zu können, wenn ICANN bekannt gibt, dass die IPv4-Pools ausgeschöpft sind.
Dieser Hinweis gilt in erster Linie für den Tunnelmechanismus 6to4 (vgl. Wikipedia, RFC 3506). Er sollte nicht mit 6in4 und Teredo-Protokollen (Wikipedia/RFC 4380) verwechselt werden. Ein direkter Tunnel zu den IPv6-Systemen des eigenen Providers verursacht nicht dieselben Probleme und Risiken wie öffentliche Protokolle.
Beide Protokolle - sowohl 6to4 als auch Teredo - 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 (http://tools.ietf.org/...) 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. Somit 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, XOR-ing 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.
Mit diesem Hinweis auf Sicherheitsrisiken möchte ich allerdings niemanden davon abhalten, IPv6 auszuprobieren. Im Gegenteil, ich rate jedem, das Protokoll jetzt zu testen und es zu kennen und sicher anwenden zu können, wenn ICANN bekannt gibt, dass die IPv4-Pools ausgeschöpft sind.
