Ein Webserver ist nur so sicher wie seine schwächste Konfiguration. Eine der häufigsten Ursachen für kompromittierte Systeme: versehentlich öffentlich zugängliche Dateien wie .env, .git-Verzeichnisse oder Backup-Dateien. Dieser Beitrag zeigt praktische Maßnahmen für Nginx und Apache, um genau das zu verhindern.

Warum sensible Dateien ein Risiko sind

Jede Datei, die nicht explizit öffentlich sein soll, kann im Fehlerfall zum Einfallstor werden. Typische Beispiele:

• .env – Datenbankzugänge, API-Keys, JWT-Secrets
• .git/ – gesamter Commit-Verlauf, inklusive gelöschter Secrets
• Backup-Dateien – *.bak, *.old, *.sql, *.zip
• Entwickler-Dateien – composer.json, package.json mit Abhängigkeiten und Scripts

Ein einzelner Zugriff auf .env reicht, um alle Secrets eines Projekts offenzulegen. Das ist kein theoretisches Risiko – automatisierte Scanner prüfen täglich Millionen von Servern genau nach solchen Dateien.

Nginx: Blockregeln für sensible Pfade

Die zuverlässigste Methode, um Zugriffe auf sensible Dateien zu verhindern, ist eine Kombination aus location-Blöcken und location ~-Regex-Matches. Folgende Regeln gehören in den server-Block Ihrer Nginx-Konfiguration:

# Sensitive files blocken
location ~ /\.(env|git|htaccess|htpasswd|ini|log|conf|config)$ {
    deny all;
    access_log off;
    log_not_found off;
}

# Verzeichnisse komplett sperren
location ~ /\.(git|svn|hg)/ {
    deny all;
    access_log off;
    log_not_found off;
}

# Backup- und temporäre Dateien
location ~* \.(bak|old|sql|zip|tar|gz|swp|swp|tmp|temp)$ {
    deny all;
    access_log off;
    log_not_found off;
}

# Verhindere Directory Listing
autoindex off;

Erklärung: Die erste Regel blockt alle versteckten Dateien mit typischen sensiblen Endungen. Die zweite Regel sperrt komplette Versionskontroll-Verzeichnisse. Die dritte Regel fängt Backup- und temporäre Dateien ab. autoindex off verhindert, dass Nginx bei fehlender index.html ein Dateiverzeichnis anzeigt.

Apache: .htaccess-Schutz

Bei Apache funktioniert der Schutz über .htaccess-Dateien oder die Server-Konfiguration. Für ein dokument Root-Verzeichnis reicht eine .htaccess mit folgenden Regeln:

<FilesMatch "^\\.(env|git|htaccess|htpasswd|ini|log|conf|config)$">
    Require all denied
</FilesMatch>

<DirectoryMatch "\\.(git|svn|hg)/">
    Require all denied
</DirectoryMatch>

# Backup-Dateien blockieren
<FilesMatch "\\.(bak|old|sql|zip|tar|gz|swp|tmp|temp)$">
    Require all denied
</FilesMatch>

# Directory Listing deaktivieren
Options -Indexes

Hinweis: Für die .htaccess-Lösung muss AllowOverride All oder zumindest AllowOverride Limit FileInfo im passenden <Directory>-Block der Hauptkonfiguration aktiviert sein. Die sauberere Lösung ist immer die zentrale Konfiguration in sites-available.

Zusätzliche Maßnahmen

Umgebungsvariablen außerhalb des Document Root

Die sicherste Methode ist, sensible Dateien gar nicht erst im Webroot abzulegen. Bei PHP-Anwendungen kann man die .env beispielsweise ein Verzeichnis über dem Document Root speichern:

/var/www/example.com/
├── .env              <-- Außerhalb des Document Root
├── public/           <-- Document Root
│   ├── index.php
│   └── ...
└── vendor/

In der PHP-Anwendung muss dann der Pfad entsprechend gesetzt werden:

$dotenv = Dotenv\Dotenv::createImmutable(__DIR__ . '/../');
$dotenv->load();

Serverweiteres

• HTTP-Header setzen: X-Content-Type-Options: nosniff und X-Frame-Options: DENY verhindern MIME-Type-Sniffing und Clickjacking.
• HTTPS erzwingen: Ein Redirect von HTTP auf HTTPS schützt vor Mitlesen – besonders bei Login-Formularen.
• Fehlerseiten konfigurieren: Benutzerdefinierte 403/404-Seiten verhindern, dass der Server seine Standard-Antworten sendet (die oft Hinweise auf die verwendete Software geben).
• Regelmäßige Updates: Nginx/Apache, PHP, Datenbank und Betriebssystem aktuell halten – viele Angriffsszenarien nutzen bekannte Schwachstellen in alter Software.

Praxisprüfung: Funktioniert es?

Nach der Konfiguration sollte man die Zugriffe testen:

# Prüfen, ob .env blockiert wird
curl -I https://example.com/.env

# Erwartete Antwort:
# HTTP/1.1 403 Forbidden

# Prüfen, ob .git blockiert wird
curl -I https://example.com/.git/config

# Prüfen, ob Backups blockiert werden
curl -I https://example.com/backup.sql

# Prüfen, ob Directory Listing deaktiviert ist
curl https://example.com/uploads/

# Erwartete Antwort: 403 Forbidden oder leer (keine Dateiliste)

Fazit

Webserver-Sicherheit beginnt mit den Grundlagen: sensible Dateien blockieren, Directory Listing deaktivieren und Server-Header setzen. Die hier gezeigten Regeln für Nginx und Apache decken 90 % der häufigen Angriffsszenarien ab. Der Rest ist eine Frage von regelmäßigen Updates, Monitoring und dem Bewusstsein, welche Dateien man überhaupt im Webroot ablegt.

---

Hinweis: Dieser Beitrag entstand aus der Praxis – beim Aufbau mehrerer Projekte auf redpandamonium.de und der damit verbundenen Auseinandersetzung mit Websicherheit.