WAF-Schutz zu Apache hinzufügen

Dies ist der traditionelle Ansatz. ModSecurity wurde ursprünglich für Apache entwickelt und integriert sich als natives Modul (mod_security2). Es läuft innerhalb des Apache-Prozesses und inspiziert jede Anfrage.

Installation unter Ubuntu/Debian:

sudo apt update
sudo apt install -y libapache2-mod-security2
sudo a2enmod security2
sudo systemctl restart apache2

Die Basis-Konfiguration von ModSecurity aktivieren:

Das Paket liefert die Grundeinstellungen der Engine nur als Beispieldatei aus. Sie müssen diese erst an die richtige Stelle kopieren. Ohne diesen Schritt läuft die Zeile IncludeOptional /etc/modsecurity/modsecurity.conf in der Konfiguration weiter unten ins Leere (IncludeOptional ignoriert einen fehlenden Pfad stillschweigend), und die Grundeinstellungen für den Zugriff auf Request-/Response-Body, die PCRE-Limits und das Audit-Logging werden nie geladen, was dazu führt, dass CRS-Regeln, die davon abhängen, sich falsch verhalten:

sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Diese Datei wird mit SecRuleEngine DetectionOnly ausgeliefert (Treffer werden protokolliert, aber nicht blockiert). Das SecRuleEngine On in der Apache-Konfiguration weiter unten überschreibt dies und blockiert aktiv. Lassen Sie die Engine für eine anfängliche Beobachtungsphase auf DetectionOnly, wenn Sie False Positives im Audit-Log prüfen möchten, bevor Sie aktiv blockieren.

Das OWASP CRS installieren:

cd /etc/modsecurity
sudo git clone https://github.com/coreruleset/coreruleset.git /etc/modsecurity/crs
sudo cp /etc/modsecurity/crs/crs-setup.conf.example /etc/modsecurity/crs/crs-setup.conf

Apache für die Verwendung von CRS konfigurieren:

Bearbeiten Sie /etc/apache2/mods-enabled/security2.conf:

