IPv6 - Die grundlegenden Funktionen, Bedrohungen und Maßnahmen

IPv6 - Die grundlegenden Funktionen, Bedrohungen und Maßnahmen IPv6 - Die grundlegenden Funktionen, Bedrohungen und Maßnahmen

13.07.2015 Aufrufe

© Secorvo Security Consulting GmbHbeschaffen sein, dass alle Daten, die für eine Filterentscheidung herangezogen werden, imersten Fragment untergebracht sind.Grundsätzlich könnten an einer Firewall zwei Strategien zum Umgang mit Fragmenten zurAnwendung kommen: Entweder Rekonstruktion an der Firewall mit anschließenderInspektion des gesamten Pakets oder Inspektion nur des ersten Fragments. Casimir Potyrajnennt als jeweilige Vor- und Nachteile einer Rekonstruktion an der Firewall u. a.[Potyraj 2007]:Vorteile· Deep Packet Inspection möglich· Filterentscheidung wird anhand desvollständigen Pakets ermittelt· Interne Nodes sind vor etwaigen Denialof-Service-Angriffendurch unvollständigefragmentierte Pakete geschütztNachteile· Mögliche Denial-of-Service-Angrifferichten sich direkt und konzentriertgegen die Firewall selbst· Gesteigerte Performance-Erwartungenan die Firewall· Ggf. müssen inspizierte Pakete zurWeiterleitung erneut fragmentiertwerdenDarüber hinaus werden verschiedene Empfehlungen angegeben, die vor allemFragmentierung in Kombination mit Tunnelung betreffen.Falls die Firewall nicht gleichzeitig Deep Packet Inspection betreiben soll, dann ist dieFilterung ohne Rekonstruktion vorzuziehen, da· ansonsten eine rekonstruierende Firewall selbst Ziel von Denial-of-Service-Angriffenwerden kann,· die meisten Header-Erweiterungen im gewöhnlichen Betrieb keine Rolle spielen und apriori ausgefiltert werden können,· selbst „exotische“ Kombinationen von Header-Erweiterungen nebst Protokoll-Header desUpper Layer Protocols mühelos innerhalb der minimal garantierten MTU untergebrachtwerden können (siehe die Tabelle oben), sofern kein unnötiger Gebrauch von Paddinggemacht wird.Daher ist davon auszugehen, dass alle für die Filterentscheidung relevanten Informationenim ersten Fragment untergebracht sein können – Pakete, bei denen dies nicht der Fall ist,können verworfen werden.Noch einfacher wäre die Filterentscheidung, wenn alle Fragmente bis auf ggf. das letzteFragment die Größe der Path MTU von der Quelle zum Ziel belegen würden. Denkbar undplausibel wäre alternativ auch eine möglichst gleichmäßige Verteilung des Pakets auf alleFragmente, so dass beispielsweise der Inhalt eines Pakets der Länge 1281 (Payload-Länge1241) auf ein Fragment der Länge 669 (= 40 + 8 + 621) und eines der Länge 668 (= 40 + 8 +620) verteilt würde. Die Strategie zur Aufteilung in Fragmente wird in den einschlägigenRFCs jedoch nicht geregelt. Aus Sicht der Filterung ist die zuerst genannte Vorgehensweisevorzuziehen. Die Praxis wird erst noch zeigen, ob sich eine Regelung hierzu durchsetzenkann.3.5 PrivatsphäreDie Rückkehr des Ende-zu-Ende-Prinzips und die Beseitigung von NAT bei IPv6 haben zueinigen Bedenken hinsichtlich der Privatsphäre der Nutzer geführt. Gleichzeitig wurdenjedoch mit IPv6 die sogenannten Privacy Extensions (PEX) eingeführt. In diesem Abschnittwird für drei unterschiedliche Szenarien die Tauglichkeit von NAT im Vergleich mit PrivacySecorvo White Paper IPv6 Seite 42 von 67WP IPv6 11 Stand 08. Oktober 2013

