Mit dem Heftschwerpunkt 'IT-Support & Troubleshooting' startet IT-Administrator ins neue Jahr. Dabei zeigen wir Ihnen, auf welchem Weg Sie Ihr eigenes ... (mehr)

Tunnel-Traffic durch andere Mechanismen filtern

Einige Tunnel-Varianten lassen sich nicht über Protokoll 41 identifizieren, da sie UDP oder TCP als Transportprotokoll nutzen und daher im Protocol-Feld entweder 17 (UDP) oder 6 (TCP) steht. Hierzu gehört Teredo. Dieser Mechanismus nutzt für den Aufbau des Tunnels zum Teredo-Server den UDP-Port 3544. Wird dieser blockiert, kann Teredo die initiale Verbindung nicht aufbauen. Dabei ist es natürlich nicht ausgeschlossen, dass ein Angreifer seinen eigenen Teredo-Server im Internet einrichtet, der nicht über den Standard-Port kommuniziert. Daher kann es nützlich sein, nach weiteren Kriterien zu filtern.

Ist der Paketfilter in der Lage, die Nutzlast (Payload) eines Pakets zu inspizieren, so kann nach einem eingehenden oder ausgehenden IPv4/UDP-Paket gefiltert werden, das ein IPv6-Paket mit dem Wert 6 im Version-Feld des Headers transportiert und dessen Absender- beziehungsweise Empfängeradresse das Teredo-Präfix 2001::/32 nutzt. RFC 7123 weist jedoch auch darauf hin, dass dies unter Umständen zu False Positives führen könnte, falls die Firewall diese Funktionen nicht korrekt implementiert hat. Das bedeutet, dass ein IPv4/UDP-Paket auch dann blockiert wird, wenn es eigentlich keinen Teredo-Traffic transportiert.

Eine weitere Möglichkeit der Filterung besteht in der Kontrolle des DNS-Traffics. So fragt zum Beispiel Windows nach dem IPv4-Host-Eintrag (A) "teredo.ipv6.microsoft.com". Dies kann ebenso vom DNS-Server oder dem Filter-Device überprüft werden wie die Anfrage der Windows-Systeme, die nach dem Namen "isatap.

Ein weiterer Ansatz, um IPv6-Traffic durch IPv4-Only-Netzwerke zu ermöglichen, sind sogenannte Tunnel-Broker. Dabei handelt es sich um IPv6-Gateways im Internet, die über einen auf dem Dualstack-Knoten installierten Client angesprochen werden. Zwischen dem Knoten und dem Gateway (Server) wird ein Tunnel aufgebaut. Der Dualstack-Knoten kommuniziert über IPv6 durch den Tunnel hindurch mit dem IPv6-Internet. Der entscheidende Unterschied zu anderen Tunnelmechanismen ist die explizite Installation eines entsprechenden Clients. IPv6-Tunnel-Broker sind in RFC 3053 beschrieben und nutzen oft das Tunnel Setup Protocol (TSP), das in RFC 5572 definiert ist. TSP kann entweder TCP oder UDP als Transport-Protokoll nutzen. In beiden verwendet TSP für die Kommunikation zum Server die Port-Nummer 3653, die von der IANA für diese Zwecke reserviert wurde.

Die Tunneltechnologie AYIYA steht für Anything In Anything. Auch wenn sie bisher nicht als RFC standardisiert wurde, ist sie jedoch weit verbreitet, da sie dafür konzipiert ist, durch NATP-Geräte, also NAT-Systeme, die Port Address Translation durchführen, zu kommmunizieren. So wird AYIYA zum Beispiel vom bekannten Tunnel-Broker SixXS eingesetzt. AYIYA kann blockiert werden durch die Filterung von TCP- und UDP-Traffic. Hierzu filtert das IPv4-Gateway ausgehenden Traffic auf die Ports 5072/UDP beziehungsweise 5072/TCP.

Fazit

Während die Filterung von nativem Ipv6- und Tunnel-Traffic technisch nicht besonders schwierig ist, besteht die erste Herausforderung darin, zunächst die Problematik zu erkennen. Beim Filtern gilt grundsätzlich der Ansatz: so viel wie nötig, so wenig wie möglich. Neben expliziten Angriffsszenarien, wie der Übernahme eines IPv6-fähigen Routers durch einen Angreifer und der Manipulation von IPv6-fähigen Knoten, die nur über IPv4 kommunizieren sollten, sind insbesondere die automatischen Tunnelmechanismen eine große Gefahr für die unkontrollierte Kommunikation von Systemen mit dem Internet. Dabei spielt noch hinein, dass IPv6 von den gängigsten Betriebssystemen bevorzugt verwendet wird und daher auch dann über IPv6 eine Kommunikation aufgebaut wird, wenn dies nur über Tunnelmechanismen möglich ist.

Hier liegt ein generelles Problem: Auch wenn die Verbreitung von IPv6 nicht in dem Maße voranschreitet, wie erwartet, findet sie dennoch statt. Immer mehr Systeme im Internet, aber auch in Unternehmensnetzwerken können über IPv6 kommunizieren und sind über IPv6 erreichbar. Wenn ein IPv6-fähiger Knoten nun vom DNS-Server als Antwort auf eine Anfrage sowohl eine IPv6- als auch eine IPv4-Adresse erhält, versucht er zunächst über die IPv6-Adresse zu kommunizieren, wenn er glaubt, IPv6-Konnektivität zu haben. Durch die Filterung des IPv6-Traffics oder mangelnde Ende-zu-Ende-Konnektivität kommt die Verbindung aber nicht zustande. Damit bricht er entweder den Kommunikationsvorgang ab oder versucht erst im Anschluss – in der Regel nach einem

Timeout – über IPv4 als Fallback-Mechanismus sein Ziel zu erreichen. Doch auch dann kommt es zu starken Verzögerungen und nicht zufriedenstellendem Verhalten der IT-Infrastruktur. Die Filterung von IPv6-Traffic kann dergestalt abgemildert werden, dass internen Knoten ein TCP-RST-Segment (mit gesetztem Reset-Flag) zurückgeliefert wird, um ihnen die Möglichkeit zu geben, darauf direkt zu reagieren.

Neben der Deaktivierung der IPv6-Funktionalität auf den Endknoten besteht zudem die Möglichkeit, den DNS-Server so zu konfigurieren, dass Anfragen aus dem IPv4-Only-Netzwerk nach AAAA-RR (IPv6-Host-Einträgen) entweder ignoriert oder mit einem DNS RCODE von 0 (NOERROR) gemäß RFC 1035 beantwortet werden. Damit ist sichergestellt, dass Knoten aus dem IPv4-Only-Netzwerk ausschließlich A-Einträge, also IPv4-Adressen vom DNS-Server, als Antwort erhalten.

Langfristig besteht die Lösung natürlich in der flächendeckenden Umstellung auf native IPv6-Konnektivität. Es bleibt zu wünschen, dass der gegenwärtige Aufwärtstrend von IPv6 dazu führt, dass die Migration auf IPv6 höchste Priorität in den Unternehmen erhält, um diese Übergangsszenarien und deren Probleme, wie in diesem Artikel beschrieben, auf einen minimalen Zeitraum zu beschränken.

(of)

comments powered by Disqus
Mehr zum Thema

IPv6-Tunneltechnologien

Nachdem IPv6 nun das offizielle Internet-Protokoll ist, bleibt nur noch die Kleinigkeit, alle Rechner im Internet umzustellen. Bis das passiert, verschaffen Tunneltechnologien eine Übergangslösung.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2022