WAF-Schutz zu Nginx hinzufügen

Bei diesem Ansatz wird Caddy+Coraza vor Ihr bestehendes Nginx geschaltet. Die Architektur sieht so aus:

Client -> Caddy + Coraza WAF (:443) -> Nginx (:80) -> Your App

Ihre Nginx-Konfiguration bleibt genau so, wie sie ist. Sie fügen einen Caddy-Container hinzu, der den gesamten Datenverkehr prüft, bevor er saubere Anfragen an Nginx weiterleitet. Bösartige Anfragen werden blockiert, bevor sie Ihren Server erreichen.

Sehen Sie sich unsere eigene Schritt-für-Schritt-Anleitung an: Nginx mit Coraza WAF per Docker schützen. Diese Anleitung führt jede Datei, jeden Build-Schritt und jeden Test im Detail durch.

Wann Sie dies wählen sollten: Sie haben ein funktionierendes Nginx-Setup, möchten es nicht ändern und wollen einfach WAF-Schutz obendrauf hinzufügen.

Anstatt zwei Container zu betreiben, können Sie Nginx vollständig ersetzen. Caddy übernimmt statische Dateien, Reverse Proxying, TLS, Header und Komprimierung, genau wie Nginx. Mit dem Coraza-Plugin bietet es zusätzlich WAF-Schutz.

Das Ergebnis: ein Container, eine Konfigurationsdatei, Webserver + WAF + automatisches HTTPS.

Wann Sie dies wählen sollten: Sie fangen neu an, möchten einen einfacheren Stack oder Ihre Nginx-Konfiguration ist unkompliziert genug, um sie nach Caddy zu übertragen.

Beide Optionen verwenden dasselbe Docker-Image. Erstellen Sie ein Dockerfile:

FROM caddy:2-builder AS builder

RUN xcaddy build \
    --with github.com/corazawaf/coraza-caddy/v2

FROM caddy:2

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Bauen Sie es:

docker build -t caddy-coraza .

So lassen sich gängige Nginx-Direktiven auf Caddy abbilden. Verwenden Sie diese Tabelle, um Ihre Konfiguration umzuwandeln:

Statische Dateien und Grundlagen

# Nginx                          -> Caddy
root /var/www/html;              -> root * /srv
index index.html;                -> (automatic with file_server)
try_files $uri $uri/ =404;       -> file_server
try_files $uri /index.html;      -> try_files {path} /index.html
gzip on;                         -> encode gzip
listen 443 ssl;                  -> (automatic with domain name)

Reverse Proxy

# Nginx                          -> Caddy
proxy_pass http://app:3000;      -> reverse_proxy app:3000
proxy_set_header Host $host;     -> (automatic)
proxy_set_header X-Real-IP ...;  -> (automatic)
proxy_read_timeout 60s;          -> reverse_proxy app:3000 { read_timeout 60s }
proxy_buffering off;             -> reverse_proxy app:3000 { flush_interval -1 }

Header und Sicherheit

# Nginx                          -> Caddy
add_header X-Frame-Options ...;  -> header X-Frame-Options DENY
add_header X-Content-Type ...;   -> header X-Content-Type-Options nosniff
server_tokens off;               -> (off by default in Caddy)

Weiterleitungen und Rewrites

