Geolokalisation und Verifikation von IP-Adressen

Transkript

1 Bachelorarbeit HT 2011 Geolokalisation und Verifikation von IP-Adressen Studiengang Wirtschaftsinformatik erstellt und vorgelegt von: Lars Stiemert <Matrikelnummer: > Kay Gottschalk <Matrikelnummer: > 6. Februar 2012 Kontakt: Aufgabenstellung und Betreuung: Prof. Dr. G. Dreo Rodosek Dr. Dipl.-Inf. (univ.) Robert Koch Kontakt Studenten: Kay Gottschalk Lars Stiemert Werner-Heisenberg-Weg Neubiberg

2 Bachelorarbeit HT 2011 Seite ii

3 Erklärung Wir versichern hiermit, dass wir die vorliegende Arbeit selbständig und ohne unzulässige Hilfe Dritter und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt haben. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Neubiberg, den 6. Februar 2012 Bachelorarbeit HT 2011 Seite iii

4 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einordnung 4 2 Geolokalisationsverfahren Existente Verfahren und Funktionsweisen im Überblick IP2Geo CBG und TBG Octant DNS LOC Resource Record Netgeo Whois Geoservice-Anbieter Bewertung und Fazit Bewertung hinsichtlich Genauigkeit, Verfälschung und Manipulation Fazit Angriffsvektoren Verfahren im Überblick Reconnaissance - Footprinting Enumeration Ausgewählte Techniken am Beispiel von Nmap Konzepte zu relevanten Ansätzen Vorüberlegung Relevante Lokalisationsstrategien Auswertung von Geo-Datenbanken Analyse von Full-Qualified Domain Names Abfrage und Analyse der RIR-Datenbestände Auslesen DNS LOC RR Der Wichtungsalgorithmus Der Algorithmus und seine Komponenten Bachelorarbeit HT 2011 Seite iv

5 Inhaltsverzeichnis 5.2 Mögliche Fehlerquellen IPTroll Programmmodi Anpassungen des Algorithmus IPTroll im Überblick Gesamtüberblick Die Konfigurationsdatei Initialisierung der Datenbanken Update der Datenbanken Der reguläre Modus Lokalisierung im regulären Modus Ausführung des Routetracing Bekannte Schwächen Evaluation Das Testfeld Testablauf Evaluationsresultat Paranoider Modus Regulärer Modus Deutung der Ergebnisse Fazit und Ausblick Abschließendes Fazit Ausblick A GeoPing-Algorithmus 93 B GeoCluster-Algorithmus 95 C GeoTrack-Algorithmus 97 Literaturverzeichnis 99 Bachelorarbeit HT 2011 Seite v

6 Abbildungsverzeichnis Abbildungsverzeichnis 2.1 Funktionsweise GeoPing Funktionsweise GeoPing - Latenzvektor GeoCluster - Erstellen der (IP, P osition) T upel GeoCluster - Aufstellen von Clustern Multilateration Octant - Bézier Kurven Octant - Set von Bézier Kurven Aufbau LOC Resource Record gemäß RFC Geografische Verantwortung der fünf Regional Internet Registries Geolokalisation mittels webbasierender Abfrage via HostIP Beispiel für Lokalisationsresultate bei fehlerhaften Messungen GeoCluster - Subclustering nicht möglich Phasen eines Penetration Test gemäß EC-Council Vergleich klassische Traceroute-Varianten und Paris Traceroute Zusammenfassung der Kerneigenschaften des Wichtungsalgorithmus Beispiel eines Virtual Private Network Programmablaufplan des Proof-of-Concept Programmablaufplan der Konfigurationsdatei Programmablaufplan zur Initialisierung der Datenbanken Programmablaufplan zum Update der Datenbanken Programmablaufplan des regulären Modus Programmablaufplan zur Lokalisierung im regulären Modus Programmablaufplan zur Ausführung des Routetracing Bachelorarbeit HT 2011 Seite vi

7 Listings Listings 2.1 Parsing Beispiel Traceroute auf vangogh.cs.berkeley.edu Abfrage DNS LOC Resource Record am Beispiel der Domain caida.org Whois-Abfrage auf ( ) Nutzung der Perl-API zur Abfrage von MaxMind Datenbeständen Nutzerspezifische Implementierung aus dem IPTroll Beispiel für Probleme bei der Analyse von FQDN (Pattern-Matching) Beispiel für Probleme bei der Analyse von FQDN (Firewall) Nutzbare Informationen aus HTML-Quelltexten Ausgewählte Verfahren am Beispiel von Nmap Identifizierung des primären Nameservers mittels Abfrage des Start of Authority Record Abfrage DNS LOC Resource Record mittels DiG und QUERY-LOC Download und Initialisierung eines Updates am Beispiel des Anbieters HostIP Ermitteln eines Archivnamens durch reguläre Ausdrücke am Beispiel von MaxMind Aufbau einer VPN -Verbindung mittels OpenVPN und Abbruchbedingung Multiples Routetracing mit Speicherung der Ergebnisse in externen Dateien sowie Kürzen von Leerzeilen Bachelorarbeit HT 2011 Seite vii

8 Verzeichnis der Algorithmen Verzeichnis der Algorithmen 4.1 Anwendung von Geo-Datenbanken Analyse von FQDN (Teil 1) Analyse von FQDN (Teil 2) Abfrage und Analyse der RIR-Datenbestände mittels Whois Auslesen LOC Resource Record A.1 GeoPing-Algorithmus B.1 Hinweise zu GeoCluster-Algorithmus B.2 GeoCluster-Algorithmus C.1 GeoTrack-Algorithmus Bachelorarbeit HT 2011 Seite viii

9 Tabellenverzeichnis Tabellenverzeichnis 2.1 Übersicht der vorgestellten Geolokalisationsverfahren Übersicht der Anzahl an Datensätzen der einzelnen Geo-Datenbanken Codeüberschneidungen am Beispiel Frankfurt am Main Wichtungsalgorithmus - Einflussnahme der verschiedenen Komponenten Codedatenbanken des IPTroll - Anzahl Datensätze Evaluation - Anzahl Datensätze und deren prozentuale Verteilung Evaluation des paranoiden Modus auf Länderebene Evaluation des paranoiden Modus auf Stadtebene Evaluation des regulären Modus auf Länderebene Evaluation des regulären Modus auf Stadtebene Zusammenfassung der Ergebnisse Bachelorarbeit HT 2011 Seite ix

10 Abkürzungsverzeichnis AfriNIC African Network Information Centre API Application Programming Interface APNIC Asia-Pacific Network Information Centre ARIN American Registry for Internet Numbers AS Autonomous System BASH Bourne Again Shell BGP Border Gateway Protocol CAIDA Cooperative Association for Internet Data Analysis CBG Constraint Based Geolocation CDN Content Delivery Networks DFN Deutsches Forschungsnetz DNS Domain Name System DSL Digital Subscriber Line FQDN Fully Qualified Domain Name GPS Global Positioning System IATA International Air Transport Asscociation IP Internet Protocol ISO Internationalen Organisation für Normung ISP Internet Service Provider ITDK Macroscopic Internet Topology Data Kit LACNIC Latin American and Caribbean Internet Addresses Registry NSE Nmap Scripting Engine PAP Programmablaufplan RFC Request for Comments RIPE NCC Réseaux IP Européens Network Coordination Centre RIR, NIR, LIR Regional-, National-, Local Internet Registry RTT Round Trip Time SOA Start of Authority Record TBG Topology Based Geolocation UMTS Universal Mobile Telecommunications System VOR Very high frequency Omnidirectional Radio range Bachelorarbeit HT 2011 Seite x

11 Vorwort Autoren: Lars Stiemert und Kay Gottschalk Aufgabenstellung Basierend auf den bereits bestehenden Arbeiten zum Themenfeld der Lokalisation von IP-Adressen (Studienprojekt IP-Lokalisierung [66] sowie der Seminararbeit Geolokalisation - Verfahren und Methoden [69]) soll ein erweitertes Konzept zur Geolokalisation und Verifikation von IP-Adressen konzipiert und prototypisch implementiert werden. Ziel ist die Konzeptionierung eines Verfahrens zur Geolokalisation von IP-Adressen unter Berücksichtigung der erforderlichen Genauigkeit sowie deren möglichen Detektierbarkeit. Ein Schwerpunkt soll hierbei die Identifizierung von aktiven Verfahren sein, welche in der Lage sind unter Nutzung geeigneter Angriffsvektoren eine möglichst umfassende Informationsbasis bei gleichzeitiger Minimierung der detektierbaren Aspekte bereitzustellen. Hierbei ist eine Geolokalisation von Adressen durchzuführen, wobei die erforderliche Mindestgenauigkeit sowie eine Policy bezüglich der Aggressivität des Detektionsvorgangs im Sinne der Detektierbarkeit von außen angegeben können werden soll. Folgende Punkte sind unter anderem zu berücksichtigen: Konzeptionierung von aktiven Lokalisationsverfahren zur Geolokalisation von IP- Adressen. Konzeptionierung und Entwicklung eines Algorithmus zur Selektion und Kombination der zuvor entwickelten passiven und aktiven Lokalisationsverfahren. Entwicklung eines Algorithmus zur Gewichtung und Bewertung der erzielten Ergebnisse. Da die Informationen, welche aus passiven Quellen gewonnen werden, bewusst fehlerhaft oder auch im Rahmen von großen Firmen mit mehreren Standorten lediglich zentral angegeben sein können, kann sich dies verfälschend auf das Ergebnis auswirken. Es muss Bachelorarbeit HT 2011 Seite 1

12 folglich versucht werden, entsprechende fehlerhafte beziehungsweise manipulierte Ergebnisse zu identifizieren. Hierfür erfolgt eine Analyse und Bewertung von Verfahren zur Verschleierung der Position einer IP-Adresse. Bewertung der für die Geolokalisation genutzten Verfahren bezüglich ihrer Anfälligkeit gegen Manipulation und Verfälschung. Die prototypische Implementierung ist für die Ausführung auf einer Kommandozeile (beispielsweise bash, csh, sh) zu konzipieren und so zu gestalten, dass eine Nutzung von Pipes ermöglicht wird. Anhand von IP-Adressen mit bekannten, verifizierten Positionen ist die Genauigkeit der gefundenen Verfahren und Algorithmen zu analysieren und zu bewerten. Einleitung Hinweis Die vorliegende Arbeit ist ein gemeinsames Projekt von Kay Gottschalk und Lars Stiemert in Kooperation mit dem Institut für Technische Informatik der Universität der Bundeswehr München. Um der aktuell gültigen Fachprüfungsordnung [112] gerecht zu werden, ist zu Beginn jedes relevanten Kapitels respektive Abschnitts ein Vermerk (Autor: [...]) zum Urheber dessen angeführt. Den Rahmen dieser Bachelorthesis bildet die Problemstellung der Zuordnung einer, mittels logischer Adresse 1, eindeutig identifizierbaren netzfähigen Entität zu einem geografischen Standort. Das Mapping ist hierbei durch die unterschiedliche Ausprägung der Granularität gekennzeichnet. Dies bedeutet, dass sich der tatsächliche Ort der gesuchten Entität entweder durch eine allgemeine Zuordnung wie Staat und Region oder durch akkurate Angaben zur Stadt bis hin zu präzisen Längen- und Breitengradangaben definiert [69, 13]. Die Granularität der Lokalisation hängt vom verfolgten Ziel der lokalisierenden Institution ab. Beispielsweise genügt für gezielte und automatisierte Werbeeinblendungen die grobe Allokation der IP-Adresse auf Landes- beziehungsweise regionaler Ebene, während für den Einsatz im Rahmen der Strafverfolgung eine möglichst genaue Lokalisation anzustreben ist [69, 66]. Ein System, dass diese Anforderungen erfüllen könnte, wäre vergleichbar mit dem Global Positioning System für mobile Endgeräte [37]. Im Verlauf der Arbeit wird die Konzeptionierung und Entwicklung eines Proof-of-Concept 2 namens IPTroll zur Lokalisation von IP-Adressen dokumentiert. Dazu werden nach der Einordnung der Bachelorthesis ausgewählte Methoden und Techniken zur Geolokalisation von netzfähigen Endgeräten vorgestellt und anschließend einer allgemeinen Bewer- 1 Im Rahmen der Arbeit werden nur IP-Adressen betrachtet. 2 Machbarkeitsnachweis, durch den die Durchführbarkeit eines Konzeptes belegt werden soll. Bachelorarbeit HT 2011 Seite 2

13 tung hinsichtlich Manipulation und Verfälschung unterzogen. Zweck ist es, einen allgemeinen Überblick über bekannte Verfahren zu geben, um so den Leser für die existenten Möglichkeiten zu sensibilisieren. Das folgende Kapitel gewährt einen kurzen Syllabus über mögliche Angriffsvektoren, ableitbare Informationen sowie die konkrete Nutzung einzelner Methoden im Kontext der Aufgabenstellung. Darauf aufbauend werden im weiteren Verlauf die im zu entwickelnden Proof-of-Concept eingesetzten Verfahren unter Bezugnahme auf ausgewählte einzusetzende Applikationen konzeptioniert. Anschließend erfolgt eine detaillierte Betrachtung des genutzten Wichtungsalgorithmus und dessen Komponenten, um darauf aufbauend den entwickelten Proof-of-Concept im Detail zu beleuchten. Hierbei wird auf die Funktionsweise, verschiedene Modi sowie damit verbundene Anpassungen des Wichtungsalgorithmus und bekannte Schwächen eingegangen. Bevor die Arbeit mit einem kurzes Resümee schließt, wird auf Basis zur Verfügung stehender IP-Adressen das entwickelte Gesamtkonzept hinsichtlich Genauigkeit und auftretender Probleme analysiert und bewertet. Danksagung Die folgenden Zeilen sind all denen gewidmet, die uns in den letzten Monaten unterstützt und die vorliegende Arbeit erst ermöglicht haben. Wir danken in erster Linie unserem Projektbetreuer Doktor Diplom Informatiker Robert Koch sowie der Professur für Kommunikationssysteme und Internet-Dienste unter der Leitung von Professor Doktor Gabi Dreo Rodosek für die Unterstützung und stetige Bereitschaft, uns bei Problemen zur Seite zu stehen. Weiterhin sind wir all unseren Kontakte zu Dank verpflichtet, welche uns mit ihrem Fachwissen zur Seite standen und uns beraten haben. Hier sei vor allem Marc Ruef (IT- Security Consultant, Scip AG [102]) mit seiner Expertise im Bereich Penetration Testing und IT-Security erwähnt. Besonderer Dank gilt Holger Engelmann (IT Berater / Lufthansa Systems AS [72]) und Michael Groh (Student der Informatik an der Hochschule für Angewandte Wissenschaften Ingolstadt [49]) für die Bereitstellung von Virtual Private Network Zugängen und Produktivumgebungen, ohne deren Hilfe verschiedene Modi des IPTroll sowie Tests derer nur schwer realisierbar gewesen wären. Abschließend erwähnt sei Dimo Doychev, der uns bereitwillig Teile vom Grundgerüst des verwendeteten LaTeX-Templates zur Verfügung gestellt hat. Bachelorarbeit HT 2011 Seite 3

14 KAPITEL 1. EINORDNUNG Kapitel 1 Einordnung Autor: Lars Stiemert [...] IP-Geography Mapping [...] Why is this hard? [...] IP address does not inherently indicate location [...] [90] Wozu wird ein Service zur Geolokalisation 1 benötigt und warum ist die Entwicklung eines solchen so kompliziert? Eine internetfähige Entität benötigt zwar eine Form der logischen Adressierung, aber keine Informationen über die geografische Lage des Kommunikationspartners. Allerdings ist diese Form der Interaktion für Menschen ungeeignet, da die zwischenmenschliche Kommunikation auf physikalischen Vorgängen und Objekten beruht [25, 69]. Das weltweite Internet mit seiner Fülle an Nutzungsmöglichkeiten und Informationen stellt heutzutage einen wesentlichen Bestandteil des alltäglichen Lebens dar. Im Rahmen der technischen Evolution der letzten Jahrzehnte nahm die Komplexität und Ausdehnung dieses dezentralen Netzes ein Vielfaches seiner ursprünglichen Größe an und tangierte dabei verschiedenste technologische sowie soziale Aspekte. Es beeinflusste nicht nur die Kommunikationstechnologie als solches, sondern auch einen erheblichen Teil des sozialen Gefüges [9, 91]. Das Internet des 21. Jahrhunderts ist allgegenwärtig und durchdringt alltägliche Aufgaben, sei es die Kommunikation mittels , Chat oder Internettelefonie oder der einfache Abruf des Wetterberichts. Viele dieser Anwendungen benötigen geografische Informationen, um die angestrebte Dienstleistung bereitzustellen oder einen verbesserten und nutzerorientierten Service anbieten zu können. 1 Geolokalisation bezeichnet die Zuordnung von logischen Adressen zu physikalischen Standorten. Bachelorarbeit HT 2011 Seite 4

15 KAPITEL 1. EINORDNUNG Da der Nutzung des Internets kaum Grenzen gesetzt sind, bietet sich auch die Möglichkeit illegaler Aktivitäten unter dem Deckmantel vermeintlicher Anonymität. For example, a computer attack could originate in China, be launched from Singapore through a computer in Alabama (yes, there are some there), and exploit a system in England. Whose laws take precedence? Who is liable for the attack? How much culpability do the carriers hold? Who will prosecute? [76, Seite 15] Unter Verwendung vom akkuraten Methoden zur Geolokalisation ist es Strafverfolgungsbehörden wie dem DHS cyber security center [29] möglich, Kriminelle zu identifizieren oder zumindest deren Herkunft soweit einzugrenzen, um die Voraussetzungen für eine weitere Strafverfolgung zu schaffen. Aufgrund der Abhängigkeit der Strafverfolgung von den jeweiligen rechtlichen Bestimmung der Länder [23] ist eine möglichst genaue Lokalisation der Täter und Tatorte eine grundlegende Voraussetzung für ein weiteres Vorgehen. Neben der Judikative sind auch Behörden der Regierung an einer stetigen Weiterentwicklung dieser Verfahren interessiert. Im Rahmen der elektronischen Kampfführung oder auch Cyberwar rücken kritische Infrastrukturen und Kontrollmechanismen industrieller Anlagen zunehmend in den Mittelpunkt von IT-Operationen. Weitere Einsatzzwecke sind die Regulierung von IT-basierenden Exporten, zum Beispiel im Bereich Kryptografie [36, 73], staatenübergreifenden sozialpolitischen Kampagnen [111] sowie der Zensur von Inhalten [104]. Automatisierte Geolokalisation von IP-Adressen ist zudem ein fundamentaler Bestandteil von Location-aware applications 2, beispielsweise zur zielgerichteten Präsentation von Werbung, Nachrichten oder sonstiger Inhalte in einer zuvor automatisch bestimmten Sprache [63]. Diese Verfahren sind folglich aus ökonomischen und wirtschaftlichen Überlegungen nicht mehr wegzudenken, da der Herkunftsort des Nutzers einen der wichtigsten Faktoren im Product Promotion Placement darstellt [24]. Internet Service Provider (ISP) als auch Betreiber von Content Delivery Networks unterstützen Mechanismen zur Geolokalisation bei Herausforderungen und Problemen im Bereich regelbasierendem Routing, Load- und Cloudbalancing 3 [20] und der Preisbildungspolitik [100]. When your packets travel through the Internet, where exactly do they go? How many users of your web site live in Europe? How will your Internet service be affected by a new transpacific cable? To answer these questions you need geographic information. Internet researchers frequently need to map their observed data to specific places. [...] [84] 2 Location-aware applications bezeichnen Anwendungen, welche Dienste auf Grundlage der geografischen Herkunft eines Nutzers anbieten [1]. 3 Load- und Cloudbalancing dient der effektiven Verteilung von Anfragen zwischen mehreren Servern oder innerhalb einer Cloud [73] und trägt somit zur Reduktion der Netzlast bei [114, 95]. Bachelorarbeit HT 2011 Seite 5