© Secorvo Security Consulting GmbHExtensions zur Wahrung der Privatsphäre diskutiert, vgl. auch [BVA 2013, Abschnitt 8.5].Dazu ist zunächst zu definieren, was eigentlich Wahrung der Privatsphäre bedeutet.· Das erste Ziel kann darin bestehen, als Host einer End-Site nicht ausfindig gemachtwerden zu können, d. h. ein Dienstanbieter (beispielsweise eine Nachrichtenseite) soll dieNutzungen des Dienstes zu verschiedenen Zeiten von einer bestimmten Site aus nichtmiteinander korrelieren können. Mit anderen Worten, es soll nicht möglich sein,verschiedene Kommunikationsvorgänge einer Site zuzuordnen.· Das zweite Ziel kann darin bestehen, als Host in einer Gruppe anderer Hosts innerhalbeiner Site nicht aufgespürt werden zu können, d. h. ein Dienstanbieter mag zwar dieZugehörigkeit eines Nutzers zu einer Site nachverfolgen, aber nicht, welcher Hostinnerhalb der Site den betreffenden Dienst verwendet. Mit anderen Worten, es soll nichtmöglich sein, zwischen den Hosts einer Site zu differenzieren.· Das dritte Ziel kann darin bestehen, als einzelner mobiler roaming Host nicht verfolgtwerden zu können.Für die Diskussion der nachfolgend diskutierten Szenarien sei zunächst auf einige Aspekteder Adressvergabe bei IPv6 im Vergleich zu IPv4 hingewiesen:· End-Sites bekommen üblicherweise ein festes IPv6-Präfix vom ISP zugewiesen,beispielsweise ein /48- oder ein /56-Präfix. Es ist davon auszugehen, dass allgemeinbekannt sein wird, welche ISPs Präfixe aus welchem Adressbereich und welcher Größean End-Sites vergeben. Somit kann davon ausgegangen werden, dass das Präfix dieEnd-Site eines Nutzers identifiziert. Daran würde auch NAT nichts ändern.· Selbst bei einer Vergabe von dynamischen IPv6-Präfixen an eine Site durch einen ISPwird eine dauerhafte Korrelation von Zugriffen allein auf Grundlage der IP-Adresse nurbedingt verhindert – bei der Verwendung von SLAAC zur Vergabe von IPv6-Adressenkann ein Host über den quasi-eindeutigen Interface-Identifier verfolgt werden. Dasselbegilt, wenn der Interface-Identifier auf andere Weise statisch vergeben wird.· Durch die Vergabe von dynamischen IPv4-Adressen an einen Node durch einen ISP wirddagegen eine dauerhafte Korrelation von Zugriffen allein auf Grundlage der IP-Adresse imAllgemeinen verhindert.3.5.1 Szenario 1 – HeimnutzerIn diesem Szenario betrachten wir einen Nutzer, beispielsweise einen Heimnutzer, der vonseinem ISP ein /56-Präfix zugewiesen bekommt.Wird dem Nutzer über einen längeren Zeitraum dasselbe Präfix zugewiesen, dann kann dieSite des Nutzers innerhalb dieses Zeitraums verfolgt werden. Die Verwendung von PrivacyExtensions verschleiert zwar den einzelnen Host, aber nicht die Site. Selbst eineVerwendung von wechselnden Subnet-IDs bringt keinen Gewinn an Privatsphäre, da die Sitenach wie vor am Präfix zu erkennen ist. Der Einsatz von NAT hilft an dieser Stelle überhauptnicht weiter.Werden Präfix (vom ISP) und Subnet-ID (vom Nutzer) dynamisch vergeben, reicht das alleinjedoch auch nicht aus. Wenn die Interface-IDs statisch vergeben werden, etwa über SLAACoder pseudozufällig über DHCPv6, dann verraten die Interface-IDs die Hosts innerhalb derSite und damit auch die Site an sich.Um eine dauerhafte Korrelation von Zugriffen allein auf Basis der IP-Adresse zu verhindern,müssen sowohl das Präfix als auch die Interface-ID und möglichst auch die Subnet-IDdynamisch vergeben werden.Secorvo White Paper IPv6 Seite 43 von 67WP IPv6 11 Stand 08. Oktober 2013

