Ein Angreifer beginnt in der Regel seine Aktivität damit, sich Informationen über das Netzwerk, die darin enthaltenen Hosts und Dienste zu beschaffen. Dazu bedient er sich normalerweise einer ausgefeilten Scanning-Methode. Die beschafften Informationen dienen ihm als Grundlage für den später folgenden, eigentlichen Angriff. IPv6 bietet von vornherein einen gewissen Schutz vor Scanning, indem die riesige Anzahl potenzieller Hosts in einem typischen LAN ein Port-Scanning relativ schwierig macht. Ein umfassender Scan eines /64-Subnetzes ist extrem zeitaufwendig, und viele Angreifer werden sich einfachere Ziele suchen. Selbstverständlich ist dies kein hundertprozentiger Schutz, aber immerhin eine wirkungsvolle Abschreckung.

Leider gibt es einige Punkte, die ein Scanning vereinfachen und wichtige Systeme einer Gefahr aussetzen. Diese Punkte zu kennen, ermöglicht Administratoren aber auch, Maßnahmen zu ergreifen:

• Vorhersehbare Adressierungsschemas: Viele Administratoren nutzen spezifische und damit relativ leicht vorhersehbare Adressierungsschemas für bestimmte Systeme, beispielsweise Server und Router. Administratoren sollten ihre Adressierungsmuster sorgfältig auswählen und vielleicht sogar wichtige Systeme ohne besonderes Schema nummerieren, selbst wenn dies das Adressmanagement etwas schwieriger macht.

• Das EUI-64-Adressformat: Zweifellos erleichtert EUI-64 die Autokonfiguration und Adressierung von Hosts. Allerdings ist auch Angreifern bekannt, wie EUI-64 und Autokonfiguration funktioniert. So wissen natürlich auch Angreifer, dass zur Erzeugung der letzten 64 Bits der Adresse die MAC-Adresse genutzt wird, in die automatisch das Muster 0xFFFE eingefügt wird. Dies reduziert den zu scannenden Adressbereich. Nochmals einfacher wird es für einen Angreifer, wenn er weiß oder zumindest ahnen kann, von welchem Hersteller die im Netzwerk genutzten Netzwerkkarten stammen. Denn wenn er dies weiß, kennt er bereits die Hälfte der MAC-Adresse.

• Ungeeignete Filterung eingehender Nachrichten: Damit IPv6 korrekt funktioniert, müssen bestimmte ICMPv6-Nachrichten im geschützten Netzwerk erlaubt sein. Diese Nachrichten können für die Informationsbeschaffung genutzt werden. Administratoren müssen Filter so einstellen, dass sie wirklich nur die notwendigen Nachrichten erlauben.

• Ungeeignete Filterung von Multicasts: Einige IPv6-Multicast-Adressen adressieren eine Gruppe von Geräten gleichen Typs, beispielsweise alle Router. Kann ein Angreifer auf solche Adressen zugreifen, könnte er Zugriff auf diese Geräte erlangen und sie angreifen (DoS). Entsprechend eingestellte Filter verhindern, dass solche Adressen über die Grenzen des Netzwerks hinaus angekündigt werden.

Wie bei IPv4 sollten nicht benötigte Dienste an den Zugangspunkten des Netzwerks gefiltert werden.

Die Autorisierung, wer auf ein Computersystem zugreifen darf, ist eine Richtlinienentscheidung. Eine solche Richtlinie kann in TCP/IP auf Schicht 3 oder 4 durchgesetzt werden. In diesem Fall wird die Entscheidung normalerweise in Firewalls getroffen. Das ist auch bei IPv6 noch so.

Die Filterung von Paketen, deren Quelladressen niemals in Internet-Routing-Tabellen auftauchen sollten, ist eine Minimalanforderung an jede Firewall. Bei IPv4 ist es einfacher, Pakete mit solchen Adressen abzulehnen (deny), bei IPv6 ist es leichter, legitime Pakete zuzulassen.

Die Zugriffssteuerung kann natürlich auch unterhalb der Netzwerkschicht erfolgen, beispielsweise mit einem auf Ports basierenden Authentifikationsmechanismus wie 802.1x. Eine 802.1x-Infrastruktur unterstützt sowohl verdrahtete und wireless Segmente des Netzwerks.