16 KAPITEL 1. EINORDNUNG Im akademischen Bereich entwickeln [118, 117, 90, 43, 84] und nutzen Forscher diese Techniken nicht nur zur reinen Allokation von IP-Adressen zu physikalischen Positionen, sondern vielmehr zur Analyse der Netzstrukturen und Diagnose von Routing-Anomalien 4 zwischen Autonomen Systemen 5 [92, 34]. Somit kann eine effizientere Aufstellung der Internetressourcen gewährleistet werden 6. 4 Das unkontrollierte und chaotische Wachstum des Internets in den letzten Jahrzehnten ist eine der Hauptursachen für die Entstehung dieser Anomalien [64]. 5 Ein Autonomes System bezeichnet ein Netz beziehungsweise eine Gruppe von Netzen, welche durch dieselbe Administrative Instanz geführt werden [7]. 6 Mao et al. [121] concluded that an accurate router-level map of the Internet would help to resolve anomalies seen in AS paths derived from traceroutes [...] [11] Bachelorarbeit HT 2011 Seite 6

17 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Kapitel 2 Geolokalisationsverfahren Autor: Lars Stiemert Die derzeit einzig existente Methode, um ein zuverlässiges und genaues Mapping von Nutzern zu geografischen Standorten gewährleisten zu können, ist die direkte persönliche oder Cookie-basierende Interaktion, indem der User beispielsweise bei der Registrierung für bestimmte Webinhalte standortbezogene Daten angeben muss. Diese Möglichkeit birgt verschiedene Nachteile [68, 84, 64]. Zum einen ist sie für den User beschwerlich und in heutigen Zeiten in denen IT-Sicherheit immer mehr an Bedeutung erlangt, auch nicht gewünscht [66]. Zum anderen ist sie ineffektiv sobald beispielsweise der Cookie auf einem anderem als dem zu lokalisierendem System gespeichert wird oder der User auf verschiedene Clients zurückgreift. Vor allem kommt diese Einschränkung auch dann vor wenn ein kommerzieller Proxy-Dienst eingesetzt wird. Diese Form der Interaktion basiert auf dem Vertrauen, dass der Nutzer auch die korrekten Daten zur Verfügung gestellt hat [64]. Um diesen Problemen entgegenzutreten wird die Entwicklung beziehungsweise Verbesserung von Geolokalisationsverfahren stetig vorangetrieben. Im Laufe der letzten beiden Jahrzehnte haben sich dabei mehrere Verfahren bewährt. Die Klassifikation der unterschiedlichen Ansätze kann nach Dahnert et al. [25] sowie Laki et al. [100, 101] in zwei Gruppen, basierend auf der zugrunde liegenden Technik, vorgenommen werden. Während die eine Gruppe auf der semantischen Deutung der vorliegenden beziehungsweise bereits vorgehaltener Datensätzen basiert, bilden aktive Latenz- und Topologie-Messungen den Grundstock für die zweite Gruppe. Eine weitere Art der Einteilung wird durch Padmanabhan et al. [90] beschrieben, welche allerdings in der oben genannten abstrakten Zweiteilung aufgeht. Nach An investigation of geographic mapping techniques for Internet hosts [90] erfolgt hierbei die Identifikation von drei verschiedener Ansätze, welche auf konkreten topologischen Zusammenhängen und aktiven Messungen beruhen. Die Darstellung nach Dahnert et al. [25] deckt diese konkretisierten Ansätze allerdings in allgemeiner Form ab und erleichtert somit bei Bedarf die Einordnung der verschiedenen Verfahren. Bachelorarbeit HT 2011 Seite 7

18 KAPITEL 2. GEOLOKALISATIONSVERFAHREN 2.1 Existente Verfahren und Funktionsweisen im Überblick Hinweis: Das vorliegende Kapitel wird aus Gründen der Übersichtlichkeit nicht nach den oben genannten Klassifizierungsansätzen unterteilt, da viele der nachfolgend vorgestellten Geolokalisationsverfahren aktive sowie semantische Komponenten aufweisen. Somit ist die Zuordnung zu einer der beiden vorgestellten Gruppen nicht eindeutig möglich. Um den Umfang der vorliegenden Arbeit möglichst auf das Wesentliche zu beschränken wird die Auswahl der vorgestellten Verfahren auf die bekanntesten sowie auf die für eine mögliche Implementierung im Rahmen des Proof-of-Concept in Frage kommende beschränkt. IP2Geo [90] ist einer der ersten auf aktiven Messungen basierende Ansätze zur Allokation einer gesuchten logischen IP-Adresse zu einer physikalischen Position. Ein ausgereifterer Ansatz, Constraint Based Geolocation (CBG) nach Gueye et al. [43], sowie dessen Weiterentwicklung Topology Based Geolocation (TBG) nach Katzbassett et al. [63] nutzt Multilateration 1 zur Lösung der Geolokalisationsproblematik. Spätere auf Bézier Kurven basierende Strategien wie das von Wong et al. [118] entwickelte Octant-Framework, setzen auf CBG beziehungsweise TBG auf und bieten die Möglichkeit, diese nutzerspezifisch durch zum Beispiel demografische Daten zu erweitern. Weitere Geolokalisationsstrategien wie NetGeo [84] basieren auf der Abfrage öffentlich zugänglicher Datensätze der Regional Internet Registries (RIR) 2, extensiver Analyse der Datenbanken von Geoservice-Anbietern [94, 78, 50] oder der Ausnutzung des Domain Name Systems gemäß RFC 1876 [86, 27, 28, 113] IP2Geo In An investigation of geographic mapping techniques for internet host [90] haben Padmanabhan et al. drei verschiedene Algorithmen namens GeoTrack, GeoPing und GeoCluster vorgestellt 3, welche auf die geografische Postion eines internetfähigen Hosts schließen können. Jeder der drei Algorithmen basiert hierbei auf unterschiedlichen Methoden, um die Lage des gesuchten Hosts zu ermitteln. GeoTrack und GeoPing nutzen aktive Netz-Messungen, typischerweise Verzögerungswerte wie Round Trip Times (RTT) oder Routetracing, auf Grundlage derer ein Mapping der gesuchten IP-Adresse vorgenommen werden kann [64]. GeoCluster hingegen teilt den IP-Adressraum in Cluster auf und versucht durch unterschiedliche Ausprägung 4 des Algorithmus diese Cluster zu lokalisieren [53, 64]. 1 The physical position of a given point can be estimated using a sufficient number of distances or angle measurements to some fixed points whose positions are known. When dealing with distances, this process is called multilateration. [46] 2 RIPE NCC, ARIN, LACNIC, AfriNIC und APNIC. 3 GeoTrack, GeoPing und GeoCluster bilden zusammen das IP2Geo-Protokoll [64]. 4 Benutzerdefinierte Anzahl an Durchläufen des Subclustering und Anwendung von Metriken. Bachelorarbeit HT 2011 Seite 8

19 KAPITEL 2. GEOLOKALISATIONSVERFAHREN GeoPing GeoPing ist ein Verfahren, welches die Korrelation zwischen Latenzwerten und geografischer Distanz ausnutzt [90]. Das Vorhandensein dieses Zusammenhangs ist ein fundamentaler Bestandteil des GeoPing-Algorithmus 5 und stellt zugleich auch eine große Herausforderung dar. Entgegen konventioneller Meinungen, dass eine solche Korrelation nicht vorhanden sei [8], bestätigen Ziviani et al. [123] eben diese Existenz. Jedoch ist diese zu schwach ausgeprägt, um sie in einem mathematischen Model formulieren zu können. [...] in general there is no strong enough correlation between geographic distance and network delay to capture such a relationship under a mathematical model [...] [3] Dies lässt sich beispielhaft daran verdeutlichen, dass Pakete aus dem Netz der Universität der Bundeswehr München selbst dann via Garching und Frankfurt geroutet werden wenn der Kommunikaktionspartner ebenfalls in München lokalisiert ist und somit zu einem deutlichen Anstieg der RTT führen, welcher wiederum in keinem Zusammenhang mit der absoluten geografischen Distanz zum Zielhost steht. Festzustellen bleibt, dass der Zusammenhang zwischen Latenzen und der physikalischen Distanz die Grundlage aller auf Messung von Verzögerungswerten basierenden Verfahren darstellt. Allerdings korreliert dieser stark mit der Anzahl der nutzbaren Landmarks sowie der Interpretation und Berücksichtigung variabler Bestandteile Messungen 6. Die Gründe hierfür sind vielschichtig und reichen von unterschiedlichen Bandbreiten der Links und Routingschleifen bis zu den den üblichen Verzögerungsarten paketvermittelnder Netze wie Verzerrungen durch Warteschlangen sowie der Verarbeitung in den einzelnen Knoten entlang des Mediums [18]. In einem typischen Anwendungsscenario von GeoPing (vergleiche Abbildung 2.1 und 2.2) steht dem Nutzer eine Menge L mit n aktiven respektive passiven Landmarks 7 sowie einer Menge P mit n Clients zur Verfügung, wobei eine Überschneidung der Mengen L und P möglich ist. 5 Vergleiche Pseudocode GeoPing-Algorithmus in Anhang A. 6 Die RTT zwischen zwei Endsystemen kann in zwei Bestandteile aufgegliedert werden. Zum einen den deterministischen beziehungsweise fixen Anteil und zum anderen einem stochastischen beziehungsweise variablen Teil [46, 62]. Der deterministische Teil beschreibt dabei die minimale Verarbeitungsverzögerung für jeden Knoten auf dem Pfad sowie die Nachrichten- und Signalverzögerung. Der stochastische Anteil hingegen beschreibt alle variablen und nicht ohne Weiteres vorhersehbaren Verzögerungsarten, wie Warteschlangen- und Verarbeitungsverzögerung, die über den minimalen Wert hinausgehen [46]. 7 Landmarks bezeichnen netzfähige Entitäten mit bekanntem Standort [123], wobei aktive Landmarks in der Lage sind, Anfragen an den Zielhost zu versenden. Bachelorarbeit HT 2011 Seite 9

20 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Formal ausgedrückt ergibt sich: P = {P 1, P 2,..., P n } mit n 1 n N L = {L 1, L 2,..., L n } mit n 1 n N P L Um Rückschlüsse auf die geografische Position der gesuchten Entität T schließen zu können bestimmt als erstes jeder Client P i P die minimale 8 RTT zu dem vorher definierten Set von Landmarks L i L und fasst das Ergebnis in einem sogenannten Latenzvektor V x = (v 1 x, v 2 x,..., v n x) zusammen (vergleiche Abbildung 2.1, Teil a). Hierbei entspricht v i x der ermittelten minimalen RTT zwischen Client P x und Landmark L i 9. Anschließend gelangt die Information über die zu lokalisierende Entität T mittels eines Location Servers, der alle Daten zu den Mengen L und P vorhält, zu den Nodes P i P, welche daraufhin die minimale RTT v T x zu T bestimmen und den Latenzvektor um diesen Wert zu V x zu V x = (v 1 x, v 2 x,..., v n x, v T x) erweitern (vergleiche Abbildung 2.1, Teil b). Im folgendem Schritt übermittelt jeder Client P i P den erweiterten Latenzvektor V x an den Location Server, der auf Grundlage dieser Informationen eine zweidimensionale Matrix V konstruiert (vergleiche Abbildung 2.1, Teil c). V = v 11 v 12 v 13 v 1x v 21 v 22 v 23 v 2x..... v n1 v n2 v n3 v nx v T 1 v T 2 v T 3 v T x Auf Basis der zeilenweisen Analyse dieser Matrix erfolgt die Schlussfolgerung auf eine mögliche geografische Position der gesuchten Hosts T (vergleiche Abbildung 2.1, Teil d). Als theoretische Position wird dabei der Landmark L i L mit dem ähnlichsten Muster in Bezug auf T angenommen [90] (vergleiche Abbildung 2.2). 8 Um signifikanten Schwankungen der Signal- und Warteschlangenverzögerung entgegenzuwirken, wird aus der Menge der ermittelten RTT der minimale Wert bestimmt [90]. 9 Dieser Vorgang findet auch dann statt, wenn keine Lokalisationsversuche unternommen werden, das heißt es erfolgt eine stetige Anpassung des Latenzvektors. Bachelorarbeit HT 2011 Seite 10

21 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Abbildung 2.1: Funktionsweise GeoPing [123]. Gestrichelte Linien repräsentieren die Messungen der Clients P i zu den Landmarks L i, während durchgezogenen Pfeile einen Informationsaustausch beschreiben [123]. Bachelorarbeit HT 2011 Seite 11

22 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Abbildung 2.2: Funktionsweise GeoPing - Latenzvektor [115]. Latenzvektor-Bestimmung zwischen einem Host sowie Set Landmarks L = {L 1, L 2, L 3, L 4 }. Bestandteile der Matrix V seien beispielsweise L 1 = {(50, 45, 20, 35) Indianapolis, IN} und L 2 = {(10, 20, 40, 60) Seattle, W A}, weshalb als Ziel Indianapolis angenommen wird [115]. Bachelorarbeit HT 2011 Seite 12

23 KAPITEL 2. GEOLOKALISATIONSVERFAHREN GeoCluster Der in An investigation of geographic mapping techniques for internet host [90] vorgestellte GeoCluster-Algorithmus 10 teilt den gesamten IP-Adressraum in Blöcke beziehungsweise Cluster auf. Anschließend wird versucht über die Allokation eines Clusters zu einer geografischen Region auf die tatsächliche Lage des gesuchten Zielsystems zu schließen [90, 53]. Die grundlegende Idee ist die Annahme, dass alle IP-Adressen eine Clusters in derselben Region zu finden sind. Damit eine logische Adresse überhaupt einem Cluster zugeordnet werden kann, werden weitreichende Informationen über die allgemeine Verteilung des IP-Bestandes benötigt. Als Basis hierfür dienen den Autonomen Systemen zugehörige BGP-Routingtabellen respektive Adress-Präfixe 11, Whois-Datenbestände und gesammelte Informationen aus anderen Quellen wie Internet Service Providern oder Registrierungsdaten von Internetdienstleistungsanbietern [64, 91, 115, 90]. Die Zuordnung einer IP-Adresse zu einem Cluster sowie die Einschränkung dessen auf ein geografisches Gebiet erfolgt prinzipiell in zwei Schritten. Zuerst werden auf Basis von Whois-Datenbeständen der fünf Regional Internet Registries und bereits erlangter Mappinginformationen, Datenbanken mit (IP, P osition) T upel aufgestellt (vergleiche Abbildung 2.3). Anschließend werden Informationen der BGP-Routingtabellen zur Identifikation topologisch 12 zusammengehöriger Cluster genutzt (vergleiche obere Abbildung 2.4). Jeder dieser Cluster wird daraufhin einer geografischen Region auf Grundlage der zuvor aufgestellten (IP, P osition) T upel zugeordnet. Gesetzt den Fall, dass es zu keinem Konsens kommen sollte (vergleiche untere Abbildung 2.4), wird zur weiteren Unterteilung Subclustering angewendet. Diese Ausprägung des GeoCluster-Algorithmus bezeichnet einen elementaren Bestandteile dessen, um identifizierte Cluster weiter zu untergliedern [90]. Dabei werden die Cluster einer erweiterten Analyse unterzogen und in zwei Subcluster mit geografischen Gemeinsamkeiten aufgeteilt. Die Anzahl der Durchläufe definiert sich entweder durch benutzerspezifische Einstellungen oder durch implementierte Abbruchbedingungen wie der Unmöglichkeit einer weiteren Aufteilung. Als physikalischer Standort der gesuchten Entität wird am Ende der geografische Raum des am ehesten übereinstimmenden Clusters angenommen [115]. 10 Vergleiche Pseudocode GeoCluster-Algorithmus in Anhang B. 11 In Investigating the Imprecision of IP Block-Based Geolocation [42] untersuchen Gueye et al. den Zusammenhang zwischen IP-Präfixen und einer bestimmten geografischen Region und bestätigen damit die Erkenntnisse von Freedman et al. [39], 12 Hier: Netztopologie. Bachelorarbeit HT 2011 Seite 13

24 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Abbildung 2.3: GeoCluster - Erstellen der (IP, P osition) T upel [115] Bachelorarbeit HT 2011 Seite 14

25 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Abbildung 2.4: GeoCluster - Aufstellen von Clustern [115] /16 stellt den auf BGP-Informationen basierenden topologischen Cluster dar. Auf Basis zu zuvor ermittelten (IP, P osition) T upel wird die Eingrenzung auf ein geografisches Gebiet vorgenommen. Da eine Entität (rot) deutlich abweicht, muss Subclustering angewendet werden [115]. Bachelorarbeit HT 2011 Seite 15

26 KAPITEL 2. GEOLOKALISATIONSVERFAHREN GeoTrack GeoTrack 13 [90] versucht auf den geografischen Standort eines Hosts zu schließen, indem dessen Full-Qualified Domain Name (FQDN) beziehungsweise den einer mit diesem in unmittelbarer toplologischer Verbindung stehenden Entität, auf geografische Hinweise untersucht wird [53]. Der Grundstock dieser Untersuchung ist durch Best Practice von Netzoperatoren begründet, die zur erleichterten Netz-Administration einzelne Knoten mit Hinweisen auf deren Standort versehen [90, 40]. GeoTrack nutzt zur Identifikation des gesuchten Hosts das sogenannte Tracerouting unter Verwendung der Traceroute-Applikation (vergleiche Listing , geografische Hinweise sind rot gekennzeichnet) [32, 91]. Somit werden im Idealfall alle Hops bis zum Zielsystem 15 aufgedeckt und deren FQDN ermittelt. Über reguläre Ausdrücke und Pattern- Matching (vergleiche Listing 2.1 nach Moore et al. [84]) werden anschließend die einzelnen Hostnamen auf geografische Hinweise untersucht. Die den regulären Ausdrücken zugrunde liegenden Datenbanken enthalten neben Städte- und Länderbezeichnungen 16 auch Flughafencodes [68], da diese gemäß einer empirischen Studie [90] größtenteils für eine Kennzeichnung der Netzknoten verwendet werden. Grund hierfür ist vor allem, dass Flughafencodes (IATA-Codes) international standardisiert sind, während Städte- beziehungsweise Ländercodes nicht eindeutig zugewiesen werden können 17. Für die Bestimmung der geografischen Position der Zieladresse wird schlussendlich der letzte Host herangezogen, dessen FQDN Positionshinweise enthält. Gesetzt den Fall, dass dieser nicht der gesuchten Entität entspricht, wird der letzte nutzbare Knoten auf dem Pfad zum Zielsystem verwendet 18. s /.? \. ( [ ˆ \. ] + ) \ d \.ALTER\.NET/$1/ t h i s, a i r p o r t. db s c l=s a n t a c l a r a, ca, us tco=tysonscorner, va, us nol=neworleans, la, us Listing 2.1: Parsing Beispiel 13 Vergleiche Pseudocode GeoTrack-Algorithmus in Anhang C. 14 Auf eine Verschleierung des Zielhostnames wird aufgrund dessen offizieller Erwähnung in TCP/IP Illustrated I: The Protocols: 001 [116] verzichtet. 15 Einschließlich des Zielhosts. 16 Beispielsweise GAR für Garching und D für Deutschland. 17 Beispielsweise könnte der Stadtcode für Frankfurt/Main/Deutschland mit dem aus Frankfurt/Indiana/USA kollidieren. Des Weiteren existieren für verschiedene Städte mehrere Bezeichner wie F und FRA für Frankfurt/Main. 18 Es ist davon auszugehen, dass zumindest der letzte Knoten vor der gesuchten Entität in dessen unmittelbarer geografischen Umgebung zu finden ist. Dies ist vor allem bei DSL- und Kabelnutzern durch die sogenannte Letzte Meile begründet [34]. Bachelorarbeit HT 2011 Seite 16