© Secorvo Security Consulting GmbHbeschaffen sein, dass alle Daten, die für eine Filterentscheidung herangezogen werden, imersten Fragment untergebracht sind.Gr<strong>und</strong>sätzlich könnten an einer Firewall zwei Strategien zum Umgang mit Fragmenten zurAnwendung kommen: Entweder Rekonstruktion an der Firewall mit anschließenderInspektion des gesamten Pakets oder Inspektion nur des ersten Fragments. Casimir Potyrajnennt als jeweilige Vor- <strong>und</strong> Nachteile einer Rekonstruktion an der Firewall u. a.[Potyraj 2007]:Vorteile· Deep Packet Inspection möglich· Filterentscheidung wird anhand desvollständigen Pakets ermittelt· Interne Nodes sind vor etwaigen Denialof-Service-Angriffendurch unvollständigefragmentierte Pakete geschütztNachteile· Mögliche Denial-of-Service-Angrifferichten sich direkt <strong>und</strong> konzentriertgegen die Firewall selbst· Gesteigerte Performance-Erwartungenan die Firewall· Ggf. müssen inspizierte Pakete zurWeiterleitung erneut fragmentiertwerdenDarüber hinaus werden verschiedene Empfehlungen angegeben, die vor allemFragmentierung in Kombination mit Tunnelung betreffen.Falls die Firewall nicht gleichzeitig Deep Packet Inspection betreiben soll, dann ist dieFilterung ohne Rekonstruktion vorzuziehen, da· ansonsten eine rekonstruierende Firewall selbst Ziel von Denial-of-Service-Angriffenwerden kann,· die meisten Header-Erweiterungen im gewöhnlichen Betrieb keine Rolle spielen <strong>und</strong> apriori ausgefiltert werden können,· selbst „exotische“ Kombinationen von Header-Erweiterungen nebst Protokoll-Header desUpper Layer Protocols mühelos innerhalb der minimal garantierten MTU untergebrachtwerden können (siehe die Tabelle oben), sofern kein unnötiger Gebrauch von Paddinggemacht wird.Daher ist davon auszugehen, dass alle für die Filterentscheidung relevanten Informationenim ersten Fragment untergebracht sein können – Pakete, bei denen dies nicht der Fall ist,können verworfen werden.Noch einfacher wäre die Filterentscheidung, wenn alle Fragmente bis auf ggf. das letzteFragment die Größe der Path MTU von der Quelle zum Ziel belegen würden. Denkbar <strong>und</strong>plausibel wäre alternativ auch eine möglichst gleichmäßige Verteilung des Pakets auf alleFragmente, so dass beispielsweise der Inhalt eines Pakets der Länge 1281 (Payload-Länge1241) auf ein Fragment der Länge 669 (= 40 + 8 + 621) <strong>und</strong> eines der Länge 668 (= 40 + 8 +620) verteilt würde. <strong>Die</strong> Strategie zur Aufteilung in Fragmente wird in den einschlägigenRFCs jedoch nicht geregelt. Aus Sicht der Filterung ist die zuerst genannte Vorgehensweisevorzuziehen. <strong>Die</strong> Praxis wird erst noch zeigen, ob sich eine Regelung hierzu durchsetzenkann.3.5 Privatsphäre<strong>Die</strong> Rückkehr des Ende-zu-Ende-Prinzips <strong>und</strong> die Beseitigung von NAT bei <strong>IPv6</strong> haben zueinigen Bedenken hinsichtlich der Privatsphäre der Nutzer geführt. Gleichzeitig wurdenjedoch mit <strong>IPv6</strong> die sogenannten Privacy Extensions (PEX) eingeführt. In diesem Abschnittwird für drei unterschiedliche Szenarien die Tauglichkeit von NAT im Vergleich mit PrivacySecorvo White Paper <strong>IPv6</strong> Seite 42 von 67WP <strong>IPv6</strong> 11 Stand 08. Oktober 2013

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!