Ich habe eine unbekannte IP in meinen Server-Logs gefunden. Was jetzt?

Geschrieben von Aldo · Threat Hunter im Blue Team
Zuletzt aktualisiert am 9. November 2026 · 9 Min. Lesezeit

Du öffnest dein Access-Log, um eigentlich etwas anderes zu suchen, und da ist sie: eine Adresse, die du nie gesehen hast und die um vier Uhr morgens an deiner Seite klopft. So findest du in etwa zehn Minuten heraus, ob sie einen zweiten Gedanken wert ist.

Fangen wir mit dem Beruhigenden an. Ein Server im öffentlichen Internet bekommt den ganzen Tag automatisierten Besuch, meist lange bevor ihn ein Mensch findet. Crawler indexieren Seiten. Forschungsprojekte scannen jede Adresse im Internet, um zu kartieren, was es gibt. Andere Skripte probieren auf Millionen von Seiten dieselben paar Türen aus und hoffen, dass jemand eine offen gelassen hat. Unbekannte Adressen zu sehen ist normal. Die Frage ist nie „Ist diese IP böse?“, sondern „Was hat sie versucht, und hat es geklappt?“

Die Zeilen finden

WordPress führt kein eigenes Besucherprotokoll. Die Spur liegt im Access-Log deines Webservers, und wo das liegt, hängt von deinem Hosting ab:

Shared Hosting mit cPanel: Unter Metriken → Raw Access (Metrics → Raw Access) lädst du das Log jeder Domain herunter. Bei Plesk öffnest du Websites & Domains → Logs.
Eigener Server (VPS): Die üblichen Standardpfade sind /var/log/nginx/access.log für nginx, /var/log/apache2/access.log für Apache unter Debian und Ubuntu und /var/log/httpd/access_log unter Red Hat, Fedora und Verwandten. Dein Hoster kann sie geändert haben; das letzte Wort hat die Konfigurationsdatei des Servers.
Windows mit IIS: C:\inetpub\logs\LogFiles\W3SVC1\ (die Zahl ist die ID deiner Website).

Um unter Linux oder macOS alle Zeilen einer Adresse herauszuziehen, suchst du sie mit einem Leerzeichen dahinter. Ohne das Leerzeichen würde eine Suche nach 203.0.113.4 auch 203.0.113.45 finden:

grep -F '185.220.101.1 ' /var/log/nginx/access.log
zgrep -F '185.220.101.1 ' /var/log/nginx/access.log.*.gz   # ältere, komprimierte Tage

Um zu sehen, welche Adressen am häufigsten kommen, zählst du das erste Feld:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Unter Windows erledigt PowerShell dieselbe Suche:

Select-String -Path 'C:\inetpub\logs\LogFiles\W3SVC1\*.log' -Pattern '185.220.101.1' -SimpleMatch

IIS schreibt seine Felder in einer anderen Reihenfolge als Apache und nginx; die Zeile #Fields: am Anfang jeder Datei sagt dir, welche Spalte die Client-Adresse ist (c-ip).

Ist das wirklich die Adresse des Besuchers?

Prüf das vor allem anderen. Wenn deine Seite hinter einem CDN oder Proxy wie Cloudflare liegt, protokolliert dein Server womöglich bei jeder Anfrage die Adresse des CDN statt die des Besuchers. Stehen in jeder Zeile dieselben paar Adressen und gehören sie zu deinem CDN, schaust du auf das CDN. Dein Server muss die ursprüngliche Adresse aus dem Header lesen, den das CDN mitschickt (bei Cloudflare CF-Connecting-IP; bei Apache erledigt das mod_remoteip, bei nginx das Modul real_ip). Bis dahin würde eine IP-Sperre auf dem Server das CDN sperren, und alle Besucher gleich mit.

Eine Zeile lesen

Die meisten Apache- und nginx-Server schreiben das Format „combined“. Hier ist eine Zeile aus dem Beispiel weiter unten, in ihre Teile zerlegt:

185.220.101.1 - - [05/Nov/2026:09:31:07 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"

185.220.101.1: Die Adresse, die sich mit deinem Server verbunden hat. Bei einer abgeschlossenen Web-Anfrage ist sie schwer zu fälschen, auch wenn sie zu einem VPN, zu Tor oder einem Cloud-Server gehören kann statt zur Person dahinter.
- -: Identität und Benutzername. Fast immer leer.
[05/Nov/2026:09:31:07 +0000]: Wann es passiert ist, mit Zeitzonenversatz.
"POST /wp-login.php HTTP/1.1": Was angefragt wurde. POST sendet Daten, hier einen Benutzernamen und ein Passwort.
200: Die Antwort deines Servers. Das wichtigste Feld der Zeile.
6832: Zurückgesendete Bytes.
"-": Referrer: die Seite, auf der der Link stand. Kommt vom Client, kann also alles behaupten.
"Mozilla/5.0 …": User-Agent: was der Client zu sein behauptet. Kommt ebenfalls vom Client, ist also ebenfalls unbewiesen.

Merk dir den letzten Punkt: Die Adresse ist ein Indiz, der User-Agent nur eine Behauptung.

Ein Praxisbeispiel: ein Morgen auf einem kleinen WordPress-Blog

Diese zwölf Zeilen sind eine typische halbe Stunde auf einem kleinen Blog. Die Adresse des einzigen normalen Lesers haben wir durch eine Dokumentationsadresse ersetzt (203.0.113.45, reserviert für Beispiele), damit hier keine echte Person auftaucht. Die übrigen Adressen sind öffentliche Infrastruktur.

Das Beispiel-Log (12 Zeilen)

203.0.113.45 - - [05/Nov/2026:09:14:02 +0000] "GET /2026/10/back-up-your-photos/ HTTP/1.1" 200 18342 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
203.0.113.45 - - [05/Nov/2026:09:14:03 +0000] "GET /wp-content/themes/twentytwentyfive/style.css HTTP/1.1" 200 4120 "https://example.com/2026/10/back-up-your-photos/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
66.249.66.1 - - [05/Nov/2026:09:15:40 +0000] "GET /2026/09/router-settings/ HTTP/1.1" 200 21004 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
167.94.138.35 - - [05/Nov/2026:09:17:11 +0000] "GET / HTTP/1.1" 200 15233 "-" "Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)"
3.5.140.1 - - [05/Nov/2026:09:20:55 +0000] "GET /.env HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
3.5.140.1 - - [05/Nov/2026:09:20:55 +0000] "GET /wp-config.php.bak HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
3.5.140.1 - - [05/Nov/2026:09:20:56 +0000] "GET /wp-content/uploads/2026/11/cache.php HTTP/1.1" 404 548 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
185.220.101.1 - - [05/Nov/2026:09:31:07 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:09 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:12 +0000] "POST /xmlrpc.php HTTP/1.1" 200 4272 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
185.220.101.1 - - [05/Nov/2026:09:31:15 +0000] "POST /wp-login.php HTTP/1.1" 200 6832 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
40.77.167.10 - - [05/Nov/2026:09:40:28 +0000] "GET /robots.txt HTTP/1.1" 200 67 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Wir haben das Log in den Log-Checker von iplover eingefügt. Er hat sechs Adressen gefunden und die fünf öffentlichen mit den öffentlichen Listen auf unserem Server abgeglichen; das Log selbst blieb im Browser. Das ist die Ergebnistabelle vom 9. November 2026:

IP-Adresse	Zeilen	Kategorie	Netzwerktyp
185.220.101.1	4	Tor-Exit-Nodes	Tor-Exit-Node
3.5.140.1	3	Cloud und Hosting	Hosting, Cloud oder Rechenzentrum
203.0.113.45	2	Privat oder reserviert	Private oder reservierte Adresse (nicht geprüft)
66.249.66.1	1	Googlebot	Nicht erkannt
167.94.138.35	1	Internet-Scanner	Nicht erkannt
40.77.167.10	1	Bingbot	Nicht erkannt

Zwei Spalten, zwei Fragen. Kategorie sagt, wofür die Adresse bekannt ist: Crawler, Scanner, Tor, Cloud-Anbieter. Netzwerktyp sagt, zu welcher Art von Netz sie gehört, soweit die öffentlichen Listen es zeigen. „Nicht erkannt“ heißt dort nur, dass keine Liste sie abdeckt; ein Urteil über die Adresse ist das nicht.

Listen ändern sich täglich. Wenn du dasselbe Beispiel später ausprobierst, kann ein Ergebnis also anders aussehen. Das bedeuten die einzelnen Gruppen für diese Seite.

Der Leser: 203.0.113.45

Zwei Anfragen im Abstand von einer Sekunde: ein Blogartikel, dann das Stylesheet des Themes, mit Google als Referrer und einem gewöhnlichen Chrome-User-Agent. Das ist ein Mensch, der gesucht, geklickt und gelesen hat. In deinem eigenen Log würde ein echter Besucher als Internetprovider auftauchen. Nichts zu tun.

Die Crawler: 66.249.66.1 und 40.77.167.10

Googlebot hat einen Artikel abgerufen, Bingbot hat robots.txt gelesen. Der Log-Checker hat beide Adressen in den Listen gefunden, die die Suchmaschinen veröffentlichen, deshalb nennt er sie beim Namen; auf den User-Agent allein verlässt er sich nie. Googlebot kannst du selbst mit zwei DNS-Abfragen prüfen, wie Google es empfiehlt: Die Rückwärtsabfrage muss auf googlebot.com, google.com oder googleusercontent.com enden, und die Vorwärtsabfrage dieses Namens muss dieselbe Adresse liefern.

host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

Soll ein Crawler seltener vorbeikommen, sag es ihm in robots.txt. Echte Suchmaschinen zu sperren nimmt dich aus ihren Ergebnissen.

Der Scanner: 167.94.138.35

Censys scannt das gesamte Internet und macht die Ergebnisse für Sicherheitsteams und Forschende durchsuchbar. Er hat deine Startseite abgerufen und ist wieder gegangen. Das ist Rauschen, kein Angriff. Du kannst Scanner sperren, wenn dich die Zeilen stören, aber sie gefährden deine Seite nicht.

Der Hochstapler: 3.5.140.1

Das ist die Zeile, bei der du zweimal hinschauen solltest. Der User-Agent sagt Googlebot, aber die Adresse gehört Amazon Web Services, nicht Google. Googles Crawler laufen nicht in Amazons Cloud. „Googlebot“ kann jeder in einen User-Agent schreiben.

Dann schau, was er wollte: /.env, /wp-config.php.bak und eine .php-Datei im Upload-Ordner. Das ist ein Einkaufszettel für Geheimnisse: .env-Dateien und Sicherungskopien von wp-config.php enthalten oft Datenbankpasswörter und Schlüssel, und eine PHP-Datei in uploads wäre eine Hintertür, die jemand früher hinterlassen hat. Alle drei bekamen 404. Da war nichts, also wurde nichts geholt.

Sorg dafür, dass das so bleibt. Ruf diese Pfade selbst auf und prüf, dass die Antwort 404 oder 403 ist, nie 200:

curl -I https://example.com/.env
curl -I https://example.com/wp-config.php.bak

Der Passwortrater: 185.220.101.1

Vier POST-Anfragen in acht Sekunden, drei an /wp-login.php und eine an /xmlrpc.php. Da probiert jemand Passwörter aus. Der XML-RPC-Endpunkt ist beliebt, weil eine einzige Anfrage viele Versuche enthalten kann.

Jede Antwort war 200, und das ist eine gute Nachricht. Wenn ein WordPress-Login fehlschlägt, wird die Anmeldeseite mit einer Fehlermeldung erneut angezeigt, und diese Seite ist ein 200. Ein erfolgreicher Login wird mit einer Weiterleitung zum Dashboard beantwortet, die im Log als 302 erscheint. Kein 302, kein Zutritt.

Die Adresse ist ein Tor-Exit-Relay, das viele Menschen teilen. Sie zu sperren würde diese vier Anfragen stoppen, aber der nächste Versuch kommt einfach von einem anderen Exit oder einem Cloud-Server. Das Tor-Projekt weist selbst darauf hin, dass manche Tor-Nutzer ganz legitime Besucher deiner Seite sein können. Die dauerhafte Lösung liegt auf deiner Seite, weiter unten.

Fazit für diesen Morgen: Niemand ist reingekommen. Zwei Dinge solltest du aber angehen: den Login absichern und prüfen, dass die geheimen Dateien wirklich nicht erreichbar sind.

Wenn du das siehst, tu das

Dieselbe Überlegung funktioniert für jede Zeile. Such dir die Zeile, die zu dem passt, was du vor dir hast:

Was du im Log siehst	Was es bedeutet	Was zu tun ist
Normale Seiten, `200`, ein Browser-User-Agent, eine Suchmaschine als Referrer	Ein Besucher	Nichts.
Ein Crawler, den der Log-Checker beim Namen nennt (Googlebot, Bingbot und Co.)	Eine echte Suchmaschine oder ein bekannter Bot	Nichts. Mit `robots.txt` kannst du ihn bremsen.
„Googlebot“ oder „bingbot“ im User-Agent, von einer Adresse, die nicht ihnen gehört	Ein falscher Crawler	Behandle ihn wie einen unbekannten Bot. Sperr ihn, wenn er stört.
Anfragen nach `/.env`, Backups, `phpmyadmin` und Ähnlichem, alle `404`	Ein Scanner auf der Suche nach Fehlern	Prüf, dass diese Pfade auch bei dir 404 liefern. Ansonsten nichts.
Dieselbe Art Anfrage mit `200` beantwortet	Eine geheime Datei war lesbar	Sofort handeln. Geh davon aus, dass sie kopiert wurde: Ändere jedes Passwort und jeden Schlüssel darin (Datenbankpasswort, WordPress-Salts, API-Schlüssel) und lösch dann die Datei.
Viele `POST`s an `/wp-login.php` oder `/xmlrpc.php`, mit `200` beantwortet	Gescheitertes Passwortraten	Login absichern (siehe unten).
Ein `POST` an `/wp-login.php` mit `302` beantwortet, von einer Adresse, die du nicht kennst	Jemand hat sich angemeldet	Prüf unter Benutzer, ob es Konten gibt, die du nicht angelegt hast, ändere alle Admin-Passwörter, nutz Überall sonst abmelden in deinem Profil und such nach kürzlich geänderten Plugins oder Themes.
Ein `200` für eine `.php`-Datei in `/wp-content/uploads/`	Möglicherweise eine bereits vorhandene Hintertür	Im Upload-Ordner hat PHP nichts zu suchen. Behandle die Seite als kompromittiert: Bitte deinen Hoster um Hilfe und spiel ein Backup ein, von dem du weißt, dass es sauber ist.
Hunderte Anfragen pro Minute aus einem Netz, und die Seite wird langsam	Ein aggressiver Bot	Begrenze ihn am CDN oder in der Firewall, oder sperr den Adressbereich.

Den Login absichern

Passwortraten hört nie auf, also mach es sinnlos, statt jede Adresse zu jagen:

Nutze für jedes Konto, das sich anmelden kann, ein langes, einzigartiges Passwort, angefangen bei den Admins.
Schalte für Admins die Zwei-Faktor-Authentifizierung ein. WordPress bringt sie nicht mit, du brauchst also ein Plugin.
Begrenze die Anmeldeversuche, am besten am CDN oder auf dem Webserver, sonst mit einem Sicherheits-Plugin.
Wenn nichts, was du nutzt, XML-RPC braucht (manche Plugins wie Jetpack und manche ältere Apps tun es), schalte es ab oder sperr /xmlrpc.php.

Wann eine Sperre sinnvoll ist

Sperren lohnt sich für eine einzelne, hartnäckige Quelle, die Ressourcen verschwendet, etwa einen Cloud-Server, der auf deine Seite einhämmert. Gegen alles andere ist es eine schwache Verteidigung, denn Bots wechseln ihre Adresse nach Belieben. Wenn du doch eine sperrst, geht es so. (Das Feld Sperrliste kopieren im Log-Checker schreibt dir diese Zeilen für die Kategorien, die du ankreuzt.)

Apache 2.4, in der Konfiguration der Website oder in .htaccess:

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

nginx, im server-Block:

deny 203.0.113.45;

Hinter Cloudflare oder einem anderen CDN sperrst du besser am CDN (Cloudflare nennt das IP Access Rules oder benutzerdefinierte WAF-Regeln; die Menünamen ändern sich ab und zu). Dein Server sieht nur die Adressen des CDN, es sei denn, du hast ihn so eingerichtet, dass er die des Besuchers liest.

Was dir eine IP-Adresse nicht verrät

Eine Adresse zeigt auf ein Netz, nicht auf eine Person. Tausende Menschen hinter einem Provider, einem VPN oder Tor können sie teilen. Nächste Woche kann sie jemand anderem gehören. Ihr Standort ist eine Schätzung, oft nur die nächste größere Stadt des Providers. Behandle eine Adresse also nicht als Identität, und versuch nicht, jemanden darüber ausfindig zu machen. Unsere Ratgeber dazu, was jemand mit einer IP-Adresse anfangen kann und ob eine IP die Wohnadresse verrät, erklären, warum.

Wenn dich eine Adresse dauerhaft angreift, ist das Netz, das sie betreibt, der richtige Ansprechpartner. Die IP-Abfrage zeigt den Inhaber und seine Abuse-Adresse aus den offiziellen Registern. Eine Antwort kannst du bei wiederholtem Missbrauch durch einen Server erwarten, nicht bei einem einzelnen Scan. Wenn du Daten oder Geld verloren hast, erstatte zusätzlich Anzeige bei der Polizei, in vielen Bundesländern auch online über die Onlinewache.

Quellen

Offizielle Dokumente, mit denen wir die Fakten in diesem Ratgeber geprüft haben.