Von Apache zu Caddy + Coraza WAF migrieren

Triftige Gründe für eine Migration:

• Einfachere Konfiguration: Der VirtualHost- + .htaccess- + mod_rewrite-Stack von Apache ist leistungsfähig, aber komplex. Ein Caddyfile für dasselbe Setup ist typischerweise ein Drittel so groß.
• Automatisches HTTPS: kein certbot mehr, keine Cron-Jobs mehr, keine Notfälle mehr wegen abgelaufener Zertifikate. Caddy verwaltet TLS-Zertifikate automatisch.
• Moderne WAF-Engine: Während die ModSecurity-Integration von Apache die ausgereifteste ist, ist Coraza eine moderne Go-Neuimplementierung, die dieselben CRS-Regeln ohne C-Abhängigkeiten ausführt.
• Docker-nativ: Caddy + Coraza läuft als einzelner Container. Keine Modul-Kompilierung, keine apt-Pakete, keine Bibliothekskonflikte.
• Leistung: Das prefork/worker-Modell von Apache ist bewährt, aber die ereignisgesteuerte Architektur von Caddy verarbeitet gleichzeitige Verbindungen mit weniger Speicheraufwand.

Migrieren Sie nicht, wenn:

• Sie stark auf mod_php angewiesen sind (obwohl php_fastcgi eine saubere Alternative ist)
• Sie Hunderte von .htaccess-Dateien über viele Verzeichnisse verteilt haben
• Ihr Team über tiefes Apache-Know-how verfügt und das aktuelle Setup gut funktioniert
• Sie Apache-spezifische Module (mod_perl, mod_python, mod_jk) ohne Alternativen nutzen

Dokumentieren Sie alles, bevor Sie beginnen:

1. Alle Sites und VirtualHosts auflisten

# Aktivierte Sites auflisten
ls /etc/apache2/sites-enabled/
# oder unter CentOS/RHEL:
ls /etc/httpd/conf.d/

# Alle ServerName-Einträge finden
grep -rh "ServerName\|ServerAlias" /etc/apache2/sites-enabled/ | sort -u

2. Alle .htaccess-Dateien finden

# Dies ist entscheidend - Caddy unterstützt .htaccess nicht
find /var/www -name ".htaccess" -exec echo "=== {} ===" \; -exec cat {} \;

Speichern Sie diese Ausgabe. Jede .htaccess-Regel muss in das Caddyfile überführt werden.

3. Proxy-Ziele und Backend-Dienste dokumentieren

grep -rh "ProxyPass\|ProxyPassReverse" /etc/apache2/sites-enabled/ | sort -u

4. Auf spezielle Module prüfen

# Geladene Apache-Module auflisten
apache2ctl -M 2>/dev/null || httpd -M 2>/dev/null

# Auf Module prüfen, die eine besondere Behandlung erfordern
# mod_php, mod_rewrite, mod_security2, mod_ssl, mod_proxy, mod_headers

5. PHP-Setup notieren

# Prüfen, ob mod_php oder PHP-FPM verwendet wird
apache2ctl -M 2>/dev/null | grep php
# Wird php aufgelistet, verwenden Sie mod_php
# Caddy verwendet stattdessen PHP-FPM - dies müssen Sie einrichten

Dies ist der größte Unterschied zwischen Apache- und Caddy-Migrationen (Nginx verwendet kein .htaccess, daher gilt dieser Schritt nicht für Nginx-Migrationen).

Gängige .htaccess-Muster und ihre Caddyfile-Entsprechungen:

# .htaccess: HTTPS erzwingen
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# Caddy: automatisch (verwenden Sie einfach einen Domainnamen)

# .htaccess: Verzeichnisauflistung verweigern
Options -Indexes
# Caddy: file_server (ohne browse-Flag)

# .htaccess: Bestimmte Dateien blockieren
<FilesMatch "\.(env|git|sql)$">
    Require all denied
</FilesMatch>
# Caddy:
@blocked path *.env *.git *.sql
respond @blocked 403

# .htaccess: Eigene Fehlerseiten
ErrorDocument 404 /404.html
# Caddy:
handle_errors {
    rewrite * /{err.status_code}.html
    file_server
}

# .htaccess: Passwortschutz
AuthType Basic
AuthName "Restricted"
AuthUserFile /path/.htpasswd
Require valid-user
# Caddy:
basicauth {
    user $2a$14$... (bcrypt-Hash)
}

# .htaccess: WordPress-Pretty-Permalinks
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# Caddy:
php_fastcgi unix//run/php/php-fpm.sock {
    try_files {path} /index.php
}

Wenn Ihr Apache-Setup mod_php verwendet, müssen Sie auf PHP-FPM umsteigen. Dies ist tatsächlich auch in Apache der empfohlene Ansatz für bessere Leistung.

PHP-FPM installieren:

sudo apt install php-fpm
# oder für eine bestimmte Version:
sudo apt install php8.3-fpm

Caddy für PHP konfigurieren:

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

    root * /var/www/html
    php_fastcgi unix//run/php/php-fpm.sock
    file_server
}

Die php_fastcgi-Direktive übernimmt das index.php-Routing, PATH_INFO und alle PHP-spezifischen Header automatisch. Für WordPress ersetzt diese eine Direktive den gesamten .htaccess-mod_rewrite-Block.

Verwenden Sie die Direktivenzuordnungstabelle aus unserer Anleitung zum Apache-WAF-Schutz, um jeden VirtualHost zu konvertieren. Fügen Sie alle .htaccess-Regeln aus dem vorherigen Schritt inline ein.

Beispielkonvertierung eines typischen Apache-VirtualHost:

Vorher (Apache):

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

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

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

    <IfModule security2_module>
        SecRuleEngine On
        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>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Nachher (Caddy):

{
    order coraza_waf first
}

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

    root * /var/www/html
    file_server
    encode gzip

    header {
        X-Content-Type-Options nosniff
        X-Frame-Options DENY
    }
}

Die HTTP-zu-HTTPS-Weiterleitung, die SSL-Konfiguration und die certbot-Integration entfallen alle. Caddy übernimmt sie automatisch.

Der Test-, Umstellungs- und Rollback-Prozess ist derselbe wie bei Nginx-Migrationen:

1. Caddyfile-Syntax validieren: caddy validate --config Caddyfile --adapter caddyfile
2. In Staging ausführen: testen Sie jede Site anhand Ihres Inventars vor der Migration
3. WAF testen: überprüfen Sie, dass Angriffe blockiert werden und legitimer Datenverkehr durchgelassen wird
4. PHP testen: überprüfen Sie bei Verwendung von PHP, dass alle Seiten rendern, Formulare abgeschickt werden und Uploads funktionieren
5. Schrittweise Umstellung: DNS-basiert (zuerst niedrigere TTL), Load-Balancer-Aufteilung oder Migration pro Site
6. Apache weiterlaufen lassen: nehmen Sie Apache erst außer Betrieb, wenn Caddy mindestens eine Woche lang stabil war

Rollback:

Leiten Sie den Datenverkehr zurück auf Apache (DNS-Änderung oder Load-Balancer-Umschaltung). Apache sollte noch laufen und bereit sein, auszuliefern. Der Rollback dauert unter 2 Minuten.

Detaillierte Umstellungsstrategien finden Sie in der Nginx-Migrationsanleitung. Der Prozess ist identisch.