Apache für PHP sicher konfigurieren

Kurz gesagt: Um Apache für PHP sicher zu konfigurieren, binden Sie PHP über PHP-FPM und mod_proxy_fcgi an, schalten .htaccess mit AllowOverride None ab und setzen ServerTokens Prod, ServerSignature Off, TraceEnable Off und Options -Indexes. LimitRequestBody passen Sie an die PHP-Grenzen an, nicht benötigte Module schalten Sie ab. Die Konfiguration ersetzt kein PHP-Update, verkleinert aber die Angriffsfläche deutlich.

Apache nach PHP2Shell: mehr als ein Neustart

Apache-Betreiber standen im Oktober 2026 unter besonderem Druck. Das PHP-Team stuft das Risiko bei mod_php am höchsten ein, weil dort ein Exploit gezeigt wurde, bevor überhaupt Anwendungscode läuft. Die akuten Schritte, also Patchen und vollständiger Neustart, beschreibt die Seite Warum mod_php das höchste Risiko trägt.

Nach dem Patch bleibt die Frage, wie gut die Apache-Konfiguration selbst ist. Gewachsene Server tragen oft Einstellungen aus vielen Jahren: Verzeichnislisten, offene .htaccess-Rechte, Module, die niemand mehr braucht. Jede davon kann einen späteren Fehler größer machen, als er sein müsste.

Dieser Beitrag beschreibt eine schlanke, sichere Grundkonfiguration für Apache 2.4 mit PHP-FPM. Die Beispiele nutzen Debian- und Ubuntu-Pfade; auf der RHEL-Familie liegen die Dateien unter /etc/httpd/.

PHP über PHP-FPM statt mod_php anbinden

Mit PHP-FPM läuft PHP in eigenen Prozessen, getrennt vom Webserver. Apache reicht Anfragen über mod_proxy_fcgi weiter. Laut Apache-Dokumentation hat die Anbindung per SetHandler einen Vorteil gegenüber ProxyPassMatch: Apache ordnet die Anfrage zuerst selbst einer Datei im Dateisystem zu und gibt erst dann an PHP-FPM weiter.

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>

Die Module aktivieren Sie unter Debian und Ubuntu mit a2enmod proxy_fcgi. Wer von mod_php umsteigt, deaktiviert das PHP-Modul und wechselt anschließend vom Prefork- zum Event-MPM. Hintergründe zur alten Betriebsart erklärt mod_php erklärt: PHP im Apache-Prozess.

Auf der PHP-FPM-Seite gehört security.limit_extensions = .php in jeden Pool. Laut PHP-Handbuch führt FPM sonst auch .phar-Dateien aus.

Apache PHP sicher konfigurieren: die Kernoptionen

Einige Einstellungen gelten für den ganzen Server und gehören in eine eigene Konfigurationsdatei, etwa /etc/apache2/conf-available/haertung.conf, aktiviert mit a2enconf haertung.

# Versionsangaben kürzen (nur serverweit möglich)
ServerTokens Prod
ServerSignature Off

# TRACE-Methode abschalten
TraceEnable Off

# Grundsätzlich nichts freigeben, Websites erlauben gezielt
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Die folgende Tabelle ordnet die wichtigsten Optionen ein. Standardwerte und Wirkung stammen aus der Apache-Dokumentation.

Wichtig bei AllowOverride: Viele Distributionen und CMS-Anleitungen setzen für den Webroot AllowOverride All. Damit kann jede .htaccess-Datei Rewrite-Regeln, Handler und bei mod_php sogar PHP-Einstellungen ändern. Ein Angreifer mit Schreibrechten in einem Upload-Ordner kann dort eine eigene .htaccess ablegen. Mit AllowOverride None ist dieser Weg verschlossen.

Ein VirtualHost als Vorlage

Der folgende VirtualHost verbindet die Punkte für eine einzelne Website. Zertifikatspfade, Socket und Verzeichnisse passen Sie an. mod_ssl und mod_headers müssen aktiv sein.

<VirtualHost *:443>
    ServerName www.example.de
    DocumentRoot /var/www/seite1/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/seite1/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/seite1/privkey.pem

    <Directory /var/www/seite1/public>
        Options -Indexes +SymLinksIfOwnerMatch
        AllowOverride None
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
    </FilesMatch>

    # Versionsverwaltung und Umgebungsdateien sperren
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, passend zu post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>