Denial-of-Service-(DoS-)Angriffe mit gefälschten oder gespooften Quelladressen bereiten große Schwierigkeiten. Zur Verhinderung von DoS-Angriffen mit gefälschten IP-Adressen empfiehlt RFC 2827 eine einfache, aber wirksame Methode zur Nutzung von Ingress-Traffic-Filtering. Diese Methode kann das Spoofing von Quelladressen verhindern. Außerdem ermöglicht sie eine Rückverfolgung des Urhebers bis zur Quelle, denn der Angreifer muss eine gültige, erreichbare Quelladresse verwenden.

Ingress-Filterung wird normalerweise in den Edge-Routern des ISPs implementiert, entweder durch Firewall-Filter oder durch einen Unicast-Reverse-Path-Forwarding-Check (uRPF).

Die Endbenutzer eines ISPs könne eine ähnliche Technik (Egress-Filterung) nutzen, um das Senden von Paketen zu verhindern, die nicht zu ihren Netzwerken gehören.

Diese Techniken lassen sich auch in IPv6 implementieren, wobei IPv6 die Ingress-Filterung noch erleichtert, da lediglich ein Präfix für den Ingress-Filter zu konfigurieren ist.

In IPv4-Netzwerken lassen sich relativ einfach Angriffe gegen das ARP-Protokoll durchführen, da Hosts nicht beweisen können, dass sie Eigentümer ihrer MAC-Adresse sind. Daher ist es beispielsweise einfach, den Default-Router des Subnetzes zu kapern. Das Netzwerk lässt sich dagegen schützen, indem man einen Switch so konfiguriert, dass er für alle Frames, die er über einen spezifischen Port empfängt, nur eine spezifische Zahl MAC-Adressen zulässt. Cisco-Switches bieten diesen Schutz mit ihrem Port-Security genannten Feature.

Falls DHCP für die Initialisierung der Hosts genutzt wird, können Angreifer auf dem Link verschiedene Angriffe gegen den DHCP-Server unternehmen. Sie können einen falschen DHCP-Server betreiben und DHCP-Nachrichten schneller als der legitime DHCP-Server liefern, sie können den DHCP-Server erschöpfen, indem sie ihn mit einer riesigen Anzahl von Requests bombardieren, sie können den vom DHCP-Server zur Verfügung gestellten IP-Adressbereich erschöpfen, indem sie zu viele IP-Adressen anfordern ... Vor solchen Angriffen schützen kann man sich durch eine Kombination aus Port-Security, DHCP-Snooping und Beschränkung der DHCP-Nachrichtenrate. Port-Security verhindert den Betrieb falscher DHCP-Server. DHCP-Snooping filtert nicht vertrauenswürdige DHCP-Nachrichten und erzeugt eine DHCP-Snooping-Binding-Tabelle. Diese Tabelle wird genutzt, um IP-Spoofing zu verhindern.

Die Hosts in einem IPv6-Netzwerk können ähnlich wie ARP angegriffen werden, beispielsweise durch Senden falscher Neighbor-Advertisement-Nachrichten, durch einen DoS-Angriff auf die Prozedur, die doppelte Adressen erkennt, oder durch Senden falscher Router-Advertisements. Zum Schutz vor Angriffen auf die Neighbor-Discovery-Prozedur kann man Secure Neighbor Discovery (SEND) implementieren (RFC 3971).

In der Vergangenheit wurden viele Broadcast-Storm-Angiffe gegen IPv4-Netzwerke unternommen, der berühmteste davon war dem smurf-Angriff. Dieser Angriff wurde durch zwei Umstände ermöglicht:

1. Ingress-Filterung war nicht implementiert, wodurch das Spoofing der Quelladresse des Angriffspakets ermöglicht wurde.

2. Die Hosts antworteten auf Nachrichten, die an eine Broadcast-Adresse gerichtet waren.

Ein solcher Angriff ist in einer IPv6-Umgebung kaum vorstellbar, denn:

• In einer IPv6-Umgebung gibt es keine Broadcast-Adressen. Dies stoppt Angriffe, die ICMP-Pakete an eine Broadcast-Adresse senden. Für Gruppen von Geräten existieren allerdings globale Multicast-Adressen (Link-Local-Adressen, Site-Local-Adressen und Site-Local-Router).