<IfModule security2_module>
    SecDataDir /var/cache/modsecurity
    SecRuleEngine On
    IncludeOptional /etc/modsecurity/modsecurity.conf
    IncludeOptional /etc/modsecurity/crs/crs-setup.conf
    IncludeOptional /etc/modsecurity/crs/rules/*.conf
</IfModule>

Starten Sie Apache neu: sudo systemctl restart apache2

Eine vollständige Anleitung finden Sie auf unserer ModSecurity-Anbieterseite.

Wenn Sie Ihren Stack vereinfachen möchten, kann Caddy+Coraza Apache vollständig ersetzen. Sie erhalten Webserver, WAF und automatisches HTTPS in einer einzigen Binärdatei. Die WAF verwendet Coraza (eine Go-Neuimplementierung von ModSecurity) mit denselben CRS-Regeln.

Der entscheidende Vorteil: keine C-Abhängigkeiten und keine komplexe Apache-Konfiguration. Sie erstellen zwar eine eigene Caddy-Binärdatei (die WAF wird als Go-Plugin ausgeliefert, das xcaddy einkompiliert, siehe einen späteren Schritt), aber das Ergebnis ist eine einzelne statische Binärdatei ohne C-Toolchain und ohne Dateisystemprüfungen pro Anfrage. Ein Caddyfile, das einen typischen Apache-VirtualHost ersetzt, umfasst 10 bis 15 Zeilen.

So werden gängige Apache-Direktiven in Caddy übertragen:

Grundlagen

# Apache                              -> Caddy
DocumentRoot /var/www/html             -> root * /srv
DirectoryIndex index.html              -> (automatic with file_server)
Options -Indexes                       -> file_server { browse }  (or omit for no listing)
ServerName example.com                 -> example.com { ... }

Reverse Proxy

# Apache                              -> Caddy
ProxyPass / http://app:3000/           -> reverse_proxy app:3000
ProxyPassReverse / http://app:3000/    -> (automatic in Caddy)
ProxyPreserveHost On                   -> (automatic in Caddy)
ProxyTimeout 60                        -> reverse_proxy app:3000 { transport http { read_timeout 60s } }

Header

# Apache                              -> Caddy
Header set X-Frame-Options DENY        -> header X-Frame-Options DENY
Header set X-Content-Type-Options ...  -> header X-Content-Type-Options nosniff
ServerTokens Prod                      -> (off by default in Caddy)

Redirects und Rewrites

# Apache                              -> Caddy
Redirect 301 /old /new                 -> redir /old /new permanent
RewriteRule ^/blog(.*)$ /news$1 [R=301]-> redir /blog* /news{path} permanent
RewriteCond %{HTTPS} off               -> (automatic with Caddy auto-HTTPS)
RewriteRule (.*) https://%{HTTP_HOST}   -> (automatic)

TLS

# Apache                              -> Caddy
SSLEngine on                           -> (automatic with domain name)
SSLCertificateFile /path/cert.pem      -> tls /path/cert.pem /path/key.pem
SSLCertificateKeyFile /path/key.pem    -> (or just use a domain name for auto-HTTPS)
SSLProtocol all -SSLv3 -TLSv1 ...      -> (TLS 1.2+ by default)

.htaccess

# Apache-.htaccess wird in Caddy nicht unterstützt.
# Verschieben Sie alle .htaccess-Regeln direkt in das Caddyfile.
# Das ist sogar ein Vorteil: keine Dateisystemprüfungen pro Anfrage.

Hier ist ein Caddyfile, das einen typischen Apache-VirtualHost mit WAF-Schutz ersetzt:

{
    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
    }
}

Vergleichen Sie dies mit dem Apache-Äquivalent:

<VirtualHost *:443>
    ServerName yourdomain.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

    <IfModule security2_module>
        SecRuleEngine On
        IncludeOptional /etc/modsecurity/modsecurity.conf
        IncludeOptional /etc/modsecurity/crs/crs-setup.conf
        IncludeOptional /etc/modsecurity/crs/rules/*.conf
    </IfModule>

    Header set X-Content-Type-Options nosniff
    Header set X-Frame-Options DENY

    <Directory /var/www/html>
        Options -Indexes
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

Das Caddyfile ist etwa ein Drittel so groß. TLS erfolgt automatisch, und die WAF-Konfiguration ist einfacher, weil Coraza das CRS direkt bündelt.

Caddy im Originalzustand kennt die Direktive coraza_waf oder order coraza_waf first nicht. Diese stammen aus dem coraza-caddy-Plugin, das Sie mit xcaddy in eine eigene Caddy-Binärdatei einkompilieren. Das offizielle caddy:builder-Image bringt xcaddy bereits mit, sodass ein mehrstufiges Dockerfile den kompletten Build übernimmt und die neue Binärdatei auf das Standard-caddy-Image legt:

# Dockerfile
FROM caddy:builder AS builder
RUN xcaddy build --with github.com/corazawaf/coraza-caddy/v2

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

Der Modulpfad muss das Suffix /v2 enthalten; das ist die aktuelle Hauptversion von coraza-caddy. Wenn Sie Go und xcaddy bereits auf dem Host installiert haben, können Sie die Binärdatei auch direkt bauen, statt Docker zu verwenden:

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

Das OWASP CRS ist im Plugin eingebettet, weshalb die Subdirektive load_owasp_crs im Caddyfile dafür sorgt, dass sich die Includes @crs-setup.conf.example und @owasp_crs/*.conf auflösen lassen. Für diese Option ist kein separater CRS-Download nötig.

Bauen Sie das Caddy+Coraza-Image aus dem oben stehenden Dockerfile und führen Sie es aus:

# Bauen
docker build -t caddy-coraza -f Dockerfile .

# Ausführen (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 den normalen Zugriff und die WAF-Blockierung:

# Normale Anfrage - sollte 200 zurückgeben
curl -o /dev/null -w "%{http_code}\n" http://localhost/

# 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"

Einige Apache-Funktionen arbeiten anders oder sind in Caddy nicht verfügbar:

Funktioniert anders

• .htaccess: nicht unterstützt. Verschieben Sie alle Regeln in das Caddyfile. Das ist sogar schneller, weil Caddy das Dateisystem nicht bei jeder Anfrage nach .htaccess-Dateien durchsucht.
• mod_rewrite mit komplexen Bedingungen: Caddy verwendet Matcher anstelle von RewriteCond/RewriteRule. Die meisten Muster lassen sich übertragen, komplexe Ketten müssen jedoch überdacht werden.
• <Directory>-/<Location>-Blöcke: Verwenden Sie stattdessen die handle- und Matcher-Direktiven von Caddy.
• Authentifizierung (mod_auth_basic): Verwenden Sie die basic_auth-Direktive von Caddy.

In Caddy nicht verfügbar

• mod_php: Caddy bettet PHP nicht ein. Verwenden Sie PHP-FPM als Backend mit php_fastcgi.
• mod_perl / mod_python: kein Äquivalent. Führen Sie Ihre Anwendung als separaten Prozess aus und leiten Sie den Datenverkehr per Reverse Proxy dorthin.
• mod_cache: Caddy hat ein cache-handler-Plugin, es ist jedoch weniger ausgereift als die Caching-Module von Apache.

Für komplexe Apache-Konfigurationen mit vielen VirtualHosts verwenden Sie diesen Prompt mit einem beliebigen KI-Assistenten:

Konvertiere die folgende Apache-VirtualHost-Konfiguration in eine Caddy-Konfiguration (Caddyfile). Füge außerdem Coraza-WAF-Schutz über das coraza-caddy-Plugin mit OWASP CRS hinzu.

Anforderungen: - Verwende die Direktive coraza_waf 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 - Konvertiere alle .htaccess-Regeln direkt in das Caddyfile - Erhalte alle Redirects, Header und Proxy-Ziele - Ersetze mod_rewrite-Regeln durch Caddy-Matcher - Füge Kommentare hinzu, die jeden Abschnitt erklären - Kennzeichne alles, was kein direktes Caddy-Äquivalent hat

Hier ist meine Apache-Konfiguration:

[Apache-VirtualHost-Konfiguration hier einfügen]

Überprüfen Sie die Ausgabe sorgfältig, insbesondere die mod_rewrite-Konvertierungen und alle .htaccess-Regeln, die eingebettet wurden.