Nginx Absichern und Betreiben

Betrieb absichern: Security Hardening, Authentifizierung, Logging, Performance und Hochverfügbarkeit. Baut auf Nginx Grundkonfiguration und Nginx Reverse Proxy und Load Balancing auf.

Security Hardening

server_tokens off;

Verbirgt die Nginx-Version in Fehlerseiten und im Server-Header – erschwert gezieltes Suchen nach bekannten Schwachstellen einer bestimmten Version. Ersetzt kein Patchen: Nginx und Betriebssystem trotzdem aktuell halten.

location /internal/ {
    deny all;
}

Sperrt einen Pfad komplett, unabhängig von jeder Authentifizierung.

Security-Header

add_header X-Content-Type-Options nosniff always;
add_header Referrer-Policy strict-origin-when-cross-origin always;

Strict-Transport-Security (HSTS) erst setzen, wenn wirklich alle betroffenen Hosts dauerhaft über HTTPS erreichbar sind – sonst sperrt sich der Browser selbst von einem eventuell nötigen HTTP-Fallback aus, und das lässt sich nicht kurzfristig zurücknehmen.

Authentifizierung und Zugriffsschutz

Basic Auth

htpasswd -c /etc/nginx/.htpasswd admin

(Paket apache2-utils bzw. httpd-tools, je nach Distribution)

location /admin/ {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:3000;
}

Passwort-Datei außerhalb des Webroots halten, Basic Auth nur über HTTPS einsetzen – sonst gehen die Zugangsdaten im Klartext über die Leitung.

IP-Beschränkung

location / {
    allow 192.0.2.0/24;
    deny all;
}

Hinter einem vorgeschalteten Proxy vorher sicherstellen, dass die echte Client-IP überhaupt ankommt (siehe Nginx Reverse Proxy und Load Balancing) – sonst greift die Beschränkung auf die falsche, immer gleiche Proxy-Adresse.

Logging und Monitoring

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;

sudo tail -f /var/log/nginx/error.log
sudo journalctl -u nginx -n 50

Nützliche Variablen in Log-Formaten

Variable	Bedeutung
`$remote_addr`	Client-IP
`$request`	komplette HTTP-Anfragezeile
`$status`	HTTP-Statuscode der Antwort
`$request_time`	Verarbeitungszeit insgesamt
`$upstream_response_time`	Zeit, die allein das Backend gebraucht hat

stub_status

location = /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}

Braucht das Modul ngx_http_stub_status_module (in den meisten Distributionspaketen bereits enthalten) und sollte – wie hier gezeigt – nicht öffentlich erreichbar sein.

Performance

worker_processes auto;
events {
    worker_connections 1024;
}
sendfile on;
keepalive_timeout 65s;
gzip on;

worker_connections zählt auch Verbindungen zum Backend mit, nicht nur zum Client – das tatsächliche Limit hängt zusätzlich vom Betriebssystem und offenen Dateideskriptoren (ulimit) ab. Beim Tunen immer eine Einstellung nach der anderen ändern und mit realistischer Last messen (zuerst eine Baseline, dann vergleichen), nicht mehrere Werte gleichzeitig.

Hochverfügbarkeit

Mehrere Backends hinter einer Nginx (siehe Nginx Reverse Proxy und Load Balancing) beseitigen nicht den einzelnen Nginx-Proxy selbst als Ausfallpunkt. Für echte Redundanz: zwei Nginx-Instanzen plus ein externer Mechanismus davor (DNS-Round-Robin oder eine virtuelle IP), und bei zustandsbehafteten Anwendungen ein gemeinsamer Session-Speicher (z. B. Redis) statt lokaler Sitzungen.

Vor dem Produktiveinsatz

DNS, Backend-Erreichbarkeit, Firewall-Regeln und Zertifikat vorher geprüft
Konfiguration vor jeder Änderung gesichert, nginx -t vor jedem reload
Admin-Zugriff eingeschränkt, Rate Limits gesetzt
Monitoring für Latenz, 4xx/5xx-Quote und Zertifikatsablauf eingerichtet
Rollback getestet, bevor er wirklich gebraucht wird