Warum wir keine externen IP-Adressen loggen

Externe IP-Adressen in den Logs versprechen Attribution und liefern sie nicht. Eine externe IP identifiziert gemietete Infrastruktur. Was das Logging dagegen sicher liefert: personenbezogene Daten im Sinne der DSGVO, mit allen Pflichten. Wer auf externe IP-Adressen in den Logs verzichtet, verliert forensisch wenig und gewinnt dafür Datenschutz. Dass eine dynamische IP-Adresse personenbezogen ist, steht seit EuGH Breyer (C-582/14, 2016) fest. Erlaubt ist das Logging trotzdem: Erwägungsgrund 49 DSGVO nennt Netzsicherheit als berechtigtes Interesse. Es kostet nur Zweckbindung, Löschfrist, Zugriffsschutz und im Breach-Fall einen meldepflichtigen Datensatz mehr. Unsere Rechnung: Diese Hausaufgaben kosten mehr, als die IP forensisch bringt.

In Gesprächen über Incident Response höre ich häufig, dass externe IPs in die Logs müssen, "damit wir Angriffe verhindern können und wissen, von wem es kommt". Nach vielen Jahren SOC-Arbeit sage ich: Nein, müssen sie nicht, und wer es war, wissen Sie damit auch nicht. Das Einzige, was sie sammeln, sind potenziell personenbezogene Informationen. Warum das so ist, und warum unsere Website deshalb ohne IP-Logging läuft, möchte ich hier begründen.

Die Vorstellung hinter IP-Logging: Eine Adresse kann einem Angreifer zugeordnet werden. Für Internet-Traffic im Jahr 2026 stimmt daran fast nichts mehr:

• VPN-Exits und Tor: Die IP kommt von einem Tunnelausgang, den sich tausende Nutzende teilen.
• Cloud-VMs: Die IP gehört zu einem Hyperscaler, gemietet für Minuten, danach hat sie jemand anderes.
• CGNAT: Mobilfunk- und viele Festnetz-Provider teilen eine öffentliche IP auf hunderte Anschlüsse gleichzeitig auf.
• GeoIP: Die Datenbank, die Ihnen "Land: X" sagt, kann im Moment des Loggens schon veraltet sein. IP-Bereiche wandern zwischen Providern und Regionen.

Kurz: Die IP ist wie Sternenlicht, ein Gruß aus der Vergangenheit.

Aus IPs lässt sich nicht einmal ableiten, mit wie vielen Angreifern Sie es zu tun haben. Ein Akteur kann über ein Botnetz mit einer Million Adressen kommen oder aber eine Million Mal von derselben Cloud-IP. Jede Statistik über die "Anzahl Angreifer" auf Basis von externen IP-Adressen misst gemietete oder gekaperte Infrastruktur, nicht Angreifer.

Es kommt schlimmer: Die Quell-IP ist nicht neutral, sondern vom Angreifer wählbar. Wer möchte, dass sein Traffic aus einem bestimmten Land zu kommen scheint, mietet dort einen Exit. False-Flag-Operationen über "passende" Herkunftsländer sind Standard.

Eine Kennzahl, die der Angreifer setzt, ist keine forensische Grundlage.

Echte Attribution existiert, aber sie funktioniert anders: Vorgehensweisen, Überschneidungen in der Angriffs-Infrastruktur über lange Zeiträume und Auskünfte von Providern. Das ist die Ebene von Strafverfolgungsbehörden und spezialisierten Intelligence-Teams mit Zugriff auf Daten. Und selbst dort endet die Kette oft an einer Jurisdiktion, die keine Auskunft gibt. Das access.log spielt in dieser Liga nicht mit.

Die IP hat einen echten, kurzen Nutzen: Sie verbindet Ereignisse innerhalb weniger Minuten. War der SSH-Login um 03:12 dieselbe Quelle wie der POST um 03:14? Gegen einen Bot: oft ja. Gegen jemanden, der es darauf anlegt, nein, der wechselt die Quelle zwischen zwei Schritten. Der Faden ist also nur gegen die zu gebrauchen, die sich keine Mühe geben, und für die reichen Session-ID, Request-ID oder eine gekürzte beziehungsweise gehashte Adresse mit kurzer Haltbarkeit (siehe Mittelweg). Für eine statische Seite ohne Konten stellt sich die Frage gar nicht.

Der Verzicht auf externe IP-Adressen kostet erstaunlich wenig. Was in unseren Logs steht und tatsächlich Fragen beantwortet:

• Angefragte Pfade: Scans auf /wp-admin/, .env oder /.git/ erkennen Sie am Pfad.
• Status-Codes und Muster: 404-Wellen, Fehlerhäufungen, kaputte Links.
• User-Agents: Bot-Verhalten und Tool-Signaturen (auch diese sind manipulierbar).
• Timing: Lastspitzen und Kampagnen-Verläufe.

Die Frage "werden wir gescannt, und wonach suchen die?" beantworten diese Felder vollständig.

Dass das keine Theorie ist, zeigt unser eigenes Log.

{"t":"2026-08-10T22:25:57+00:00","host":"nexcurity.com","method":"GET","uri":"/wp-includes/css/buttons.css","proto":"HTTP/1.1","status":404,"bytes":891,"rt":0.000,"ref":"http://nexcurity.com/wp-includes/css/buttons.css","ua":"Go-http-client/2.0"}

