Spurensuche

IP-Nummern aus Logdateien von Internet-Hosts enthalten oftmals weit mehr Informationen, als sich mit einem einfachen Nameservice-Lookup extrahieren lässt. Im Zeitalter von ortsbezogenen Diensten ist besonders die Gewinnung der Anwender-Koordinaten von Interesse.

vorlesen Druckansicht 45 Kommentare lesen
Lesezeit: 15 Min.
Von
  • Eckehart Röscheisen
Inhaltsverzeichnis

Egal ob beim Lesen von Webseiten, E-Mail-Versand oder bei der Dateiübertragung mittels FTP: Die Anwender aller Internet-Dienste hinterlassen mit ihrer unabdingbaren IP-Adresse mehr oder weniger eindeutige Spuren nicht nur über ihre Aktivitäten, sondern häufig auch über ihren Aufenthaltsort. Jeder Internet Service Provider (ISP) verfügt über einen begrenzten Pool solcher Adressen, die zentral registriert sind. Bei jedem Login und bei jeder beliebigen Interaktion mit einem Server im Internet hinterlassen die Kunden quasi die Hausnummer ihres Rechners. Vielen Betreibern insbesondere von Webangeboten ist daran gelegen, diese Information auszuwerten. Und der Konsument auf der Gegenseite sollte sich darüber bewusst sein, was sich über ihn ohne sein Zutun herausfinden lässt.

Die IP-Nummer enthält zwar topologische Informationen über die Netzstruktur (Hierarchie und Besitzer der Teilnetze), aber anders als Telefonnummern zunächst keinerlei Anhaltspunkt über den Ort des ‘Teilnehmers’. Zudem wird sie von vielen Providern dynamisch vergeben, das heißt, bei jeder Einwahl ist der Anwender unter einer anderen Nummer erreichbar. Eine Reihe von Methoden widmet sich der mehr oder weniger zuverlässigen Ermittlung von Zusatzinformationen wie Firma, Firmenadresse, Hosting Provider, Access Provider, Art des Zugangs oder sogar des Aufenthaltsorts eines IP-Clients.

Unix enthält einige rudimentäre Werkzeuge, die bei der Analyse gute Dienste leisten können (siehe Kasten). Auch im Web gibt es Projekte und exemplarische Anwendungen, die sich mit der Ermittlung von Information aus IP-Adressen beschäftigen. Das Hauptaugenmerk gilt der geografischen Position eines Anwenders.

Mehr Infos

Basis-Netzwerktools aus dem Unix-Baukasten

Aus Unix-Systemprogrammen lässt sich ein Grundstock an Werkzeugen zum Ermitteln von Informationen über IP-Adressen und Domain-Namen zusammenstellen.

nslookup stellt Informationen von Domain Name System (DNS) Servern dar. Das Diagnosewerkzeug agiert interaktiv oder per Kommandozeilenaufruf. Um nur eine Information abzurufen, genügt meist der nicht-interaktive Modus für die Übersetzung von IP-Nummern in Domain-Namen oder umgekehrt. Als zweites Argument lässt sich der zu befragende DNS-Server angeben.

dig (‘Domain Internet Grouper’) ähnelt im Wesentlichen nslookup, bereitet aber die Antwort des Servers ausführlicher auf.

ping überprüft Verbindungen zu einem oder mehreren Remote-Rechnern, indem es ICMP-Testpakete (Internet Control Message Protocol) versendet und auf das Echo des Zielrechners wartet. Tatsächlich kann ping nicht nur den Namen eines Computers und dessen IP-Adresse prüfen, sondern auch, ob er überhaupt online ist. Auf diese Weise lassen sich etwa Domain-Resolution-Probleme identifizieren.

traceroute stellt die Route eines ICMP-Datenpakets dar. Durch Variieren der TTL-Zeit (Time to Live) lassen sich die einzelnen Router (‘Hops’) auf dem Weg des Pakets identifizieren und aufgezeichnen. traceroute startet mit einem TTL-Wert von 1 und erhöht diesen dann jeweils um 1, bis der Zielrechner antwortet oder der maximale TTL-Wert, also die maximale Anzahl von Hops, erreicht ist. Die Route setzt sich aus den Meldungen ‘ICMP Time Exceeded’ der jeweiligen Router zusammen. Da manche Router in einem solchen Fall die Datenpakete einfach ignorieren (im denglischen Fachslang ‘droppen’), ist das Ergebnis nicht immer eine vollständige Routing-Liste.

