{"id":1480,"date":"2014-07-26T01:01:30","date_gmt":"2014-07-25T23:01:30","guid":{"rendered":"http:\/\/blog.patricksauer.net\/?p=1480"},"modified":"2014-07-25T19:06:20","modified_gmt":"2014-07-25T17:06:20","slug":"penetration-testing-von-ipv6-netzwerken","status":"publish","type":"post","link":"https:\/\/security.sauer.ninja\/de\/pentest\/penetration-testing-von-ipv6-netzwerken\/","title":{"rendered":"Penetration Testing von IPv6-Netzwerken"},"content":{"rendered":"<p>Ein gew\u00f6hnliches IPv4-Netzwerk besteht nicht aus sonderlich vielen IP-Adressen. Ein \/24er Block besteht aus 256 Adresse. Selbst bei einem wesentlich gr\u00f6\u00dferem \/22 existieren nur 1.024 Adressen. Auch wenn nicht alle nutzbar sind (Network, Broadcast) bleiben wir einmal bei diesen Zahlen.<\/p>\n<p>Relativ am Anfang eines Penetrationstests einer IT-Infrastruktur bzw. einem Netzwerk steht die Identifizierung der Live-Hosts, also der IP-Adressen, die tats\u00e4chlich einem Host zugewiesen sind. Das kann durch einen kurzen Ping-Sweep passieren oder man ignoriert ICMP und scannt den maximalen Port-Range \u00fcber TCP und UDP. Vergleicht man beide F\u00e4lle anhand eines \/22er-Blocks ergibt das bei einem Ping-Sweep 1.024 zu verschickende Anfragen und bei einem Scan \u00fcber den gesamten Port-Bereich inkl. TCP und UDP bereits 1.024*65.535*2 = 134.215.680 \u2013 \u00fcber 130 Millionen Anfragen, um absolut zuverl\u00e4ssig alle aktiven Hosts in einem \/22 erkennen zu k\u00f6nnen.<\/p>\n<p>Definitiv ist der Scan \u00fcber alle Ports relativ zeitintensiv, aber noch realisierbar. Gehen wir einmal davon aus, dass ein Host jede Anfrage mit CLOSED o.\u00e4. beantwortet und der Scanner nicht in einen Timeout l\u00e4uft. Bei einer angenommenen Netzwerk-Latenz von 1ms (Gigabit-Ethernet) dauert der Scan \u2013 sofern nicht parallelisiert \u2013 ca. 37 Stunden. Wird der Scan um den Faktor 10 parallelisiert, ist er in 3,7 Stunden fertig. Selbst der komplette Scan eines etwas gr\u00f6\u00dferen IPv4-Netzes ist kein gigantisches Problem.<\/p>\n<p>Und dann kam IPv6.<\/p>\n<p>Nachdem der Adressraum bei IPv6 128bit betr\u00e4gt, im Gegensatz zu 32bit bei IPv4, sind die Netze wesentlich gr\u00f6\u00dfer. Gehen wir einmal von einem kleineren \/56 IPv6-Netz aus. Das sind gerade einmal 9.223.372.036.854.775.808 Adressen. Also knapp 10^19 Adressen. Selbst wenn man nun auf einen vollst\u00e4ndigen Scan verzichtet und nur einen Ping-Sweep zur Erkennung der Live-Hosts nutzt, sind das immernoch 10^19 Anfragen, die verschickt werden m\u00fcssen. Nehmen wir an, wir verschicken (unrealistischer Weise) 100.000 Anfragen gleichzeitig, die alle in 1ms beantwortet werden. Wie lange dauert dann nur ein simpler Ping-Sweep \u00fcber ein \/56-Netz? 10^11 Sekunden bzw. 27.777.777 Stunden bzw. 1.157.407 Tage bzw. 3.170 Jahre. Ein Scan \u00fcber ein komplettes \u201ekleines\u201c IPv6-Netz \u2013 unm\u00f6glich!<\/p>\n<p>Es gibt zwar verschiedene statische H\u00e4ufungen, wie Netzwerk-Administratoren IPv6-Adressen vergeben, aber selbst die Ber\u00fccksichtigung beliebter Bestandteile von IPv6-Adressen wie  \u201e:dead:\u201c, \u201e:b00b:\u201c, \u201e:cafe:\u201c oder \u201e:babe:\u201c schr\u00e4nkt die Auswahl nicht zuverl\u00e4ssig genug f\u00fcr einen Penetrationstest ein. <\/p>\n<p>Ein anderer Ansatz ist das Sniffen des gesamten IPv6-Verkehrs \u00fcber Mirror\/Monitoring-Ports an zentralen Core-Switche \u00fcber eine gewisse Dauer. Das setzt nat\u00fcrlich nicht nur die grunds\u00e4tzliche technische M\u00f6glichkeit voraus, sondern auch die Kooperation des Unternehmens. Sofern man einmal betriebliche oder datenschutzrechtliche Bedenken au\u00dfen vor l\u00e4sst \u2013 Datenschutzbeauftragte (Abgreifen von personenbezogenen Daten) und Betriebsr\u00e4te (Achtung m\u00f6gliche Leistungskontrolle) werden das in der Praxis sicherlich zu verhindern wissen. Technisch grunds\u00e4tzlich m\u00f6glich, ob wirklich umsetzbar sei einmal dahingestellt.<\/p>\n<p>Bleibt eigentlich nur noch eine Liste mit IPv6-Adressen von den Administratoren des Zielnetzwerks zu erfragen. Idealerweise wird der Bestand von Hosts und verwendeten IP-Adressen in irgendeiner Datenbank oder Datei gepflegt. In wie weit solch eine Liste vollst\u00e4ndig ist, kann man naturgem\u00e4\u00df von au\u00dfen nicht wirklich beurteilen. Es bleibt nur noch \u00fcbrig, diese Liste mit m\u00f6glichen weiteren IP-Adressen zu erg\u00e4nzen, die man z.B. durch DNS Enumeration o.\u00e4. gewinnen kann.<\/p>\n<p><em>Egal wie, absolut vollst\u00e4ndige Penetrationstests von IPv6-Netzwerken sind fast unm\u00f6glich zu garantieren. Ein Penetrationstests von IPv6-Netzwerken kann vollst\u00e4ndig sein, muss er aber nicht. Das schlimmste daran ist, dass man nicht wissen wird, ob ein Test nun alle Hosts betrachtet hat oder nicht.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ein gew\u00f6hnliches IPv4-Netzwerk besteht nicht aus sonderlich vielen IP-Adressen. Ein \/24er Block besteht aus 256 Adresse. Selbst bei einem wesentlich gr\u00f6\u00dferem \/22 existieren nur 1.024 Adressen. Auch wenn nicht alle nutzbar sind (Network, Broadcast) bleiben wir einmal bei diesen Zahlen. Relativ am Anfang eines Penetrationstests einer IT-Infrastruktur bzw. einem Netzwerk steht die Identifizierung der Live-Hosts, &#8230; <span class=\"more\"><a class=\"more-link\" href=\"https:\/\/security.sauer.ninja\/de\/pentest\/penetration-testing-von-ipv6-netzwerken\/\">[Read more&#8230;]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":{"0":"entry","1":"post","2":"publish","3":"author-psauer","4":"post-1480","6":"format-standard","7":"category-pentest"},"_links":{"self":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts\/1480","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/comments?post=1480"}],"version-history":[{"count":7,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts\/1480\/revisions"}],"predecessor-version":[{"id":1487,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/posts\/1480\/revisions\/1487"}],"wp:attachment":[{"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/media?parent=1480"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/categories?post=1480"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/security.sauer.ninja\/de\/wp-json\/wp\/v2\/tags?post=1480"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}