Das doppelte Header unset ist kein Versehen. Laut Apache-Dokumentation landen Header aus mod_proxy_fcgi in einer anderen internen Tabelle als Header des Servers selbst; mit beiden Varianten erwischen Sie beide Fälle. Weitere Header, die Besucher aktiv schützen, beschreibt der Ratgeber Sicherheits-Header für Websites.

Upload- und Cache-Ordner brauchen zusätzlich eine Ausführungssperre. Wie Sie alle beschreibbaren Ordner finden und sperren, steht unter PHP-Ausführung in Upload-Ordnern verbieten.

Module ausmisten und Ergebnis prüfen

Jedes geladene Modul ist Code, der auf Anfragen reagiert. Prüfen Sie, welche Module aktiv sind, und schalten Sie ab, was Sie nicht brauchen. Typische Kandidaten sind autoindex, status ohne Zugriffsbeschränkung, cgi und userdir.

# Aktive Module anzeigen
apachectl -M | sort
# Beispiel Debian/Ubuntu: Verzeichnislisten-Modul abschalten
sudo a2dismod autoindex
# Konfiguration prüfen und erst dann neu laden
sudo apachectl configtest && sudo systemctl reload apache2
# Test von außen: TRACE soll 405 liefern, .git 403
curl -s -o /dev/null -w "%{http_code}\n" -X TRACE https://www.example.de/
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD

Besondere Aufmerksamkeit verdient mod_status. Die Statusseite zeigt laufende Anfragen mit Adressen und aufgerufenen Pfaden. Wird sie gebraucht, beschränken Sie den Zugriff mit Require ip auf Ihre Verwaltungsnetze. Dasselbe gilt für Statusseiten von PHP-FPM, die über Apache erreichbar gemacht wurden.

Als zusätzliche Schicht vor der Anwendung kann eine eigene Web Application Firewall sinnvoll sein; den Einstieg beschreibt ModSecurity und OWASP Core Rule Set einsetzen.

Fazit: Ordnung schlägt Einzelmaßnahme

Eine sichere Apache-Konfiguration für PHP besteht aus wenigen, gut verstandenen Bausteinen. PHP läuft über PHP-FPM getrennt vom Webserver, .htaccess wird nicht ausgewertet, Versionsangaben und TRACE sind abgeschaltet, Größengrenzen passen zu PHP, und beschreibbare Ordner führen keine Skripte aus. Keiner dieser Punkte ist für sich spektakulär. Zusammen sorgen sie dafür, dass ein Fehler an einer Stelle nicht sofort zur Übernahme des Servers führt.

Für Geschäftsführung und Projektverantwortliche ist eine zweite Eigenschaft fast wichtiger: Eine aufgeräumte Konfiguration ist nachvollziehbar. Stehen alle Regeln im VirtualHost statt verstreut in Dutzenden .htaccess-Dateien, lässt sich bei der nächsten kritischen Lücke schnell prüfen, welche Website wie angebunden ist. In einer Lage wie im Oktober 2026 spart das genau die Zeit, auf die es ankommt.

Planen Sie die Umstellung trotzdem in Ruhe und mit Testumgebung. Ein überhasteter Wechsel von mod_php auf PHP-FPM kurz vor einem Wochenende erzeugt eher neue Probleme, als er löst.

Wie hilft PHP SOS konkret?

• Bestand prüfen: Wir lesen die gesamte Apache-Konfiguration, alle aktiven Module und alle .htaccess-Dateien aus.
• Umstieg planen: Wo noch mod_php läuft, bereiten wir den Wechsel auf PHP-FPM mit eigenen Pools je Website vor.
• Konfiguration härten: Wir setzen Kernoptionen, übernehmen .htaccess-Regeln in die VirtualHosts und sperren beschreibbare Ordner.
• Testen und dokumentieren: Nach jeder Änderung prüfen wir die Websites von außen und halten den Stand im Rahmen der Server-Härtung fest.

Häufige Fragen

Quellen

• Apache: Kernfunktionen (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: Sicherheitsmeldungen