27 KAPITEL 2. GEOLOKALISATIONSVERFAHREN metatron : / home/ t r o n# traceroute vangogh.cs.berkeley.edu t r a c e r o u t e to vangogh. cs. b e r k e l e y. edu ( ) 1 winscreen.rz. UniBw Muenchen. de ( ) ms 2 xr gar1 ge8 3.x win. dfn. de ( ) ms 3 zr f r a 1 te x win. dfn. de ( ) ms t1 3. inr 201 sut. Berkeley.EDU ( ) ms 13 reccev eecs br 10GE.EECS. Berkeley.EDU ( ) ms 14 soda 10g edge.eecs. Berkeley.EDU ( ) ms 15 vangogh. CS. Berkeley.EDU ( ) ms Listing 2.2: Traceroute auf vangogh.cs.berkeley.edu CBG und TBG Constraint Based Geolocation [43] wurde entwickelt, um den Problemen eines diskreten Lösungsraumes bei der Lokalisation mittels Landmarks entgegenzuwirken [91]. In Constraint-based geolocation of internet hosts [43] stellen Gueye et al. einen Ansatz basierend auf Multilateration vor (vergleiche Abbildung 2.5), wodurch die Position eines Hosts anhand der Distanz 19 zu bekannten Entitäten angenommen wird und ein stetiger Lösungsraum entsteht [53]. Der CBG-Algorithmus nutzt für die Bestimmung der Distanz Beobachtungen über die Ausbreitungsgeschwindigkeit von Signalen in Glasfaserleitungen 20,21. Empirische Studien belegen, dass es sich hierbei um einen Wert von 2 3 c [92, 46] beziehungsweise nach neuesten Analysen um 4 9 c [117] handelt. Aufgrund dieser Werte22 können zu jedem aktiven Landmark L i aus einer Menge L, wobei L = {L 1, L 2,..., L n } mit n 1, n N, zwei Nebenbedingungen U iτ und O iτ sowie darauf basierend eine Kreisfunktion K iτ aufgestellt werden. U iτ beschreibt hierbei die theoretische Distanz zwischen Landmark und gesuchter Entität bei maximaler 23 Ausbreitungsgeschwindigkeit der Signale, das heißt c. O iτ hingegen definiert die tatsächliche Distanz unter Berücksichtigung von Verzögerungsarten und der Annahme einer Signalgeschwindigkeit von 2 3 c. Die Schnittmenge über allen ermittelten Kreisfunktionen dient der Bestimmung einer geografischen Region, dessen Zentrum als tatsächliche Position der gesuchten IP-Adresse angenommen wird (vergleiche Abbildung 2.5) [43]. 19 Basierend auf Latenzmessungen unter Ausnutzung der bereits erwähnten Korrelation zwischen geografischer Distanz und Verzögerungswerten im Netz. 20 Es ist davon auszugehen, dass bis auf die Letzte Meile respektive Satelliten-Links nahezu alle Leitungen aus Glasfaser bestehen [92]. 21 Im Vakuum ist diese gleich der Lichtgeschwindigkeit c [96]. 22 CBG nutzt 2 c als Berechnungsgrundlage [43, 53] Um sicherzustellen, dass sich die gesuchte Entität auch innerhalb der Messgrenzen befindet, muss eine bewusste Überschätzung der Distanz vorgenommen werden [43, 69]. Bachelorarbeit HT 2011 Seite 17

28 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Formal ausgedrückt ergibt sich: L = {L 1, L 2,..., L n } U iτ = g iτ O iτ = g iτ + γ iτ K = {K 1τ, K 2τ,..., K nτ } S = L i K iτ i, n 1 i, n N Topology Based Geolocation [63] ist eine um topologische Aspekte weiterentwickelte Variante von CBG. Katzbassett et al. lokalisieren 24 zur Optimierung der geografischen Zielregion alle Knoten auf dem Netzpfad zwischen den einzelnen Landmarks der Menge L hin zur gesuchten Entität [53]. Abbildung 2.5: Multilateration [46, 101]. Der gestrichelte Kreis um ein Landmark L i mit dem Radius g iτ + γ iτ repräsentiert die obere Grenze der geografischen Strecke zum Ziel, das heißt die theoretisch maximale Entfernung zum Landmark L i. Die untere Grenze respektive die theoretisch minimale Entfernung zwischen Landmark L i und Zielhost wird durch den vollständigen Kreis mit dem Radius g iτ beschrieben [69]. Der rot beziehungsweise grau gekennzeichnete Bereich beschreibt die geografische Zielregion [101]. 24 Unter Nutzung des ursprünglichen CBG-Algorithmus nach Gueye et al. [43, 53]. Bachelorarbeit HT 2011 Seite 18

29 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Octant Octant 25 ist ein modulares Framework zur Geolokalisation, welches zur Bestimmung der physikalischen Aufenthaltsregion des Zielsystems eine Vielzahl geometrischer Kurven, sogenannte Bézier Kurven 26, sowie positive als auch negative Bedingungen 27 nutzt [118, 91] (vergleiche Abbildung 2.6 und 2.7). Das von Wong et al. [118] entwickelte Framework baut auf den Erkenntnissen von TBG [63] auf und erweitert diesen Ansatz durch Nutzung der auf den Netzpfad befindlichen Knoten als zusätzliche Landmarks. Durch den modularen Aufbau ermöglicht Octant die Formulierung zusätzlicher Nebenbedingungen, die eine mögliche geografische Region signifikant eingrenzen können [103]. Diese Nebenbedingungen basieren beispielsweise auf erhobenen demographischen Daten, durch die ein mögliches Lokalisationsareal auf bewohnte Gebiete beschränkt werden kann. Weitere Möglichkeiten sind das Einbringen von Informationen der Regional Internet Registries sowie die Ausnutzung von Geoservice-Anbietern wie MaxMind [78] oder Quova [94]. Abbildung 2.6: Octant - Bézier Kurven [118]. Jede Bézier Kurve a, b und c besteht aus vier Hilfspunkten P 0, P 1, P 2 und P 3 zur Ausrichtung der Kurve. P 0 respektive P 3 stellen Start- und Endpunkt sowie P 1 und P 2 zusätzliche Kontrollpunkte dar [118]. 25 Octant ist der derzeitige State of the Art im Anwendungsgebiet der Geolokalisation von IP-Adressen [13]. 26 [...] Bézier curves provide a compact way to represent large, complex areas precisely. They also admit efficient intersection, union, and subtraction operations. [118] 27 Positive Nebenbedingungen bestätigen beziehungsweise erweitern eine bestimmte Region in der sich theoretisch das Zielsystem befindet, während negative zum Ausschluss von bestimmten Arealen führen, beispielsweise Ozeane. Bachelorarbeit HT 2011 Seite 19

30 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Abbildung 2.7: Octant - Set von Bézier Kurven [118] DNS LOC Resource Record Request for Comments (RFC) 1876 [28] beschreibt einen Ansatz zur Integration von geografischen Informationen 28 innerhalb des Domain Name Systems (DNS) [86]. Diese Möglichkeit zur Geolokalisation basiert auf der flächendeckenden Einführung eines neuen DNS Resource Record. Der so entstehende LOC 29 Eintrag hält die geografische Position des bezeichnenden Hosts, Subnetz beziehungsweise Netz vor (vergleiche Listing 2.3) [28, 117]. tron@metatron : / home/ tron# dig -t LOC caida.org ; <<>> DiG <<>> t LOC caida. org ; ; g l o b a l o p t i o n s : +cmd ; ; Got answer : ; ; >>HEADER<< opcode : QUERY, s t a t u s : NOERROR, id : ; ; f l a g s : qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 ; ; QUESTION SECTION: ; caida. org. IN LOC ; ; ANSWER SECTION: caida. org. IN LOC N W m 30m 10m 10m ; ; AUTHORITY SECTION: caida. org. IN NS ns1. caida. org. caida. org. IN NS ns1. ucsd. edu. ; ; Query time : 95 msec ; ; WHEN: Wed Dec : 3 8 : Listing 2.3: Abfrage DNS LOC Resource Record am Beispiel der Domain caida.org 28 Speziell Längen- und Breitengrade. 29 LOC bezeichnet hierbei die Kurzform von Location [64]. Bachelorarbeit HT 2011 Seite 20

31 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Nach RFC 1876 [28] besteht der acht Byte große LOC Record neben Angaben zur Version sowie Längen- Breitengraden auch aus Informationen zur Konkretisierung der Position einer zu beschreibenden Netzentität (vergleiche Abbildung 2.8 und Listing 2.3) 30 : Abbildung 2.8: Aufbau LOC Resource Record gemäß RFC 1876 [28] Version: Versionsnummer Size: Position der Entität in Bezug auf Längen- und Breitengrad 31 Horiz Pre / Vert Pre: Päzisionsangaben zum Feld Size (10m 10m) Latitude / Longitude: Breiten- und Längengrad (32 53 N W) Altitude: Höhenlage (107.00m) 30 Aus Sicherheitsgründen bleibt dem jeweiligen Netzoperator die Wahl inwiefern er die einzelnen Felder des LOC Record befüllt [27, 117]. 31 Der Längen- und Breitengrad bildet das Zentrum des Umkreises in dem der Host oder das Netz beziehungsweise Subnetz lokalisiert ist. Bachelorarbeit HT 2011 Seite 21

32 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Netgeo NetGeo [84] ist eine von der Cooperative Association for Internet Data Analysis (CAI- DA) [108] entwickelte datenbankbasierende Methode zur Allokation von geografischen Informationen zu einer IP-Adresse beziehungsweise Autonomen Systems [91]. Der Zugriff auf die NetGeo Applikation erfolgt interaktiv mittels Webbrowser oder diverser zur Verfügung stehender Application Programming Interfaces (API) 32. NetGeo unterstützt in seiner letzen und aktuellen Ausprägung von September die Suche auf Grundlage von IP-Adressen, Domain- und Hostnamen sowie der Nummer eines Autonomen Systems [84]. Die Lokalisation einer Entität erfolgt über die Abfrage der zugrunde liegenden Datenbank, heuristischer Analyse von Whois-Datenbeständen sowie einer Sammlung unterschiedlicher Scripte zum Parsen 34 von Geoinformationen [84, 123]. Auch die Möglichkeit zum Auslesens der bereits vorgestellten DNC LOC Resource Records wurde bei der Entwicklung von NetGeo bedacht und implementiert [69, 84] Whois Whois [87] ist ein Protokoll zur Abfrage von Informationen zu IP-Adressen, Hostnamen sowie Autonomen Systemen. Diese Angaben werden in dezentral verwalteten Datenbanken der Registraturen, Provider und Behörden vorgehalten. Allgemein betrachtet ist der gesamte IP-Adressraum unter den fünf Regional Internet Registries RIPE NCC, ARIN, LACNIC, AfriNIC und APNIC aufgeteilt [97, 4, 70, 109, 6, 99, 91]. Zu beachten ist hierbei, dass die IANA [56] die zentrale Vergabestelle für IP-Adressen und Domain-Namen ist. Sie delegiert die (geografische) Verantwortung für bestimmte Subnetzbereiche an die fünf Regional Internet Registries (vergleiche Abbildung 2.9). Da das gesamte Adressvergabesystem auf einer baumartigen Hierachie beruht, teilen die RIR die ihrer Verantwortung unterliegenden Bereiche jeweils den unterstellten National Internet Registries (NIR) beziehungsweise Local Internet Registries (LIR) zu [99]. Diese wiederum vergeben Anteile davon direkt an die Internet Service Provider oder größere Carrier, welche letzten Endes dem jeweiligen Nutzer oder Firmen einzelne IP-Adressen oder kleinere Subnetze zuweisen [24]. Die unter Ausnutzung des Whois-Dienstes abfragbaren Datenbestände der Registraturen geben Aufschluss über Eigentümer, Verantwortlichkeiten und Kontaktdaten einer Domain beziehungsweise IP-Adresse (vergleiche Listing 2.4). Durch die Analyse der erhaltenen Informationen werden Rückschlüsse auf die geografische Position der gesuchten Entität ermöglicht (vergleiche Listing 2.4, rot gekennzeichnet) [64, 100]. 32 Zur Verfügung stehen Java- und Perl-API [84, 22]. 33 NetGeo wird seit 1999 nicht offiziell weiterentwickelt. 34 Zur Reduktion von sogenannten False Positves werden zur Extraktion von Geoinformationen in der Sprache verschiedene Datensätze verwendet [117, 84]. Bachelorarbeit HT 2011 Seite 22

33 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Abbildung 2.9: Geografische Verantwortung der fünf Regional Internet Registries [12] : / home/ tron# whois -h whois.ripe.net % This i s the RIPE Database query s e r v i c e. % Note : t h i s output has been f i l t e r e d. inetnum : netname : UNIBWMNET d e s c r : U n i v e r s i t a e t der Bundeswehr Muenchen ; Rechenzentrum d e s c r : Werner Heisenberg Weg 39, D Neubiberg country : DE... remarks : timezone GMT+01 (GMT+02 with DST)... person : Ludwig Bayer address : U n i v e r s i t a e t der Bundeswehr Muenchen address : Rechenzentrum address : Werner Heisenberg Weg 39 address : Neubiberg address : Germany phone : fax no : Listing 2.4: Whois-Abfrage auf ( ) Bachelorarbeit HT 2011 Seite 23

34 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Geoservice-Anbieter Die Nutzung von Geoservice-Anbietern hat sich im Verlauf der letzten Jahre zur vorherrschenden Methode der Lokalisation von IP-Adressen entwickelt [101, 52]. Geoservice-Anbieter wie MaxMind [78] oder auch Quova [94] stellen Datenbanken zur Verfügung, auf Basis derer sich unter Anderen auch für Unternehmen und Endverbraucher eine einfache und performante Möglichkeit zur Geolokalisation eröffnet. Das Angebot reicht hierbei vom kostenlosen Service wie HostIP [50], über den kommerziellen Erwerb einer Datenbank, bis hin zu auf der Abfrageanzahl basierenden Preisstrategien wie sie Quova betreibt [120]. Die Zuordnung einer logischen Adresse zu einer geografischen Position erfolgt über den Abgleich der angefragten IP-Adresse beziehungsweise des Domainnamen mit den internen Datenbeständen der Anbieter. Diese Datensätze zeigen dabei in Abhängigkeit vom jeweiligen Geoservice-Anbieter deutliche Unterschiede in der Genauigkeit, Granularität sowie Umfang der gelieferten Ergebnisse auf [12, 120, 52]. Zur Abfrage der Datenbestände kommen hierbei je nach Anwendungszweck und Anbieter entweder webbasierende Abfragen mittels Webbrowser (vergleiche Abbildung 2.10), die Integration von Application Programming Interfaces (vergleiche Listing 2.5) oder nutzerspezifische Implementierungen (vergleiche Listing 2.6) zum Einsatz [66, 24]. Abbildung 2.10: Geolokalisation mittels webbasierender Abfrage via HostIP [50] Bachelorarbeit HT 2011 Seite 24

35 KAPITEL 2. GEOLOKALISATIONSVERFAHREN my $ g i = Geo : : IP >open( / l i b /MM/GeoIP/GeoIPCity. dat, GEOIP STANDARD) ; my $record = $gi >record by name ( ) ; print $record >country code, $record >country code3, $record >country name, $record >region, $record >region name, $record >c i t y, $record >p o s t a l c o d e, $record >l a t i t u d e, $record >l o n g i t u d e ; Listing 2.5: Nutzung der Perl-API zur Abfrage von MaxMind Datenbeständen... SELECT l o c FROM i a t a WHERE l o c LIKE $cp AND ( c2 = $2 OR c3 = $2 ) LIMIT 1 ;... Listing 2.6: Nutzerspezifische Implementierung aus dem IPTroll Die Herkunft der Datensätze beziehungsweise auf welcher Basis diese erstellt wurden, lässt sich bei fast allen Anbietern nur durch empirische Studien und Analysen vermuten [52, 120, 12, 103]. In IP Geolocation Databases: Unreliable? [52] werden als grundlegende Bezugsquellen BGP-Routingtabellen und Datenbestände der Registraturen genannt. Weitere Quellen sind Partnerseiten der jeweiligen Anbieter [120], welche die Eingabe von IP-Adressen und Positionen ermöglichen, sowie direkte Kontakte zu Internet Service Providern 35. Über diese werden beispielsweise konkrete Informationen zum (geografischen) Routing und Adressverteilung bezogen [101]. 35 Beispiel: Quova [94, 101]. Bachelorarbeit HT 2011 Seite 25

36 KAPITEL 2. GEOLOKALISATIONSVERFAHREN 2.2 Bewertung und Fazit Die nachfolgende Tabelle gewährt nochmals einen kurzen Überblick aller in Kapitel 2 vorgestellten Verfahren und Methoden zur Geolokalisation. Spalte zwei gibt an, ob sich die in der ersten Spalte gelistet Methode auf die Nutzung von Landmarks oder lediglich der angefragten IP-Adresse stützt. Die dritte Spalte beschreibt, inwiefern die Methode eine Kombination von Verfahren nutzt oder sich auf eines beschränkt 36. Die letzten beiden Spalten geben zum einen Aufschluss über den Lösungsraum und die grundsätzlich von den Entwicklern angedachten Hilfsprogramme 37. Tabelle 2.1: Übersicht der vorgestellten Geolokalisationsverfahren Methode Landmark/IP Hybrid Lösungsraum Hilfsprogramm GeoPing Landmark - diskret - CBG Landmark ja stetig - Octant Landmark ja stetig - TBG Landmark ja stetig - GeoTrack IP - diskret Traceroute NetGeo IP ja diskret Whois GeoCluster IP - diskret - Geoservices IP - diskret - Whois IP - diskret Whois DNS LOC IP - diskret Bewertung hinsichtlich Genauigkeit, Verfälschung und Manipulation Hinweis: Im Folgenden wird auf die Angabe von konkreten Werten zur Präzision der betrachteten Verfahren Abstand genommen. Grund hiefür ist, dass diese Werte zumeist in akademischen Forschungsnetzen wie Planet Lab [93] oder in Abhängigkeit von der demografischen Beschaffenheit 38 ermittelt wurden. Somit sind die bestimmten Werte gegebenenfalls nicht global repräsentativ. CBG, TBG, Octant, GeoPing und GeoTrack Constraint Based Geolocation nach Gueye et al. [43] ist eine Entwicklung zur Erweiterung des diskreten Lösungsraumes der bisherigen Geolokalisationsverfahren auf Basis 36 Hiermit ist vor allem Multilateration oder ein Kombination von Latenz- und Topologiemessungen gemeint. 37 Beispielsweise nutzt TBG zwar Verfahren zum Tracerouting, beschränkt sich hierbei aber nicht auf eine spezielle Applikation. 38 Hauptsächlich werden stark industrialisierte Regionen wie Europa oder den USA betrachtet. Bachelorarbeit HT 2011 Seite 26

37 KAPITEL 2. GEOLOKALISATIONSVERFAHREN von Landmarks [91]. Dazu nutzt CBG Multilaterations-Algorithmen und schafft somit einen stetigen Lösungsraum. Indem CBG bewusst eine Überschätzung der oberen Grenze O iτ (vergleiche Abbildung 2.5) vornimmt wird versucht sicherzustellen, dass der Lösungsraum nicht leer ist. Dies führt allerdings gleichzeitig zur Erhöhung der Schnittmenge S und somit zur signifikanten Vergrößerung des möglichen Zielgebietes in dem die Entität positioniert sein kann. Die Genauigkeit dieser Lokalisationstrategie wird maßgeblich von der Anzahl der zur Verfügung stehenden Landmarks [123] und deren Positionierung beeinflusst [2, 89]. Das heißt je mehr geografisch sinnvoll 39 verteilte Landmarks zur Verfügung stehen, desto akkurater fällt die Lokalisation aus. Ein fundamentales Problem werfen hierbei Firewall-, Proxy und Intrusion Detection Lösungen auf. Da CBG nach Eriksson et al.[13] ausschließlich Ping-basierende Methoden zur Bestimmung der nötigen Verzögerungswerte nutzt, ist davon auszugehen, dass viele Messungen fehlerhaft ausfallen 40 oder verfälscht werden. Abbildung 2.11 illustriert, wie das Ergebnis einer Lokalisation durch verfälschte Messungen ausfallen kann 41 : Abbildung 2.11: Beispiel für Lokalisationsresultate bei fehlerhaften Messungen [100]. (a) skizziert die tatsächliche Postion der Zielentität T, während (b) und (c) die Auswirkung auf das Lokalisationsergebnis bei verfälschten Messung darstellen [100]. Die nicht vorhersehbare Routenwahl der Pakete in Form von Routingschleifen führt ebenso zu Verzerrungen der Messwerte [34, 18, 62]. Der CBG-Algorithmus versucht diesen 39 Unter Berücksichtigung demografischer Aspekte. 40 Zur Firewall-, Proxy- und Network-Address-Translation (NAT) Problematik, vergleiche DipZoom: The Internet Measurements Marketplace [82]. 41 Wenige Millisekunden können zu einer geografischen Abweichung von mehreren hundert Kilometern führen. Durch Metriken wird versucht dieser Problematik zu entgegnen. Bachelorarbeit HT 2011 Seite 27