• Die IPv6-Spezifikation erlaubt keine Antworten auf Nachrichten, die für globale Multicast-Adressen bestimmt sind. Dabei gibt es allerdings zwei Ausnahmen: die Packet-Too-Big-Nachricht und die Parameter-Problem-Nachricht.

Der Zweck eines IP-Routing-Angriffs ist die Störung oder Zerstörung des Router-Peerings oder der Routing-Informationen mit dem Ziel, einen weiteren Angriff nachzuschieben, beispielsweise einen DoS-Angriff. Auch Administratoren eines IPv6-Netzwerkes müssen mit Angriffen auf ihre Routing-Infrastruktur rechnen.

BGP, IS-IS und EIGRP nutzen bei IPv4 und IPv6 denselben Sicherheitsalgorithmen: keyed MD5-Digest. In diesen Fällen sind die Routing-Protokolle bei IPv6 so zu schützen, wie es bei IPv4 getan wird.

OSPFv3 und RIPng nutzen indes IPsec. Wer also eines dieser beiden Routing-Protokolle verwendet, der sollte IPSec zum Schutz dieser Protokolle konfigurieren.

Die weiteren Angriffstypen gegen die Router-Infrastruktur gleichen denen, die bei IPv4 genutzt werden. Hier sollten also ähnliche Gegenmaßnahmen ergriffen werden wie bei IPv4, beispielsweise Zugriffsbeschränkungen für Router, SSH-Authentifikation etc.

Das Einfangen ungeschützter Daten in einer IPv6-Umgebung gleicht dem Sniffing in IPv4-Umgebungen. Wireshark (ehemals Ethereal) ist ein von Netzwerkadministratoren sehr häufig eingesetztes Tool zum Einfangen und Auswerten von Paketen, das natürlich auch jedem Angreifer zur Verfügung steht.

Die obligatorische Unterstützung von IPSec in IPv6-Umgebungen kann dieses Problem abschwächen.

Ohne IPSec werden diese Angriffe bei IPv6 ebenso zum Erfolg führen wie bei IPv4. IPv6 ist mit IPSec zwar eng verknüpft, aber es ist noch nicht alltäglich, dass Netzwerkadministratoren IPSec auch wirklich nutzen. Zertifikate können die nötige End-to-End-Authentifikation auf Anwendungsebene bieten. Ohne einen solchen Mechanismus sind Man-in-the-Middle-Angriffe möglich.

Heute haben die meisten Angriffe auf Computersysteme die Anwendungsschicht zum Ziel. Solche Angriffe erlangen Zugriff auf Systemressourcen, indem sie Pufferüberläufe in den Anwendungen ausnutzen oder sich durch Ausführung von Code höhere Privilegien aneignen.

Diese Angriffstypen sind nicht mit dem zugrunde liegenden Netzwerkprotokoll verknüpft. Aus diesem Grund ist nach einer Migration zu IPv6 keine Änderung zu erwarten. Die Administratoren müssen die Probleme kennen und ihre Systeme permanent aktualisieren, um solche Angriffe zu verhindern.

Flooding-Angriffe sind bei IPv4 und IPv6 identisch. Sie zu verhindern, wird also auch bei IPv6 eine Aufgabe sein. Dafür benötigen Administratoren wirksame DoS-Erkennungswerkzeuge, die IPv6-Kommunikationsflüsse analysieren können, um DoS-Flüsse zu finden. Falls die Kommunikation durch IPSec authentifiziert wird, erreichen die DoS-Pakete die Anwendung zwar nicht, aber der Kommunikationskanal könnte immer noch überflutet werden, womit der Angriff im Endeffekt doch noch erfolgreich wäre.

Adressen dieses Typs wurden entwickelt, weil es Bedenken gab, ein und denselben Schnittstellen-Identifier in mehrfachen Kommunikationskontexten zu benutzen. Man könnte den Identifier ja nutzen, um scheinbar unabhängige Aktivitäten miteinander in Beziehung zu setzen. Diese Privacy-Extension-Adressen verhindern das zwar, sie bringen aber auch ein paar Probleme mit sich: Sie machen das Troubleshooting komplizierter, erfordern häufige Updates von Reverse-DNS-Einträgen, erlauben einfacheres Adress-Spoofing, verhindern die Unterscheidung temporärer und gefälschter Adressen und verbessern dabei die Präfix-Privacy kein Stück.

