Konfigurér Apache sikkert til PHP

Kort sagt: For at konfigurere Apache sikkert til PHP binder I PHP på via PHP-FPM og mod_proxy_fcgi, slår .htaccess fra med AllowOverride None og sætter ServerTokens Prod, ServerSignature Off, TraceEnable Off og Options -Indexes. LimitRequestBody tilpasser I til PHP-grænserne, moduler, der ikke er nødvendige, slår I fra. Konfigurationen erstatter ingen PHP-opdatering, men formindsker angrebsfladen tydeligt.

Apache efter PHP2Shell: mere end en genstart

Apache-driftsansvarlige stod i oktober 2026 under særligt pres. PHP-teamet vurderer risikoen ved mod_php som højest, fordi der er vist en exploit, før applikationskode overhovedet kører. De akutte skridt, altså patching og fuldstændig genstart, beskriver siden Hvorfor mod_php bærer den højeste risiko.

Efter patchen består spørgsmålet, hvor god selve Apache-konfigurationen er. Servere, der er vokset over tid, bærer ofte indstillinger fra mange år: mappelister, åbne .htaccess-rettigheder, moduler, som ingen længere har brug for. Hver af dem kan gøre en senere fejl større, end den behøver at være.

Dette indlæg beskriver en slank, sikker grundkonfiguration til Apache 2.4 med PHP-FPM. Eksemplerne bruger Debian- og Ubuntu-stier; i RHEL-familien ligger filerne under /etc/httpd/.

Bind PHP på via PHP-FPM i stedet for mod_php

Med PHP-FPM kører PHP i egne processer, adskilt fra webserveren. Apache sender forespørgsler videre via mod_proxy_fcgi. Ifølge Apache-dokumentationen har tilslutningen via SetHandler en fordel frem for ProxyPassMatch: Apache henfører først selv forespørgslen til en fil i filsystemet og giver først derefter videre til PHP-FPM.

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

Modulerne aktiverer I under Debian og Ubuntu med a2enmod proxy_fcgi. Den, der skifter fra mod_php, deaktiverer PHP-modulet og skifter derefter fra prefork- til event-MPM. Baggrund om den gamle driftsform forklarer mod_php forklaret: PHP i Apache-processen.

På PHP-FPM-siden hører security.limit_extensions = .php hjemme i hver pool. Ifølge PHP-manualen udfører FPM ellers også .phar-filer.

Konfigurér Apache sikkert til PHP: kerneindstillingerne

Nogle indstillinger gælder for hele serveren og hører hjemme i en egen konfigurationsfil, f.eks. /etc/apache2/conf-available/haertung.conf, aktiveret med a2enconf haertung.

# Forkort versionsangivelser (kun mulig serverdækkende)
ServerTokens Prod
ServerSignature Off

# Slå TRACE-metoden fra
TraceEnable Off

# Frigiv grundlæggende intet, tillad websites målrettet
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Tabellen nedenfor indordner de vigtigste indstillinger. Standardværdier og virkning stammer fra Apache-dokumentationen.

Vigtigt ved AllowOverride: Mange distributioner og CMS-vejledninger sætter AllowOverride All for webroden. Dermed kan hver .htaccess-fil ændre rewrite-regler, handlere og ved mod_php endda PHP-indstillinger. En angriber med skriverettigheder i en upload-mappe kan dér lægge sin egen .htaccess. Med AllowOverride None er denne vej lukket.

En VirtualHost som skabelon

Den følgende VirtualHost forener punkterne for et enkelt website. Certifikatstier, socket og mapper tilpasser I. mod_ssl og mod_headers skal være aktive.

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

    # Spær versionsstyring og miljøfiler
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, passende til post_max_size = 32M
    LimitRequestBody 33554432

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

Det dobbelte Header unset er ingen forglemmelse. Ifølge Apache-dokumentationen havner headere fra mod_proxy_fcgi i en anden intern tabel end serverens egne headere; med begge varianter fanger I begge tilfælde. Yderligere headere, der aktivt beskytter besøgende, beskriver vejledningen Sikkerhedsheadere til websites.

Upload- og cache-mapper har desuden brug for en udførelsesspærring. Hvordan I finder og spærrer alle skrivbare mapper, står under Forbyd PHP-udførelse i upload-mapper.

Ryd ud i moduler, og kontrollér resultatet

Hvert indlæst modul er kode, der reagerer på forespørgsler. Kontrollér, hvilke moduler der er aktive, og slå fra, hvad I ikke har brug for. Typiske kandidater er autoindex, status uden adgangsbegrænsning, cgi og userdir.

# Vis aktive moduler
apachectl -M | sort
# Eksempel Debian/Ubuntu: slå modulet til mappelister fra
sudo a2dismod autoindex
# Kontrollér konfigurationen, og genindlæs først derefter
sudo apachectl configtest && sudo systemctl reload apache2
# Test udefra: TRACE skal give 405, .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

Særlig opmærksomhed fortjener mod_status. Statussiden viser kørende forespørgsler med adresser og kaldte stier. Bruges den, begrænser I adgangen med Require ip til jeres administrationsnet. Det samme gælder statussider fra PHP-FPM, som er gjort tilgængelige via Apache.

Som yderligere lag foran applikationen kan en egen web application firewall være fornuftig; indgangen beskriver Brug ModSecurity og OWASP Core Rule Set.

Konklusion: Orden slår enkeltforanstaltning

En sikker Apache-konfiguration til PHP består af få, godt forståede byggesten. PHP kører via PHP-FPM adskilt fra webserveren, .htaccess vurderes ikke, versionsangivelser og TRACE er slået fra, størrelsesgrænser passer til PHP, og skrivbare mapper udfører ingen scripts. Ingen af disse punkter er i sig selv opsigtsvækkende. Sammen sørger de for, at en fejl ét sted ikke straks fører til overtagelse af serveren.

For ledelse og projektansvarlige er en anden egenskab næsten vigtigere: En ryddelig konfiguration er forståelig. Står alle regler i VirtualHost i stedet for spredt i dusinvis af .htaccess-filer, kan man ved næste kritiske sårbarhed hurtigt kontrollere, hvordan hvert website er tilsluttet. I en situation som i oktober 2026 sparer det netop den tid, det kommer an på.

Planlæg alligevel omstillingen i ro og mag og med testmiljø. Et forhastet skifte fra mod_php til PHP-FPM kort før en weekend skaber snarere nye problemer, end det løser.

Hvordan hjælper PHP SOS konkret?

• Kontrollér beholdningen: Vi udlæser hele Apache-konfigurationen, alle aktive moduler og alle .htaccess-filer.
• Planlæg skiftet: Hvor mod_php stadig kører, forbereder vi skiftet til PHP-FPM med egne pools pr. website.
• Hærd konfigurationen: Vi sætter kerneindstillinger, overfører .htaccess-regler til VirtualHosts og spærrer skrivbare mapper.
• Test og dokumentér: Efter hver ændring kontrollerer vi websites udefra og fastholder tilstanden inden for rammerne af serverhærdningen.

Ofte stillede spørgsmål

Kilder

• Apache: Kernefunktioner (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: Sikkerhedsmeddelelser