38 KAPITEL 2. GEOLOKALISATIONSVERFAHREN zwar mit einer beschreibenden Größe γ vorzubeugen 42, allerdings lassen sich dadurch nur vorhersehbare Verzerrungen in gewissen Grenzen berücksichtigen 43. Katzbassett et al. [63] Topology Based Geolocation verifiziert das mögliche Lokalisationsareal und steigert signifikant die Genauigkeit [63], aber es stellt lediglich eine erweiterte Variante des CBG-Algorithmus dar und wirft entsprechend dieselben Problemfelder auf. TBG ermöglicht zwar die Reduktion der auftretenden Fehler, allerdings auf Kosten der Performance 44. Hinzu kommt, dass die Analyse von Hostnamen und die Nutzung von Tracerouting eigene Fehlerquellen wie DNS Misnaming [122] und Alias Resolution [67] mit sich bringen. Auch das von Wong et al. vorgestellte Octant-Framework basiert im weitesten Sinne auf CBG, da es auf TBG aufsetzt [118]. Durch die Möglichkeit der modularen Einbindung von erweiterten Quellen wie demografischen Daten und die Nutzung von zusätzlichen Nebenbedingungen ermöglicht Octant eine granulare sowie akkurate Geolokalisation. Nichtsdestotrotz weist auch diese Methode eine ähnliche Anfälligkeit für Fehler auf wie etwa TBG oder auch CBG. GeoPing [90] unterliegt als ein auf aktiven Messungen basierender Ansatz vergleichbaren Herausforderungen wie die bereits erwähnten Strategien. Die Granularität der erzielten Ergebnisse hängt auch bei diesem Ansatz maßgeblich von der Menge und Position der nutzbaren Landmarks ab [123, 40]. Auch Verzerrungen, verursacht durch beispielsweise Routingschleifen, der Letzten Meile sowie sicherheitstechnischen Aspekten [40], stellen hierbei fundamentale Probleme bei der Lokalisierung einer IP-Adresse dar [34, 18, 62]. Die Genauigkeit der gelieferten Resultate beschränkt sich bei GeoPing auf einen diskreten Lösungsraum, was in diesem Kontext bedeutet, dass nicht eine Region als mögliches Resultat angenommen wird, sondern ein konkreter Landmark. Das der IP2Geo-Suite entstammende GeoTrack [90] stützt sich zur physikalischen Zuordnung einer IP-Adresse auf geografische Hinweise im FQDN der auf dem Netzpfad befindlichen Knoten. Ähnlich wie TBG unterliegt es hierbei dem Problem des DNS Misnaming nach Zhang et al. [122]. Hinzu kommt das Problem, dass die Nutzung von geografischen Pattern als Teil des Hostnamens kein Standard darstellt und der Umfang sowie Art der Anwendung vom jeweiligen Provider beziehungsweise Netzbetreiber 42 γ dient der Berechnung von O iτ mit O iτ = g iτ + γ iτ (vergleiche Abbildung 2.5). 43 RTT zwischen zwei Endsystemen kann in zwei Bestandteile aufgegliedert werden. Zum einen den deterministischen beziehungsweise fixen Anteil und zum anderen einem stochastischen beziehungsweise variablen Teil [46, 62]. Der deterministische Teil beschreibt dabei die minimale Verarbeitungsverzögerung für jeden Router auf dem Pfad sowie die Signal- und Nachrichtenverzögerung. Diese Werte sind feststehend für jeden einzelnen Pfad zwischen zwei Endsystemen. Der stochastische Anteil hingegen beschreibt alle variablen und nicht ohne Weiteres vorhersehbaren Verzögerungsarten, wie Warteschlangen- und Verarbeitungsverzögerung, die über den minimalen Wert hinausgehen [46]. [69, Seite 17] 44 Hier: Netzlast und Geschwindigkeit der Berechnungen durch vermehrte Messungen. Bachelorarbeit HT 2011 Seite 28

39 KAPITEL 2. GEOLOKALISATIONSVERFAHREN abhängig ist (vergleiche Listing ) [40]. Gravierend hinsichtlich der Genauigkeit wirkt sich die Nutzung von Traceroute [32] aus, da es durch das UDP- beziehungsweise ICMP-Protokoll gestützt wird und diese Pakete an Netzknoten häufig verworfen werden [74, 1, 68, 121]. Es besteht eine hohe Fehlerwahrscheinlichkeit, da als Ergebnis der letzte Knoten, der geografische Hinweise enthält 46, als tatsächliche Position angenommen wird (vergleiche Listing 2.8) [64]. tron@metatron : / home/ tron# traceroute ae ebr2. Frankfurt1. Level3. net ( ) ms ae ebr2. NewYork1. Level3. net ( ) CHINA TELEC. car4. SanJose1. Level3. net ( ) ms... Listing 2.7: Beispiel für Probleme bei der Analyse von FQDN (Pattern-Matching) tron@metatron : / home/ tron# traceroute 3 c h a r l i z e. munich. local ( ) ms 4 fw. munich. local ( ) ms Listing 2.8: Beispiel für Probleme bei der Analyse von FQDN (Firewall) DNS LOC Die flächendeckende Einführung eines zusätzlichen DNS Resource Records stellt einen nicht unerheblichen Eingriff in die bestehende DNS-Struktur dar. Aus diesem Grund und infolge des Mehrbedarfs an Verwaltungsaufwand mangelt es der Integration des LOC Record [28] an Akzeptanz seitens der Netzoperatoren [43, 117]. Da RFC 1876 keinen offiziellen Standard beschreibt, verbleibt die Entscheidung über dessen Umsetzung beim Netzbetreiber. Somit basiert auch die Genauigkeit und Granularität der Angaben wiederum auf Präferenzen der Netzadministratoren. Nicht nur, dass diese die Entscheidung inne haben, inwiefern sich die Angaben des LOC Record auf ein (Sub-)Netz oder konkreten Host beziehen 47, auch obliegt ihnen die uneingeschränkte Möglichkeit zur Verfälschung der Angaben. Mangels flächendeckender Verbreitung existieren allerdings keine empirischen Studien, um konkrete Aussagen über die Genauigkeit 45 Durch Pattern-Matching könnte der Netzknoten in China lokalisert werden, obwohl er bei genauer Betrachtung des Netzpfades definitiv in San Jose zu finden ist. 46 Auch Timeouts aufgrund von Verzerrungen führen zum selben Effekt. 47 Grundlage für diese Entscheidung bilden zumeist sicherheitstechnische Aspekte [28]. Bachelorarbeit HT 2011 Seite 29

40 KAPITEL 2. GEOLOKALISATIONSVERFAHREN und Konsistenz dieser Geolokalisationsmethode treffen zu können. Ohne die Betrachtung dieses Aspekts, ist mit der Umsetzung von RFC 1876 eine einfache und performante Lösung zu Lokalisation von IP-Adressen gegeben. NetGeo, GeoCluster und Whois Das Whois-Protokoll [87] ist ein performanter und elementarer Dienst im Internet, dessen Nutzung zur Abfrage öffentlicher Datenbestände der Registraturen jedem Nutzer frei steht. In diesem Punkt liegt bereits das erste Hemmnis begründet, da die RIR aufgrund von Missbrauch nur noch gefilterte Informationen liefern (vergleiche Listing 2.4, blau markiert). Aufgrund der im Regelfall nicht vorhandenen expliziten Prüfung der hinterlegten Informationen sind die Datensätze nur unter Vorbehalt als korrekt zu bewerten, da hierdurch die Möglichkeiten zur absichtlichen Verfälschung und Täuschung gegeben sind [64, 91]. Problematisch ist zudem, dass die hinterlegten Angaben nicht unbedingt mit der gesuchten Entität in Einklang zu bringen sind. Die Ursache dafür liegt in der Form der Verteilung von IP-Adressen, da diese normalerweise nur in Adressblöcken verteilt werden. Somit ist ein Mapping einer einzelnen IP zur einem Standort nicht ohne Weiteres möglich, zumal meist nur die Adresse vom Hauptsitz des Präfix-Eigentümers hinterlegt ist. Diese wiederum bringt keinen Nutzen, falls das zugehörige Autonome System geografisch weit gestreut ist [39, 103, 91]. [...] internet users whose IP addresses were registered with some of the largest ISP s were registered to that ISP s corporate address instead of their actual, physical location. So based on the WHOIS database search, customers who were physically located in Atlanta could appear to be located in Pasadena, CA some 2500 miles away. [24] Falls es sich allerdings um ein kleines Autonomes System wie beispielsweise von privaten Universitäten handelt, sind die hinterlegten Daten zumindest auf Stadtebene akkurat [40]. Da GeoCluster für eine erste Zuordnung einer IP-Adresse unter anderem die Datenbestände der Registraturen nutzt, unterliegt es den selben Restriktionen wie die klassische Whois-Abfrage. Gerade bei global operierenden administrativen Instanzen ist eine sinnvolle Eingrenzung der geografischen Region nicht gegeben. Begründet ist diese durch die bereits erwähnte Streuung von Autonomen Systemen beziehungsweise der Zuordnung mehrerer Adresspräfixe zu einem AS [42, 45, 39, 103, 91]. Durch den in Kapitel vorgestellten Subclustering-Algorithmus versuchen Padmanabhan et al. [90] diesem Problem entgegenzuwirken und trotzdem eine Geolokalisation zu ermöglichen (vergleiche Abbildung 2.4 und 2.12). Bachelorarbeit HT 2011 Seite 30

41 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Abbildung 2.12: Subclustering nicht anwendbar (vergleiche Abbildung 2.4) [115] Der von Moore et al. entwickelte NetGeo-Ansatz [84] sieht sich den gleichen Herausforderungen gegenüber wie GeoCluster. Dies ist durch die extensive Nutzung von Whois- Abfragen begründet, wodurch sich zusätzlich das Problem der übermäßigen Verbindungen zu den Whois-Servern ergibt [84]. Durch Caching der Abfragen wird allerdings versucht die Anzahl der Anfragen an die Registraturen zu minimieren, um so nicht durch die RIR des Missbrauchs bezichtigt zu werden. Die Genauigkeit der Lokalisation ist durch die Verwendung zusätzlicher Methoden zur Ergebnisverifikation wie DNS LOC RR und mehrsprachiger Datenbanken zur Analyse von Hostnamen als akkurater als die klassische Nutzung der Whois-Funktionalität zu bewerten. Es bleibt zu erwähnen, dass NetGeo seit 1999 nicht mehr weiterentwickelt wird, allerdings noch zur Verfügung steht [22] Geoservice-Anbieter The other side of the coin with geolocation databases is that, [...] their accuracy is more than questionable [42] [103] especially due to lack of information about the methodology used to build them. [52] Viele der von Geoservice-Betreibern angebotenen Lokalisationsverfahren basieren auf Datenbanken, welche Informationen über die zugewiesenen IP-Adressen beziehungsweise Subnetze vorhalten. Für gewöhnlich ist die Genauigkeit der Daten mangels vertrauenswürdiger Angaben zur Herkunft und Erhebung als fragwürdig zu bewerten [52, 100]. Bachelorarbeit HT 2011 Seite 31

42 KAPITEL 2. GEOLOKALISATIONSVERFAHREN Betreiber wie Quova [94] verwenden eigens patentierte Verfahren zur Erhebung [75], während Anbieter wie HostIP [50] auf die Unterstützung von Freiwilligen angewiesen sind, die ihre IP-Adresse und zugehörigen Standort bereitwillig zur Verfügung stellen [12]. Andere wiederum unterhalten, um zusätzliche Datensätze abgreifen zu können, Kontakte zu Partnerseiten, Behörden und Internet Service Providern. Somit basieren die vorgehaltenen Informationen einerseits auf der Annahme gegenseitigen Vertrauens zwischen Anbieter und Usern (bei HostIP) und anderseits auf Verfahren die entweder proprietär sind oder für objektive Dritte nicht nachvollziehbar [52, 12, 69]. Hinzu kommt, dass viele Datenbanken weder die konkrete Verteilung der IP-Adressbereiche, noch die BGP-Präfixe reflektieren [52]. Begründet ist dies neben anderen Faktoren durch den Versuch der Geoservice-Anbieter möglichst granulare Ergebnisse liefern zu können und somit der gegebenen Präfixe in weitere Subnetze zu unterteilen. Ein weiteres Problem der Nutzung von Geoservice-Datenbanken ist deren Konsistenz [53]. Das heißt, falls Inkonsistenzen innerhalb der Datensätze auftreten, können diese nur mittels regelmäßig einzuspielender Updates und Pflege unterbunden werden. Gerade in Hinblick auf IPv6 stellt die Verwaltung der Datenbanken eine derzeit noch nicht gelöste Herausforderung dar 48 [53]. Neueste Studien [52, 12] untersuchen die Genauigkeit und Glaubwürdigkeit ausgewählter Datenbanken von Geoservice-Betreibern. Sie kommen zu dem überereinstimmenden Ergebnis, dass diese auf Landesebene akkurate und konsistente Resultate liefern 49. Auf Städteebene hängt die Genauigkeit der Lokalisation neben dem Bruttosozialprodukt eines Landes, auch unmittelbar mit dessen demografischer Beschaffenheit zusammen [52] Fazit Der vorangegangene Abschnitt zeigte auf, dass jede Strategie bestimmten Restriktionen unterliegt und lässt folglich den Schluss zu, dass eine kombinierte Lösung von verschiedenen Methoden eine durch Optimierung verbesserte Geolokalisation zulassen würde [91]. Here one can see that each strategy suffers from certain restrictions. Therefore the use of a well thought out hybrid technique may improve the geographic location estimation. As a result, a strategy that combines different locations inferences would offer better results, since these strategies obtain information from different sources to estimate geolocation. This is the starting point and main motivation [...] [91] Zudem können durch den Einsatz von hybriden Lösungsansätzen fragwürdige Sachverhalte wie beispielsweise durch wechselseitiges Vertrauen erlangte Daten hinsichtlich ihrer Genauigkeit verifiziert werden. Somit lassen sich absichtliche oder durch Verzerrungen verursachte Manipulationen und Verfälschungen aufdecken und berücksichtigen. 48 Die Ursache liegt unter anderem in der Erweiterung des IP-Adressraums auf Adressen begründet. 49 Nach Poese et al. [52] zwischen 96% bis 98%. Bachelorarbeit HT 2011 Seite 32

43 KAPITEL 3. ANGRIFFSVEKTOREN Kapitel 3 Angriffsvektoren Autor: Lars Stiemert Neben der reinen Positionsbestimmung von IP-Adressen ermöglichen nahezu alle Geolokalisationstrategien direkt oder indirekt Rückschlüsse auf sicherheitstechnische Aspekte in Relation auf die gesuchte Entität. Das mögliche Spektrum an Informationen ist vielfältig und reicht hierbei von Ausgangspunkten für Social Engineering 1 [61] über softwareseitige Schwachstellen bis hin zu Netz- respektive topologischen Zugangspunkten. Solche Informationen sind im Zeitalter der elektronischen Kampfführung und des Cyber War und Cyber Defense nicht nur für Militär und Behörden, sondern auch für Unternehmen und in gewisser Weise auch für den normalen Internetnutzer von elementarer Bedeutung. In welchem Umfang und in welcher Art und Weise diese Daten gewonnen und vor allem eingesetzt werden, hängt vom jeweiligem Anwendungszweck wie beispielsweise digitale Angriffe, Verteidigung oder sicherheitstechnischen Optimierungen ab. Das nachfolgende Kapitel soll einen Überblick über mögliche Verfahren zur Aufdeckung von Angriffsvektoren bei gleichzeitiger Minimierung der Detektierbarkeit liefern. Im Kontext der Aufgabenstellung erfolgt deswegen eine Konzentration auf Methoden respektive Applikationen, die nicht zum direkten Ausspähen von Daten beziehungsweise zur Umgehung von Sicherheitsvorkehrungen gemäß 202c Strafgesetzbuch 2 vorgesehen sind. 1 Beispielsweise die Ermittlung von Kontaktdaten via Whois-Abfragen. 2 Sogenannter Hackerparagraf, offiziell Vorbereiten des Ausspähens und Abfangens von Daten. Bachelorarbeit HT 2011 Seite 33

44 KAPITEL 3. ANGRIFFSVEKTOREN 3.1 Verfahren im Überblick Die im Folgenden skizzierten Verfahren stellen nur eine kleine Auswahl dessen dar, was im Bereich der Sicherheitsanalyse von IT-System zur erweiterten Informationsgewinnung möglich ist, da der Analyst in seiner Handlungsfreiheit kaum eingeschränkt ist. Um relevante Methoden unter Beachtung des 202c Strafgesetzbuch auf die wesentlichen zu beschränken, erfolgt eine Orientierung an den ersten beiden Phasen eines Penetration Tests 3 nach dem Standard des International Council of E-Commerce Consultants (EC-Council) [55] (vergleiche Abbildung 3.1). Bei der Durchführung eines Penetration Tests erfolgt die Unterscheidung in fünf beziehungsweise sechs Phasen: Abbildung 3.1: Phasen eines Penetration Test gemäß EC-Council [76]. Reconnaissance beschreibt hierbei alle Schritte zur ersten Informationsbeschaffung über eine Zielumgebung 4 [74, 76]. Darauf aufbauend werden in der Phase Enumeration Applikationen und Techniken zur Ermittlung tiefgreifender Informationen angewendet 5, um so mögliche Einstiegspunkte beziehungsweise Angriffsvektoren für die folgenden Phasen beziehen zu können [76]. 3 Bei einem Penetration Test geht es also nicht nur darum, potentielle Schwachstellen zu ermitteln, sondern Sicherheitslücken als solche zu beweisen (Proof-of-Concept) und damit ihr tatsächliches Risiko zu bestimmen. [74, Seite 58] 4 Beispielsweise Abfragen mittels des Whois-Dienstes [74]. 5 Beispielsweise Techniken wie Port Scanning [74, 76] Bachelorarbeit HT 2011 Seite 34

45 KAPITEL 3. ANGRIFFSVEKTOREN Reconnaissance - Footprinting Wissen ist Macht - dies gilt natürlich auch für die elektronische Kriegsführung. Aus diesem Grund ist es vor einem Angriff von nicht zu unterschätzender Wichtigkeit, sich zuerst umfassend über sein Ziel zu informieren. Dieses erste Vorgehen wird als Footprinting bezeichnet [74, Seite 87] Footprinting bezeichnet das erste Sammeln von Informationen zu einer Zielentität ohne dabei bewusst mit dieser interaktiv zu kommunizieren. Der Vielfältigkeit an Möglichkeiten zur Informationsgewinnung im Kontext des Footprinting sind hierbei keine Grenzen gesetzt. Auch dienen gewonnene Daten der Verifikation bereits vorhandener und deren Widerlegung beziehungsweise Erweiterung [74]. Als möglicher Informationsursprung kommen hierbei hauptsächlich öffentliche verfügbare Quellen wie die Datenbestände der Regional Internet Registries infrage (vergleiche Listing 2.4). Die so gewonnenen Daten können beispielsweise anschließend zur erweiterten Informationsgewinnung an Index-Suchmaschinen übergeben werden 6 [74]. Weitere Quellen entstehen durch eventuell vorhandene Webpräsenzen im Zusammenhang mit der Zielentität. Diese erlauben nicht nur Rückschlüsse auf geografische Beschaffenheit und Kontaktdaten, sondern auch mittels Analyse des HTML 7 -Quelltext Zugriff auf erweiterte Informationen (vergleiche Listing 3.1 [74, Seite 95]) [74]. [...] verheerend sind [...] Informationen mit Hinweisen auf Authentifizierungs- Mechanismen. Angaben über Benutzername/Passwort-Kombinationen stehen oft in größeren Projekten, um auch den anderen Entwicklern [...] Zugriff ermöglichen zu können [74, Seite 95]... <html> <head> <! Kommentar : Das FTP Passwort l a u t e t 1234 > <t i t l e>text des T i t e l s</ t i t l e> </head> <body> I n h a l t des Dokuments </body> </html> Listing 3.1: Nutzbare Informationen aus HTML-Quelltexten Als weitere Quelle zur Ermittlung von Ausgangspunkten für ein weiteres Vorgehen bieten sich Netzwerkabfragen an. Hier sind besonders Abfragen der DNS Ressource Record aufschlussreich (vergleiche 2.3), da sich mittels derer ein erstes Bild des Zielnetz ergeben 6 Suchmaschinen wie Google bieten zur Suche eine eigene Syntax an, die für eigene Zwecke ausgenutzt werden kann (vergleiche Google Hacking [71]). 7 Die Hypertext Markup Language, beschreibt eine Auszeichnungssprache für Webinhalte. Bachelorarbeit HT 2011 Seite 35

