SSL-Reverse-Proxy mit Nginx, Let's Encrypt und CrowdSec: Production Guide

Nginx Cheatsheet

Quick reference for Nginx web server, reverse proxy, and load balancer configuration

Warum ein dedizierter Reverse Proxy

Eine dedizierte Reverse-Proxy-Schicht ist die effektivste Sicherheitsinvestition, die Sie für eine Webanwendung tätigen können. Sie übernimmt die SSL-Terminierung, Rate Limiting, WAF-Inspektion und das Upstream-Routing – all dies sind Aufgaben, die einzelne Applikationsserver nicht selbst verwalten sollten.

Der hier vorgestellte Stack kombiniert drei praxiserprobte Tools: Nginx für das Request-Handling, Certbot für automatisches SSL und CrowdSec für eine verhaltensbasierte WAF/IPS.

Architektur

Nginx Konfigurationsentscheidungen

Worker Tuning

Die ereignisgesteuerte Architektur von Nginx bedeutet, dass die Worker-Konfiguration direkten Einfluss auf den Durchsatz hat:

worker_processes auto;
worker_connections 1024;
multi_accept on;
use epoll;

• auto Worker-Prozesse = Anzahl der CPU-Kerne
• 1024 Verbindungen pro Worker = 4096 gleichzeitige Verbindungen auf einer 4-Kern-VM
• epoll ist der Linux-native Event-Loop – signifikant effizienter als select oder poll

SSL Hardening

Die SSL-Konfiguration folgt dem „Modern“-Profil von Mozilla:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Wichtige Entscheidungen:

• Nur TLS 1.2 + 1.3: TLS 1.0/1.1 sind universell veraltet. Kein moderner Client verbindet sich ohne 1.2+.
• Prefer server ciphers off: Ermöglicht es Clients, ihre bevorzugte Verschlüsselung innerhalb des erlaubten Sets auszuhandeln. Moderne Clients wählen ChaCha20 oder AES-GCM, welche beide akzeptabel sind.
• Session Cache aktiviert: Ein 10MB-Cache speichert ca. 40.000 Sessions, was den Handshake-Overhead für zurückkehrende Clients reduziert.

Rate Limiting

Das Rate Limiting wird pro Zone und nicht pro Request konfiguriert:

limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_conn_zone $binary_remote_addr zone=addr:10m;

Der $binary_remote_addr Key verwendet die Client-IP im Binärformat (4 Bytes für IPv4, 16 für IPv6), um den Speicherverbrauch zu minimieren. Die 10MB-Zone speichert ca. 80.000 Einträge.

Certbot und Let's Encrypt

Zertifikats-Lebenszyklus

Der Certbot-Container verwaltet den vollständigen Lebenszyklus der Zertifikate:

1. Erstausstellung: Beim ersten Start führt Certbot eine HTTP-01 Challenge via Webroot unter /var/www/certbot durch.
2. Automatische Erneuerung: Ein Cronjob läuft alle 12 Stunden (0 */12 * * *), um Erneuerungen zu prüfen.
3. Grace Period: Let's Encrypt Zertifikate sind 90 Tage gültig. Certbot erneuert sie automatisch bei einer Restlaufzeit von 30 Tagen, was einen Puffer von 60 Tagen bietet.

Warum Webroot-Modus

Certbot unterstützt mehrere Challenge-Typen. Der Webroot-Modus (--webroot -w /var/www/certbot) ist die beste Wahl für diesen Stack:

• Keine Port-Konflikte: Im Gegensatz zum Standalone-Modus wird die ACME-Challenge über Nginx auf Port 80 bereitgestellt.
• Keine Downtime: Certbot muss Nginx nicht stoppen oder Ports belegen.
• Funktioniert innerhalb von Docker: Der Webroot ist ein Shared Volume zwischen den Nginx- und Certbot-Containern.

CrowdSec WAF/IPS

Wie CrowdSec funktioniert

CrowdSec ist eine verhaltensbasierte Security-Engine. Sie analysiert Logs, erkennt Angriffe mithilfe von Community-beigesteuerten Szenarien und blockiert bösartige IPs auf der Ebene des Reverse Proxys:

1. Log-Parsing: CrowdSec liest die Nginx-Access-Logs (gemountet als Volume).
2. Szenarien-Matching: Vordefinierte Szenarien erkennen SQL-Injection, XSS, Path Traversal, Brute-Force und Scanner-Aktivitäten.
3. Entscheidungs-Propagation: Wenn ein Szenario auslöst, erstellt CrowdSec eine Entscheidung (Ban, Captcha, Throttle), die vom Bouncer durchgesetzt wird.
4. Community-Blockliste: CrowdSec teilt anonymisierte Angriffsdaten und stellt so eine globale, in Echtzeit aktualisierte Blockliste bereit.

Konfiguration

Der CrowdSec-Container ist mit der Nginx-Collection konfiguriert, welche Folgendes enthält:

• crowdsecurity/nginx: Basis-Nginx-Parser
• crowdsecurity/http-cve: Erkennung von HTTP-Vulnerability-Scanning
• crowdsecurity/http-bf: Brute-Force-Erkennung an Login-Endpunkten
• crowdsecurity/http-path-traversal: Path-Traversal-Versuche

Der Bouncer läuft als separater Container (basiert auf nftables), der über eine API mit CrowdSec kommuniziert:

docker compose exec crowdsec cscli decisions list

# Manually ban an IP
docker compose exec crowdsec cscli decisions add --ip 1.2.3.4 --duration 24h

Production Hardening Checklist

• Server Tokens deaktivieren (server_tokens off) — verhindert die Offenlegung der Version
• client_max_body_size pro Anwendung setzen — Standard-1MB blockiert Datei-Uploads
• limit_req pro Upstream konfigurieren — verhindert, dass ein langsamer Dienst andere blockiert
• proxy_read_timeout angemessen setzen — Long-Polling-Endpunkte benötigen 300s+
• Real IP aus Docker-Netzwerken konfigurieren — bewahrt die ursprüngliche Client-IP hinter dem Docker-Networking
• Watchtower-Profil in der Produktion entfernen — niemals den Reverse Proxy automatisch aktualisieren
• /etc/letsencrypt sichern — der Verlust von SSL-Zertifikaten erfordert eine Neuausstellung und Neupropagierung
• CrowdSec-Metriken überwachen — cscli metrics zeigt das Erkennungsvolumen und blockierte IPs

Key Takeaways

• Ein Reverse Proxy ist Ihre erste Verteidigungslinie — TLS-Terminierung, Rate Limiting und WAF sollten niemals von Applikationsservern gehandhabt werden.
• Der Certbot Webroot-Modus ist Docker-freundlich — er funktioniert hinter Nginx ohne Port-Konflikte.
• CrowdSec erkennt Angriffe automatisch — es ist nicht notwendig, manuell WAF-Regeln für gängige Angriffe zu schreiben
• Der Stack ist service-agnostisch — fügen Sie einen beliebigen Upstream-Container hinzu und dieser ist geschützt