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

Das Problem von nativem IPv6-Support

Die gängigen Betriebssysteme unterstützen IPv6 nativ und aktivieren es per Default. Demnach ist grundsätzlich auch in einem IPv4-Netzwerk IPv6 latent aktiv. Mindestens eine Link-Local-Adresse hat jedes IPv6-aktivierte Interface. Auch wenn diese Adresse zunächst nur auf den lokalen Link, also das lokale Subnetz, beschränkt ist, kann die Kommunikation eines solchen Hosts in bestimmten Situationen erweitert werden: Gelingt es einem Angreifer, den Router zu kontrollieren, so kann er ihn für IPv6 konfigurieren und zum Beispiel Router Advertisements aktivieren. Wird vom Angreifer ein Präfix konfiguriert, das zum lokalen Standort geroutet wird, bringt er IPv4-Knoten mit aktiviertem Dualstack dazu, Global-Unicast-Adressen zu bilden, mit denen sie ins Internet gelangen können (Bild 2).

Das größte Problem hierbei ist die stateless Autoconfiguration (SLAAC). Dieses Feature ist bei den gängigen Betriebssystemen per Default aktiv. Empfängt ein IPv6-aktivierter Knoten ein Router Advertisement mit Präfix-Option (darin ist ein 64 Bit langes IPv6-Präfix enthalten), bildet er mit Hilfe dieses Präfixes nach bestimmten Regeln eine komplette IPv6-Adresse, die unter bestimmten Bedingungen global eindeutig ist. Dabei nutzt er zur Erstellung der Interface-ID entweder das erweiterte EUI-64-Format, das auf der MAC-Adresse des Interfaces basiert, oder die Privacy Extensions nach RFC 4941. Alternativ verwendet Windows einen einmalig erstellten Randomized Identifier. In jedem Fall ist die Eindeutigkeit gewährleistet. Hat der Router nun noch einen Anschluss an die IPv6-Infrastruktur des Unternehmens oder direkt ans Internet, kann der Dualstack-Knoten, der eigentlich nur über IPv4 kommunizieren sollte, mit seiner IPv6-Adresse online gehen.

Aber auch wenn ein IPv6-aktivierter Knoten keine Router Advertisements empfängt, versuchen die meisten Betriebssysteme, auf IPv6-aktivierten Interfaces via DHCPv6 eine IPv6-Konfiguration zu erlangen. Gelingt es dem Angreifer, einen Rogue-DHCPv6-Server einzurichten (also einen "wilden", nicht berechtigten Server), kann der Knoten auch auf diese Weise unerwünscht zu einer vollwertigen IPv6-Adresse gelangen. Eine weitere Herausforderung für den Angreifer besteht hier allerdings darin, dass es derzeit keine Möglichkeit gibt, das Default-Gateway des Knotens über DHCPv6 zu setzen. Dieses muss entweder via Router Advertisements oder manuell konfiguriert werden.

Sicherheit für nativen IPv6-Traffic

Auch wenn nativer IPv6-Traffic nach der Migration auf IPv6 den gewünschten Zustand darstellt, muss er während der Migration kontrolliert werden. Der effektivste Schutz vor unerwünschtem, nativen Ipv6-Traffic besteht in einem mehrstufigen Verfahren:

- Zunächst sollten Sie die entsprechenden nicht genutzten IPv6-Features deaktivieren. So kann IPv6 entweder komplett oder nur die Autoconfiguration abgeschaltet werden, um sicherzustellen, dass der Knoten keine IPv6-Adressen bildet und Router Advertisements ignoriert.

- Außerdem sollte der netzwerkbasierte Schutz durch Konfiguration entsprechender Filterregeln auf den Paketfiltern implementiert werden. Auch wenn das Unternehmen bereits einigen Teilen der Infrastruktur die IPv6-Kommunikation ermöglicht, können Sie die aktuell nur mit IPv4 kommunizierenden Komponenten mit entsprechend restriktiven Filterregeln für den IPv6-Traffic blockieren. Hier gilt der übliche Ansatz für Firewalls: so viel wie nötig, so wenig wie möglich. Entscheidend ist die vollumfängliche Einbeziehung von IPv6 in die Sicherheitsplanung.

- Zum Schutz vor nicht erwünschten IPv6-Routern und DHCPv6-Servern existieren Features wie RA-Guard (RFC 6105) sowie DHCPv6-Shield. Diese Funktionen werden auf Switches implementiert und als First-Hop-Security bezeichnet. Auch SeND (Secure Neighbor Discovery) ist ein Verfahren, das über kryptografisch gesicherte Adressen (CGA, Cryptographically Generated Addresses) vor nicht autorisierten Routern und anderen Systemen schützt. Allerdings erfordert SeND eine aufwendige Konfiguration auf allen Kommunikationspartnern und ist somit kein probates Mittel, um IPv4-Only-Netzwerke zu schützen. Wer sich die Mühe macht, SeND zu implementieren, wird in der Regel zuvor die IPv6-Kommunikation aktiviert haben.

Weitere Schutzmaßnahmen betreffen Security-Devices wie VPN-Gateways oder NIDS/NIPS. Diese sollten Sie ebenfalls für IPv6-Awareness konfigurieren.

Bild 3: Ein IPv6-Paket wird an einer bestimmten Stelle in IPv4 eingekapselt und als IPv4-Paket weiter transportiert.
comments powered by Disqus

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