46 KAPITEL 3. ANGRIFFSVEKTOREN kann 8. Zur Bestimmung der Subnetzgröße zu einer Zielentität stehen Techniken wie Broadcast Pings oder ICMP Mapping mittels des ICMP address mask Typ 17 zur Verfügung [74, Kapitel 4 und 5]. Eine weitere Form der Netzabfrage dient der Aufdeckung (Mapping) aktiver Systeme. Hierfür stehen verschiedenste Techniken unter Nutzung unterschiedlicher Protokolle und Zustände 9 zur Wahl [74]. Mittels Routetracing lassen sich im Kontext der Aufgabenstellung nicht nur Hinweise auf geografische Gegebenheiten, sondern auch Informationen zu Zugriffspfaden und möglichen Security Appliances wie Firewalls ermitteln. Anhand der Namensgebung und dem Verhalten der Datenpakete an bestimmten Netzknoten lassen sich Rückschlüsse auf deren Funktion oder Konfiguration schließen (vergleiche Listing ) [74, 76, 96]. Beispiel zur Interpretation von FQDN eines Netzknotens nach Steenbergen [96, Seite 19]: xe edge1.newyork1.level3.net XE-#/#/# is Juniper 10GE port. The device has at least 12 slots. It s at least a 40G/slot router since it has a 10GE PIC in slot 1. It must be Juniper MX960, no other device could fit this profile Enumeration Um mögliche Zugangspunkte zur Zielumgebung aufdecken zu können, werden aufbauend auf den bereits erlangten Informationen erweitere Techniken genutzt. Diese basieren häufig auf der direkten Kommunikation mit der Zielentität und sind durch diese Interaktion am Perimeter detektierbar. Die Detektionswahrscheinlichkeit korreliert hierbei stark mit der gewählten Methode beziehungsweise deren Abwandlungen 11. Ein elementarer Bestandteil der Enumeration besteht in der Ermittlung aktiver Dienste auf dem Zielsystem. Dies kann mittels des sogenannten Port Scanning erfolgen, wobei der Status eines Ports, im Kontext des klassischen TCP/IP nach Stevens [116], ermittelt wird. Die Unterscheidung erfolgt hierbei in drei Stati [74]: Open: Der Port befindet sich im LISTENING-Status, das heißt eine Netzapplikation wartet an dieser Stelle auf eine Verbindungsaufnahme. 8 Dies trifft vor allem dann zu, wenn ein DNS-Zonentransfer möglich ist. 9 Beispielsweise Flag-Setzung bei TCP. 10 Der Netzknoten fw.munich.local lässt aufgrund der Namensgebung (fw) und dem scheinbaren Verwerfen von Datenpaketen (ab Zeile 4) auf eine Firewall schließen. 11 Vergleiche half-open SYN-Scan versus full-connect TCP-Scan [74, Kapitel 6]. Bachelorarbeit HT 2011 Seite 36

47 KAPITEL 3. ANGRIFFSVEKTOREN Closed: Der Port befindet sich im CLOSED-Status, dies heißt es wird an dieser Stelle kein Dienst angeboten. Filtered: Der Port befindet sich in diesem Zustand, wenn auf die Anfragen seitens des Analysten keinerlei Reaktionen erfolgen. Dies ist zumeist ein Hinweis auf eine filternde Instanz wie Firewalls. Nachdem aktive Dienste ermittelt wurden, erfolgt als zweiter Schritt die Identifikation der auf offenen Ports lauschenden Netzapplikationen. Dieses Verfahren wird auch als Application Mapping bezeichnet [76, 74]. Hierbei lassen sich nicht nur Rückschlüsse auf die verwendete Software schließen, sondern gleichzeitig auch auf deren Version sowie möglicherweise Konfiguration und der damit verbundenen Verwundbarkeit dieser [76]. Die Grundlage für diese Technik bildet unter anderem die von der IANA [56] publizierte Zuordnung ausgewählter Ports zu einer bestimmten Applikation [57]. Eine weitere Technik ist das sogenannte OS-Fingerprinting 12 bei dem versucht wird Rückschlüsse auf das verwendete Betriebsystem ziehen zu können [74]. Dieses Verfahren basiert auf den Eigenheiten eines jeden Betriebssystems oder auch einer Gruppe von Betriebssystemen 13 die dieses im Idealfall wie eine Art Fingerabdruck identifizieren [74]. Zudem macht sich die Technik in RFC nicht konkretisierte Verhaltensregeln oder auch mangelnde Umsetzung derer zunutze 14, wodurch Betriebssysteme unterschiedliche Implementierungen des selben RFC aufweisen können und somit eine Identifikation derer ermöglicht wird. 3.2 Ausgewählte Techniken am Beispiel von Nmap Der vorgegebene, zeitlich beschränkte, Rahmen dieser Arbeit bedingt, dass im Folgenden nur auf für die Implementierung im Kontext des Proof-of-Concept relevanten Techniken eingegangen wird. Zur Illustration dient das von Gordon Fyodor Lyon entwickelte Nmap 15. Die unter Listing 3.2 aufgeführte Anwendung von Nmap stellt einen möglichen Implementierungsansatz unter Berücksichtigung ausgewählter Strategien zur Ermittlung von Angriffsvektoren dar. Um rechtliche Vorkommnisse zu vermeiden, erfolgte das dargestellte Scenario ausschließlich nach vorheriger Rücksprache mit Eigentümer der unter der IP-Adresse erreichbaren Domain. 12 An enumeration technique used to provide information about a computer system; generally used for operating system identification (also known as fingerprinting). [76, Seite 342] 13 Beispielsweise weisen unixoide Betriebssysteme ähnliche Charakteristika auf und können aus diesem Grund nicht immer genau hinsichtlich einer Distribution oder ähnlichem ermittelt werden. 14 Beispielsweise die Einhaltung der maximalen Länge von ICMP-Nachrichten, welche bei Nichteinhaltung zum Beispiel bei Windows durch das Versenden überlanger Pakete, unter anderem dem sogenannten Ping of Death, zum Blue Screen of Death führen kann. 15 Network Mapper. Bachelorarbeit HT 2011 Seite 37

48 KAPITEL 3. ANGRIFFSVEKTOREN 1 metatron : # nmap -PP -ss -sv -O osscan-guess -T3 -f reason -n S t a r t i n g Nmap 5.00 ( http : / /nmap. org ) at :15 CET Not shown : 980 c l o s e d p o r t s 6 Reason : 980 r e s e t s PORT STATE SERVICE REASON VERSION 9 25/ tcp f i l t e r e d smtp no response 10 53/ tcp f i l t e r e d domain no response 11 80/ tcp open http syn ack l i g h t t p d / tcp f i l t e r e d nntp no response / tcp f i l t e r e d netbios ssn no response / t c p open imap syn ack Dovecot imapd / tcp open s s l / http syn ack l i g h t t p d / tcp f i l t e r e d microsoft ds no response / tcp open smtp syn ack P o s t f i x smtpd / tcp f i l t e r e d submission no response / t c p open s s l / imap syn ack Dovecot imapd / tcp f i l t e r e d ms sql s no response / tcp f i l t e r e d o r a c l e no response / t c p open unknown syn ack / tcp open http syn ack I c e c a s t plugin / t c p open unknown syn ack / tcp open ssh syn ack OpenSSH ( p r o t o c o l 2. 0 ) Device type : g e n e r a l purpose WAP Running (JUST GUESSING) : 30 Linux 2. 6.X 2. 4.X (88%), Linksys Linux 2. 4.X (86%) Aggressive OS g u e s s e s : 33 Linux (88%), Linux ( Fedora Core 6) (87%), No exact OS matches for host ( test c o n d i t i o n s non i d e a l ) S e r v i c e I n f o : Host : mail. minad. de Nmap done : 1 IP address (1 host up ) scanned in seconds Listing 3.2: Ausgewählte Verfahren am Beispiel von Nmap Bachelorarbeit HT 2011 Seite 38

49 KAPITEL 3. ANGRIFFSVEKTOREN Zeile 1: Aufruf des Programms Nmap mit den folgenden Parametern [41]: -PP Ermittlung der Netzmaske zur gescannten IP-Adresse, um so Rückschlüsse auf die mögliche Anzahl an Hosts schließen zu können. Aufgrund der restriktiven Einstellungen der meisten Netzknoten bleibt dieser Versuch mittels ICMP Typ 17 oft erfolglos [74]. -sv Dieses Flag ermöglicht die Anwendung des bereits besprochenen Application Mappings, um die Version aktiver Dienste zu identifizieren. Beispielsweise wartet auf Port 80 der Lighthttp-Daemon auf Verbindungen, um anfragenden Clients den HTTP-Webdienst anbieten zu können (vergleiche Zeile 9). -O - -osscan-guess Zur Erkennung des Betriebssystems setzt Nmap auf eine umfangreiche Datenbank von Fingerprints [41] (-O) oder versucht mittels der aktiven Dienste bestimmte Betriebssystem-Charakteristika zu identifizieren und darüber eine Zuordnung zu ermöglichen ( osscan-guess). -ss - -reason Half-open SYN-Scans (-ss) nutzen die Funktionsweise des Three Way Handshake nach Stevens [116] aus. Im Prinzip funktioniert die Verbindungsaufnahme zwischen Client 16 und Server wie vorgeschrieben, allerdings wartet der Client nur die erste Antwort des Servers ab und beendet dann die Verbindung. Antwortet der Server mit gesetztem SYN/ACK-Flag, zeigt dies eine aktive Applikation auf diesem Port an (Status: OPEN ). Bleibt eine Reaktion seitens des Servers aus (-reason) wird der Port als FILTERED markiert. Sollte keine Applikation auf dem getesteten Port lauschen, befindet sich dieser im Status CLOSED [41, 47]. Vorteil dieser Technik ist, dass sie relativ unauffällig 17 und performant in der Ausführung ist [41]. Nachteilig wirkt sich hingegen die Vorausetzung von Superuser-Rechten aus. Diese werden benötigt, um Pakete mit gesetztem RST-Flag zu versenden. -f -T3 Zur Minimierung der Detektionswahrscheinlichkeit seitens Intrusion Detektion Systeme oder Firewall bietet sich die Möglichkeit der Fragmentierung von IP-Paketen an (-f). Die Idee dahinter ist, den TCP-Header auf mehrere Pakete zu verteilen und so Security Applliances zu täuschen, da das erste Paket 16 Hier: Angreifer. 17 Geringe Gefahr durch Logging [47]. Bachelorarbeit HT 2011 Seite 39

50 KAPITEL 3. ANGRIFFSVEKTOREN weder Payload noch Flags, sondern nur Ziel und Quelladresse enthält [47]. Eine weitere Methode um die Auffälligkeit am Perimeter zu reduzieren, besteht in der Variation des Timings und Anzahl parallel laufender Scans (-T). Die Wahl der Agressivität (1-5) ist hierbei nicht nur durch die Detektionswahrscheinlichkeit bedingt, sondern auch über die verfügbare Bandbreite [41]. -n $IP-Adresse Um die Performance von Nmap zu erhöhen, ist es oft sinnvoll auf eine DNS- Namensauflösung zu verzichten (-n). Im Rahmen einer auf FQDN -Analyse basierenden Geolokalisationsstrategie bleibt dies auch anzuraten. Aufgrund dessen kann eine zusätzliche Netzlast vermieden werden, da bereits Routetracing eine vollständige Namensauflösung zur Folge hat. Zeile 5-25: Endresultat des Port Scans der well known Ports [57] sowie der ermittelten Softwareversionen. Zeile 29-35: Vermutete Version des Betriebssystems aufgrund von OS-Fingerprinting. Zeile 37: Identifizierter DNS MX Record der zugehörigen Domain Minad.de. Verfahren wie die Suche mittels Index-Suchmaschinen werden aus den bereits erwähnten Zeitgründen nicht für eine Implementierung in Betracht gezogen, zumal die Anwendung in den meisten Fällen nicht automatisiert werden kann. Der Großteil der anderen umrissenen Techniken kann, wie im Listing 3.2 aufgeführt, mittels Nmap leicht und ohne großen Aufwand an Ressourcen in den Proof-of-Concept integriert werden. Bachelorarbeit HT 2011 Seite 40

51 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Kapitel 4 Konzepte zu relevanten Ansätzen Autor: Lars Stiemert Wie im Fazit unter bereits festgestellt, ist die Verwendung von lediglich einer Geolokalisationsstrategie nicht sinnvoll, da jede eigenen Restriktionen unterliegt. Folglich muss zur Steigerung der Effizienz und Genauigkeit eine sinnvolle hybride Lösung gefunden werden. Aufgrund der beschränkten Ressourcen die für eine Lösung der Aufgabenstellung zur Verfügung stehen wird ein Konzept entwickelt, dass sich auf öffentlich zugängliche, ressourcenschonende sowie nicht kommerzielle Ansätze stützt. Unter Beachtung dieses Aspekts beschreibt das folgende Kapitel die allgemeine Konzeptionierung einer Geolokalisationstategie aus einer Auswahl der in Kapitel 2 vorgestellten Methoden. Dazu erfolgt im ersten Teil eine kurze Vorüberlegung, warum verschiedene Ansätze nicht weiter betrrachtet werden. Im Anschluss daran wird auf die Gründe für den Einsatz ausgewählter Strategien eingegangen, um sie dann anhand von Pseudocode- Listings einzeln zu skizzieren. Hierbei wird bereits ein direkter Bezug auf möglich einzusetzende Applikationen hergestellt. Es werden hierbei ausschließlich mögliche Konzepte beschrieben, diese besitzen allerdings keinen Anspruch auf Vollständigkeit oder tatsächliche Umsetzung im Proof-of-Concept. Die Pseudoalgorithmen sind somit nur als möglicher Anhalt für die spätere Implementierung zu erachten. Wie die relevanten Methoden im Konkreten umgesetzt werden, wird im Kapitel 6 beschrieben. Bachelorarbeit HT 2011 Seite 41

52 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN 4.1 Vorüberlegung Alle auf aktive Latenzmessungen basierenden Verfahren werden unter Berücksichtigung der beschränkt zur Verfügung stehenden Ressourcen nicht weiter betrachtet. Hierzu zählen GeoPing [90], CBG [43], TBG [63] sowie das Octant-Framework [118]. Hauptproblem bei diesen Ansätzen ist die Voraussetzung einer ausreichenden Menge an nutzbaren Landmarks, die zudem geografisch sinnvoll verteilt sein müssen. Auch wenn eine ausreichende Anzahl an Landmarks zur Verfügung stehen würde, sind Ansätze basierend auf Messung von Verzögerungswerten nicht performant und für den alltäglichen Gebrauch verwendbar. Da NetGeo [84] 1999 offiziell eingestellt und nicht mehr weiterentwickelt wird [22] sowie als webbasierende Lösung nicht mehr in vollem Umfang nutzbar ist, wird dieser Ansatz für weiteren Überlegungen nicht mehr in Betracht gezogen. NetGeo has not been actively maintained since 1999, and this will probably not change in the foreseeable future. As a result, there are several known major issues affecting accuracy and service availability. Please be warned that NetGeo may give wildly incorrect results, especially for recently allocated or re-assigned IP addresses. [22] Nichtsdestotrotz sind die Informationen über die Funktionsweise von NetGeo in Bezug auf Whois-Abfragen und Pattern-Matching 1 von elementarer Bedeutung für die Konzeption einer hybriden Geolokalisationsstrategie. GeoCluster und GeoTrack [90] sind mangels Zugang zu den erforderlichen Informationen 2 für ein Implementierung im Rahmen eines Proof-of-Concept nicht vorgesehen. Allerdings lassen sich Ideen wie die Analyse von Hostnamen konzeptionell verarbeiten. 4.2 Relevante Lokalisationsstrategien Auswertung von Geo-Datenbanken Für die Entwicklung einer hybriden Geolokalisationsstrategie ist die Nutzung der Datenbanken von Geoservice-Anbietern eine Grundfeste für weitere Untersuchungen. Obwohl die Genauigkeit und Glaubwürdigkeit der Datenbanken als fragwürdig gilt [52, 120, 12, 103], lässt sich trotzdem eine akkurate 3 geografische Einordnung auf Landesebene vornehmen [52]. Somit bildet die Allokation der gesuchten IP-Adresse zu einem Land mittels Anwendung von Geo-Datenbanken eine solide Basis für beispielsweise die Einschränkung der für ein Pattern-Matching verwendeteten Sprache oder Codes. 1 [...] Pattern-Matching [...], bei dem nach spezifischen Mustern (pattern) eine Übereinstimmung (to match) gesucht wird. [74, Seite 88] 2 Genutzte Algorithmen scheinen nicht öffentlich zugänglich zu sein. 3 Nach Poese et al. erfolgt in 96%-98% der Testfälle eine korrekte Zuordnung auf Landesebene [52]. Bachelorarbeit HT 2011 Seite 42

53 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Weiterhin bildet die Verwendung mehrerer Geo-Datenbanken eine breite Datenbasis (vergleiche Tabelle 4.1), auf Grundlage derer die jeweiligen Ergebnisse wechselseitig verifiziert werden können und eine geografische Zuordnung des IP-Adressraum ermöglicht wird 4 [52, 12]. Gegebene finanzielle Restriktionen beschränken die Auswahl der in Frage kommenden Geoservice-Betreiber auf nicht kommerzielle Anbieter. Um für eine weitere Nutzung Aussagen über die Genauigkeit der Geo-Datenbanken treffen zu können werden nur Anbieter betrachtet, die bereits durch empirische Studien [52, 120, 12, 103] untersucht wurden. Unter Berücksichtigung der aufgeführten Restriktionen beschränkt sich die Wahl auf die Datenbestände der Anbieter HostIP, MaxMind, IP2Location und IPInfoDB [50, 78, 60, 119], wobei lediglich die Datenbanken von HostIP und IPInfoDB kostenfrei sind. Von IP2Location und MaxMind werden die kostenfreien Versionen der angebotenen Datenbanken genutzt 5. Ein weiterer Vorteil der gewählten Geoservice-Betreiber ist die unentgeldliche Bereitstellung von regelmäßgen Updates, die zum Teil wöchentlich von der Webseite des jeweiligen Anbieters bezogen werden können. Es bleibt zu erwähnen, dass die Ergebnisse zur Abfrage der gesuchten IP-Adresse abschließend anbieterspezifisch hinsichtlich Genauigkeit gewichtet werden müssen, um eine möglichst akkurate Ausgangsbasis für weitere Anwendungen bilden zu können. Tabelle 4.1: Übersicht der Anzahl an Datensätze der einzelnen Geo-Datenbanken [52] Anbieter Adressblöcke Lat/Long Anzahl Länder Anzahl Städte HostIP IP2Location InfoDB MaxMind Algorithmus 4.1 skizziert Geolokalisation durch Nutzung von Geo-Datenbank ausgewählter Geoservice-Anbieter: Nach erfolgter Abfrage der einzelnen Datenbanken mit Hilfe der gesuchten IP-Adresse werden die Ergebnisse verglichen und anbieterspezifisch gewichtet. 4 HostIP verwendet beispielsweise /24-Adresspräfixe zur Zuordnung einer IP-Adresse, während Max- Mind diese weiter aufsplittet um granulare Ergebnisse liefern zu können [52]. 5 Die Genauigkeit und Anzahl der Datensätze ist hierbei aufgrund der unterschiedlichen Adressblöcke geringfügig reduziert. Bachelorarbeit HT 2011 Seite 43

