Apache Webserver Hardening 2026 – HTTPS, TLS 1.3, Security Headers und sichere Cookies

Ein praxisnaher Hardening-Guide für Apache 2.4 unter Debian: HTTP→HTTPS, TLS 1.3, HSTS, sichere Cookies, CSP, Security Headers, minimale Informationspreisgabe, restriktive Directory-Regeln und saubere Tests.

1. Hardening ist ein Schichtenmodell

Apache-Hardening bedeutet nicht, möglichst viele Zeilen aus einer Checkliste zu kopieren. Ziel ist eine nachvollziehbare Kombination aus minimaler Angriffsfläche, aktuellem TLS, restriktiven Dateirechten, sicheren Browser-Headern, sauberem Logging und regelmäßigen Updates.

2. Benötigte Module aktivieren

Für die hier gezeigte Baseline werden vor allem `ssl`, `headers` und `rewrite` benötigt. Unter Debian können sie mit `a2enmod` aktiviert werden. Nicht benötigte Module sollten nicht aus Gewohnheit geladen werden.

sudo a2enmod ssl headers rewrite
sudo apachectl configtest

3. HTTP konsequent auf HTTPS umleiten

Port 80 kann ausschließlich für den Redirect verwendet werden. `mod_rewrite` übernimmt die Weiterleitung und erhält Host sowie angeforderten Pfad. Apache dokumentiert HTTPS-Redirects als typischen Anwendungsfall von `mod_rewrite`.

<VirtualHost *:80>
    RewriteEngine On
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

4. HTTPS-VirtualHost

Der TLS-VirtualHost enthält Zertifikat, Schlüssel, TLS-Policy, Header und DocumentRoot. Der private Schlüssel gehört niemals in den Webroot und muss restriktive Dateirechte besitzen.

5. TLS 1.3 erzwingen

Mit `SSLProtocol TLSv1.3` akzeptiert Apache ausschließlich TLS 1.3. Das ist eine bewusst strenge Policy und kann alte Clients, Scanner oder Embedded-Geräte aussperren. Für eine moderne, kontrollierte Umgebung ist es eine starke Option; bei unbekannter Clientbasis ist `TLSv1.2 TLSv1.3` oft der pragmatischere Kompromiss.

SSLProtocol TLSv1.3

6. TLS-1.3-Cipher

TLS 1.3 hat eine andere Cipher-Auswahl als TLS 1.2. Moderne OpenSSL-Versionen stellen die üblichen TLS-1.3-Cipher bereit. Alte Copy-and-Paste-Cipherlisten aus TLS-1.2-Tutorials sollte man nicht ungeprüft übernehmen.

7. HSTS

`Strict-Transport-Security` sorgt dafür, dass Browser eine Domain künftig nur noch per HTTPS aufrufen. `includeSubDomains` sollte nur verwendet werden, wenn wirklich alle relevanten Subdomains HTTPS-fähig sind. `preload` ist eine langfristige Entscheidung und gehört nicht blind in jede Konfiguration.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

8. Sichere Cookies

Session-Cookies sollten `Secure`, `HttpOnly` und ein passendes `SameSite`-Attribut besitzen. Apache kann fehlende Attribute mit `mod_headers` ergänzen. Das ist eine zusätzliche Schutzschicht, aber kein Ersatz für korrektes Cookie-Handling in der Anwendung.

Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"

9. X-Content-Type-Options

`X-Content-Type-Options: nosniff` ist eine einfache und sinnvolle Baseline gegen unerwünschtes MIME-Sniffing.

10. Referrer-Policy

`strict-origin-when-cross-origin` reduziert unnötige Referrer-Informationen bei Cross-Origin-Anfragen und ist für viele Websites eine gute Ausgangsbasis.

11. Content-Security-Policy

CSP kann XSS-Auswirkungen erheblich reduzieren, muss aber zur Anwendung passen. Deshalb zunächst `Content-Security-Policy-Report-Only` verwenden, Verstöße analysieren und die Policy schrittweise verschärfen.

Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"

