Was Bots auf einem neuen Server suchen: 8.900 Anfragen

Diese Seite ist seit vier Wochen online. Sie hat keine Kommentare, keinen Login, keine Datenbank und kein PHP – nur HTML-Dateien, die ein Webserver ausliefert. Kaum jemand kennt sie. Trotzdem sind in dieser Zeit 8.874 Anfragen auf 1.925 verschiedene Adressen eingegangen, die es nie gab.

Das ist kein Angriff auf diese Seite. Das ist das Grundrauschen des Internets, und jeder Server bekommt es ab, sobald sein Name in einer Zertifikatsliste oder einem DNS-Eintrag auftaucht. Wer einen Homelab-Dienst nach außen öffnet, sollte wissen, wie dieses Rauschen aussieht – und was davon tatsächlich gefährlich wäre.

Die Zahlen

Quelle ist die Webstatistik des Hosting-Pakets, Zeitraum 4. August bis 2. September 2026.

	Wert
Echte Besuche (Menschen und Suchmaschinen)	816
Anfragen auf nicht existierende Adressen	8.874
Verschiedene nicht existierende Adressen	1.925
Häufigste einzelne Adresse	/wp-admin/install.php, 380-mal

Auf jeden echten Besuch kommen also rund elf Anfragen von Programmen, die eine Schwachstelle suchen. Für eine Seite ohne Reichweite ist das der Normalfall, nicht die Ausnahme.

Was gesucht wird

Die 1.925 Adressen lassen sich fast vollständig in sieben Gruppen einordnen. Die Reihenfolge ist die nach Anzahl der verschiedenen Pfade.

1. Hinterlassene Webshells

714 Pfade, alle mit der Endung .php: /1.php, /ops.php, /dex.php, /wp_filemanager.php, /this_is_a_new_hello_world.php und Hunderte zufällig wirkende Namen wie /3PJcpMFsD8B.php.

Das sind keine Angriffe, sondern Nachkontrollen. Wer einen Server einmal kompromittiert hat, legt eine kleine PHP-Datei ab, über die er später wieder hineinkommt. Die Scanner prüfen, ob eine solche Datei von einem früheren Einbruch noch da ist – auf jedem Server, den sie finden, ob er je betroffen war oder nicht.

2. Konfigurationsdateien mit Zugangsdaten

401 Pfade. Allein .env in dreißig Varianten: /.env, /.env.bak, /.env.production, /.env.local, /api/.env, /backend/.env, /config/.env. Dazu secrets.json, config.json, credentials.json, rclone.conf, .s3cfg, .npmrc.

Eine .env-Datei enthält bei vielen Web-Frameworks Datenbankpasswort, API-Schlüssel und Mail-Zugangsdaten im Klartext. Sie gehört nicht ins Webroot, liegt aber dort, wenn jemand das ganze Projektverzeichnis auf den Server kopiert hat. Ein einziger Treffer zahlt für den Scanner Tausende Fehlversuche.

3. Git-Verzeichnisse

185 Pfade: /.git/config (99-mal), /.git/HEAD, /.git-credentials, /.gitconfig, /.svn/entries, dazu CI-Dateien wie /.github/workflows/deploy.yml und /.gitlab-ci.yml.

Ein erreichbares .git-Verzeichnis ist der vollständige Quelltext samt Historie – und damit auch jede Zugangsdatei, die je eingecheckt und später „gelöscht“ wurde. Es entsteht auf dieselbe Art wie die .env: Das Repository selbst wurde ausgeliefert statt seines Build-Ergebnisses.

4. Schlüssel und Cloud-Zugänge

93 Pfade: /.ssh/id_rsa, /.ssh/id_ed25519, /.ssh/authorized_keys, /server.key, /key.pem, /.aws/credentials, /.aws/config, /firebase-adminsdk.json, /service-account.json, /terraform.tfstate, /.docker/config.json.

Jede dieser Dateien öffnet nicht den Webserver, sondern etwas Größeres dahinter: das Cloud-Konto, die Container-Registry, den Zustand der ganzen Infrastruktur. Ein terraform.tfstate enthält regelmäßig Passwörter im Klartext.

5. Konfigurationen von KI-Werkzeugen

13 Pfade, jeder rund zwanzigmal abgefragt: /.claude.json, /.claude/settings.json, /.config/anthropic/credentials/default.json, /.cursor/mcp.json, /.codex/config.toml, /.aider.conf.yml, /.continue/config.json, /.mcp.json, /.hermes/auth.json, /.openclaw/.env.

Diese Gruppe ist neu. Die Scanner suchen gezielt nach den Dateien, in denen KI-Coding-Werkzeuge ihre API-Schlüssel ablegen. Die Logik ist dieselbe wie bei .env: Wer sein Home-Verzeichnis oder sein Projekt unbedacht ausliefert, gibt damit auch den Schlüssel preis – und ein API-Schlüssel für ein Sprachmodell lässt sich unmittelbar zu Geld machen. Dass dieselbe Liste auf einem Server abgefragt wird, der weder Home-Verzeichnis noch PHP hat, zeigt, wie wenig die Scanner unterscheiden.

6. Entwicklungsserver

Rund 60 Pfade: /@fs/.env, /@fs/proc/self/environ, /.astro/manifest.json, /.vscode/launch.json, /_ignition/health-check, /ngsw.json.

Das @fs/-Präfix gehört zum Entwicklungsserver von Vite, der in einer verwundbaren Version beliebige Dateien des Systems auslieferte. Die Scanner prüfen, ob jemand seinen Dev-Server statt eines Produktions-Builds ins Netz gestellt hat. Dass .astro/manifest.json dabei ist, ist eine hübsche Pointe: Diese Seite ist mit Astro gebaut. Ausgeliefert wird aber nur dist/, und da liegt diese Datei nicht.

7. WordPress

286 Pfade, angeführt von /wp-admin/install.php mit 380 Anfragen – der häufigste Pfad überhaupt. Dazu /wp-login.php, /xmlrpc.php, /wp-json/, Plugin-Verzeichnisse.

install.php ist deshalb so beliebt, weil eine WordPress-Installation, die hochgeladen und dann vergessen wurde, dort auf ihren ersten Administrator wartet. Wer zuerst kommt, richtet ihn ein.

Wer da scannt

Die Anfragen kommen nicht von einem Angreifer, der diese Seite ausgesucht hat. Sie kommen aus gemieteter Rechenzeit, verteilt auf viele Adressen:

• Drei Server bei einem kanadischen Hoster haben am selben Nachmittag innerhalb von zwei Minuten dieselbe Liste abgearbeitet – ein Scanner, drei Maschinen.
• Ein Dutzend Adressen aus einer großen Cloud, jede mit demselben Muster von sieben Seiten und acht Anfragen.
• Eine einzelne Adresse mit 527 Anfragen über den ganzen Monat, die alles einmal durchprobiert und dann alle paar Tage wiederkommt.

Als Programm geben sie sich meist ehrlich zu erkennen: curl, python-requests, Go-http-client, oder schlicht scanner und checker. Ein Teil trägt den Namen eines Browsers, was nichts ändert – das Zugriffsmuster bleibt maschinell.

Was daraus folgt: Gegenmaßnahmen gegen einzelne Adressen bringen nichts. Eine gesperrte Adresse wird durch die nächste ersetzt, und die Liste ist dieselbe. Auch eine neue, unbekannte Domain hilft nicht – die Seite wurde innerhalb von Stunden nach dem ersten Zertifikat gefunden, weil Zertifikatsausstellungen öffentlich protokolliert werden.

Wen es trifft – und wann

Gefunden wird jeder. Getroffen wird nur, wer auf eine dieser Anfragen mit 200 statt 404 antwortet. Die Liste oben verrät ziemlich genau, wer das ist:

• Wer das Projektverzeichnis ausliefert statt des Build-Ergebnisses. git clone direkt ins Webroot, daneben die .env für die Datenbank. Der häufigste Fall auf Shared Hosting, und die Zielgruppe der Gruppen 2 und 3.
• Wer eine Installation vergessen hat. Eine Test-Subdomain, eine alte Staging-Umgebung, ein WordPress, das hochgeladen und nie eingerichtet wurde. Deshalb ist install.php der meistgefragte Pfad: Der Angreifer legt den Administrator an, den der Betreiber nie angelegt hat.
• Wer einen Entwicklungsserver nach außen hängt. Homelab-typisch: der Dev-Server hinter einem Reverse Proxy oder Tunnel, „nur kurz zum Zeigen“. Darauf zielt Gruppe 6.
• Wer WordPress mit ungepflegten Plugins betreibt. Die Webshell-Pfade aus Gruppe 1 suchen Server, bei denen ein Plugin-Exploit schon einmal durch war.
• Wer sein Home-Verzeichnis freigibt. Selten, aber genau dafür stehen die KI-Werkzeug-Pfade: ein schnell gestarteter python -m http.server im falschen Ordner, eine zu großzügige Dateifreigabe.

Nicht in dieser Liste, aber von denselben Betreibern mit anderen Listen gescannt: Proxmox-, PBS- und NAS-Oberflächen, SSH und RDP hinter einer Portweiterleitung.

Und der Zeitpunkt:

Wann	Was passiert
Stunden nach dem Zertifikat	Der Hostname steht in den öffentlichen Zertifikatsprotokollen und wird erstmals abgeklopft. Hier war das der Tag vor dem Livegang.
Danach laufend	Jede Scanner-Flotte kommt alle paar Tage wieder, mit erweiterter Liste. Es gibt keine ruhige Phase – auch nicht nach Jahren.
Tage nach einer neuen Lücke	Sobald eine Schwachstelle veröffentlicht ist, steht ihr Pfad auf den Listen. Die Dev-Server-Lücke aus Gruppe 6 war innerhalb weniger Tage in den Scans.
Im Moment des Treffers	Antwortet /.env mit 200, werden die Zugangsdaten sofort maschinell ausgewertet. Cloud-Schlüssel werden erfahrungsgemäß innerhalb von Minuten bis Stunden benutzt, nicht Wochen später.

Das ist der Punkt, der die Reihenfolge festlegt: Der erste Scan kommt vor dem ersten Leser. Wer einen Dienst öffnet und ihn „später absichern“ will, hat das Zeitfenster bereits verpasst. Absichern heißt hier zum Glück nicht viel – siehe nächster Abschnitt.

Was tatsächlich schützt

Die gute Nachricht steckt in der Liste selbst: Fast alles, was gesucht wird, ist eine Datei, die auf einem sauber aufgesetzten Server nicht existiert. Der Schutz besteht nicht darin, die Scanner abzuwehren, sondern darin, dass sie nichts finden.

Ausliefern, was gebaut wurde – nicht, was gebaut hat

Der häufigste Fehler hinter allen Gruppen oben ist derselbe: Das Projektverzeichnis liegt im Webroot. Damit sind .git, .env, Editor- und Werkzeugkonfigurationen automatisch erreichbar.

Die Regel dagegen ist einfach. Ins Webroot kommt ausschließlich das Build-Ergebnis. Bei dieser Seite ist das der Ordner dist/, der per rsync übertragen wird – das Repository selbst verlässt die Build-Maschine nie. Wer ein Framework mit Laufzeit betreibt, hält Code und Webroot getrennt: Das Framework zeigt mit seinem public/-Ordner ins Webroot, der Rest liegt eine Ebene darüber.

Eine .gitignore schützt hier übrigens vor nichts. Sie verhindert, dass eine Datei ins Repository kommt – nicht, dass sie auf dem Server liegt.

Den Webserver Dotfiles verweigern lassen

Als zweite Ebene für den Fall, dass doch etwas durchrutscht: Der Webserver soll Dateien und Verzeichnisse mit führendem Punkt grundsätzlich nicht ausliefern. Bei Apache ist das eine Regel in der Konfiguration, bei Caddy ein @dotfiles-Matcher, bei nginx ein location ~ /\. mit deny all. Damit sind .env, .git, .ssh, .aws und die gesamte Gruppe 5 mit einer Zeile erledigt – unabhängig davon, was jemand später einmal hochlädt.

Die eigenen Logs einmal ansehen

Das ist der Teil, der die meisten überrascht. Zwei Befehle auf dem Zugriffsprotokoll eines Apache- oder nginx-Servers zeigen, was bei dir gesucht wird:

# Die zwanzig häufigsten Adressen, die es nicht gibt
awk '$9 == 404 { print $7 }' access.log | sort | uniq -c | sort -rn | head -20

# Wurde ein bestimmter Pfad angefragt – und mit welchem Status?
grep -F '/.env' access.log | awk '{ print $9 }' | sort | uniq -c

Wichtig ist die zweite Zeile: Ein 404 ist gut. Ein 200 auf /.env bedeutet, dass die Datei ausgeliefert wurde – dann sind alle darin enthaltenen Zugangsdaten als bekannt zu betrachten und sofort zu tauschen.

Und wenn ein Scan trifft?

Irgendwann übersieht man etwas. Ein Plugin, ein Test-Upload, ein vergessener Dienst. Dann entscheidet nicht die Firewall, sondern die Datensicherung darüber, was der Vorfall kostet.

Die Scanner aus Gruppe 1 suchen nach Servern, die bereits jemandem gehören. Wer so einen Server zurückholen will, braucht einen Stand von vor dem Einbruch – und weiß meist nicht genau, wann der war. Genau dafür ist die Aufbewahrung über Wochen gedacht, die in Ransomware-sichere Backups beschrieben ist. Und das Backup-Ziel darf vom kompromittierten Server aus nicht erreichbar sein, sonst ist es das erste, was aufgeräumt wird.

Ein zweiter Punkt, der selten bedacht wird: Die Anzahl der 404-Antworten ist selbst ein Signal. Ein plötzlicher Sprung auf das Zehnfache bedeutet meist, dass die Seite auf einer neuen Scanner-Liste gelandet ist. Ein Sprung auf null bedeutet oft, dass der Webserver nicht mehr antwortet. Wer ohnehin ein Backup-Monitoring betreibt, kann diesen Wert mit geringem Aufwand daneben legen.

Checkliste

• Im Webroot liegt nur das Build-Ergebnis, kein Repository, keine .env
• Der Webserver liefert keine Dateien und Verzeichnisse mit führendem Punkt aus
• Kein Entwicklungsserver ist von außen erreichbar
• Keine vergessene Installation wartet auf ihren ersten Administrator
• Die Top-20-404-Liste der eigenen Logs wurde einmal angesehen
• /.env und /.git/config liefern nachweislich 404, nicht 200
• Die Datensicherung reicht Wochen zurück und ist vom Server aus nicht löschbar

Häufige Fragen

Muss ich diese Adressen sperren? Nein. Die Adressen wechseln, die Liste bleibt. Sperren kostet Pflege und verhindert nichts, was ein sauber aufgesetzter Server nicht ohnehin mit einem 404 beantwortet. Sinnvoll ist eine Sperre nur bei Diensten mit Login, um Passwort-Rateversuche zu bremsen – das ist ein anderes Thema als das hier beschriebene Abklopfen.

Warum wird ein Server gefunden, den niemand kennt? Weil jedes TLS-Zertifikat in öffentlichen Protokollen erscheint, sobald es ausgestellt ist. Scanner lesen diese Protokolle laufend mit. Ein neuer Hostname ist damit innerhalb von Stunden bekannt, ganz ohne Link und ohne Suchmaschine.

Ist eine statische Seite dagegen immun? Gegen fast alles in dieser Liste ja, weil es nichts gibt, das Code ausführt. Nicht immun ist sie gegen den Fehler, das falsche Verzeichnis auszuliefern – ein .git-Ordner im Webroot ist auf einer statischen Seite genauso lesbar wie überall sonst.

Sind die Zugriffe der Suchmaschinen in den 8.874 enthalten? Nein. Googlebot, Bingbot und die anderen fragen nach Seiten, die es gibt, und nach robots.txt. Die Zahl umfasst nur Anfragen auf Adressen, die auf dieser Seite nie existiert haben.

Weiter im Cluster

• Ransomware-sichere Backups – der Plan für den Fall, dass ein Scan trifft
• Backup-Monitoring – wo ein 404-Zähler mit hineinpasst
• 3-2-1-Backup-Strategie – der Überblick
• Typische Backup-Fehler – der Fehler „Backup-Ziel vom Server aus erreichbar“ ist auch dort dabei