54 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Algorithmus 4.1 Anwendung von Geo-Datenbanken function GeoDb(String ipadresse) Array[String] loc Ergebnisse der einzelnen Abfragen, initalisiert mit 0 Int p = 0 Wahrscheinlichkeit function SameResults(String location) Int HelpVar = 0 if $location == $loc[0] then HelpVar += Wahrscheinlichkeit von HostIP end if if $location == $loc[1] then HelpVar += Wahrscheinlichkeit von MaxMind end if if $location == $loc[2] then HelpVar += Wahrscheinlichkeit von IpInfoDB end if if $location == $loc[3] then HelpVar += Wahrscheinlichkeit von IP2Location end if return $HelpVar end function Hilfsvariable Abfrage HostIP-Datenbank zu $ipadresse $loc[0] Abfrage MaxMnd-Datenbank zu $ipadresse $loc[1] Abfrage IPInfoDB-Datenbank zu $ipadresse $loc[2] Abfrage IP2Location-Datenbank zu $ipadresse $loc[3] if $loc[0]!= 0 then $p = SameResults($loc[0]) return ($loc[0], $p) end if if $loc[1]!= 0 && $loc[1]!= $loc[0] then $p = SameResults($loc[1]) return ($loc[1], $p) end if if $loc[2]!= 0 && $loc[2]!= $loc[1] && $loc[2]!= $loc[0] then $p = SameResults($loc[2]) return ($loc[2], $p) end if if $loc[3]!= 0 && $loc[3]!= $loc[2] && $loc[3]!= $loc[1] && $loc[3]!= $loc[0] then $p = SameResults($loc[3]) return ($loc[3], $p) end if end function Bachelorarbeit HT 2011 Seite 44

55 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Analyse von Full-Qualified Domain Names Mangels Vorlage der ursprünglichen Algorithmen ist eine Implementierung des von Padmanabhan et al. entwickelten GeoTrack [90] nicht möglich. Die Grundidee der Untersuchung beziehungsweise Deutung von FQDN auf geografische Hinweise ist dennoch einer konzeptuellen Berücksichtigung wert. Nach Steenbergen [96] kann die Interpretation von Routetracing Resultaten hinsichtlich der Hostnamen, Aufschluss über die geografische Position und Typ des Netzknotens geben. Weitere ableitbare Informationen sind Netzwerkgrenzen und individuelle Merkmale der einzelnen Router. Der Einsatz von Routetracing ist aufgrund der zu erhebenden Topologiemessungen nicht als performant zu bewerten, lässt sich aber trotzdem leicht implementieren und verarbeiten. GeoTrack setzt zur Identifikation von zu untersuchenden Knoten auf die Traceroute- Applikation [32, 90]. Der Vorteil dieses Programms ist, dass es in der Grundkonfiguration nahezu jeden Betriebssystems implementiert ist [96]. Da klassische Traceroute-Derivate bei asynchronen Routing Probleme aufweisen und möglicherweise nicht den korrekten Netzpfad darstellen [15, 85, 77, 121], wird eine Applikation wie Paris Traceroute [17] benötigt, die trotz derlei Komplikationen zu einem nutzbaren Endergebnis führt (vergleiche Abbildung 4.1) [16]. Abbildung 4.1: Vergleich klassische Traceroute-Varianten und Paris Traceroute [17]. Vorgehen gängiger Traceroute-Derivate und die daraus ableitbare Pfaddarstellung und der im Idealfall auflösbare Netzpfad durch Paris Traceroute im Vergleich [17]. Bachelorarbeit HT 2011 Seite 45

56 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Die Wahrscheinlichkeit zur Auflösung eines kompletten Netzwerkpfads steigt durch den Einsatz differenzierten Routetracing mittels der TCP, UDP und ICMP Netzwerkprotokolle [96, 74]. Während klassische unixoide Traceroute-Anwendungen UDP-Pakete sowie als Standard Zielport verwenden, stützt sich das Windows-Pendant auf das ICMP-Protokoll. Problematisch bei beiden Anwendungen ist das Verhalten von UDP und ICMP an Security Appliances [74, 105, 41], vor allem in Verbindung mit den standardisierten Port und ICMP-Typen 6. Auch die generelle Nutzung des TCP Protokolls stellt keinen idealen Lösungsansatz dar, wirkt sich allerdings positiv auf die Detektierbarkeit am Perimeter eines Netzes aus. TCP is a poor choice for general use (frequently filtered), typically only seen as a method to work around specific firewalls. [96, Seite 7] Es liegt folglich nahe, eine Kombination von unterschiedlichen Protokollen und Algorithmen 7 zur vollständigen Aufklärung des Netzpfades zwischen Quelle und Senke zu implementieren. Gesetzt den Fall, dass der Pfad trotzdem nicht vollständig ermittelt werden kann, ist davon auszugehen, dass dieser zumindest in unterschiedlichen Ausprägungen 8 vorliegen wird. Über einen Vergleich der genutzten Verfahren hinsichtlich der aufgedeckten Hops lässt sich ermitteln, welche Ausgabe letzten Endes für eine weitere Verarbeitung dienlich ist. Das von Michael C. Toren entwickelte Programm TCPTraceroute [80] ist eine Routetracing-Implementierung unter Nutzung von TCP-Paketen auf Zielport 80. Im Gegensatz zu dem von Van Jacobson entwickelten Traceroute nutzt TCPTraceroute TCP Pakete mit gesetztem SYN Flag, was einer Firewall beziehungsweise einem Intrusion Detection System signalisiert, dass ein Verbindungsaufbau vom internen Netz aus initialisiert wurde und die Pakete einer halboffenen Verbindung zugeordnet und durchgelassen werden können 9 [19, 74]. Ein weitere Vorteil hierbei ist, dass TCP-Pakete die zu einem offenen Port führen, etwa Port 80 eines Webservers, eine hohe Wahrscheinlichkeit aufweisen nicht geblockt zu werden, da sie für Router und Firewalls im Normalfall eine legale Kommunikation darstellen [19]. Zur Untersuchung auf geografische Hinweise herangezogen werden neben dem FQDN der Zieladresse auch die beiden vorangegangenen Hops. Es ist nach Dischinger et al. [34] sowie Bovy et al. [18] davon auszugehen, dass sich einer oder auch beide Knoten im Einzugsbereich der gesuchten Entität befinden und somit ebenfalls Aufschluss über eine geografische Positionierung geben können 10. Eine weitere Annahme basiert auf der Analyse der FQDN von Nameservern, welche für 6 Hier: ICMP Destination Unreachable. und ICMP Echo Response [96, 116]. 7 Vergleiche hierzu Manual Page Paris Traceroute [17]. 8 Hier: Anzahl aufgedeckter Hops. 9 Hier: Ausnutzung des geregelten Three-Way-Handshakes zum Aufbau einer TCP-Verbindung [116]. 10 Gerade bei DSL- und Kabel-Nutzern wird dabei auf die Letzte Meile Bezug genommen. Bachelorarbeit HT 2011 Seite 46

57 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN den Adressbereich beziehungsweise Zone der gesuchten IP-Adresse zuständig ist. Gemäß Gummadi et al. [62] und Leonard et al. [30] befinden sich autoritative Nameserver aus Performancegründen sowie zur Reduktion der Netzlast in geografischer Nähe der zu verwaltenden Zone. Um den Primär zuständigen Nameserver zu identifizieren, bietet sich die Abfrage des Start of Authority Record (SOA) an. Dieser beinhaltet neben einer Mailadresse des Hauptverantwortlichen auch den primären Namesserver (vergleiche Listing 4.1) 11. : / home/ tron# dig -t SOA unibw.de ; <<>> DiG 9.6 ESV R4 P3 <<>> t SOA unibw. de... ; ; ANSWER SECTION: unibw. de IN SOA dns01. rz. unibw muenchen. de. hostmaster. unibw. de. ; ; AUTHORITY SECTION: unibw. de IN NS ws kar1. win ip. dfn. de. unibw. de IN NS dns03. rz. unibw muenchen. de. unibw. de IN NS dns01. rz. unibw muenchen. de. ; ; ADDITIONAL SECTION: dns01. rz. unibw muenchen. de IN A dns03. rz. unibw muenchen. de IN A ws kar1. win ip. dfn. de IN A Listing 4.1: Identifizierung des primären Nameservers mittels Abfrage des Start of Authority Record Sobald alle relevanten FQDN ermittelten wurden, werden diese mittels Pattern-Matching und regulärer Ausdrücke auf geografische Hinweise untersucht. Die Basis dafür bildet eine kumulierte Datenbank mit Länder-, Städte-, Region- sowie Flughafencodes der International Air Transport Asscociation (IATA) [54] und zusätzlich Funkfeuercodes 12. Algorithmus 4.2 und 4.3 skizzieren einen möglichen Ansatz zur IP-Adress Lokalisation mittels der Untersuchung von FQDN auf geografische Hinweise: Mit Hilfe von Routetracing und DNS-Abfragen erfolgt die Identifizierung aller relevanten Knoten und Hosts, die anschließend auf Grundlage von vorgehaltenen Codes sowie Pattern-Matching analysiert werden. 11 Bei der Mailadresse des zuständigen Administrators wird hierbei anstelle eines at -Zeichens ein Punkt verwendet. 12 VHF omnidirectional radio range (VOR). Bachelorarbeit HT 2011 Seite 47

58 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Algorithmus 4.2 Analyse von FQDN (Teil 1) Require: RouteTracing, CompareByHop Vergleiche Algorithmus 4.3 function FqdnAnalysis(String ipadresse) String locns Array[String] loctrace geograf. Position via Nameserver geograf. Positionen via einzelner Hops function GetNameserver(String ipadresse) String ns FQDN des Nameservers Auslesen des primären Nameservers zu $ipadresse $ns return $ns end function function CheckFqdnWithDb(String fqdn) Array[String] splitfqdn String geoinfo for all segment in $splitfqdn[0...n] do segmentierter FQDN extrahierte geografische Position Extraktion der geografischen Postion via $splitfqdn[i] $geoinfo end for return $geoinfo end function function CheckHopsOfTrace(Array[String] trace) Array[String] geoinfos extrahierte Geo-Informationen der Hops for all hops in $trace[0...n] do CheckFqdnWithDb(i) $geoinfos[i] end for return $geoinfos end function locns = CheckFqdnWithDb(GetNameserver($ipAdresse)) loctrace =CheckHopsOfTrace(RouteTracing($ipAdresse)) if $locns in $loctrace[0...n] then return $locns else $locns $loctrace[n+1] return $loctrace end if end function Bachelorarbeit HT 2011 Seite 48

59 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Algorithmus 4.3 Analyse von FQDN (Teil 2) function CompareByHop(Array[String] trace1, Array[String] trace2) Int counta, countb = 0 Hilfsvariablen for i = length($trace1), i > 0, i do for j = length($trace2), j > 0, j do if $trace1[$i] == $trace2[$j] && $i >= $j then return $trace1 else if $trace1[$i] == $trace2[$j] && $i < $j then return $trace2 end if $countb += 1 end for $counta +=1 end for end function function RouteTracing(String ipadresse) Array[String] trace Array[String] tracetcp Array[String] traceudp Array[String] traceicmp Hops des besten Trace alle Hops des Trace mittels TCP alle Hops des Trace mittels UDP alle Hops des Trace mittels ICMP TraceTCP $ipadresse $tracetcp TraceUDP $ipadresse $traceudp TraceICMP $ipadresse $traceicmp trace = CompareByHop(CompareByHop(traceUdp, traceicmp), tracetcp) return $trace end function Abfrage und Analyse der RIR-Datenbestände Die Nutzung der Regional Internet Registries stellt eine einfache und leistungsfähige Möglichkeit dar, um Angaben über eine eventuelle geografische Zuordnung beziehen zu können. Mit Hilfe des Whois-Protokolls und des gleichnamigen Dienstes ist es jedem Nutzer möglich diese Daten kostenfrei abzufragen 13. Aufgrund der Anfälligkeit für Manipulationen und möglicher globaler Streuung des Autonomen Systems, welches die gesuchte IP-Adresse beherbergt (vergleiche Kapitel 2), sollten die extrahierten Informationen nur in Verbindung mit anderen Geolokalisationsansätzen verwendet werden. 13 Der Whois-Dienst gehört zur Basisimplementierung nahezu jeden Betriebssystems. Bachelorarbeit HT 2011 Seite 49

60 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Algorithmus 4.4 skizziert eine mögliche Implementierung zur Geolokalisation mit Hilfe von Datenbeständen der RIR: Nach erfolgter Whois-Abfrage werden aus den gewonnen Daten alle geografischen Informationen mittels Pattern-Matching sowie regulärer Ausdrücke extrahiert und für eine weitere Verarbeitung aufbereitet zur Verfügung gestellt. Da der Aufruf einer Whois- Abfrage unter den meisten Betriebssystemen gleich ist, wird dieser innerhalb des Algorithmus direkt aufgeführt. Algorithmus 4.4 Abfrage und Analyse der RIR-Datenbestände mittels Whois function WhoisAll(String ipadresse) String location Resultat der Lokalisation function WhoisQueryAndAnalysis(String ipadresse) String rir verwaltende RIR String whois Ausgabe der Whois-Abfrage String geoinfo extrahierte Geoinformationen Identifikation der RIR, welche $ipadresse verwaltet $rir if $rir == ARIN then whois -h whois.arin.net $ipadresse $whois else if $rir == APNIC then whois -h whois.apnic.net $ipadresse $whois else if $rir == RIPE then whois -h whois.ripe.net $ipadresse $whois else if $rir == AfriNIC then whois -h whois.afrinic.net $ipadresse $whois else if $rir == LACNIC then whois -h whois.lacnic.net $ipadresse $whois else whois -h whois.iana.org $ipadresse $whois end if Pattern-Matching und regulärer Ausdrücke auf $whois $geoinfo return $geoinfo end function location = WhoisQueryAndAnalysis($ipAdresse) return $location end function Bachelorarbeit HT 2011 Seite 50

61 KAPITEL 4. KONZEPTE ZU RELEVANTEN ANSÄTZEN Auslesen DNS LOC RR Dem DNS LOC Resource Record [28] mangelt es zwar an flächendeckender Präsenz [53], allerdings stellt er eine öffentlich zugängliche Quelle dar, die leicht mittels DiG [59] oder QUERY-LOC [106] abzufragen ist (vergleiche Listing 4.2) und bei Vorhandensein eine Grundlage zur erweiterten Verifikation bereits vorhandener geografischer Angaben darstellt. Algorithmus 4.5 skizziert eine mögliche Implementierung zum Auslesen des DNS LOC RR zu einer gesuchten IP-Adresse: Algorithmus 4.5 Auslesen LOC Resource Record function DnsLocQuery(String ipadresse) String loc ausgelesener DNS LOC RR Auslesen LOC Resource Record zu $ipadresse $loc return $loc end function : / home/ tron# dig -t LOC caida.org ; <<>> DiG <<>> t LOC caida. org... caida. org. IN LOC N W m 30m 10m 10m... tron@metatron : / workdir / query loc 0.4.0# query-loc caida.org N W m 30.00m 10.00m 10.00m Listing 4.2: Abfrage DNS LOC Resource Record mittels DiG und QUERY-LOC Bachelorarbeit HT 2011 Seite 51

62 KAPITEL 5. DER WICHTUNGSALGORITHMUS Kapitel 5 Der Wichtungsalgorithmus Autor: Kay Gottschalk Durch die hohe Anzahl an möglichen Datenquellen soll in diesem Kapitel dargelegt werden, wie der damit einhergehenden Heterogenität in dem zu entwickelndem Proofof-Concept allgemein entgegengetreten werden kann. Anhand der Ausgangslage wird die Entwicklung eines (Wichtungs-)Algorithmus zur Verifizierung der zugrundeliegenden Datenbankergebnisse nachfolgend beschrieben und mögliche Fehlerquellen bei der Verarbeitung und Wichtung betrachtet. Analysiert man zunächst die theoretischen Aspekte eines Algorithmus, so ist dieser nach Cormen [110] eine definierte Rechenvorschrift, die eine Größe oder Menge an Größen als Eingabe verwendet und eine Ausgabe mit einer Menge an Größen erzeugt. In Anbetracht dessen stellt sich ein Algorithmus als eine Folge von Rechenschritten dar, bei der die Eingabe in eine Ausgabe umgewandelt wird. Eine Charakterisierung der Algorithmen kann nach Logofatu [35] anhand folgender Punkte erfolgen: Als Sequenz von Schritten, welche die Eingabe in die gewünschte Ausgabe transformiert. Als Menge von Anweisungen, die in einer endlichen Anzahl von Schritten eine korrekte Lösung zu den jeweiligen Instanzen des gegebenen Problems finden. Als Menge von Regeln zur Lösung eines Problems. Die Ausführung erfolgt maschinell oder manuell. Als Folge von Operationen zur Organisation von Daten in Datenstrukturen. Als Abstraktion eines Programms, das auf einem Rechnermodell oder einer physischen Maschine ausgeführt werden kann. Bachelorarbeit HT 2011 Seite 52

63 KAPITEL 5. DER WICHTUNGSALGORITHMUS Der zu entwickelnde Wichtungsalgorithmus wird daher als Menge von Anweisungen betrachtet, um die zugrunde liegenden Datensätze aus der Datenbank maschinell in einer endlichen Anzahl von Schritten zu verifizieren, zu wichten und in eine gewünschte Datenstruktur zu bringen. Als besondere Anforderung an den Algorithmus gilt es verschiedene Eventualitäten bei der Extraktion von Informationen zu betrachten sowie flexibel zu verarbeiten, um eine einheitliche Datenstruktur bei der Ausgabe gewährleisten zu können. 5.1 Der Algorithmus und seine Komponenten In diesem Teilkapitel wird ein Überblick über den entwickelten Algorithmus gewährt, seine einzelnen Bestandteile vorgestellt und der jeweilige Einfluss auf die Gewichtung beschrieben. Die Vielfältigkeit der Einflussfaktoren sowie die nicht garantierbare Akquisition einzelner Bestandteile 1 stellen wichtige Aspekte bei der Konzeption des Wichtungsalgorithmus dar. Die Wichtung im eigentlichen Sinne kann dabei nicht auf Grundlage einer fixen Datenmenge erfolgen und muss flexibel anpassbar sein. Gleichzeitig gilt es, vorhandene Abhängigkeiten bei der Validierung der Ergebnisse zu beachten (vergleiche Abbildung 5.1). Abbildung 5.1: Zusammenfassung der Kerneigenschaften des Wichtungsalgorithmus 1 Beispielsweise kostenpflichtige Geo-Datenbanken. Bachelorarbeit HT 2011 Seite 53

64 KAPITEL 5. DER WICHTUNGSALGORITHMUS Geo-Datenbanken In Bezug auf Kapitel 4.1.1, in dem bereits die Vorauswahl der genutzten Geoservice- Datenbanken begründet wird, behandelt der vorliegende Abschnitt die Wichtung der einzelnen Datenbanken und deren Einfluss auf den Algorithmus. Zur Verwendung kommen die Datenbanken der Anbieter HostIP, MaxMind, IP2Location und IPInfoDB [50, 78, 60, 119]. Ausgehend von einem Gesamtwert von 100 Prozent für die freien Geo-Datenbanken schneidet der Anbieter MaxMind mit dem insgesamt höchsten Einfluss von 50 Prozent ab. Die Wichtung erfolgt dabei ausschließlich auf Grundlage der Analyse empirischer Studien und deren Ergebnissen [52, 120, 12, 103]. So weisen die Datenbanken von MaxMind im direkten Vergleich die größte Anzahl an Städten sowie Längen- und Breitengradinformationen auf [52]. An zweiter Stelle folgt die Datenbank des Anbieters IPInfoDB mit 25 Prozent, wobei dies gemäß Poese et al. sowie Huffaker et al. [52, 12] der Verwendung der MaxMind Lite Version als Grundlage geschuldet ist. Der Anbieter IP2Location fließt mit 15 Prozent in die Wertung der Datenbanken ein. Die Abwertung des Anbieters ist der im Vergleich zu MaxMind und IPInfoDB hohen Fehlerrate bei der genauen Adressblockbestimmung geschuldet [52]. Als letzter Anbieter sei HostIP, mit einer Einflussnahme von zehn Prozent auf die Datenbankwertung genannt. Die Ursache liegt hierbei in der reinen Zusammensetzung der Datenbank auf Basis freiwillig und unentgeltlich bereitgestellter Angaben seitens der Anwender, welche nur schwer durch den Anbieter auf Genauigkeit hin zu verifizieren sind. Weiterhin ist die Lokalisierung bei diesem Anbieter auf /24-Blöcke begrenzt [52]. Datenbestände der Regional Internet Registries In Bezug auf die in Kapitel beschriebene Abfrage und Analyse von RIR-Datenbeständen bezieht sich dieser Abschnitt auf den Einfluss der Datensätze bezüglich des Wichtungsalgorithmus. Die Abfrage der Daten wird durch die kostenfreie Nutzung des Whois-Dienstes mittels des Whois-Protokolls ermöglicht. Die Datenbanken der Geoservice-Anbieter und deren Ergebnisse dienen als Ausgangsbasis für die Verifizierung seitens der RIR-Datenbestände (nähere Informationen siehe Kapitel 5.2). Die von den Regional Internet Registries vorgehaltenen Daten werden via Pattern-Matching sowie regulärer Ausdrücke untersucht, um so Geoinformationen zu extrahieren. Weiterhin muss eine Differenzierung vorgenommen werden, bei welcher Registratur die IP-Adresse vergeben ist, um die IP-Adresse bei der jeweiligen Vergabestelle direkt abfragen zu können 2. 2 Diese Notwendigkeit besteht mangels einheitlicher Abfrage und Ausgabe Schemata der einzelnen RIR. Bachelorarbeit HT 2011 Seite 54