12. Permissions-Policy

Nicht benötigte Browserfunktionen wie Kamera, Mikrofon oder Geolocation können deaktiviert werden. Das reduziert die verfügbare Funktionalität für Angreifer und Drittinhalte.

13. Serverinformationen reduzieren

`ServerTokens Prod`, `ServerSignature Off` und `TraceEnable Off` reduzieren unnötige Informationen und deaktivieren TRACE. Das ersetzt kein Patchmanagement, macht automatisches Fingerprinting aber weniger ergiebig.

ServerTokens Prod
ServerSignature Off
TraceEnable Off

14. Directory-Regeln

`Options -Indexes` verhindert Directory Listings. `AllowOverride None` verhindert unerwartete `.htaccess`-Overrides. Für den DocumentRoot sollte der Zugriff explizit erlaubt werden; sensible Verzeichnisse gehören möglichst außerhalb des Webroots.

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

15. Dateirechte und Uploads

Apache sollte nur lesen können, was es ausliefern muss. Schreibrechte im DocumentRoot sind besonders kritisch. Upload-Verzeichnisse sollten möglichst nicht als ausführbarer Webbereich dienen.

16. PHP-FPM statt Wildwuchs

Bei PHP-Anwendungen ist eine Trennung über PHP-FPM und `mod_proxy_fcgi` oft sauberer als eine pauschale PHP-Ausführung in jedem Verzeichnis. Apache liefert statische Dateien, PHP-FPM verarbeitet PHP.

17. Zertifikate und Let's Encrypt

Zertifikate sind nur dann nützlich, wenn Erneuerung und Reload zuverlässig funktionieren. Ablaufüberwachung und ein getesteter Renewal-Prozess gehören zum Betrieb.

18. Konfiguration testen

Vor jedem Reload `apachectl configtest`; danach kontrolliert reloaden. TLS lässt sich lokal mit `openssl s_client` prüfen. Externe TLS-Scanner liefern eine zweite Perspektive aus Client-Sicht.

apachectl configtest
systemctl reload apache2
openssl s_client -connect example.com:443 -tls1_3

19. Logging und Fail2ban

Access- und Error-Logs sind für Diagnose und Angriffserkennung wichtig. Logrotation verhindert volllaufende Datenträger. Fail2ban kann wiederholte Muster blockieren, ersetzt aber weder Firewall noch starke Authentisierung.

20. Eine komplette Baseline

Die folgende Konfiguration verbindet die wichtigsten Bausteine zu einem brauchbaren Ausgangspunkt für eine klassische öffentliche Debian-Apache-Website. Sie muss an Domain, Pfade und Anwendung angepasst werden.

/var/log/apache2/access.log
/var/log/apache2/error.log

# Beispiel: Status prüfen
systemctl status apache2

21. Was man nicht blind aktivieren sollte

TLS 1.3-only, HSTS mit Subdomains und CSP können reale Clients beeinflussen. Erst testen, dann verschärfen. HSTS wird vom Browser gespeichert; CSP sollte bei komplexen Anwendungen zunächst nur beobachten.

# Apache 2.4 / Debian – Hardening-Baseline
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    RewriteEngine On
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

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

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

    # Strikte TLS-1.3-Policy. Für Legacy-Clients ggf. TLSv1.2 TLSv1.3 verwenden.
    SSLProtocol TLSv1.3
    SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

    ServerTokens Prod
    ServerSignature Off
    TraceEnable Off

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

    # Defense-in-depth; Anwendung sollte Cookies idealerweise selbst korrekt setzen.
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"

    # CSP zunächst beobachten und an die Anwendung anpassen:
    # Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"

    ErrorLog ${APACHE_LOG_DIR}/example-error.log
    CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

22. Fazit

Die starke Kombination lautet: minimale Angriffsfläche, HTTPS, moderne TLS-Version, sichere Cookies, Security Headers, restriktive Dateirechte, wenig Versionsinformationen, Logs, Updates und ein getesteter Rollback-Weg.