IPv6 hat mindestens genauso viele Sicherheitsprobleme wie das altbekannte IPv4

Die Sicherheit von IPv4 entspricht ungefähr der Sicherheit von IPv6.  Warum erwarten wir also mehr von IPv6?

Beim Einarbeiten in das IPv6-Protokoll ist man fasziniert davon, wie sehr sich das IPv6-Neighbor-Discovery-Protocol (NDP) (siehe RFC 4861) vom IPv4-Address-Resolution-Protocol (ARP) unterscheidet. ARP ist einer der zentralen Elemente beim Verbindungsaufbau. So verwendet hierfür IPv4 den Broadcast- und IPv6 den Multicast-Mechanismus. Auch interagiert NDP mit dem ICMPv6-Protokoll als auch mit dem Multicast-Listener-Discovery (MLD). IPv6 NDP verfügt über weitaus mehr Funktionen als nur dem Binden von IPv6-Adressen und MAC-Adressen lokaler Knoten. IPv6-NDP ist der entscheidende Mechanismus, wie Knoten ihre IPv6-Adressen erhalten, dem Netz beitreten und ihre Pakete aus dem Netz heraus übermitteln.

Zu Beginn des Erlernen des IPv6- und des NDP-Protokolls wird man sehr schnell mit den verschiedenen Sicherheitsproblemen und Angriffen konfrontiert, die die Schwachstellen des NDP-Protokolls ausnutzen können. Ohne große Probleme kann man die sogenannten Router-Advertisement (RA)-Nachrichten fälschen, um Hosts dazu zu bringen, die IPv6-Mechanismen zu aktivieren, ein bestehendes IPv6-Netzwerk neu zu nummerieren oder sogar einen Man-In-The-Middle (MITM)-Angriff durchzuführen. Es ist auch möglich, Neighbor-Solicitation (NS)- und Neighbor-Advertisement (NA)-Nachrichten zu fälschen, um link-local Nodes zu verwirren und Nachbar-Caches zu beschädigen. Diese Probleme wurden in den „Operational Neighbor Discovery Problems“ (siehe RFC 6583) ausführlich dokumentiert. Diese Probleme sind daher alles andere als neu und die IT-Industrie kennt die  NDP-Sicherheitslücken seit fast 15 Jahren.

Das stellt einige Netzwerk- und Sicherheitsadministratoren vor ein Problem und diese  erwägen, eine IPv6-Einführung wegen dieser Sicherheitsprobleme mit NDP zu stoppen. Natürlich ist der Panikmodus der falsche Weg! Es gilt sich über die Details von IPv6- und NDP- Sicherheitsmaßnahmen genau zu informieren und anschließend die Schwachstellen zu beseitigen.

Es gilt, ein Angreifer kann die Schwachstellen in NDP nur dann ausnutzen, wenn dieser direkt mit dem betreffenden Layer-2-Netzwerksegment verbunden ist oder die Kontrolle über mindestens einen Computer im LAN übernommen hat. Das setzt jedoch voraus, dass sich der Angreifer bereits im internen Netzwerk befindet. Normalerweise möchte ein Angreifer, der sich Zugang zu einem internen Netzwerk verschafft hat, nicht auf seine Anwesenheit aufmerksam machen, während dieser Erkundungen durchführt und auf andere Systeme zugreift. Die Motivation für einen Angreifer, DoS-Angriffe oder Manöver (wie Rogue-RA-Angriffe) durchzuführen, ist gering, da diese Verhaltensweisen leicht zu erkennen sind und Spuren der Anwesenheit des Angreifers hinterlassen.

