.env- und .git-Dateien auf dem Server: Wonach Scanner suchen

In den Logs meines Servers sehe ich regelmäßig Anfragen nach Adressen, die es auf der Website nicht gibt: /.env, /.git/config, /backup.zip, /phpinfo.php. Das sind weder Kunden noch Suchmaschinen, sondern automatische Scanner. Sie fragen nacheinander Tausende Firmenwebsites ab und prüfen, ob jemand auf dem Server eine Datei mit Passwörtern oder eine Kopie der gesamten Website liegen gelassen hat.

Ist eine solche Datei erreichbar, genügt ein einziger Download: Das Datenbankpasswort, der Schlüssel zum E-Mail-Konto oder eine Kopie der Kundendaten gelangt an eine fremde Person. In diesem Ratgeber zeige ich, wonach Scanner suchen, wie Sie Ihre eigene Website in 10 Minuten prüfen und wie Sie diese Dateien sperren.

Wonach Scanner suchen

Dieselben Adressen tauchen in den Logs vieler Server immer wieder auf. Hinter jeder steht eine Datei, die nach einem Deployment oder einem Update manchmal im Verzeichnis der Website zurückbleibt.

Ein wichtiger Unterschied: Die Datei wp-config.php führt der Server als Programm aus, daher ist ihr Inhalt von außen nicht sichtbar. Eine Kopie davon mit einer anderen Endung (.bak, .old, .txt) ist dagegen eine gewöhnliche Textdatei, die der Browser einfach anzeigt oder herunterlädt.

Wie diese Dateien auf den Server gelangen

Niemand lässt sie absichtlich liegen. Am häufigsten sehe ich fünf Szenarien:

1. Deployment durch Kopieren des ganzen Projektordners. Zusammen mit den Dateien der Website landen das versteckte Verzeichnis .git und die Datei .env auf dem Server.
2. Eine Kopie „nur für den Moment“ vor einem Update. Jemand packt die Website in eine backup.zip im Verzeichnis der Website und vergisst, sie zu löschen.
3. Kopien aus dem Editor. Der Editor hinterlässt neben der bearbeiteten Datei Dateien mit der Endung ~, .bak oder .swp.
4. Eine alte Version der Website in einem Unterverzeichnis. Nach dem Wechsel der Website landet die vorherige in /old/ oder /test/ und läuft weiter, oft ohne Updates.
5. Backups im öffentlichen Verzeichnis. Manche Backup-Tools speichern Archive an einem Ort, der über den Browser erreichbar ist.

So prüfen Sie Ihre Website in 10 Minuten

Prüfen Sie ausschließlich Ihre eigene Website oder eine Website, die Sie im Auftrag des Inhabers betreuen.

Schritt 1: Geben Sie die Adressen im Browser ein. Ersetzen Sie ihredomain.pl durch Ihre Adresse und öffnen Sie nacheinander:

https://ihredomain.pl/.env
https://ihredomain.pl/.git/config
https://ihredomain.pl/.git/HEAD
https://ihredomain.pl/backup.zip
https://ihredomain.pl/phpinfo.php

Ein gutes Ergebnis ist der Fehler 403 oder 404. Ein schlechtes Ergebnis ist der angezeigte Inhalt der Datei oder ein gestarteter Download.

Schritt 2: Sehen Sie das Verzeichnis der Website durch. Melden Sie sich im Dateimanager des Hosting-Panels an (oder per FTP) und öffnen Sie das Verzeichnis der Website, meist public_html oder www. Suchen Sie nach Dateien mit den Endungen .zip, .sql, .tar.gz, .bak, .old und nach den Verzeichnissen old, test, kopia.

Schritt 3: Prüfen Sie die Dateilisten in Verzeichnissen. Öffnen Sie die Adresse eines Verzeichnisses mit Bildern, z. B. https://ihredomain.pl/wp-content/uploads/ bei WordPress. Sehen Sie eine Liste von Dateien statt einer leeren Seite oder eines Fehlers, zeigt der Server den Inhalt von Verzeichnissen jedem Besucher.

Eine umfassendere Prüfung der Website, nicht nur auf diese Dateien, finden Sie im Ratgeber Firmenwebsite kostenlos prüfen.

Was tun, wenn eine Datei erreichbar ist

Wenn eine der Adressen Inhalt angezeigt hat, gehen Sie in dieser Reihenfolge vor:

1. Löschen Sie die Datei oder verschieben Sie sie aus dem Verzeichnis der Website. Backups sollten nicht an einem Ort liegen, der aus dem Internet erreichbar ist.
2. Betrachten Sie die Passwörter aus dieser Datei als offengelegt. Ändern Sie das Datenbankpasswort, erzeugen Sie neue API-Schlüssel und widerrufen Sie die alten, ändern Sie das Passwort des Postfachs, das die Website nutzt. Erzeugen Sie bei WordPress auch neue Authentifizierungsschlüssel und Salts, wodurch alle angemeldeten Personen abgemeldet werden.
3. Bitten Sie das Hosting um die Logs. Fragen Sie, ob jemand diese Adresse abgerufen hat (Serverantwort 200). Das zeigt, ob die Datei abgeflossen ist oder nur dalag.
4. Prüfen Sie, ob personenbezogene Daten abgeflossen sind. Enthielt die Kopie eine Datenbank mit Kundendaten, kann das eine Verletzung des Schutzes personenbezogener Daten sein. Art. 33 DSGVO verlangt eine Meldung an den Präsidenten der UODO (Urząd Ochrony Danych Osobowych, die polnische Datenschutzbehörde) unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Informationen und das Formular finden Sie auf uodo.gov.pl.

Den vollständigen Plan für den ersten Tag nach Entdeckung eines Problems beschreibe ich im Ratgeber Lücke in der Firmenwebsite: Was in den ersten 24 Stunden zu tun ist.

Sperre in der Serverkonfiguration

Das Löschen der Dateien ist die Grundlage, es lohnt sich aber, solche Adressen auch dauerhaft zu sperren. Dann ist eine versehentlich hochgeladene Datei nicht erreichbar.

Apache (viele Shared-Hosting-Angebote), Datei .htaccess im Verzeichnis der Website:

# Keine Dateilisten in Verzeichnissen
Options -Indexes

# Dateien und Verzeichnisse, die mit einem Punkt beginnen (.env, .git), außer .well-known
RedirectMatch 404 /\.(?!well-known)

# Kopien und Dumps, die nicht im Verzeichnis der Website liegen sollten
<FilesMatch "(\.(sql|bak|old|swp)|~)$">
  Require all denied
</FilesMatch>

Drei Hinweise vor dem Einfügen:

• Erstellen Sie eine Kopie der aktuellen .htaccess und öffnen Sie die Website direkt nach der Änderung. Manche Hostings erlauben die Zeile Options nicht, dann zeigt die Website den Fehler 500. Entfernen Sie in diesem Fall die Zeile und fragen Sie das Hosting, wie sich die Dateiliste abschalten lässt.
• Require all denied funktioniert in Apache 2.4, also auf der überwiegenden Mehrheit der heutigen Server.
• Die Ausnahme für .well-known ist nötig, weil darüber unter anderem die Erneuerung des SSL-Zertifikats läuft.

Nginx (VPS-Server, die Änderung nimmt der Administrator vor):

location ~ /\.(?!well-known) {
    deny all;
}

location ~* \.(sql|bak|old|swp)$ {
    deny all;
}

Wiederholen Sie nach der Änderung und dem Löschen überflüssiger Dateien Schritt 1 der Prüfung: Alle Adressen sollten 403 oder 404 zurückgeben.

Wie Sie das künftig verhindern

• Laden Sie nur die Dateien der Website auf den Server, ohne das Verzeichnis .git, Projektdateien und Notizen. Deployment-Tools haben dafür eine Ausschlussliste.
• Halten Sie .env außerhalb des öffentlichen Verzeichnisses. Frameworks wie Laravel haben ein eigenes Verzeichnis public, und nur dieses sollte aus dem Internet sichtbar sein, während die Datei .env eine Ebene höher liegt.
• Bewahren Sie Backups außerhalb des Website-Verzeichnisses und außerhalb des Servers auf. Wie Sie das organisieren, beschreibe ich im Ratgeber zum Website-Backup und zur 3-2-1-Regel.
• Räumen Sie nach jedem Update auf: Löschen Sie Testdateien, Archive und alte Versionen der Website.
• Wiederholen Sie die Prüfung aus diesem Ratgeber einmal im Quartal. Das dauert 10 Minuten, und Scanner machen keine Pause.

Zusammenfassung

Scanner suchen nach Dateien, die versehentlich auf dem Server geblieben sind, und tun das automatisch, unabhängig von der Größe der Firma. Prüfen Sie die fünf Adressen aus diesem Ratgeber, löschen Sie überflüssige Kopien und richten Sie eine Sperre in der Serverkonfiguration ein. Wenn Sie das lieber jemand anderem überlassen, prüfe ich im Rahmen eines Sicherheitsaudits Website und Server, und dauerhaften Schutz bietet die technische Betreuung. Sie können mir auch einfach schreiben.