65 KAPITEL 5. DER WICHTUNGSALGORITHMUS Städte-, Region-, Flughafen- und Funkfeuercodes Wie dem im Kapitel beschrieben GeoTrack [90] Ansatz ähnlich, ist die Analyse der FQDN auch für die nachfolgende Implementierung und Verifizierung des Standortes einer gesuchten Entität angedacht. Die FQDN werden anhand unterschiedlicher Datensätze zwecks geografischer Hinweise untersucht. Für die spätere Implementierung kann hierbei auf eine kumulierte Datenbank mit Städte-, Region- und Flughafencodes der IATA sowie VHF omnidirectional radio range (VOR) beziehungsweise Funkfeuercodes zugegriffen werden. Es erfolgt eine Analyse des FQDN der gesuchten netzfähigen Entität, des mittels SOA Record identifizierbaren primären Nameservers und der durch Routetracing ermittelten Hops im angenommen Einzugsbereichs des eigentlichen Zielsystems 3. Der durch die eigenen Datenbanken ermittelte Ländercode bezüglich der Position des Zielsystems wird zur Eingrenzung der zu erwartenden Datenbankergebnisse verwendet. Jeder FQDN wird in seine einzelnen Segmente zerlegt und durch Pattern-Matching und reguläre Ausdrücke (ähnlich eines Extraktionsalgorithmus [38, 33]) mit den unterschiedlichen Datenbanken abgeglichen, um den Standort des Hosts zu bestätigen. Die Verifikation auf Grundlage von Code-Datenbanken bildet den Abschluss der Komponenten des Wichtungsalogrithmus. 5.2 Mögliche Fehlerquellen Wie vorhergehend bereits angemerkt, werden in diesem Kapitel mögliche Fehlerquellen einzelner Komponenten des Wichtungsalgorithmus betrachtet. Da es sich bei dem zu entwickelnden Programm um ein Proof-of-Concept handelt und dessen Komponenten aus einer Vielzahl verschiedener Datensätze resultieren, sind Fehler im Programmablauf nicht auszuschließen. Das Anpassen von Millionen von Datensätzen mittels Algorithmen in eine homogene Form stellt ein nicht triviales Problem dar. Demzufolge wird die Heterogenität der verschiedenen Datenquellen als wichtiger Einflussfaktor bei der Fehlerbetrachtung angesehen. Zusätzlich gilt es gewisse Faktoren zu beachten, die außerhalb des eigenen Einflussbereichs liegen. So können temporäre Auslastungen des Internets die Datenerfassung beeinflussen 4 oder abweichende beziehungsweise nicht der Norm entsprechende Datensätze zu einem Fehler im Programmablauf führen. Nachfolgend werden mögliche Fehlerquellen der drei Hauptkomponenten des IPTrolls vorgestellt. 3 Hier: Letzte Meile. 4 Beispielsweise die Abfrage von RIR-Datenbeständen oder den Erfolg eines Traceroute. Bachelorarbeit HT 2011 Seite 55

66 KAPITEL 5. DER WICHTUNGSALGORITHMUS Geo-Datenbanken Wie verschiedene empirische Studien [52, 120, 12, 103] zeigen, liefern die dem Proof-of- Concept zugrundeliegenden Geo-Datenbanken keine hundertprozentigen Ergebnisse. Es ist möglich, dass absichtliche oder durch Verzerrungen bewirkte Verfälschungen innerhalb der Datenbestände auftreten 5 [120]. Vor allem durch Anwender bereitgestellte Datensätze sind zumeist schwer durch den Anbieter zu verifizieren und stellen somit ein Problem dar. Der Anbieter HostIP [50], dessen Datensätze ausschließlich durch Freiwillige bereitgestellt werden, bildet innerhalb des hybriden Datenbankansatzes des IPTroll folglich den geringsten Wichtungsfaktor (vergleiche Kapitel 5.1). Insgesamt bietet der kombinierte Ansatz aus verschiedenen Datenbanken, wie in Kapitel beschrieben, eine Möglichkeit zur Relativierung fehlerhafter beziehungsweise fehlender Datensätze. Folglich lassen sich abweichende Ergebnisse durch mehrfache Verifizierung in ihrer Gewichtung abschwächen. Datenbestände der Regional Internet Registries Über die Abfrage von RIR-Datenbeständen mittels des Whois-Dienstes wird die Nutzung von hinterlegten Geoinformationen zu AS beziehungsweise IP-Adressblöcken ermöglicht. Diesbezüglich können manipulierte und verfälschte Daten auftreten und müssen innerhalb der Gewichtung berücksichtigt werden. Zusätzlich erschwert wird die automatisierte Auswertung von RIR-Datenbeständen durch eine nicht standardisierte Struktur und Zeichenkodierung der Rückgabe sowie der Fehlerbehandlung 6. Städte-, Region-, Flughafen- und Funkfeuercodes Wie bereits die Geoservice-Datenbanken aufzeigen, können verzerrte Ausgaben auftreten. Bezüglich der Code-Datenbanken stellt die Überschneidung von Codes das größte Problem dar. Als Beispiel für vorkommende Überschneidungen dient Tabelle 5.1. Besonders die Funkfeuer- (VOR) und Flughafencodes besitzen zahlreiche Interferenzen untereinander. Wie das Beispiel aufzeigt, sind die zutreffenden Ergebnisse alle dem Land Deutschland zuzuordnen. Es empfiehlt sich daher zur Verifikation durch Codedatenbanken bereits eine Vorabbedingung mittels der Länderkennzahl der Internationalen Organisation für Normung (ISO) zu definieren. Dies allerdings birgt eine potentielle Fehlerquelle, da bereits eine Eingrenzung vorab stattfinden muss. Die Länderkennzahl muss wiederum durch die Geo-Datenbanken oder Whois-Anfragen 5 Die Verifikation bereitgestellten Datensätze Dritter obliegt dem Geoservice-Anbieter. Das bedeutet, wenn diese nicht überprüft und als korrekt angenommen werden können, besteht lediglich eine Vertrauensbasis. 6 Die Registraturen verwenden unterschiedliche Schemata und Strukturen bei der Auflistung der hinterlegten Daten. Auch die Abfrage ist nicht einheitlich festgelegt, da beispielsweise die ARIN [4] die Eingabe einer IP-Adresse nur in einer bestimmten Form erlaubt. Bachelorarbeit HT 2011 Seite 56

67 KAPITEL 5. DER WICHTUNGSALGORITHMUS zuvor definiert werden, was wiederum eine weitere Fehlerquelle generiert. Daraus resultiert, dass die Code-Datenbanken einen geringen Einfluss auf den Wichtungsalgorithmus haben, da die Ergebnisse auf der Eingrenzung durch Rückgabewerte der Geo- Datenbanken beziehungsweise Whois-Anfragen basieren. Tabelle 5.1: Codeüberschneidungen am Beispiel Frankfurt am Main Code Ort Datenbank Land Ländercode FW Frankfurt am Main VOR Deutschland DE FFM Frankfurt am Main VOR Deutschland DE FFM Minnesota (Fergus Falls) IATA USA US FRA Frankfurt am Main (Flughafen) IATA Deutschland DE FRA Fora VOR Brasilien BR FRD Frankfurt am Main VOR Deutschland DE FRD Washington (Friday Harbor) IATA USA US ZRB Frankfurt am Main (HBF) IATA Deutschland DE EDDF Frankfurt am Main (Flughafen) IATA Deutschland DE Bachelorarbeit HT 2011 Seite 57

68 KAPITEL 6. IPTROLL Kapitel 6 IPTroll Autor: Kay Gottschalk No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes. [48] Die Wahl der für eine Problemstellung optimalen Programmiersprache ist mitunter nicht einfach und eher als subjektiv zu betrachten. Scripting beziehungsweise Shell Scripting 1 verweist dabei auf die klassische UNIX-Philosophie, komplexe Konzepte in trivialere Teilaufgaben zu untergliedern. Nach Cooper [79] gibt es hierbei Kontroversen, ob dies der bessere oder zumindest ästhetisch ansprechendere Ansatz zur Problemlösung sei. Überdies erscheint Shell Scripting nach den Kriterien von Mayer 2 als nicht opportun. Ungeachtet dessen stellt Shell Scripting eine schnelle Methode zum Aufbau einer komplexen Applikation dar [79]. Die begrenzte Funktionalität eines Skripts kann als nützlicher Schritt in der Projektentwicklung gesehen werden [79]. In diesem Kapitel wird der entwickelte Proof-of-Concept IPTroll im Kontext der Aufgabenstellung dargelegt. Die Implementierung realisiert eine Möglichkeit zur Ausführung auf der Kommandozeile. Hinsichtlich der aus der Aufgabenstellung hervorgehenden Anforderungen wird dafür die Bourne Again Shell (bash) gewählt, da es auf den gängigsten unixoiden Systemen die Standard-Shell darstellt [10]. 1 Referenzierend zur Umsetzung des Proof-of-Concept IPTroll. 2 [...] a useful language needs arrays, pointers, and a generic mechanism for building data structures. [48] Bachelorarbeit HT 2011 Seite 58

69 KAPITEL 6. IPTROLL 6.1 Programmmodi Es gelten hinsichtlich der Aufgabenstellung verschiedene Anforderungen an den zu entwickelnden Proof-of-Concept. Diese sieht eine Selektion oder Kombination von aktiven und passiven Lokalisationsverfahren vor. Zudem soll eine Gewichtung sowie Bewertung der erzielten Ergebnisse erfolgen. Weiterhin gilt als Voraussetzung, dass die Applikation eine Nutzung von Pipes 3 ermöglicht. Zur Gewährleistung der Anforderungen an die Funktionalität erfolgt eine Untergliederung der Programmmodi in einen paranoiden 4, regulären und aggressiven Modus. Nachfolgend werden die unterschiedlichen Programmmodi und der zugehörigen Optionen sowie Argumente vorgestellt. Name: IPTroll - ein Proof-of-Concept für Geolokalisation Synopsis:./IPTroll.sh [ -D -E ] [-a Aggressivität ] [ -p Präzision ] [ -vpn ] -ip Host -ipf Beschreibung: Das Internet stellt eine große, komplexe Aggregation von Informations- und Kommunikationssystemen dar, welche durch Gateways miteinander verbunden sind [32]. Innerhalb dieses dezentralen Netzes stellt die Allokation von IP-Adressen zu physikalischen Positionen eine nicht triviale Problematik dar. IPTroll nutzt eine Kombination von Geo- und im Rahmen der Arbeit erstellte Datenbanken sowie Whois- Abfragen, um diese Zuordnung vorzunehmen. Hinzu kommt die Anwendung von Extraktionsalgorithmen auf Grundlage von Städte-, Region-, Flughafen- und Funkfeuercodes. Der einzig obligatorische Parameter ist die IP-Adresse oder der Verweis auf eine Datei, die Netzadressen vorhält. Das Ausgabeformat kann zusätzlich durch optionale Parameter begrenzt beziehungsweise erweitert werden. Programmmodi: Paranoid: Basierend auf der Nutzung passiver Lokalisationsverfahren erlaubt der paranoide Modus eine Geolokalisation ohne direkte Verbindung zum gesuchten Host. Hierbei wird eine Kombination von Geoservice- und Code-Datenbanken 3 Der Einsatz der sogenannte Pipe ermöglicht die Nutzung der Ausgabe eines Prozesses als Eingabe eines Folgeprozesses. 4 Die Lokalisation erfolgt ohne direkte Verbindung zum gesuchten Host. Bachelorarbeit HT 2011 Seite 59

70 KAPITEL 6. IPTROLL sowie Whois-Abfragen zur Positionsbestimmung genutzt. Als Basis für die angehende Lokalisierung dient die IP-Adresse des Hosts sowie der primär verwaltende Nameserver dieser Zone. Der Wichtungsalgorithmus analyisiert die aus den Datenbanken gelieferten Ergebnisse und verifiziert sie mittels abgefragter Datenbestände der Registraturen. Zudem wird ein Extraktionsalgorithmus genutzt, um die ermittelten FQDN für eine weitere Bestätigung zu untersuchen. In Bezug auf potentielle Angriffsvektoren bietet der paranoide Modus Informationen hinsichtlich möglicher Mailserver, des SOA Records (primärer Nameserver, verantwortlicher Administrator) und der sekundären Nameserver. Weiterhin ist ein Auslesen potentieller DNS LOC Resource Records vorgesehen. Der Modi bietet dabei einen limitierten Umfang zur Verifizierung des ermittelten geografischen Standorts bei gleichzeitig kurzer Ausführungsdauer. Regulär: In Bezug auf den paranoiden Modus, differenziert sich der reguläre um weitere Verifikationskennzeichen. Innerhalb des Verfahrens kommt es dabei zur Interaktion mit dem Zielsystem via Routetracing, da diesbezüglich versucht wird Netzpfade mittels TCPTraceroute [80] und Paris Traceroute [17] aufzudecken. Dabei wird auf die unterschiedlichen Funktionalitäten dieser Applikationen zurückgegriffen, verschiedene Netzprotokolle für das Routetracing zu nutzen. Anschließend erfolgt ein Vergleich der ermittelten Netzpfade hinsichtlich aufgedeckter Hops von der Quelle bis zur Senke. Ergänzend zu den Basiswerten wie der IP-Adresse des Hosts und dem FQDN des primären Namesservers, werden entweder die beiden unmittelbar vor dem Zielsystem liegenden oder der letzte auflösbare Hop zur Verifikation herangezogen. Hierbei werden Lokalisierungsvorgänge identisch zu der des Zielsystems vorgenommen. Anschließend wird aufgrund der Annahme der sogenannten Letzten Meile [34] ein Abgleich der Ergebnisse mit dem des Zielsystems vorgenommen, um dieses möglichst zu validieren. Verweisend auf den paranoiden Modus bietet die reguläre Variante des IP- Troll die Möglichkeit der Erkennung eines weiteren potentiellen Angriffsvektors. Etwaig auf dem Zielsystem verfügbare Webserver können anhand eines Präfixes [open] mittels Routetracing 5 erkannt und ausgegeben werden. Der Modi bietet präzise Ergebnisse auf Grundlage der großen Anzahl an Verifikationsparametern, wobei sich die Ausführungsdauer durch die Anwendung von Routetracing merklich erhöht. 5 Hier: unter Verwendung von TCPTraceroute [80]. Bachelorarbeit HT 2011 Seite 60

71 KAPITEL 6. IPTROLL Aggressiv: Die Funktionalitäten erweitern sich im aggressiven Modus um die Aufdeckung von Angriffsvektoren hinsichtlich des Zielsystem. Diesbezüglich existiert eine Implementierung des Security Scanners Nmap [41]. Der Scanner bietet einen hohen Umfang an Funktionen zur Identifikation von Angriffsvektoren. Die Anwendung stellt unter anderem Funktionen wie Port Scanning, Applikation Mapping, Betriebssystemerkennung und die Nmap Scripting Engine (NSE) [41] für individuelle Anfragen zur Verfügung. Die eigentliche Ausgabe erfolgt im direkten Anhang zur vorangegangenen Lokalisation. Weiterhin ist eine spezifische Einstellung der von Nmap zu nutzenden Parameter über die IPTroll-Konfigurationsdatei möglich. Optionen: -a Die Aggressivitätsstufe legt den Funktionsumfang der zu erfolgenden Lokalisation fest. Der Standardwert ist durch a1 definiert und bezeichnet den paranoiden Modus (a2 determiniert den regulären und a3 den aggressiven Modus). -p Mit Hilfe der Präzisierungsstufe kann der Umfang auszugebender Informationen limitiert werden. Der reguläre Wert ist auf p3 festgesetzt und umfasst die vollen Ausgabeinformationen (p1 begrenzt die Ausgabe auschließlich auf das Land und p2 zusätzlich auf die Stadt). -vpn Der Parameter ermöglicht eine Nutzung des IPTrolls über ein Virtual Private Network (VPN) (vergleiche Abbildung 6.1) in Kombination mit OpenVPN [88]. Infolge dessen wird der gesamte Datenverkehr 6 des Proof-of-Concept verschlüsselt übertragen sowie die Herkunft der Anfragen verschleiert. Vorausgesetzt wird, dass auf dem vorhandenen System eine vollständig konfigurierte OpenVPN -Implementierung vorhanden ist. 6 Inklusive DNS. Bachelorarbeit HT 2011 Seite 61

72 KAPITEL 6. IPTROLL Abbildung 6.1: Beispiel eines Virtual Private Network [83]. Es erfolgt eine Remoteverbindung zu einem VPN -Gateway über die Infrastruktur eines öffentlichen Netzes. Aus der Sicht des Nutzers existiert eine Punkt-zu-Punkt Verbindung zum VPN -Gateway [83]. -ip Legt die zu lokalisierende IP-Adresse fest. Die Ausgabe der Ergebnisse erfolgt hierbei auf der Konsole. (Kann durch ipf ersetzt werden.) -ipf Dient der Nutzung einer Datei mit IP-Adressen, um eine automatisierte Lokalisierung der beinhalteten Internetadressen zu ermöglichen. Die anschließende Ausgabe wird in eine zuvor definierte Datei umgelenkt. Die Pfadangaben für die Adress- sowie die Ausgabedatei müssen innerhalb der Konfigurationsdatei des IPTroll vorgenommen werden. Optionen der Programmmodi: -D Der Default-Parameter initialisiert den regulären Modus des IPTroll und nutzt Datenbanken von Geoservice-Anbietern, Whois-Abfragen und Code- Datenbanken. Bachelorarbeit HT 2011 Seite 62

73 KAPITEL 6. IPTROLL Weiterhin wird die Präzisierungsstufe mit p3 initialisiert. Diesbezüglich reicht die Angabe einer IP-Adresseingabe beziehungsweise einer IP-Adressdatei als Folgeparameter. -E Zur nutzerdefinierten Konfiguration dient der Expert-Parameter. Hierdurch werden unter anderem genaue Angaben bezüglich der Präzisierungsstufe und Verifikationsfaktoren ermöglicht. Diese Parameter sind optional und werden bei Verzicht mit den zugehörigen Standardwerten initialisiert. 6.2 Anpassungen des Algorithmus Im Folgenden werden zur dedizierten Auswertung innerhalb einzelnen Programmmodi nötige Änderungen des Algorithmus erläutert. Ein Algorithmus charakterisiert gemäß Logofatu [35] eine Menge von Anweisungen, die in einer endlichen Anzahl von Schritten eine korrekte Lösung zu den jeweiligen Instanzen des gegebenen Problems finden. Zusätzlich bedingt durch den Rückschluss, dass nach Cormen [110] das übliche Maß für Effizienz Geschwindigkeit sei, gilt die Intention, eine möglichst geringe Anzahl an Rechenschritten zu favorisieren. Infolgedessen stellt der Umfang an Verifikationsfaktoren, also der jeweiligen Programmmodi, den Zusammenhang für die Anzahl an erforderlichen Rechenschritten dar. Die jeweiligen Validierungskomponenten werden innerhalb des Algorithmus betrachtet, um die Eintrittswahrscheinlichkeit der Ergebnisse ermitteln zu können. Obgleich die Anzahl an Faktoren zur Errechnung der Wahrscheinlichkeiten differiert, muss der Maximalwert erreichbar bleiben. Demzufolge ist es notwendig, Anpassungen an den zugrundeliegenden Wichtungsfaktoren hinsichtlich der Komponenten des Algorithmus (vergleiche Kapitel 5.1) vorzunehmen. Tabelle 6.1: Wichtungsalgorithmus - Einflussnahme der verschiedenen Komponenten Geo- RIR- Code-Datenbanken Datenbanken Datenbestände (IATA, VOR,...) Land (Reg./Aggr.) ca. 65% ca. 23% ca. 12% Stadt (Reg./Aggr.) ca. 50% ca. 29% ca. 21% Land (Paranoid) ca. 81% ca. 10% ca. 9% Stadt (Paranoid) ca. 63% ca. 20% ca. 17% Bachelorarbeit HT 2011 Seite 63

74 KAPITEL 6. IPTROLL Tabelle 6.2: Anzahl vorhandener Datensätze bezüglich Länder- und Städteinformationen innerhalb der Codedatenbanken des IPTroll. Land Stadt Anzahl Geo-Datenbanken Die Datensätze der Geoservice-Datenbanken bilden die Grundlage der Bestimmung von geografischen Positionen innerhalb des IPTroll. Ferner müssen Differenzierungen hinsichtlich der Wichtung der Geo-Datenbanken (vergleiche Kapitel 5.1.1) bezüglich der zu ermittelnden geografischen Zuordnungsgröße (Land, Stadt) sowie innerhalb der Programmmodi vorgenommen werden. Nach Poese et al. [52] erfolgt in 96% bis 98% der Testfälle eine korrekte Zuordnung auf Landesebene. Folglich werden Anpassungen in Hinblick auf die Eintrittswahrscheinlichkeit der ermittelten Ergebnisse (Land, Stadt) aus Geoservice-Datenbanken vorgenommen (vergleiche Tabelle 6.1). Weiterhin variiert dieser Einfluss innerhalb der Programmmodi in Folge der unterschiedlichen Anzahl von Einflussfaktoren. So liefern der reguläre sowie aggressive Modus durch die Anwendung von Routetracing zusätzliche Verifizierungselemente. Datenbestände der Regional Internet Registries Die Datenbestände der Registraturen geben Aufschluss über Eigentümer, Verantwortlichkeiten und Kontaktdaten einer Domain oder einer IP-Adresse (vergleiche Kapitel 2.1.6). Demzufolge werden die aus den RIR-Datenbeständen extrahierten Geoinformationen im Vergleich zu den Code-Datenbanken aufgrund der hohen Trefferwahrscheinlichkeit stärker gewichtet (vergleiche Tabelle 6.1). Die geografischen Informationen der Registraturen erhalten infolge des Routetracing innerhalb des regulären sowie des aggressiven Modus, hinsichtlich der damit einhergehenden erhöhten Anzahl an Verifikationsfaktoren, eine höhere Wichtung. Städte-, Region-, Flughafen- und Funkfeuercodes Die Ergebnisse der Code-Datenbanken sind vergleichsweise gering gewichtet (vergleiche Tabelle 6.1). Dies ist bedingt durch die geringe Aussicht auf Erfolg bei der Extraktion von geografischen Informationen innerhalb der FQDN mittels der Code-Datenbanken. Die erhöhte Anzahl von Städteschlüsseln im Vergleich zu Ländercodes (vergleiche Tabelle 6.2) führt zu einer differenzierten Betrachtung hinsichtlich des Wichtungsalgorithmus. Folglich müssen die Codedatenbanken in Anbetracht der Validierung von Städten über einen zunehmenden Einfluss verfügen(vergleiche Tabelle 6.1). Gemäß den unterschiedli- Bachelorarbeit HT 2011 Seite 64

75 KAPITEL 6. IPTROLL chen Verifikationselementen im Sinne des Routetracing muss eine angepasste Wichtung innerhalb der Programmmodi erfolgen (vergleiche Tabelle 6.1). 6.3 IPTroll im Überblick Innerhalb dieses Kapitels wurden die benötigten Programmmodi und erforderlichen Anpassungen an den Algorithmus im Kontext der Aufgabenstellung betrachtet und vorgestellt. Als Ergebnis ist eine prototypische Implementierung zur Anwendung auf der Kommandozeile von unixoiden Betriebssystemen entstanden. Sie umfasst die vorgestellten Verfahren zur Geolokalisierung (vergleiche Kapitel 4) sowie den zugrundeliegenden Algorithmus (vergleiche Kapitel 5) zur Auswertung der erfassten Ergebnisse. Die folgenden Abschnitte beschreiben die abgeschlossene Entwicklung und ermöglichen einen Gesamtüberblick über die Struktur des Proof-of-Concept. Der Ablauf folgt dem Prinzip der prozeduralen Programmierung [5], bei der ein Algorithmus in überschaubare Teile 7 zerlegt wird. Der Programmfluss ist durch lineare Folgen von Anweisungen sowie Methodenaufrufe festgelegt und folgt einem Programmablaufplan (PAP) 8. Der Ablauf wird nachfolgend, durch die Darstellung mittels PAP sowie spezifischer Code- Listings, weitergehend erklärt und dargestellt Gesamtüberblick Der erste Schritt (vergleiche Abbildung 6.2) stellt eine fundamentale Bedingung für den erfolgreichen Ablauf des Proof-of-Concept nach Programmstart dar. So werden die Angaben innerhalb der Konfigurationsdatei ausgelesen und verifiziert, um die funktionalen Implementierungen im weiteren Programmprozess zu realisieren. Nachdem die Zugangsdaten für den MySQL-Dienst verfügbar sind, kann mittels des MySQL-Clients auf den lokalen Datenbankserver zugegriffen werden. Somit folgt im zweiten Schritt eine bedingte Anweisung zur Initialisierung der Datenbanken. Sollte die Datenbank IPTroll nicht existent sein, wird ein Zwischenschritt zum Einrichten der gesamten Datenbankstruktur und der dazugehörigen Inhalte ausgeführt. Nach erfolgreicher Beendigung des Startablaufs folgt im weiteren Abschnitt das Verarbeiten der an den Funktionsaufruf angehängten Parameter, sodass im letzten Schritt der gewählte Programmmodus ermitteln werden kann. 7 Hier: Unterprogramme, Prozeduren oder Funktionen. 8 Ablaufdiagramm für Computeranwendungen. Bachelorarbeit HT 2011 Seite 65

76 KAPITEL 6. IPTROLL Abbildung 6.2: Programmablaufplan des Proof-of-Concept Bachelorarbeit HT 2011 Seite 66

77 KAPITEL 6. IPTROLL Die Konfigurationsdatei Abbildung 6.3: Programmablaufplan der Konfigurationsdatei Für einen korrekten Ablauf des IPTroll ist die Existenz und Anpassung der Konfigurationsdatei IPTroll.conf essentiell. Diesbezüglich wird im ersten Schritt (vergleiche Abbildung 6.3) das Vorhandensein der Konfigurationsdatei innerhalb des Ausführungsverzeichnisses überprüft. Sollte die Datei nicht existieren, wird ein Entwurf erstellt sowie der weitere Programmablauf beendet. Bachelorarbeit HT 2011 Seite 67

78 KAPITEL 6. IPTROLL Die Datei enthält die benutzerspezifischen Angaben für den Zugriff auf den MySQL- Dienst des unixoiden Betriebssystems, welche sich aus einem Benutzernamen und dem dazugehörigen Passwort zusammensetzen. Ein Fehlen dieser grundlegenden Angaben hat ebenfalls einen Programmabbruch zur Folge. Zusätzlich sind in der IPTroll.conf die Pfade für eine mögliche IP-Adress- und die dafür benötige Rückgabedatei hinzuzufügen. Sollten Anpassungen bezüglich der Nmap- Implementierung erforderlich sein, können die gesetzten Parameter beziehungsweise Flags gegebenenfalls bearbeitet werden Initialisierung der Datenbanken Abbildung 6.4: Programmablaufplan zur Initialisierung der Datenbanken Den Hauptaspekt zur Erfassung der Lokalisierungsergebnisse (vergleiche Kapitel 4.1.1) bilden die kombinierten Anfragen auf die Inhalte verschiedener Geo-Datenbanken. Zusätzlich muss für die weitere Implementierung auf die kumulierte Datenbank mit Städte-, Region- und Flughafencodes der IATA sowie Funkfeuercodes zugegriffen werden. Die Generierung der Datenbankstruktur und die Initialisierung der jeweiligen Inhalte ist für eine erfolgreiche Lokalisierung zwingend erforderlich. Die Implementierung ist im Programmablaufplan (vergleiche Abbildung 6.4) dargestellt und zeigt die lineare Abfolge in zwei Schritten. Bachelorarbeit HT 2011 Seite 68

79 KAPITEL 6. IPTROLL Update der Datenbanken Abbildung 6.5: Programmablaufplan zum Update der Datenbanken. Empirische Studien [120] belegen, dass über einen definierten Zeitraum signifikante Änderungen an den Geo-Datenbanken zu beobachten sind. Folglich ist es ratsam die Datensätze aktuell zu halten. Die Anbieter der Geolokalisierungsdatenbanken bieten dementsprechend in regelmäßigen Abständen Updates für ihre Datenbanken an. Um den erforderlichen Aufwand seitens des Nutzers gering zu halten, beinhaltet der Proof-of-Concept eine entsprechende Update- Funktionalität für Geo-Datenbanken von zwei verschiedenen Anbietern 9. Dabei ist es vorgesehen, die Aktualisierungsfunktion je nach Bedarf manuell durch den entsprechenden Parameter beim Programmaufruf zu starten. Das Archiv des Anbieters HostIP ist dauerhaft über den selben Verweis verfügbar und kann durch entsprechende Implementierung (vergleiche Listing 6.1) bezüglich der Updatefunktionalität genutzt werden. Um das gegenwärtige MaxMind-Update verfügbar zu machen, muss der aktuelle Archivname über einen regulären Ausdrucks ermittelt werden (vergleiche Listing 6.2). Die nachfolgende Initialisierung der neuen Datensätze ist äquivalent zu HostIP durchführbar (vergleiche Listing 6.1). 9 Hier: HostIP und MaxMind. Bachelorarbeit HT 2011 Seite 69

80 KAPITEL 6. IPTROLL wget q u i e t http : / / db. h o s t i p. i n f o / mirror / h o s t i p c u r r e n t. s q l. gz i f [ f h o s t i p c u r r e n t. s q l. gz ] ; then gunzip h o s t i p c u r r e n t. s q l. gz rm f o r c e h o s t i p c u r r e n t. s q l. gz f i i f [ f h o s t i p c u r r e n t. s q l ] ; then DODBU1= mysql u $MYSQLUSER p$mysqlpw s i l e n t <<SQL drop database i f e x i s t s i p l o c 1 ; c r e a t e database i f not e x i s t s i p l o c 1 ; use i p l o c 1 ; source h o s t i p c u r r e n t. s q l ; q u i t SQL rm f o r c e h o s t i p c u r r e n t. s q l Listing 6.1: Download und Initialisierung eines Updates am Beispiel des Anbieters HostIP wget q u i e t http : / / g e o l i t e. maxmind. com/ geoip / database / GeoLiteCity CSV UPD3= grep o [ [ : alpha : ] ] [ [ : d i g i t : ] ] \. zip index. html t a i l 1... rm f o r c e index. html... Listing 6.2: Ermitteln eines Archivnamens durch reguläre Ausdrücke am Beispiel von MaxMind Der reguläre Modus Das Kernstück des Proof-of-Concept bilden die drei unterschiedlichen Programmmodi. Die regulären und aggressiven Modi beinhalten eine kombinierte Routetracing-Implementierung (vergleiche Kapitel 4.1.2), wohingegen der paranoide Modus auf Methoden der direkten Kommunikation mit dem Zielsystem verzichtet. Demnach bieten der reguläre sowie aggressive Modus, durch die Auflösung von Netzpfaden zum Host, zusätzliche Lokalisierungsfaktoren zur wechselseitigen Verifizierung der ermittelten Ergebnisse. In Bezug auf die genannten Differenzierungsmerkmale der einzelnen Programmmodi wird auf eine separate Darstellung einzelner Programmablaufpläne verzichtet und infolgedessen ein Überblick am Beispiel des regulären Modus vorgenommen (vergleiche Abbildung 6.6). Bachelorarbeit HT 2011 Seite 70

81 KAPITEL 6. IPTROLL Abbildung 6.6: Programmablaufplan des regulären Modus Bachelorarbeit HT 2011 Seite 71

82 KAPITEL 6. IPTROLL Der Proof-of-Concept ermöglicht die optionale Verschlüsselung des Datenverkehrs in Kombination mit OpenVPN [88] (vergleiche Kapitel 6.1) und damit auch die Verschleierung der Herkunft der Anfragen. Ist der optionale Parameter im ersten Schritt gesetzt, wird zu Beginn der Lokalisierung eine Verbindung über ein VPN initialisiert. Sollte es zu Problemen bei der VPN - Verbindung kommen, so wird die Lokalisierung abgebrochen und das Programm beendet 10 (vergleiche Listing 6.3). Im weiteren Verlauf erfolgt die Analyse des Eingabeflag und somit die Wahl des Ausgabeformats der Lokalisationsergebnisse. Wird die IP-Adresse als Parameter bei der Eingabe überreicht, erfolgt die Ausgabe auf Konsolenebene. Sollte die Eingabe über eine externe Datei gefordert sein, so werden die enthaltenen IP-Adressen mittels einer for-schleife 11 sukzessiv lokalisiert und die Ergebnisse in eine externe Datei ausgelagert. Eine mögliche bestehende VPN -Verbindung wird nach Abschluss der Aus- beziehungsweise Rückgabe beendet. # OPENVPN b e i Bedarf s t a r t e n i f [ f i $!= ${ / vpn/} ] ; then s e r v i c e openvpn s t a r t > /dev/ n u l l VPNCHECK = p s A grep openvpn i f [ z $VPNCHECK ] ; then # S k r i p t beenden exit f i Listing 6.3: Aufbau einer VPN -Verbindung mittels OpenVPN und Abbruchbedingung Lokalisierung im regulären Modus Basierend auf den Anforderungen der Aufgabenstellung bilden die Selektion und Kombination von aktiven sowie passiven Lokalisationsverfahren einen wichtigen Aspekt bei der Bewertung der erzielten Ergebnisse. Die Geolokalisation unterscheidet sich, zwischen den jeweiligen Programmmodi, anhand der Auswahl von aktiven sowie passiven Verfahren. So erfolgen innerhalb des paranoiden Modus zwei Abfragen von RIR-Datenbeständen als Bestandteil passiver Methoden. Erweitert werden diese um aktive Methoden mittels kombinierter Traceroute-Anwendungen innerhalb des regulären sowie aggressiven Modus. 10 Diese Vorgehensweise dient dem Schutz des Nutzers, da es ansonsten zu einer unverschlüsselten Kommunikation mit dem Zielsystem kommen könnte. 11 Kontrollstruktur zur Ausführung einer Gruppe von Anweisungen mit einer bestimmten Anzahl von Wiederholungen [31]. Bachelorarbeit HT 2011 Seite 72

83 KAPITEL 6. IPTROLL Zusätzlich verfügt der aggressive Modus, zur erweiterten Aufdeckung möglicher Angriffsvektoren, über die in Kapitel 3.2 vorgestellte Nmap-Implementierung. Die Abfolge der einzelnen prozeduralen Bestandteile richtet sich nach den Abläufen der vorgestellten Komponenten des Algorithmus (vergleiche Kapitel 5.1). Hierbei werden die jeweiligen Ergebnisse aus Geo-Datenbanken ermittelt und nachfolgend durch die Datenbestände der Regional Internet Registries sowie durch Städte-, Region-, Flughafen- und Funkfeuercodes (vergleiche Kapitel 5.1) verifiziert. Zur präventiven Vermeidung fehlerhafter Ausgaben erfolgt bereits vorab eine Filterung der IP-Adresse des zu lokalisierenden Zielsystems. Infolgedessen wird die Internetadresse mittels regulärer Ausdrücke hinsichtlich ihrer Gültigkeit überprüft. Zusätzlich bedarf es einer Filterung von IP-Adressen aus reservierten Adressbereichen, da sie nicht geroutet werden 12 und somit mehrfach Verwendung finden können [58, 51]. Eine geografische Zuordnung ist folglich nicht möglich geschweige denn gewollt. Im Anschluss an die Validierung erfolgt die Ermittlung verschiedener Netzpfade mittels Routetracing (vergleiche Kapitel 4.1.2) zum Zielsystem. Nach dem Abschluss kann mit der Ermittlung der Ergebnisse aus den Geo-Datenbanken verschiedener Anbieter (vergleiche Kapitel 4.1.1) begonnen werden. Diese sind anhand von RIR-Datenbeständen sowie der Identifikation geografischer Hinweise innerhalb der FQDN (vergleiche Kapitel 4.1.2) zu verifizieren. Der Start of Authority Record des Zielsystems beherbergt unter anderem den jeweiligen primären Nameserver. Dieser wird innerhalb der drei Programmmodi zur weiteren Verifizierung herangezogen (vergleiche Kapitel 4.1.2) und hinsichtlich der zugehörigen IP-Adresse sowie des FQDN analysiert. Abschließend implizieren der reguläre sowie aggressive Modus hinsichtlich der Routetracing-Ergebnisse weitere Lokalisationsfaktoren. Der Ablauf bleibt identisch und beinhaltet die Analyse der IP-Adressen sowie der dazugehörigen FQDN der zu analysierenden Hops. 12 Falls diese dennoch bei beispielsweise Traffic-Analysen auftreten sollten, ist dies zumeist auf Konfigurationsfehler seitens der Netzoperatoren zurückzuführen. Bachelorarbeit HT 2011 Seite 73

84 KAPITEL 6. IPTROLL Abbildung 6.7: Programmablaufplan zur Lokalisierung im regulären Modus Bachelorarbeit HT 2011 Seite 74

85 KAPITEL 6. IPTROLL Ausführung des Routetracing In der Konzeptionierung wurde bereits deutlich, dass die Kombination von differenzierten Routetracing die Wahrscheinlichkeit zur Auflösung eines kompletten Netzpfades steigert. Eine Kombination unterschiedlicher Netzprotokolle sowie Traceroute-Derivaten bildet dabei die Grundlage der Routetracing-Implementierung. So werden die Applikationen TCPTraceroute [80] sowie Paris-Traceroute [17] in Kombination mit den Netzprotokollen TCP, UDP und ICMP genutzt. Sind die Traceroutes abgeschlossen, so kann mit der Kürzung der in Dateien gespeicherten und aufgelösten Netzpfade begonnen werden. Hierbei werden die Dateien kopiert und um überflüssige Zeichen, Daten und nicht auflösbare Hops gekürzt (vergleiche Listing 6.4). Im Anschluss kann über eine Funktion ermittelt werden, welche Ausgabe für eine weitere Verwendung dienlich ist. Letztendlich werden bei erfolgreicher Ermittlung eines vollständigen Netzpfades zum Zielsystem die letzten beiden Knoten zur Validierung der Ergebnisse herangezogen. Sollte der Netzpfad Lücken im angenommenen Einzugsbereich des eigentlichen Zielsystems aufweisen 13, so wird ausschließlich der letzte auflösbare Knoten zur weiteren Verifizierung herangezogen. t c p t r a c e r o u t e w1 q1 m30 $1 2> /dev/ n u l l sed /ˆ $/d > t0 p a ris t r a c e r o u t e Q m30 T1000 pudp q1 $1 sed /ˆ $/d > p10 p a ris t r a c e r o u t e Q m30 T1000 ptcp q1 $1 sed /ˆ $/d > p20 p a ris t r a c e r o u t e Q m30 T1000 picmp q1 $1 sed /ˆ $/d > p30 Listing 6.4: Multiples Routetracing mit Speicherung der Ergebnisse in externen Dateien sowie Kürzen von Leerzeilen 13 Hier: Letzte Meile. Bachelorarbeit HT 2011 Seite 75

86 KAPITEL 6. IPTROLL Abbildung 6.8: Programmablaufplan zur Ausführung des Routetracing Bachelorarbeit HT 2011 Seite 76