Die Zwischenstationen werden jeweils mittels DNS Resolve aufgelöst dargestellt, sodass die Route eines Testpakets nicht nur topologische, sondern unter Umständen bereits geografische Informationen liefert. Ein Programm namens ‘Visual Route’ dient der Darstellung dieses Wegs auf einer Weltkarte (www.visualware.com/visualroute/).

whois gibt Informationen über Second-Level-Domains aus der InterNIC-Datenbank oder des zuständigen NIC für eine Länder-Domain aus. Außer mit whois per Kommandozeile kann man auch via telnet oder auf einem Webserver beim jeweiligen Registrar fündig werden. whois führt eine generische String-Suche in der Datenbank des oder der für die Top Level Domain zuständigen Registrare durch. Die Informationen umfassen Kontaktinformationen für Ansprechpartner in den Bereichen Organisation, Administration und Technik.

Die Cooperative Association for Internet Data Analysis (CAIDA) etwa ist eine zu diesem Zweck von Unternehmen und Forschungseinrichtungen betriebene Organisation. Ihre geografische Internet-Datenbank NetGeo ist eines der zentralen Projekte. NetGeo umfasst eine Reihe von Perl-Scripts, die IP-Adressen oder Domain-Namen geografischen Orten zuordnen und mit Visualisierungswerkzeugen - etwa einem grafischen Traceroute oder dem Internet-Atlas- darstellen. Die NetGeo-Datenbank fungiert als eine Art Proxy-Datenbank für Whois-Anfragen an das System: Neue Anfragen werden mit den Perl-Scripts bearbeitet und die Ergebnisse für neue Anfragen in die Datenbank geschrieben.

Das grafische Traceroute der CAIDA benutzt die Analysetools der ‘NetGeo’-Datenbank, um Traceroutes auf einer Weltkarte zu visualisieren (Abb. 1).

Wenn die Datenbank einen neuen Whois-Eintrag aufnimmt, werden neben dem Country-Code auch Informationen über den Ort (Stadt, Region, Distrikt, Staat, Land) durch ein Perl-Script extrahiert. Für US-Adressen wird darüber hinaus die Postleitzahl (‘Zip Code’) extrahiert, so vorhanden. Falls diese Informationen fehlen, versucht das Script aus eventuellen Telefonnummern geografische Indizien abzuleiten. Dieses Verfahren ist selten zufriedenstellend, weil die Whois-Datenbanken bestenfalls die zentrale Adresse eines Providers oder einer Firma enthalten, nicht jedoch den Ort des tatsächlichen Einwahlknotens.

Da das Herleiten der Ortsinformation - etwa aus einer Whois-Datenbank - nicht zufrieden stellend funktionieren kann, beschäftigten sich einige Forschungsprojekte und Initiativen mit der Frage, wie man derlei Information in das Domain Name System (DNS) des Internet integrieren kann. Nach dem Willen der Betreiber von ckdhr.com etwa soll das DNS erweitert werden um einen ‘DNS LOC (location) Resource Record’, der die geografischen Informationen über einen Server enthält. Unternehmen und Organisationen, die eigene Server betreiben, könnten in Eigeninitiative diese Informationen über ihren Standort eintragen und gegebenenfalls aktualisieren. Sie könnten aber auch aus Sicherheitsgründen bewusst falsche Informationen angeben.

Initiativen wie ‘DNS LOC’ wollen das DNS-System um geografische Informationen wie Längen- und Breitengrad eines Servers erweitern (Abb. 2).

Auf der Site von ckdhr.com befindet sich eine Demonstration namens ‘LOC to Maps’, die zeigt, was es mit diesem Vorschlag auf sich hat. Mit diesem System ließen sich die Server der Betreiber geografisch orten und auf einer Landkarte visualisieren.

Bereits im November 1994 hatten Mitarbeiter der Curtin University of Technology in Perth, Australien, in ihrem Request for Comments (RFC 1712) ein ähnliches experimentelles Protokoll zur Erweiterung des Domain Name System vorgeschlagen. Der Vorschlag umfasst ebenfalls einen neuen Resource Record mit Längen- und Breitengraden, der die DNS-Daten ergänzen soll.

