Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03575.jsonl.gz/1903

Everybody who starts (consciously) integrating IPv6 in their network has to decide how to provision IPv6 addresses, default routes and recursive DNS server (RDNSS) information to all clients.
To make this simple and automated, IPv6 includes SLAAC (StateLess Address Auto Configuration). This is a good thing, but it’s stateless, so you no longer manage your IP address provisioning centrally (as you did with DHCP in IPv4) and thus lose traceability (i.e. which node has which IP at any given time). Moreover, SLAAC supports provisioning of RDNSS information only since RFC 6106 (November 2010), and not everybody supports this. For example, Microsoft doesn’t, and it doesn’t seem to have any intention of changing this.
Many believe this is reason enough to forget about SLAAC – or at least try to – and use DHCP just like in the good old IPv4-only days. Indeed, there is such a thing as DHCPv6, but unfortunately it doesn’t provision default router information, and, once again, not everybody supports it. For example, Android doesn’t, and it doesn’t seem to have any intention of changing this.
This means most of us will end up with a mixture of SLAAC and DHCPv6 (either the stateless or stateful variant), which is not a problem in theory because IPv6 Router Advertisements (the ICMPv6 message type used for SLAAC) have flags for that.
ICMPv6 Type 134 (Router Advertisement) flags:
M – Managed Address Configuration. DHCPv6 is available for IPv6 address allocation.
O – Other Configuration. Other configuration information is available through DHCPv6 (e.g. the RDNSS).
Flags in prefix information option:
A – Address Configuration flag. The prefix can be used for stateless address configuration (SLAAC).
L – On-Link flag. The prefix can be used for on-link determination (other IPv6 addresses with the same prefix are on the same L2 subnet).
But how do implementations behave if the information provided by Router Advertisement conflicts with that from DHCPv6 due to human error, conflicting default settings or an attacker? And how do such conflicts affect network stability and security?
This is what the talk from Enno Rey at the last Tech Talk of the Swiss IPv6 Council in Zurich was about. Enno presented the results of the research he and his team conducted in their IPv6 lab at ERNW in Heidelberg.
Some examples of the findings:
Windows 8.1 configures IPv6 address from DHCPv6, despite the fact that the Management flag (M) in the Router Advertisement is not set.
If both SLAAC and DHCPv6 provide RDNSS information and M/A/O flags are set, Fedora, Centos and OS X configure RDNSS information from both sources, Ubuntu only from the RAs, and Windows only from DHCPv6.
If two routers send RAs with conflicting M/O flags, basically all operating systems behave differently.
When people hear about IPv6-specific security issues, they frequently tend to rate this as an argument in favour of delaying or avoiding IPv6 deployment on their enterprise or campus network. Even without IPv6 being consciously deployed, however, some of the IPv6-related security issues were already introduced to most networks many years ago. The reason for this is simple: IPv6 is implemented in all common operating systems and enabled by default. We introduced hosts with these operating systems on our networks several years ago – be they clients on the office network or servers in a data centre or DMZ.
Since most, if not all, of today’s company networks are IPv6-enabled to a certain degree, they are attackable over IPv6. To make things worse, in contrast to IPv4, IPv6 brings along different kinds of autoconfiguration functionality, which can be misused. Network operators and security people who have neither basic IPv6 experience nor measures in place to detect IPv6-related attacks run a risk, and this risk is permanently increasing as the bad guys have already started to use IPv6. Bad guys are usually early adopters. Continue reading “IPv6 insecurities on “IPv4-only” networks”
Wer in seiner Organisation IPv6 einführt, muss sich darüber Gedanken machen, wie die Adressvergabe für Server und Clients geregelt werden soll. Dabei spielen auch Sicherheits- und Privatsphären-Aspekte eine Rolle. In diesem Beitrag wollen wir dazu die Themen Adress-Autokonfiguration und Privacy Extensions etwas näher betrachten.
SLAAC – Autokonfiguration
Neben den von IPv4 bekannten Möglichkeiten – statische Adresskonfiguration oder DHCP – gibt es für IPv6 zusätzlich den Mechanismus der Adress-Autokonfiguration (RFC 4862: IPv6 Stateless Address Autoconfiguration, SLAAC). Dieser bedarf weder einer manuellen Konfiguration auf dem Client noch einer zentralen Instanz, welche die Adressen zuteilt. Der lokale Teil der IPv6-Adresse (Interface Identifier, IID, 64 Bit) wird dabei lokal auf dem Host gebildet, und zwar gemäss Standard abgeleitet von der MAC-Adresse des Interfaces nach dem Modified EUI-64 Verfahren.
Da die MAC-Adresse in aller Regel gleich bleibt, hat nun der Host – beispielsweise der Laptop eines Geschäftsreisenden – weltweit eine IPv6-Adresse, deren letzten 64 Bit immer konstant bleiben. Dadurch hat man neben den existierenden Tracking-Mechanismen (Cookies, Browser-Fingerprint, etc.) noch ein statisches Datum, mit dem der Client auf Ressourcen zugreift – und damit dauerhaft und weltweit trackbar ist. Ein Problem für die Privatsphäre des Nutzers. Continue reading “IPv6 Adress-Autokonfiguration aus Security-Sicht”
In einem aktuellen Internet-Draft (draft-ietf-opsec-vpn-leakages-02) beschreibt Fernando Gont Gefahren, die von VPN-Software ausgeht, welche nicht IPv6-fähig ist. Eine Zusammenfassung:
Führen Organisationen IPv6 auf ihren Client-Systemen ein, ist die bevorzugte Strategie in der Regel die, dass IPv6-Konnektivität zusätzlich zur bestehenden IPv4-Anbindung hergestellt wird (“Dual Stack”). Wenn diese Clients sich nun per VPN mit dem nächsten Office-Standort verbinden, sei es z.B. vom Home-Office oder Kunden aus, dann sollte die Verbindung über diese VPN-Schicht für eine verschlüsselte Datenübertragung sorgen.
Das Problem ist nun, dass heute nicht alle VPN-Clients IPv6-fähig und für das Dual-Stack-Szenario gerüstet sind. Sie kennen vereinfacht gesagt kein IPv6. Wenn nun eine VPN-Verbindung aufgebaut wird, kümmern sich diese VPN-Clients wie gewohnt um den IPv4-Traffic, z.B. indem sie die Default Route ändern um den Traffic in den VPN-Tunnel zu leiten. IPv6-Traffic wird aber weiterhin über die normalen IPv6-Routen geleitet und bleibt damit von der VPN-Verschlüsselung ausgenommen. Integrität und Vertraulichkeit der möglicherweise sensiblen Daten ist dadurch nicht mehr gewährleistet.
1. Operativen Betrieb absichern – IPv6 ist bereits da!
Als aller erstes sollten Sie das latente Risiko durch existierende Dual-Stack-Rechner in Ihrer IT-Umgebung einschätzen: Alle modernen Betriebssysteme sind IPv6-enabled und können mittels Autokonfiguration “von aussen” konfiguriert werden. Damit stehen einem potenziellen Angreifer einige IPv6-spezifische Attacken zur Verfügung, ohne dass Sie jemals IPv6 bewusst konfiguriert und ausgerollt haben. Auf den Systemen wird durch die Autokonfiguration ausserdem “eine zweite Tür geöffnet”, für die bestehende Sicherungsmechanismen (beispielsweise IP-basierende ACLs) unter Umständen nicht greifen. Continue reading “IPv6 für (Security-)Manager – Teil 4: Loslegen, aber sicher!”
Beiden Veranstaltungen gemein waren eine hohe Dichte an hochkarätigen Speakern, die nicht – wie vielleicht befürchtet – die letztjährigen Talks wiederaufbereiteten, sondern viel Neues zu berichten hatten. Beiden Veranstaltungen gemein war auch, dass sie in Kinosälen stattfanden. Mit riesigen Leinwänden für die Präsentationen und gemütlichen Sesseln anstelle von Tageslicht und der üblichen Konferenzmöbel.
Beide Konferenzen boten sowohl reichlich technisch versierte Vorträge, als auch genügend Stoff zum Nachdenken fürs IT-Management. Verschiedene parallele Tracks sorgten dabei für eine breite Auswahl.
Im vorigen Teil dieser Reihe haben wir uns das Big Picture der IPv6-Integration angeschaut. In diesem dritten Teil geht es nun darum, welche Treiber für die Integration von IPv6 potenziell bestehen. Diese Übersicht kann Ihnen als Basis dienen, um sich ein Bild zu machen, wie die individuelle Situation in Ihrer Organisation aussieht.
Im Rahmen einer neuen Tech-Event-Reihe, die das Swiss IPv6 Council in Kooperation mit Digicomp durchführt, hatte ich am vergangenen Montag die Gelegenheit, das Thema “IPv6 Security und Hacking” vorzustellen. Mit rund 70 Teilnehmern stiess auch diese zweite Veranstaltung der Reihe auf reges Interesse.
Im ersten Teil dieser Reihe zum Thema IPv6 ging es darum, warum IPv6 ein Management-Thema ist: Die Auswirkungen von IPv6 auf Ihre IT-Organisation sind vielfältig. Für eine sowohl kosteneffiziente als auch sichere Integration von IPv6 in die eigene Organisation ist es erforderlich, dass Sie sich einen Überblick in Form einer Bestandsaufnahme verschaffen. Auf dieser Basis kann eine individuelle IPv6-Integrationsstrategie entwickelt werden, inklusive einer Roadmap, die interne und externe Abhängigkeiten mit berücksichtigt. Beispiele für solche Abhängigkeiten sind bestehende Investitions- und Entwicklungs-Zyklen, aber auch die IPv6-Readiness der IT-Security.
Das folgende “IPv6 – Big Picture” soll eine Orientierung über betroffene Bereiche und notwendige Aktivitäten geben:
In den horizontalen Feldern sind die verschiedenen Bereiche der IT aufgeführt, die irgendwann im Laufe der IPv6-Integration betroffen sind. Die senkrechten Felder enthalten Aktivitäten, die innerhalb der IPv6-Integration anstehen. Im einzelnen:
Über IPv6 – dem Nachfolger des Internet-Protokoll-Standards IPv4 – wird nun seit 15 Jahren gesprochen. In dieser Zeit ist das Thema jedoch ohne grössere Auswirkungen auf die produktive IT der meisten Organisationen geblieben. Daher wundert es nicht, wenn sich viele IT-Manager daran gewöhnt haben, IPv6 entweder zu ignorieren, oder als eine niedrigpriorisierte und vielleicht auch eher technische Angelegenheit einzuordnen.
Auch wenn dieser Umgang mit dem Thema in der Vergangenheit oft ohne grössere Risiken möglich war, kann man heute davon ausgehen, dass dies für die Zukunft nicht mehr in gleichem Masse gilt. Es lohnt sich also, einen frischen Blick auf den “Fall IPv6” zu werfen: