Kurz gesagt: Backup-Dateien im Webroot, also Datenbank-Dumps (.sql), Archive (.zip, .tar.gz) und Sicherungskopien (.bak, .old, ~), kann jeder herunterladen, der den Dateinamen kennt oder errät. Suchen Sie solche Dateien regelmäßig mit find, verschieben Sie Sicherungen außerhalb des öffentlichen Verzeichnisses, sperren Sie typische Endungen im Webserver und prüfen Sie in den Zugriffsprotokollen, ob sie bereits abgerufen wurden.
Das Backup, das zum Leck wird
Kurz vor einem Update erzeugt jemand noch schnell eine Sicherung: backup.zip im Hauptverzeichnis, daneben datenbank.sql. Das Update klappt, die Dateien bleiben liegen. Monate später sind sie immer noch da, mit dem kompletten Code, allen Kundendaten und den Zugangsdaten der Website.
Dieses Muster gehört zu den häufigsten Befunden bei Prüfungen von Webservern. Es braucht keinen Exploit und keine Lücke in PHP. Ein Webserver liefert aus dem Webroot aus, was dort liegt, und Archive oder SQL-Dateien führt er nicht aus, sondern bietet sie zum Download an.
Ein Archiv der Website enthält dabei nicht nur Daten, sondern auch den Code samt Konfiguration. Wer es herunterlädt, kann in Ruhe nach Schwachstellen suchen und kennt die Zugangsdaten zur Datenbank.
Automatisierte Scanner suchen gezielt nach typischen Namen wie backup.zip, site.tar.gz oder dump.sql, oft kombiniert mit dem Domainnamen oder einem Datum. Wer glaubt, ein ungewöhnlicher Dateiname schütze, unterschätzt, wie systematisch diese Suche läuft.
Welche Dateien gemeint sind
Backup-Dateien im Webroot treten in mehreren Formen auf:
| Art | Typische Endungen | Was drinsteckt |
|---|---|---|
| Datenbank-Dumps | .sql, .sql.gz, .dump |
Kundendaten, Bestellungen, Passwort-Hashes, Einstellungen |
| Archive der Website | .zip, .tar, .tar.gz, .tgz, .rar, .7z |
gesamter Code, Konfiguration, Uploads |
| Kopien einzelner Dateien | .bak, .old, .orig, .save, .php~, .copy |
oft Konfigurationsdateien mit Zugangsdaten |
| Editor-Reste | .swp, .swo, ~ am Ende |
Teile von gerade bearbeiteten Dateien |
| Plugin-Sicherungen | eigene Unterordner im CMS | vollständige Sicherungen, teils mit erratbaren Namen |
Besonders heikel sind Kopien von Konfigurationsdateien. Die Originaldatei config.php führt der Server aus, ihr Inhalt bleibt verborgen. Die Kopie config.php.bak liefert er als Text aus, mitsamt Datenbankpasswort.
Backup im Webroot finden: Suche auf dem Server
Die folgende Suche listet verdächtige Dateien unterhalb der Webroots mit Datum und Größe. Passen Sie die Pfade an Ihren Server an:
find /var/www /srv/www -type f \( \
-iname '*.sql' -o -iname '*.sql.gz' -o -iname '*.dump' -o \
-iname '*.zip' -o -iname '*.tar' -o -iname '*.tar.gz' -o -iname '*.tgz' -o \
-iname '*.rar' -o -iname '*.7z' -o \
-iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' -o \
-iname '*~' -o -iname '*.swp' \) \
-printf '%TY-%Tm-%Td %10s %p\n' 2>/dev/null | sort
Nicht jeder Treffer ist ein Problem. Manche Archive sind bewusst zum Download bereitgestellt, etwa Handbücher. Jede Datei verdient aber eine bewusste Entscheidung. Achten Sie besonders auf große Dateien und auf Ordner von Backup-Plugins. Bei Shared Hosting ohne Shell-Zugang hilft die Dateiübersicht im Hosting-Panel oder ein Abruf per SFTP.
Finden Sie einen Datenbank-Dump mit Kundendaten im Webroot, verschieben Sie ihn sofort aus dem öffentlichen Verzeichnis und sichern Sie die Zugriffsprotokolle, bevor diese rotiert werden. Erst danach klären Sie, ob die Datei abgerufen wurde.
Wurde die Datei schon heruntergeladen?
Die Antwort steht in den Zugriffsprotokollen des Webservers. Gesucht sind erfolgreiche Abrufe, also Status 200, auf die gefundenen Dateien:
# Erfolgreiche Abrufe typischer Backup-Endungen (Combined-Logformat)
zgrep -hE '\.(sql|sql\.gz|zip|tar|tgz|gz|bak|old|7z|rar)[ ?]' /var/log/nginx/access.log* \
| awk '$9 == 200 {print $4, $1, $7, $10}'
Die Ausgabe zeigt Zeitpunkt, Adresse, Pfad und Größe der Antwort. Entspricht die übertragene Größe der Dateigröße, wurde die Datei vollständig geladen. Wie lange Protokolle zurückreichen, hängt von der Rotation ab. Reichen sie nicht bis zum Erstellungsdatum der Datei, lässt sich ein früherer Abruf nicht ausschließen. Ausführlich beschreibt das Webserver-Logs nach einem Angriff auswerten. Ohne Zugriff auf die Rohprotokolle, etwa bei Shared Hosting, fragen Sie beim Hoster nach den Protokollen für den betreffenden Zeitraum.
Wurde ein Dump mit personenbezogenen Daten abgerufen oder ist das nicht auszuschließen, beginnt die Prüfung einer Meldepflicht. Die Grundlagen fasst DSGVO-Meldepflicht: 72 Stunden nach dem Vorfall zusammen; die Bewertung im Einzelfall gehört zu Ihrem Datenschutzbeauftragten. Zugangsdaten aus abgerufenen Dateien tauschen Sie in jedem Fall aus.
Backup-Plugins, Panels und Umzüge
Viele Funde gehen auf Backup-Plugins von CMS und Shops zurück. Sie legen Sicherungen häufig in einem Unterordner des Webroots ab, teils mit Namen aus Datum und Domain, die sich erraten lassen. Prüfen Sie in jedem Plugin drei Einstellungen: Wohin wird gesichert? Werden lokale Kopien nach dem Hochladen an ein externes Ziel gelöscht? Ist der lokale Ordner gegen direkten Abruf geschützt?
Sicherungen aus Hosting-Panels liegen in der Regel außerhalb des Webroots, etwa im Home-Verzeichnis. Problematisch wird es, wenn jemand eine solche Sicherung in den Webroot kopiert, weil der Download im Browser bequemer ist als per SFTP. Für Umzüge gilt deshalb: Übertragung per SFTP oder direkt zwischen den Servern, nie über einen öffentlichen Link.
Betreuen Agenturen oder Dienstleister Ihre Websites, sollte diese Regel auch im Vertrag stehen, samt Pflicht zum Aufräumen nach Wartungsarbeiten. Hinweise gibt IT-Dienstleister-Verträge: Sicherheitspflichten klar regeln.
Dauerhaft vorbeugen: Speicherort und Sperren
Damit sich das Problem nicht wiederholt, braucht es zwei Ebenen. Die erste ist organisatorisch: Sicherungen haben einen festen Ort außerhalb des Webroots und zusätzlich außerhalb des Servers. Wie eine belastbare Sicherung aussieht, beschreibt der Ratgeber Backups nach der 3-2-1-Regel.
Die zweite Ebene ist technisch: Der Webserver verweigert typische Backup-Endungen grundsätzlich, auch wenn doch einmal eine Datei liegen bleibt.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Archive wie .zip sperren Sie nur, wenn Ihre Website keine Downloads in diesem Format anbietet, oder gezielt in den Verzeichnissen, in denen keine Downloads liegen. Ergänzend helfen eine regelmäßige automatische Suche mit Benachrichtigung und eine kurze Regel im Team: Keine Sicherungen und Kopien im Webroot, auch nicht für fünf Minuten. Verwandte Fälle wie versteckte Konfigurationsdateien behandelt Zugangsdaten und .env-Dateien richtig schützen.
Wie hilft PHP SOS konkret?
- Wir durchsuchen Ihre Webroots nach Dumps, Archiven, Kopien und Plugin-Sicherungen und bewerten jeden Fund.
- Wir prüfen anhand der Zugriffsprotokolle, ob Dateien abgerufen wurden, und dokumentieren das Ergebnis für Ihre Datenschutzbewertung.
- Wir richten Sperren im Webserver und eine regelmäßige automatische Suche ein.
- Wir verlegen Sicherungen an einen geschützten Ort außerhalb des Webroots.
Diese Arbeiten sind Teil unserer Server-Härtung für PHP-Webserver.
Häufige Fragen
Warum landen Backups überhaupt im Webroot?
Meist aus Bequemlichkeit: Ein Dump wird für einen Umzug erzeugt, ein Plugin legt Sicherungen im eigenen Ordner ab, oder vor einer Änderung wird schnell eine Kopie einer Datei mit der Endung .bak angelegt. Danach gerät die Datei in Vergessenheit.
Wie gefährlich ist eine Datei wie config.php.bak?
Sehr. Eine Datei mit der Endung .php wird vom Server ausgeführt, ihr Inhalt bleibt verborgen. Eine Kopie mit anderer Endung liefert der Server dagegen meist als Text aus, mitsamt Datenbankpasswort und Schlüsseln.
Ist ein öffentlich abrufbarer Datenbank-Dump eine Datenpanne?
Wenn er personenbezogene Daten enthält und abgerufen wurde oder ein Abruf nicht ausgeschlossen werden kann, kommt eine Meldepflicht nach DSGVO in Betracht. Die Bewertung im Einzelfall übernehmen Ihr Datenschutzbeauftragter oder Ihre Rechtsberatung.
Wo sollten Backups stattdessen liegen?
Außerhalb des Webroots und zusätzlich außerhalb des Servers, nach der 3-2-1-Regel. Mindestens eine Kopie sollte so gespeichert sein, dass der Webserver selbst sie nicht löschen oder verändern kann.