Beiden Vorschlägen dürfte wenig Erfolg beschieden sein, denn seitens der Industrie gibt es wenig Veranlassung, Internet-Standards für solche Zusatzinformationen zu fordern. Dennoch gibt es eine Reihe von Anwendungen, die mit Hilfe von Ortsinformationen überhaupt erst funktionieren würden. Wenn Klarheit über den Ort eines Clients besteht, könnte ihm eine Webseite etwa automatisch lokalspezifischen Content - Restaurant-Tipps, Konzerthinweise, Lokalnachrichten und dergleichen liefern.

Der Kieler Elektrotechnik-Student Jan Kneschke betreibt eine IP-Datenbank speziell für den deutschsprachigen Raum. Sein ‘Localizer’ nutzt die Tatsache aus, dass die Provider ihren Routern ortsbezogene Namen geben. Technisch läuft die Erfassung der Daten nach dem folgenden Prinzip ab: Mittels traceroute wird der letzte Router gesucht, dann das Städtekürzel aus dem DNS-Namen gefiltert und danach in eine lesbare Form übersetzt.

Derzeit kann Localizer immerhin für rund 18 Millionen IP-Adressen (schätzungsweise mehr als 75 Prozent des deutschsprachigen Netzes) die entsprechenden Orte und Access-Provider benennen. Je nach Provider lässt sich mit Hilfe dieser Datenbank der Benutzer in einem Radius von 25 Kilometern lokalisieren. Berücksichtigt sind alle großen deutschen Internet-Provider und deren Backbone-Anbieter. Ein kleines C-Programm kann Zugangsinformation aus der Datenbank innerhalb von Millisekunden ermitteln. Damit lassen sich so genannte ‘Location based Services’ implementieren, die basierend auf dieser geografischen Information ihren Inhalt automatisch anpassen.

Zu den Kunden von Kneschke zählen zwei Ad-Server-Firmen, die damit ein Feature mehr anbieten können. Bislang verstand die Werbeindustrie unter ‘Regional Advertising’ das Schalten von Bannern auf lokal ausgerichteten Websites. Jetzt lassen sich basierend auf der IP-Nummer automatisch lokale Banner selektieren: Das Ad-Server-System extrahiert aus der Anfrage eines Nutzers (Request) dessen IP-Adresse, sucht in der Datenbank nach der zugehörigen Region und wählt bei einem Treffer ein lokalspezifisches Banner aus, sonst ein bundesweites. Das Verfahren wird längst in realen Internet-Projekten eingesetzt; die Schlagworte ‘Regional Targeting’ und ‘Local Advertising’ versprechen Mehreinnahmen durch die gezieltere Ansprache der Anwender.

Auch der Neu-Isenburger Ad-Server-Anbieter AdTech hat ein Verfahren namens ‘AdLocal’ zur geografischen Lokalisierung eines Nutzers entwickelt. In monatelanger Handarbeit und mit Hilfe von Software-Robots sowie Online-Gewinnspielen, bei denen die Internet-Nutzer Adressdaten eingeben sollten, baute AdTech ähnlich wie Jan Kneschke eine eigene Datenbank von IP-Adressen auf. Das Verfahren funkioniert zumindest bei regional agierenden ISPs, die Privatkunden und kleinere Unternehmen versorgen.

‘Allerdings wurde unser gut funktionierendes System schon bald von der Entwicklung überrollt’, berichtet AdTech-Sprecher Dirk Freytag. ‘Anfang 2001 hatten wir noch eine gute Auflösung. Doch dann veränderte sich die Struktur der Netze durch die massive Carrier-Verschmelzung so gravierend, dass unsere Auflösungsquote immer schlechter wurde. Dazu kommt, dass man Provider wie AOL bis heute nicht aufschlüsseln kann, weil deren Struktur hochgradig zentralisiert ist. Aus diesem Grund sehen wir es heute nicht mehr als sinnvoll an, Lokalisierung bei der Vermarktung unserer AdServer-Technologie in den Vordergrund zu stellen.’ Die Versprechen seiner Mitbewerber in diesem Bereich hält Freytag zum Teil für unseriös.

IP-Adressen können aber in vielen Fällen tatsächlich aussagekräftige Ergebnisse in puncto geografischer Ortung erzielen, weil viele Access Provider - etwa T-Online oder Arcor - ihre Netze stark regional strukturiert haben und sich so über die IP-Nummer die Region oder sogar die Stadt identifizieren lassen. Bei vielen anderen Anbietern sind die Informationen aber tatsächlich schwer zu ermitteln.

