Wem gehört diese IP-Adresse?
In Logfiles von Firewalls und Webservern, in E-Mail-Headern und in Abuse-Meldungen stehen unzählige IP-Adressen. Wer steckt dahinter? Eine Zuordnung zu einer bestimmten Person ist von außen praktisch nie möglich – wohl aber die Bestimmung des Netzbetreibers, des zuständigen Ansprechpartners und einer groben geografischen Einordnung. Dieser Guide zeigt, wie das geht, welche Werkzeuge heute maßgeblich sind und wo die Grenzen liegen.
Was sich ermitteln lässt – und was nicht
Die Registry-Datenbanken beantworten die Frage, welcher Organisation ein Adressblock zugeteilt ist. Das ist in aller Regel ein Provider, ein Rechenzentrumsbetreiber oder ein größeres Unternehmen. Wer die Adresse zum fraglichen Zeitpunkt tatsächlich benutzt hat, weiß nur dieser Betreiber.
Mehrere Effekte erschweren die Zuordnung zusätzlich:
- Dynamische Vergabe. Anschlusskennungen wechseln. Ohne genauen Zeitstempel inklusive Zeitzone ist eine Nachforschung wertlos.
- Carrier-Grade NAT. Viele Provider teilen eine öffentliche IPv4-Adresse auf hunderte Anschlüsse auf. Erst Zeitstempel und Quellport grenzen den Anschluss ein.
- Cloud und Hosting. Bei Adressen großer Anbieter nennt die Registry den Anbieter, nicht dessen Kunden. Der eigentliche Betreiber des Dienstes bleibt unsichtbar.
- VPN, Proxy und Tor. Die sichtbare Adresse ist dann die des Dienstes, nicht die des Nutzers.
- Gefälschte Absenderadressen. Bei UDP-basierten Angriffen und in E-Mail-Headern können Adressen frei erfunden sein.
Für den praktischen Alltag ist das weniger einschränkend, als es klingt. Die häufigste Frage lautet nicht „wer war das?", sondern „an wen melde ich das?" – und darauf gibt die Registry eine belastbare Antwort in Form des Abuse-Kontakts.
Wer vergibt IP-Adressen?
Die Vergabe läuft über vier Stufen. Die IANA verwaltet den globalen Adressraum und gibt große Blöcke an fünf Regional Internet Registries (RIRs) ab. Diese teilen Adressbereiche an Local Internet Registries (LIRs) zu – meist Provider und größere Netzbetreiber –, die daraus wiederum ihre Kunden versorgen. Öffentlich einsehbar sind die ersten drei Stufen.
| RIR | Region | whois-Server | RDAP-Endpunkt |
|---|---|---|---|
| RIPE NCC | Europa, Naher Osten, Teile Zentralasiens | whois.ripe.net | rdap.db.ripe.net |
| ARIN | USA, Kanada, Teile der Karibik | whois.arin.net | rdap.arin.net/registry |
| APNIC | Asien und Pazifikraum | whois.apnic.net | rdap.apnic.net |
| LACNIC | Lateinamerika und Karibik | whois.lacnic.net | rdap.lacnic.net/rdap |
| AFRINIC | Afrika | whois.afrinic.net | rdap.afrinic.net/rdap |
In Japan, Korea, China, Brasilien und einigen weiteren Ländern gibt es zusätzlich National Internet Registries (etwa JPNIC, KRNIC, CNNIC, NIC.br). Abfragen zu Adressen aus diesen Regionen verweisen vom zuständigen RIR dorthin weiter; die detaillierten Angaben stehen dann nur in der nationalen Datenbank. Eine brasilianische Adresse etwa beantwortet LACNIC mit einem Verweis auf whois.registro.br.
IPv4 ist vergeben
Die IANA hat ihren freien IPv4-Vorrat 2011 an die RIRs ausgeschüttet. Seither ist der Pool nacheinander in allen Regionen versiegt; im RIPE-Gebiet fiel die letzte reguläre Zuteilung im November 2019. Neue Adressen bekommt man dort nur noch über eine Warteliste – einmalig ein /24 für LIRs ohne frühere Zuteilung – oder durch Kauf von einem bisherigen Inhaber.
Für die Recherche hat das eine unangenehme Nebenwirkung: Adressblöcke wechseln durch Transfers deutlich häufiger den Inhaber als früher. Ein Registry-Eintrag beschreibt den heutigen Zustand. Wer einen Logeintrag von vor drei Jahren untersucht, kann auf einen Betreiber stoßen, der damals gar nichts mit der Adresse zu tun hatte. Das Änderungsdatum im Datensatz ist deshalb ein wichtiges Feld.
RDAP statt whois
Das whois-Protokoll stammt aus dem Jahr 1982 und kennt weder definierte Abfragen noch ein festes Antwortformat. Jede Registry liefert eigenen Freitext, was maschinelle Auswertung mühsam macht. Der Nachfolger heißt RDAP (Registration Data Access Protocol): Abfragen laufen über HTTPS, Antworten kommen als JSON, und die zuständige Registry lässt sich automatisch ermitteln.
Bei Domainnamen ist der Wechsel bereits vollzogen: Zum 28. Januar 2025 entfiel die Pflicht der generischen Top-Level-Domains, überhaupt noch einen whois-Dienst anzubieten, und viele Registries haben ihn seither abgeschaltet. Bei den Länderdomains – darunter .de – gilt diese Vorgabe nicht; dort ist whois vielfach weiterhin der einzige Weg.
Bei IP-Adressen ist die Lage entspannter. Alle fünf RIRs betreiben RDAP und weiterhin whois auf Port 43. Für neue Skripte ist RDAP die richtige Wahl; für die schnelle Abfrage von Hand tut es whois nach wie vor.
Bootstrapping: die richtige Registry finden
Man muss nicht wissen, welche Registry für eine Adresse zuständig ist. Die IANA veröffentlicht Zuordnungstabellen, anhand derer ein Client die passende Stelle bestimmt:
https://data.iana.org/rdap/ipv4.jsonhttps://data.iana.org/rdap/ipv6.jsonhttps://data.iana.org/rdap/asn.json
Wer das nicht selbst umsetzen will, schickt die Abfrage an einen Bootstrap-Dienst, der auf die zuständige Registry weiterleitet. Auch das klassische whois-Kommando erledigt die Weiterleitung selbstständig, indem es dem Verweis der zuerst befragten Registry folgt.
Abfrage in der Praxis
Auf der Kommandozeile genügt für eine erste Auskunft:
whois 193.99.144.80
Strukturiert und maschinenlesbar wird es mit RDAP. Die Antwort ist JSON, lässt sich also direkt weiterverarbeiten:
curl -s https://rdap.db.ripe.net/ip/193.99.144.80 | jq
Für die Zuordnung einer Adresse zum autonomen System – also zu dem Netz, das die Adresse im globalen Routing ankündigt – eignet sich der whois-Dienst von Team Cymru. Er beantwortet auch Massenabfragen und ist damit für die Auswertung ganzer Logdateien brauchbar:
whois -h whois.cymru.com " -v 193.99.144.80"
Alle RIRs bieten daneben Weboberflächen an. Sie sind für Einzelabfragen bequem, für die Auswertung größerer Mengen aber ungeeignet – und alle Registries drosseln Abfragen ab einer gewissen Rate.
Die Antwort lesen
Ein whois-Datensatz aus der RIPE-Datenbank enthält im Kern diese Felder:
| Feld | Bedeutung |
|---|---|
| inetnum | Der Adressbereich, auf den sich der Eintrag bezieht |
| netname | Kurzname des Netzes, oft mit Hinweis auf den Verwendungszweck |
| descr | Freitextbeschreibung, häufig der Firmenname |
| country | Ländercode – Angabe des Inhabers, keine Ortsbestimmung |
| org | Verweis auf den Organisationsdatensatz mit Anschrift |
| abuse-c | Kontakt für Missbrauchsmeldungen |
| status | Art der Zuteilung, etwa ALLOCATED PA oder ASSIGNED PI |
| mnt-by | Wer den Eintrag pflegen darf |
| last-modified | Datum der letzten Änderung |
Häufig gibt es zu einer Adresse mehrere ineinander verschachtelte Einträge: einen großen Block für den Provider und darin einen kleineren für den Endkunden. Der spezifischste Eintrag ist der aussagekräftigste.
Ein verbreiteter Irrtum betrifft country. Das Feld nennt das Land der eingetragenen Organisation, nicht den Standort der Geräte. Ein deutscher Provider kann Adressen in Rechenzentren weltweit einsetzen, ohne dass sich der Eintrag ändert. Hinzu kommt, dass die Angabe optional ist: Bei ARIN-Einträgen fehlt sie häufig ganz. Wer sich auf dieses Feld verlässt, bekommt für einen erheblichen Teil des Adressraums keine Antwort.
Adressbereiche ohne Inhaber
Nicht jede Adresse ist jemandem zugeteilt. Wer eine der folgenden Adressen in einem Logfile findet, braucht keine Registry zu befragen – die Quelle liegt entweder im eigenen Netz oder die Adresse ist gefälscht.
| Bereich | Verwendung | Festgelegt in |
|---|---|---|
| 10.0.0.0/8 | Privates Netz | RFC 1918 |
| 172.16.0.0/12 | Privates Netz | RFC 1918 |
| 192.168.0.0/16 | Privates Netz | RFC 1918 |
| 100.64.0.0/10 | Carrier-Grade NAT beim Provider | RFC 6598 |
| 169.254.0.0/16 | Link-Local, Selbstkonfiguration | RFC 3927 |
| 127.0.0.0/8 | Loopback | RFC 1122 |
| fc00::/7 | Privates IPv6-Netz | RFC 4193 |
| fe80::/10 | Link-Local IPv6 | RFC 4291 |
Die vollständige Liste der Sonderbereiche führt RFC 6890; sie löst die früher üblichen RFC 3330 und RFC 5735 ab. Die IANA pflegt dieselbe Information zusätzlich als laufend aktualisierte Registry für IPv4 und IPv6.
Besonderheiten bei IPv6
Die Abfrage funktioniert bei IPv6 genauso – whois 2a02:2e0:3fe:1001:302:: oder der entsprechende RDAP-Aufruf liefern denselben Aufbau. Zwei Unterschiede sind für die Auswertung wichtig.
Erstens bekommt ein Endkunde kein einzelnes Gerät zugewiesen, sondern gleich ein ganzes Präfix, üblicherweise ein /56 oder /64. Ein Gerät wechselt innerhalb dieses Präfixes fortlaufend seine Adresse, weil die Privacy Extensions temporäre Adressen erzeugen. Für die Wiedererkennung ist deshalb nicht die einzelne Adresse aussagekräftig, sondern das Präfix.
Zweitens entfällt Carrier-Grade NAT. Eine IPv6-Adresse gehört zu genau einem Anschluss – die Kette ist kürzer und eindeutiger als bei IPv4.
Datenschutz und rechtliche Grenzen
Seit Geltung der DSGVO enthalten die Registry-Datenbanken deutlich weniger personenbezogene Angaben als früher. Namen und Kontaktdaten natürlicher Personen sind weitgehend entfallen oder durch Rollenobjekte ersetzt. Erhalten geblieben sind die Angaben zur Organisation und – im RIPE-Gebiet verpflichtend – der Abuse-Kontakt. Für den eigentlichen Zweck der Datenbank ändert das wenig: Sie soll Netzbetreiber erreichbar machen, nicht Nutzer identifizieren.
Die Auflösung einer IP-Adresse zu einem konkreten Anschluss kann in Deutschland nur der Provider vornehmen, und er darf es nur auf einer gesetzlichen Grundlage – im Regelfall auf Anordnung eines Gerichts oder einer Strafverfolgungsbehörde. Eine private Anfrage beim Provider bleibt ohne Ergebnis. Wer einen Rechtsverstoß verfolgen will, führt das über Anzeige oder anwaltliche Vertretung, nicht über die whois-Datenbank.
Geolokalisierung: ein anderes Thema
Dienste, die eine IP-Adresse einer Stadt zuordnen, greifen nicht auf Registry-Daten zurück, sondern auf kommerzielle Datenbanken, die aus Messungen, Providerangaben und Routing-Daten geschätzt werden. Auf Länderebene sind sie meist zuverlässig, auf Stadtebene oft nicht. Bei Mobilfunk, Satellitenanschlüssen, VPN-Diensten und Adressen hinter Carrier-Grade NAT liegen sie regelmäßig weit daneben. Als Indiz taugen solche Angaben, als Beweis nicht.
Vorgehen bei einem Fund im Logfile
- Prüfen, ob die Adresse in einem Sonderbereich liegt. Dann liegt die Ursache im eigenen Netz.
- Registry abfragen und den spezifischsten Eintrag heraussuchen. Änderungsdatum beachten.
- Autonomes System bestimmen, wenn der Registry-Eintrag unklar bleibt – das Routing verrät, wer die Adresse tatsächlich ankündigt.
- Abuse-Kontakt aus dem Eintrag entnehmen und die Meldung dorthin schicken, mit Zeitstempel inklusive Zeitzone, betroffener Adresse, Quellport und einem Auszug der Logzeilen.
- Bei strafrechtlich relevanten Sachverhalten Anzeige erstatten. Die Zuordnung zum Anschlussinhaber ist den Behörden vorbehalten.
Je präziser die Meldung, desto wahrscheinlicher ist eine Reaktion. Ein Abuse-Team, das nur eine IP-Adresse ohne Zeitangabe erhält, kann daraus nichts machen.