Als Reaktion auf diese NDP-Schwachstellen wurde von den Herstellern und den Protokollgremien viel Arbeit geleistet, um die Nutzung von IPv6-NDP abzusichern. Das IETF entwickelte hierfür das Secure-Neighbor-Discovery (SEND) -Protokoll (siehe 3971). Viele Hersteller von drahtgebundenen und drahtlosen Netzwerken haben diese Funktionen bereits in ihre Produkte integriert, um diese Arten von NDP-Angriffen zu erkennen und zu blockieren. Cisco bezeichnet diese Verbesserungen als die First-Hop-Security (FHS)-Maßnahmen (siehe https://www.cisco.com/c/en/us/products/ios-nx-os-software/ipv6-first-hop-security-fhs/index.html?dtid=osscdc000283&linkclickid=srch), die in Switches, Routern und Wireless LAN-Controllern implementiert sind, um IPv6-Knoten zu sichern. Die Router-Advertisements (RA) sind eine wichtiger Funktion, um als IPv6-fähiger Knoten einem IPv6-Netzwerk beitreten zu können. Gleichzeitig ist diese Funktion auch eine bekannte Schwachstelle von IPv6. Die IETF hat im RFC 6104 (Titel: „Rogue IPv6 Router Advertisement Problem Statement“ beschrieben, wie ein Angreifer gefälschte RA-Nachrichten erzeugen kann, um ein LAN zu stören oder um in eine MITM-Position zu gelangen. Als Reaktion auf dieses Problem hat die IETF die Lösung in den IPv6-Router-Advertisement-Guards (RA Guard) (siehe RFC 6105) erarbeitet, einer Technik in Ethernet-Switches und anderen Netzwerkkomponenten, die nur die Weiterleitung legitimer RAs vom lokalen IPv6-Router zulässt. RA-Guard blockiert alle anderen RA-Pakete, die von einem nachgeschalteten Knoten im LAN stammen. Die IETF hat darüber hinaus ihre Arbeit zu diesem Thema fortgesetzt und die „Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)“ (siehe RFC 7113) veröffentlicht. Weitere Verbesserungen wurden in Form einer Begrenzung der Fragmentierung von NDP-Nachrichten erzielt, die in „Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery“ (siehe RFC 6980) beschrieben wurde. Die gleiche Technik kann von Cable Modems, Wireless LAN Controllern oder einfach als Softwareanwendung auf einem Knoten im LAN umgesetzt werden. Inzwischen gibt es viele Software-Tools, die dabei helfen können, unberechtigte RA-Nachrichten zu erkennen und NDP-Probleme aufzudecken. Zu diesen Tools gehören NDPMon (https://sourceforge.net/projects/ndpmon/), ramond (https://ramond.sourceforge.net), Kame rafixd (https://github.com/kame/kame/tree/master/kame/kame/rafixd), 6Guard (https://github.com/chenjj/ipv6-attack-detector/ ) und addrwatch (https://github.com/fln/addrwatch). Mit Hilfe dieser Werkzeuge haben Unternehmen die Möglichkeit, gefälschte NDP- und RA-Nachrichten im LAN zu überwachen und zu erkennen. Bei manchen Netzwerken herrscht der Eindruck vor, dass IPv6- von Natur aus sicherer sind als IPv4-Netze. Das hat damit zu tun, dass IPsec von Beginn an in das IPv6-Konzept integriert wurde  Die folgenden optionalen Extension-Header wurden von Beginn an unterstützt: Authentication Headers (AH) und Encapsulating Security Payload (ESP). Die Aufnahme von IPsec in die Protokollspezifikation hat viele Nutzer zu der Annahme verleitet, dass alle IPv6-Kommunikationströme automatisch IPsec verwenden müssen, was nicht der Fall ist. IPsec wurde auch in Pv4 integriert, aber aufgrund der umfangreichen Verwendung von NAT in IPv4-Netzen wird AH jedoch nicht so häufig verwendet. Stattdessen wird eher ESP mit ESP-HMAC und NAT-Traversal verwendet. Aus diesem Grund wird oft argumentiert, dass IPsec-Verbindungen, die sowohl AH als auch ESP mit IPv6 und globalen Adressen verwenden, sicherer sind als IPsec mit IPv4, ESP-only und NAT. In der Praxis werden die IPv6-Header-Optionen oftmals nicht genutzt. Sowohl IPv4 als auch IPv6 sind von ihrem Ursprung her nicht dazu gedacht, einen sicheren Transportdienst auf der Netzwerkschicht bereitzustellen. Die Sicherheit wird in der Regel den unteren Schichten oder den oberen Schichten des OSI-Modells überlassen. Die Sicherheit von IPv4 und IPv6 ist gleichwertig und sollte gleichermaßen gesichert werden. Ein versierter Angreifer wird versuchen, das am wenigsten geschützte Protokoll auszunutzen.  as schwächste Glied in der Kette ist dasjenige, das am ehesten zu knacken ist. Bei gleichen Voraussetzungen wird der Angreifer das Protokoll angreifen, das nicht ausreichend geschützt ist. Während der Fokus oftmals auf auf der Verbesserung der Sicherheit von IPv6 liegt, sollten wir nicht vergessen, dass es auch wichtig ist, IPv4 zu sichern. Tatsächlich ist die Sicherung von IPv4 wahrscheinlich noch dringender, da es noch immer das meist genutzte Protokoll ist. Das Address Resolution Protocol (ARP) von IPv4 weist ähnliche Schwachstellen auf. Das ARP-Spoofing kann beispielsweise dazu verwendet werden, um ein lokales LAN zu sabotieren, einen MITM-Angriff durchzuführen, eine Switch-CAM-Tabelle zu überlasten und Datenverkehr auszuspähen sowie Knoten zu verwirren und den Verkehrsfluss zu unterbrechen. Auch bei diesen Angriffen wird vorausgesetzt, dass der Angreifer bereits im Netz befindet oder bereits einen Computer im lokalen Segment kompromittiert hat. Es ist eine verblüffende Tatsache, dass die meisten Unternehmen keine Schritte zur Sicherung ihrer IPv4-ARP-Nutzung unternommen haben. Es gibt mehrere IPv4-LAN-Sicherheitstechniken, die jedoch nicht weit verbreitet sind. Beispielsweise verwenden die meisten IPv4-Netzwerke keine dynamische ARP-Inspektion (DAI) als Methode zur Erkennung, Unterbindung oder Ratenbegrenzung von ARP-Angriffen. DAI ist auf herkömmlichen Cisco-Switchs verfügbar. DHCP-Snooping ist eine Methode zur Erkennung und Unterbindung von gekaperten DHCP-Servern, aber nur in wenige Netzwerken wird  diese Funktion genutzt. IP Source Guard ist eine weitere Technik, die in Verbindung mit DHCP-Snooping genutzt werden kann, um zu verhindern, dass Knoten Datenverkehr von einer anderen Adresse als der vom legitimen DHCP-Server übermittelt bekommen. Auch nutzten nur wenige Unternehmen das Unicast Reverse Path Forwarding (RPF) in ihren IPv4-Netzwerken. Dieser Mechanismus ist im RFC 3704 beschrieben und funktioniert für IPv4- und IPv6-Netzwerke gleichermaßen. Nutzt man Unicast RPF für IPv6 dann sollte man diese Schutzfunktion auch auf IPv4, ausweiten. Es gibt auch mehrere Sicherheitstechniken für LAN-Switches, die auf Netzwerke mit IPv4 oder IPv6 angewendet werden können. Der Vorteil dieser Methoden besteht darin, dass man die Sicherheit für beide Protokollwelten gleichzeitig gewährleisten kann. Mit Private VLANs kann ein LAN-Segment abgeschottet werden, das zusätzlichen Schutz benötigt.  Der Standard IEEE 802.1X kann Knoten, die einem Netzwerk beitreten, mit dem Extensible Authentication Protocol (EAP) authentifizieren und den Knoten dem richtigen VLAN zuweisen oder die Kommunikation des Knotens auf andere Weise einschränken. Die 802.1AE MACsec Spezifikation bietet Methoden zur Authentifizierung, Autorisierung und Vertraulichkeit der Kommunikation in einem LAN.

Fazit

Mathias Hein, Consultant, Buchautor, Redakteur

Kein Protokoll ist frei von Fehlern und IPv6 hat mindestens genauso viele Probleme wie das altbekannte IPv4. Sobald man die Probleme kennt, kann man eine Strategie entwickeln, um die Protokolle zu schützen. Bei der Einführung von IPv6 in den kommenden Jahren sollten die verfügbaren Techniken zur Sicherung von NDP- und RA-Nachrichten genutzt werden. Gleichzeitig sollten auch die verbleibenden IPv4-Netzwerke abgesichert werden, damit für beide Protokollvarianten der gleiche Schutz besteht.

Mathias Hein, Consultant