# Apache für PHP sicher konfigurieren

> Apache PHP sicher konfigurieren: PHP-FPM über mod_proxy_fcgi, AllowOverride None, ServerTokens, TraceEnable und LimitRequestBody richtig setzen und prüfen.

Quelle: https://phpsos.de/blog/apache-fuer-php-absichern/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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](https://phpsos.de/php2shell/mod-php-risiko/).

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.

```apache
<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](https://phpsos.de/php/mod-php-erklaert/).

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`.

```apache
# 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.

| Direktive | Standard | Empfehlung | Warum |
|---|---|---|---|
| `ServerTokens` | `Full` | `Prod` | `Server`-Header nennt nur „Apache“ |
| `ServerSignature` | `Off` | `Off` | keine Versionszeile unter Fehlerseiten |
| `TraceEnable` | `on` | `Off` | TRACE wird mit 405 abgelehnt |
| `Options` | `FollowSymlinks` | `-Indexes`, Symlinks nur nach Eigentümer | keine Verzeichnislisten |
| `AllowOverride` | `None` | `None` | `.htaccess` wird nicht ausgewertet |
| `LimitRequestBody` | 1 GiB (seit 2.4.54) | passend zu `post_max_size` | große Anfragen früh ablehnen |

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.

```apache
<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](https://phpsos.de/ratgeber/sicherheits-header/).

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](https://phpsos.de/blog/php-in-uploads-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`.

```bash
# 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.

> **Wichtig:**
> Stellen Sie `AllowOverride` nicht ohne Vorbereitung um. Übernehmen Sie zuerst die Regeln aus allen `.htaccess`-Dateien in den VirtualHost und testen Sie die Website auf einer Kopie. Sonst funktionieren Weiterleitungen und schöne URLs nach dem Neuladen nicht mehr.

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](https://phpsos.de/blog/modsecurity-owasp-crs/).

## 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](https://phpsos.de/leistungen/server-haertung/) fest.


## Häufige Fragen

**Sollte ich mod_php noch verwenden?**  
Für neue Einrichtungen empfehlen wir PHP-FPM über mod_proxy_fcgi. Das PHP-Team stuft das Risiko durch PHP2Shell bei mod_php am höchsten ein. Mit PHP-FPM läuft PHP getrennt vom Webserver, mit eigenen Benutzern je Website und eigenen Grenzen.

**Warum AllowOverride None, wenn mein CMS .htaccess braucht?**  
Eine .htaccess kann jeder anlegen, der im Webroot schreiben darf, auch eingeschleuster Code. Mit AllowOverride None wertet Apache solche Dateien nicht aus. Die Regeln Ihres CMS übernehmen Sie dann einmalig in den VirtualHost. Das ist etwas Aufwand, macht die Konfiguration aber nachvollziehbar und schneller.

**Kann ich ServerTokens je Website unterschiedlich setzen?**  
Nein. Laut Apache-Dokumentation gilt ServerTokens für den gesamten Server und lässt sich nicht je VirtualHost ändern. Es steuert zugleich die Versionsangabe unter Fehlerseiten, die ServerSignature einblendet.

**Welchen Wert hat LimitRequestBody standardmäßig?**  
Seit Apache 2.4.54 liegt der Standard bei 1 GiB, in Version 2.4.53 und älter war er unbegrenzt. Setzen Sie den Wert passend zu post_max_size Ihrer PHP-Konfiguration, damit zu große Anfragen schon im Webserver abgelehnt werden.

## Quellen

- [Apache: Kernfunktionen (core)](https://httpd.apache.org/docs/2.4/mod/core.html)
- [Apache: mod_proxy_fcgi](https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html)
- [Apache: mod_headers](https://httpd.apache.org/docs/2.4/mod/mod_headers.html)
- [php.net: Sicherheitsmeldungen](https://www.php.net/)