Konfigurera Apache för PHP säkert

Kort sagt: För att konfigurera Apache för PHP säkert kopplar ni in PHP via PHP-FPM och mod_proxy_fcgi, stänger av .htaccess med AllowOverride None och sätter ServerTokens Prod, ServerSignature Off, TraceEnable Off och Options -Indexes. LimitRequestBody anpassar ni till PHP-gränserna, moduler som inte behövs stänger ni av. Konfigurationen ersätter ingen PHP-uppdatering men minskar angreppsytan tydligt.

Apache efter PHP2Shell: mer än en omstart

Apache-operatörer stod i oktober 2026 under särskilt tryck. PHP-teamet bedömer risken som störst vid mod_php, eftersom en exploit där har visats innan någon applikationskod alls körs. De akuta stegen, alltså patchning och fullständig omstart, beskriver sidan Varför mod_php bär den högsta risken.

Efter patchen återstår frågan hur bra själva Apache-konfigurationen är. Servrar som vuxit fram över tid bär ofta inställningar från många år: kataloglistor, öppna .htaccess-rättigheter, moduler som ingen längre behöver. Var och en av dem kan göra ett senare fel större än det behövde vara.

Det här inlägget beskriver en smal, säker grundkonfiguration för Apache 2.4 med PHP-FPM. Exemplen använder sökvägar för Debian och Ubuntu; i RHEL-familjen ligger filerna under /etc/httpd/.

Koppla in PHP via PHP-FPM i stället för mod_php

Med PHP-FPM körs PHP i egna processer, skilt från webbservern. Apache lämnar förfrågningar vidare via mod_proxy_fcgi. Enligt Apache-dokumentationen har inkopplingen via SetHandler en fördel jämfört med ProxyPassMatch: Apache kopplar först själv förfrågan till en fil i filsystemet och lämnar sedan först vidare till PHP-FPM.

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

Modulerna aktiverar ni under Debian och Ubuntu med a2enmod proxy_fcgi. Den som byter från mod_php avaktiverar PHP-modulen och växlar därefter från prefork- till event-MPM. Bakgrund om det gamla driftläget förklarar mod_php förklarat: PHP i Apache-processen.

På PHP-FPM-sidan hör security.limit_extensions = .php hemma i varje pool. Enligt PHP-manualen kör FPM annars även .phar-filer.

Konfigurera Apache för PHP säkert: kärnalternativen

Vissa inställningar gäller för hela servern och hör hemma i en egen konfigurationsfil, till exempel /etc/apache2/conf-available/haertung.conf, aktiverad med a2enconf haertung.

# Korta versionsuppgifter (bara servergemensamt möjligt)
ServerTokens Prod
ServerSignature Off

# Stäng av TRACE-metoden
TraceEnable Off

# Tillåt i grunden ingenting, webbplatser öppnar riktat
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Tabellen nedan placerar de viktigaste alternativen. Standardvärden och verkan kommer från Apache-dokumentationen.

Viktigt vid AllowOverride: många distributioner och CMS-anvisningar sätter AllowOverride All för webbroten. Då kan varje .htaccess-fil ändra rewrite-regler, handlers och vid mod_php till och med PHP-inställningar. En angripare med skrivrättigheter i en uppladdningsmapp kan där lägga en egen .htaccess. Med AllowOverride None är den vägen stängd.

En VirtualHost som mall

Följande VirtualHost förenar punkterna för en enskild webbplats. Certifikatsökvägar, socket och kataloger anpassar ni. mod_ssl och mod_headers måste vara aktiva.

<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ärra versionshantering och miljöfiler
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, passande till post_max_size = 32M
    LimitRequestBody 33554432

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

Det dubbla Header unset är inget misstag. Enligt Apache-dokumentationen hamnar huvuden från mod_proxy_fcgi i en annan intern tabell än huvuden från servern själv; med båda varianterna fångar ni båda fallen. Fler huvuden som aktivt skyddar besökare beskriver guiden Säkerhetsrubriker för webbplatser.

Uppladdnings- och cachemappar behöver dessutom en körspärr. Hur ni hittar och spärrar alla skrivbara mappar står under Förbjud PHP-körning i uppladdningsmappar.

Rensa ut moduler och kontrollera resultatet

Varje laddad modul är kod som reagerar på förfrågningar. Kontrollera vilka moduler som är aktiva och stäng av det ni inte behöver. Typiska kandidater är autoindex, status utan åtkomstbegränsning, cgi och userdir.

# Visa aktiva moduler
apachectl -M | sort
# Exempel Debian/Ubuntu: stäng av modulen för kataloglistor
sudo a2dismod autoindex
# Kontrollera konfigurationen och ladda först därefter om
sudo apachectl configtest && sudo systemctl reload apache2
# Test utifrån: TRACE ska ge 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ärskild uppmärksamhet förtjänar mod_status. Statussidan visar pågående förfrågningar med adresser och anropade sökvägar. Behövs den begränsar ni åtkomsten med Require ip till era förvaltningsnät. Detsamma gäller PHP-FPM:s statussidor som gjorts nåbara via Apache.

Som ytterligare ett lager framför applikationen kan en egen Web Application Firewall vara meningsfull; ingången beskriver Använd ModSecurity och OWASP Core Rule Set.

Slutsats: ordning slår enskilda åtgärder

En säker Apache-konfiguration för PHP består av få, väl förstådda byggstenar. PHP körs via PHP-FPM skilt från webbservern, .htaccess utvärderas inte, versionsuppgifter och TRACE är avstängda, storleksgränserna passar PHP och skrivbara mappar kör inga skript. Ingen av punkterna är spektakulär i sig. Tillsammans ser de till att ett fel på ett ställe inte genast leder till att servern tas över.

För ledning och projektansvariga är en andra egenskap nästan viktigare: en städad konfiguration är spårbar. Står alla regler i VirtualHost i stället för utspridda i dussintals .htaccess-filer går det snabbt att vid nästa kritiska sårbarhet kontrollera vilken webbplats som är inkopplad hur. I ett läge som i oktober 2026 sparar det just den tid det handlar om.

Planera ändå omställningen i lugn och ro och med testmiljö. Ett förhastat byte från mod_php till PHP-FPM strax före en helg skapar snarare nya problem än det löser.

Hur hjälper PHP SOS konkret?

• Kontrollera beståndet: Vi läser ut hela Apache-konfigurationen, alla aktiva moduler och alla .htaccess-filer.
• Planera övergången: Där mod_php fortfarande körs förbereder vi bytet till PHP-FPM med egna pooler per webbplats.
• Härda konfigurationen: Vi sätter kärnalternativen, för över .htaccess-regler till VirtualHost och spärrar skrivbara mappar.
• Testa och dokumentera: Efter varje ändring kontrollerar vi webbplatserna utifrån och dokumenterar läget inom ramen för serverhärdningen.

Vanliga frågor

Källor

• Apache: kärnfunktioner (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: säkerhetsmeddelanden