Apache veilig configureren voor PHP

Kort gezegd: Om Apache veilig voor PHP te configureren, koppelt u PHP via PHP-FPM en mod_proxy_fcgi, schakelt u .htaccess uit met AllowOverride None en stelt u ServerTokens Prod, ServerSignature Off, TraceEnable Off en Options -Indexes in. LimitRequestBody stemt u af op de PHP-grenzen, niet-benodigde modules schakelt u uit. De configuratie vervangt geen PHP-update, maar verkleint het aanvalsoppervlak aanzienlijk.

Apache na PHP2Shell: meer dan een herstart

Apache-beheerders stonden in oktober 2026 onder bijzondere druk. Het PHP-team schat het risico bij mod_php het hoogst in, omdat daar een exploit is aangetoond voordat er zelfs maar applicatiecode draait. De acute stappen, dus patchen en volledig herstarten, beschrijft de pagina Waarom mod_php het hoogste risico draagt.

Na de patch blijft de vraag hoe goed de Apache-configuratie zelf is. Gegroeide servers dragen vaak instellingen uit vele jaren: maplijsten, open .htaccess-rechten, modules die niemand meer nodig heeft. Elk daarvan kan een latere fout groter maken dan nodig is.

Dit artikel beschrijft een slanke, veilige basisconfiguratie voor Apache 2.4 met PHP-FPM. De voorbeelden gebruiken Debian- en Ubuntu-paden; in de RHEL-familie staan de bestanden onder /etc/httpd/.

PHP via PHP-FPM koppelen in plaats van mod_php

Met PHP-FPM draait PHP in eigen processen, gescheiden van de webserver. Apache geeft verzoeken door via mod_proxy_fcgi. Volgens de Apache-documentatie heeft de koppeling via SetHandler een voordeel boven ProxyPassMatch: Apache wijst het verzoek eerst zelf aan een bestand in het bestandssysteem toe en geeft pas daarna door aan PHP-FPM.

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

De modules activeert u onder Debian en Ubuntu met a2enmod proxy_fcgi. Wie van mod_php overstapt, deactiveert de PHP-module en wisselt daarna van de prefork- naar de event-MPM. Achtergronden over de oude uitvoeringsmodus legt mod_php uitgelegd: PHP in het Apache-proces uit.

Aan de PHP-FPM-kant hoort security.limit_extensions = .php in elke pool. Volgens de PHP-handleiding voert FPM anders ook .phar-bestanden uit.

Apache veilig voor PHP configureren: de kernopties

Enkele instellingen gelden voor de hele server en horen in een eigen configuratiebestand, bijvoorbeeld /etc/apache2/conf-available/haertung.conf, geactiveerd met a2enconf haertung.

# Versiegegevens inkorten (alleen server-breed mogelijk)
ServerTokens Prod
ServerSignature Off

# TRACE-methode uitschakelen
TraceEnable Off

# In beginsel niets vrijgeven, websites staan gericht toe
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

De volgende tabel ordent de belangrijkste opties. Standaardwaarden en werking komen uit de Apache-documentatie.

Belangrijk bij AllowOverride: veel distributies en CMS-handleidingen stellen voor de webroot AllowOverride All in. Daarmee kan elk .htaccess-bestand rewrite-regels, handlers en bij mod_php zelfs PHP-instellingen wijzigen. Een aanvaller met schrijfrechten in een uploadmap kan daar een eigen .htaccess neerzetten. Met AllowOverride None is die weg afgesloten.

Een VirtualHost als sjabloon

De volgende VirtualHost verbindt de punten voor één enkele website. Certificaatpaden, socket en mappen past u aan. mod_ssl en mod_headers moeten actief zijn.

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

    # Versiebeheer en omgevingsbestanden blokkeren
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

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

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

Het dubbele Header unset is geen vergissing. Volgens de Apache-documentatie belanden headers uit mod_proxy_fcgi in een andere interne tabel dan headers van de server zelf; met beide varianten vangt u beide gevallen. Verdere headers die bezoekers actief beschermen, beschrijft de gids Beveiligingsheaders voor websites.

Upload- en cachemappen hebben aanvullend een uitvoeringsblokkade nodig. Hoe u alle beschrijfbare mappen vindt en blokkeert, staat onder PHP-uitvoering in uploadmappen verbieden.

Modules uitdunnen en het resultaat controleren

Elke geladen module is code die op verzoeken reageert. Controleer welke modules actief zijn en schakel uit wat u niet nodig hebt. Typische kandidaten zijn autoindex, status zonder toegangsbeperking, cgi en userdir.

# Actieve modules tonen
apachectl -M | sort
# Voorbeeld Debian/Ubuntu: module voor maplijsten uitschakelen
sudo a2dismod autoindex
# Configuratie controleren en pas daarna opnieuw laden
sudo apachectl configtest && sudo systemctl reload apache2
# Test van buitenaf: TRACE moet 405 geven, .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

Bijzondere aandacht verdient mod_status. De statuspagina toont lopende verzoeken met adressen en opgevraagde paden. Is ze nodig, beperk de toegang dan met Require ip tot uw beheernetwerken. Hetzelfde geldt voor statuspagina's van PHP-FPM die via Apache bereikbaar zijn gemaakt.

Als extra laag voor de applicatie kan een eigen Web Application Firewall zinvol zijn; de eerste stappen beschrijft ModSecurity en OWASP Core Rule Set inzetten.

Conclusie: orde verslaat afzonderlijke maatregelen

Een veilige Apache-configuratie voor PHP bestaat uit enkele, goed begrepen bouwstenen. PHP draait via PHP-FPM gescheiden van de webserver, .htaccess wordt niet beoordeeld, versiegegevens en TRACE zijn uitgeschakeld, groottegrenzen passen bij PHP en beschrijfbare mappen voeren geen scripts uit. Geen van deze punten is op zich spectaculair. Samen zorgen ze ervoor dat een fout op één plek niet meteen tot overname van de server leidt.

Voor directie en projectverantwoordelijken is een tweede eigenschap bijna belangrijker: een opgeruimde configuratie is navolgbaar. Staan alle regels in de VirtualHost in plaats van verspreid over tientallen .htaccess-bestanden, dan is bij de volgende kritieke kwetsbaarheid snel te controleren welke website hoe is gekoppeld. In een situatie als in oktober 2026 bespaart dat precies de tijd waar het op aankomt.

Plan de omschakeling toch rustig en met een testomgeving. Een overhaaste wissel van mod_php naar PHP-FPM vlak voor een weekend veroorzaakt eerder nieuwe problemen dan dat hij er oplost.

Hoe helpt PHP SOS concreet?

• Bestand controleren: wij lezen de gehele Apache-configuratie, alle actieve modules en alle .htaccess-bestanden uit.
• Overstap plannen: waar nog mod_php draait, bereiden wij de overstap naar PHP-FPM voor met eigen pools per website.
• Configuratie verharden: wij stellen kernopties in, nemen .htaccess-regels over in de VirtualHosts en blokkeren beschrijfbare mappen.
• Testen en documenteren: na elke wijziging controleren wij de websites van buitenaf en leggen wij de stand vast in het kader van de serverhardening.

Veelgestelde vragen

Bronnen

• Apache: kernfuncties (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: beveiligingsmeldingen