Möglicherweise ist es besser, statt solcher Adressen ein neueres IPv6-Feature zu nutzen: Cryptographically Generated Addresses (CGA), RFC 3972. Dieses Feature generiert einen zufälligen Schnittstellen-Identifier basierend auf dem öffentlichen Schlüssel (public key) des Knotens. CGA beweist das Eigentum einer Adresse und verhindert das Spoofing und den Diebstahl existierender IPv6-Adressen.

DHCP kann ein Gerät mit einer Adresse und anderen Konfigurationsinformationen ausstatten. DHCPv6-Server nutzen DCHP-Unique-Identifier (DUIDs), um Clients für die Auswahl von Konfigurationsparametern zu identifizieren. DHCP-Clients nutzen DUID, um einen Server zu identifizieren.

Ein DUID kann aus verschiedenen Quellen generiert werden:

• Basierend auf der Link-Layer-Address-Plus-Time (DUID-LLT)

• Basierend auf der Enterprise-Number (DUID-EN)

• Basierend auf der Link-Layer-Adresse (DUID-LL)

Bei DUID-LLT und DUID-LL existiert eine Verknüpfung zwischen der IPv6-Adresse und der Link-Layer-Adresse (normalerweise eine MAC-Adresse) in den Statusinformationen des DHCPv6-Servers. Bei DUID-EN ist es Aufgabe des Administrators, eine solche Verknüpfung herzustellen.

Werden die Adressen aus einem gut identifizierbaren Teil in /64 zugewiesen, dann können die Firewalls dafür sorgen, dass nur Hosts, die DHCPv6 für die Adresskonfiguration verwenden, sich mit Zielen außerhalb des geschützten Netzwerks verbinden können.

Die statische Adresskonfiguration gleicht der statischen Konfiguration bei IPv4. Hier gibt es also auch die gleichen Probleme wie bei IPv4.

Router-Advertisements sind einer der großen Unterschiede zwischen IPv6 und IPv4. IPv4 stellt die Adresse eines Gateways üblicherweise per DHCP oder durch statische Konfiguration zur Verfügung. Bei IPv6 können Router, die am selben Link angeschlossen sind, das Neighbor-Discovery-Protocol für verschiedene Zwecke verwenden. Sie können damit beispielsweise die Präsenz anderer Router entdecken, deren Link-Layer-Adressen herausfinden, Parameter lernen etc. Ein solcher Mechanismus bringt aber auch ein gewisses Risiko mit sich. Die Anzahl der Angriffe, die möglich sind, sobald man an die Stelle des Default-Gateways getreten ist, ist beängstigend.

Router betrachten die Informationen, die sie in Router-Advertisements von anderen Routern erhalten, als bindend, selbst wenn diese Informationen nicht digital signiert oder verschlüsselt sind. Router ändern also betroffene Konfigurationseinstellungen ohne Verifikation. Bösartige Knoten können in den optionalen Feldern des ICMPv6-Extension-Headers fehlerhafte Werte eintragen, beispielsweise ein falsches Präfix oder eine falsche Link-Layer-Adresse. Da legitime Router-Advertisements nicht notwendigerweise Werte für sämtliche Optionen enthalten, stehen die Chancen nicht schlecht, dass die fehlerhaften Werte nicht durch ein nachfolgendes legitimes Router-Advertisement korrigiert werden.

Administratoren sollten sich dieser Situation bewusst sein und Konfigurationen vermeiden, wo solche Advertisements standardmäßig konfiguriert sind. DHCPv6-Systeme können möglicherweise dabei helfen, solche falschen Konfigurationen zu verhindern.

Beginnt ein falscher Router damit, Verkehr umzuleiten, dann wird er wahrscheinlich als „böser Proxy” den Inhalt ausgehender Pakete modifizieren oder als Endknoten in einem Kommunikationsfluss agieren. Diese zwei Formen eines Angriffs lassen sich mit IPSec verhindern. IPSec ist aber keine Option, wenn ein Ende der Kommunikation nicht von vornherein bekannt ist, es sehr viele Peers gibt oder sie sich unterschiedlichen Managementdomänen befinden. Auch hier kann DHCPv6 helfen.