Ein Scanner sucht mit einem "Go-http-client" nach WordPress-Dateien.

{"t":"2026-08-11T10:37:39+00:00","host":"nexcurity.com","method":"GET","uri":"/en/home/node/.aws/credentials","proto":"HTTP/1.1","status":404,"bytes":891,"rt":0.000,"ref":"https://www.nexcurity.com/home/node/.aws/credentials","ua":"Mozilla/5.0 (compatible; Google-Extended/1.0; +http://www.google.com/bot.html)"}
{"t":"2026-08-16T03:44:10+00:00","host":"nexcurity.com","method":"GET","uri":"/de/.gcloud/credentials","proto":"HTTP/1.1","status":404,"bytes":891,"rt":0.000,"ref":"https://www.nexcurity.de/.gcloud/credentials","ua":"Mozilla/5.0 (compatible; Google-Extended/1.0; +http://www.google.com/bot.html)"}
{"t":"2026-08-16T03:44:16+00:00","host":"nexcurity.com","method":"GET","uri":"/en/aws/iam/temporary-credentials","proto":"HTTP/1.1","status":404,"bytes":891,"rt":0.000,"ref":"https://www.nexcurity.com/aws/iam/temporary-credentials","ua":"Mozilla/5.0 (compatible; Google-Extended/1.0; +http://www.google.com/bot.html)"}

Der User-Agent ist, wie die IP, vom Angreifer frei wählbar. Mitte August lief ein Credential-Scan durch unser Log.

Der Bot gibt sich als "Google-Extended" aus. Ich bin mir sehr sicher, dass der echte Googlebot keine Credentials crawlt. Und mal ganz ehrlich, so unter uns: Google-Extended existiert als Crawler gar nicht. Es ist ein Token für die robots.txt, mit dem der Nutzung für KI-Training widersprochen werden kann.

Nebenbei ist die Pfadliste ein Zeitzeuge des Hype-Cycles. Neben den Klassikern (.env in allen Varianten, AWS- und GCP-Credentials) suchen Bots jetzt gezielt nach Config-Files, Tokens und API-Schlüsseln für KI-Dienste. Wonach gesucht wird, wissen wir damit ziemlich genau. Wer sucht und warum, hätte uns die IP-Adresse nicht verraten.

Wem "keine IP" zu drastisch ist, der kann kürzen (/24 bzw. /48) oder hashen. Beim Hash entscheidet das Salt: Mit festem Salt ist die Adresse nur ein Pseudonym und bleibt personenbezogen. Erst ein Salt, das täglich wechselt, macht daraus etwas, das einen Tag lang korreliert und morgen niemandem mehr gehört. Dazu eine Löschfrist von 24 bis 72 Stunden.

1. Runtime-Verarbeitung ist etwas anderes als Logging. Rate-Limiting und Brute-Force-Schutz dürfen und sollen die IP im Arbeitsspeicher nutzen. Ohne IP-Adressen in den Logs funktioniert fail2ban nicht mehr. Nutzen Sie stattdessen bei nginx limit_req, bei Traefik die RateLimit-Middleware und bei OpenSSH ab 9.8 PerSourcePenalties; das ist In-Memory-Drosselung pro Quelle.
2. Interne IP-Adressen sind ein anderes Thema. Innerhalb des eigenen Netzes ist eine IP ein Gerät in Ihrem Inventar. Da ist die Zuordnung möglich.

Logging von externen IP-Adressen für die Gefahrenabwehr wird überbewertet, auch als präventives Deny von extern nach intern anhand von IOCs. IP-IOCs haben eine kurze Halbwertszeit. Nutzen Sie sie zur Lärmreduktion im Arbeitsspeicher. Was aber hinzukommt, ist die Datenschutz-Last.

Und wie schon geschrieben: interne IP-Adressen und auch der Verkehr von intern nach extern sind andere Geschichten.

• Logging-Inventur: Prüfen Sie, welche Ihrer Internet-erreichbaren Dienste IP-Adressen von extern speichern, auch in Reverse-Proxy- und Load-Balancer-Logs (X-Forwarded-For).
• Bedarf hinterfragen: Warum brauchen wir die IP-Adressen von extern? Welche Entscheidung wurde damit getroffen?
• Schutzfunktionen umbauen statt abschalten: Rate-Limiting auf In-Memory-Verarbeitung umstellen.
• Die Datenschutzerklärung angleichen: Wenn nichts geloggt wird, darf die Erklärung das auch klar sagen.

• Nichts geloggt gilt erst, wenn auch CDN, Provider-LB und WAF keine IP-Adressen speichern.
• Nginx und das error log. Während das access.log ein eigenes log_format bekommen kann, geht das mit dem error log nicht. Dort werden die IP-Adressen geloggt. Außer nginx hängt hinter einem Reverse-Proxy ohne aktives realip-Modul; dann bekommt er nur die Reverse-Proxy-IP. Ein zusätzliches log_not_found off in der nginx conf verhindert die 404-open() failed-Zeilen, die am häufigsten eine Client-IP tragen.
• Außerhalb des Web-Stacks loggen in der Standardeinstellung sshd und ufw IP-Adressen mit. Zum Anonymisieren bringt rsyslog das Modul mmanon mit; alternativ journald-seitig filtern.