Ein Problem ergibt sich bei global oder zumindest bundesweit agierenden Online-Diensten wie AOL. Zwar wählen sich die Nutzer beider Dienste über eine bundesweit einheitliche Einwahlnummer bei einem jeweils in ihrer Nähe befindlichen Einwahlknoten zum Ortstarif ein. Diese aber lassen sich aufgrund von sehr viel komplexeren und zentral gesteuerten Vergabeschlüsseln nicht identifizieren. So wird ein und dieselbe IP-Adresse mal einem Nutzer aus Hamburg, mal einem aus Konstanz zugewiesen, sein Standort ist demnach nicht zu orten. Erschwert wird die Aufschlüsselung zudem durch lastabhängige Routing-Mechanismen - ist einer der lokalen Einwahlknoten ‘überfüllt’, wird der Nutzer zum nächsten freien umgeleitet. Die Provider selbst haben darüber hinaus natürlich kein Interesse, derlei Informationen nach außen zu geben.

Ebenso komplex sind die Netze großer Konzerne wie IBM oder Siemens strukturiert, die in der Regel hauseigene Dial-in-Zugänge für ihre Mitarbeiter anbieten. In diesem Fall werden unter Umständen zehntausende von Mitarbeitern dem geografischen Ort des Network Operations Centers zugeordnet, eine ebenfalls nutzlose Information.

Aus Datenschutzgründen ist es sogar begrüßenswert, wenn sich ein Anwender nicht mit Sicherheit lokalisieren lässt. Manch einer dürfte sich eher überrumpelt fühlen als ‘gezielt angesprochen’, wenn er bei einem internationalen Nachrichtendienst plötzlich Werbung für eine Pizzeria in seinem Stadtteil eingeblendet bekommt. Bei den potenziellen Werbepartnern - primär den mittelständischen Unternehmen in den Regionen - jedenfalls hat sich das Verfahren bis heute nicht durchsetzen können. ‘Es gibt keine Nachfrage für derlei Features’, kommentiert Freytag.

Doch Werbung ist nicht das einzige Einsatzgebiet für die Lokalisierung, und sie muss auch nicht zum Zeitpunkt der Zugriffe stattfinden. Im E-Business agierende Unternehmen könnten die IP-Adressen aus den Logdateien ihrer Server mittels Data Mining filtern, neu sortieren und mit weiteren Informationen anreichern, um damit eine direkte Ansprache von Kunden und Interessenten zu realisieren (Customer Relationship Management).

Rechtlich scheint der Einsatz von reinen IP-Analyseverfahren und -Datenbanken unbedenklich, schließlich sind die IP-Adressen frei und für jedermann verfügbar. Whois-Datenbanken unterliegen jedoch grundsätzlich dem Urheberrecht und sind nicht ohne weiteres für eigene Anwendungen einzusetzen.

Dennoch bleibt bei exzessiver Nutzung aller legalen Möglichkeiten ein bitterer Nachgeschmack für die in Sachen Datenschutz ohnehin wenig verwöhnten Internet-Anwender. ‘Zwischen dem Wunsch nach möglichst komfortabler Nutzung von Webseiten und dem Sicherheitsbedürfnis vieler Nutzer besteht grundsätzlich ein Zielkonflikt’, meint Karin Schuler von der Deutschen Vereinigung für Datenschutz (DVD). Deren ‘Schwarze Liste’ stellt die obligatorische und unnötige Nutzung von Scripting und Cookies an den Pranger.

Eckehart Röscheisen
ist freier IT-Autor, Berater und Buchautor.

[1] http://jan.kneschke.de/projects/localizer/

[2] Cooperative Association for Internet Data Analysis (CAIDA); NetGeo;

[3] Internet Assigned Numbers Authority (IANA); Country Code Top Level Domains Database;

[4] Cyber Geography Research;

[5] Uri Raz; How do I find the geographical location of a host, given its IP address?;

[6] Eckehart Röscheisen; ip-telligence;

Mehr Infos

iX-TRACT

  • Aus IP-Adressen lassen sich häufig Ortsinformationen herleiten, die für die Anbieter regionaler Informationen interessant sein können.
  • Erweiterungen des Internet-Namensdienstes DNS um geografische Zusatzinformationen haben experimentellen Charakter und dürften sich nur schwer durchsetzen.
  • Eindeutige Ortszuordnungen sind umso schwerer zu treffen, je größer das Netz des Providers ist und je zentraler das Routing auf der letzten Meile verwaltet wird.