# Nginx                          -> Caddy
return 301 https://$host$uri;    -> redir https://{host}{uri} permanent
rewrite ^/old(.*)$ /new$1;       -> rewrite /old* /new{path.1}
location /blog { ... }           -> handle /blog/* { ... }
location = /health { ... }       -> handle /health { ... }

TLS / HTTPS

# Nginx                          -> Caddy
ssl_certificate /path/cert.pem;  -> tls /path/cert.pem /path/key.pem
ssl_certificate_key /path/...;   -> (or just use a domain name for auto-HTTPS)
ssl_protocols TLSv1.2 TLSv1.3;  -> (TLS 1.2+ by default)

Hier ist ein vollständiges Caddyfile, das eine typische Nginx-Konfiguration für eine statische Website ersetzt, mit WAF-Schutz:

{
    order coraza_waf first
}

yourdomain.com {
    coraza_waf {
        load_owasp_crs
        directives `
        Include @coraza.conf-recommended
        Include @crs-setup.conf.example
        Include @owasp_crs/*.conf
        SecRuleEngine On
        `
    }

    root * /srv
    file_server
    encode gzip

    header {
        X-Content-Type-Options nosniff
        X-Frame-Options DENY
        Referrer-Policy strict-origin-when-cross-origin
    }
}

Für ein Reverse-Proxy-Setup (z. B. Proxy zu einer Node.js- oder Python-Anwendung):

{
    order coraza_waf first
}

yourdomain.com {
    coraza_waf {
        load_owasp_crs
        directives `
        Include @coraza.conf-recommended
        Include @crs-setup.conf.example
        Include @owasp_crs/*.conf
        SecRuleEngine On
        `
    }

    reverse_proxy app:3000
}

Starten Sie den Container (Beispiel für statische Dateien):

docker run -d -p 80:80 -p 443:443 \
  -v ./Caddyfile:/etc/caddy/Caddyfile:ro \
  -v ./site:/srv:ro \
  -v caddy_data:/data \
  caddy-coraza

Testen Sie, dass normaler Datenverkehr funktioniert:

curl http://localhost/

Testen Sie, dass Angriffe blockiert werden:

# SQL-Injection - sollte 403 zurückgeben
curl -o /dev/null -w "%{http_code}\n" "http://localhost/?id=1%20OR%201=1"

# XSS - sollte 403 zurückgeben
curl -o /dev/null -w "%{http_code}\n" "http://localhost/?q=%3Cscript%3Ealert(1)%3C/script%3E"

# Scanner - sollte 403 zurückgeben
curl -o /dev/null -w "%{http_code}\n" -H "User-Agent: nikto" http://localhost/

Einige Nginx-Funktionen haben keine direkten Caddy-Entsprechungen. Darauf sollten Sie achten:

Funktioniert anders

• upstream-Blöcke mit Gewichtungen/Health-Checks: Caddy erledigt dies inline in reverse_proxy mit anderer Syntax. Load-Balancing-Richtlinien (round_robin, least_conn, ip_hash) werden unterstützt, sind aber anders benannt.
• map-Direktive: keine direkte Entsprechung. Verwenden Sie für einfache Fälle vars oder Caddys expression-Matcher.
• limit_req_zone / Rate Limiting: verwenden Sie Caddys rate_limit-Direktive (als Plugin verfügbar).
• Komplexe location-Regex: Caddy verwendet Path-Matcher und benannte Matcher anstelle von Regex-Locations. Die meisten Muster lassen sich sauber übertragen, aber tief verschachtelte Regex-Locations müssen überdacht werden.

In Caddy nicht verfügbar

• proxy_cache: Caddy verfügt über kein eingebautes Antwort-Caching (es gibt ein cache-handler-Plugin, das aber weniger ausgereift ist als das von Nginx). Wenn Sie stark auf Nginx' Proxy-Cache angewiesen sind, behalten Sie Nginx als Backend.
• Lua/njs-Scripting: keine Entsprechung. Wenn Sie Nginx-Lua-Skripte haben, müssen diese als Caddy-Plugins (Go) neu geschrieben oder in Ihre Anwendung verlagert werden.
• HTTP/2 Push: in Browsern veraltet und in Caddy nicht unterstützt.

Wenn Ihre Nginx-Konfiguration lang oder komplex ist, können Sie einen KI-Assistenten bei der Umwandlung nutzen. Hier ist ein Prompt, den Sie in ChatGPT, Claude oder ein beliebiges LLM einfügen können:

Wandle die folgende Nginx-Konfiguration in eine Caddy-Konfiguration (Caddyfile) um.
Füge außerdem Coraza-WAF-Schutz mit dem coraza-caddy-Plugin und OWASP CRS hinzu.

Anforderungen:
- Verwende die coraza_waf-Direktive mit load_owasp_crs
- Binde @coraza.conf-recommended, @crs-setup.conf.example und @owasp_crs/*.conf ein
- Setze SecRuleEngine On
- Verwende "order coraza_waf first" im globalen Optionsblock
- Erhalte die gesamte bestehende Funktionalität (Weiterleitungen, Header, Proxy-Ziele)
- Füge Kommentare hinzu, die jeden Abschnitt erklären
- Kennzeichne alles, was keine direkte Caddy-Entsprechung hat

Hier ist meine Nginx-Konfiguration:

[Füge hier deine nginx.conf oder Site-Konfiguration ein]

Überprüfen Sie die Ausgabe sorgfältig. Prüfen Sie, ob alle Ihre Locations, Weiterleitungen und Proxy-Ziele erhalten bleiben. Testen Sie die umgewandelte Konfiguration in einer Staging-Umgebung, bevor Sie den Produktivverkehr umstellen.