# Konfigurér Apache sikkert til PHP

> Konfigurér Apache sikkert til PHP: PHP-FPM via mod_proxy_fcgi, AllowOverride None, ServerTokens, TraceEnable og LimitRequestBody sat og kontrolleret rigtigt.

Kilde: https://phpsos.de/da/blog/apache-fuer-php-absichern/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

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

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

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

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

| Direktiv | Standard | Anbefaling | Hvorfor |
|---|---|---|---|
| `ServerTokens` | `Full` | `Prod` | `Server`-headeren nævner kun "Apache" |
| `ServerSignature` | `Off` | `Off` | ingen versionslinje under fejlsider |
| `TraceEnable` | `on` | `Off` | TRACE afvises med 405 |
| `Options` | `FollowSymlinks` | `-Indexes`, symlinks kun efter ejer | ingen mappelister |
| `AllowOverride` | `None` | `None` | `.htaccess` vurderes ikke |
| `LimitRequestBody` | 1 GiB (siden 2.4.54) | passende til `post_max_size` | afvis store forespørgsler tidligt |

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.

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

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

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

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

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

> **Vigtigt:**
> Omstil ikke `AllowOverride` uden forberedelse. Overfør først reglerne fra alle `.htaccess`-filer til VirtualHost, og test websitet på en kopi. Ellers virker viderestillinger og pæne URL'er ikke længere efter genindlæsningen.

Som yderligere lag foran applikationen kan en egen web application firewall være fornuftig; indgangen beskriver [Brug ModSecurity og OWASP Core Rule Set](https://phpsos.de/da/blog/modsecurity-owasp-crs/).

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


## Ofte stillede spørgsmål

**Bør jeg stadig bruge mod_php?**  
Til nye opsætninger anbefaler vi PHP-FPM via mod_proxy_fcgi. PHP-teamet vurderer risikoen ved PHP2Shell som højest for mod_php. Med PHP-FPM kører PHP adskilt fra webserveren, med egne brugere pr. website og egne grænser.

**Hvorfor AllowOverride None, når mit CMS har brug for .htaccess?**  
En .htaccess kan enhver oprette, der må skrive i webroden, også indsmuglet kode. Med AllowOverride None vurderer Apache ikke sådanne filer. Reglerne fra jeres CMS overfører I så engangs til VirtualHost. Det er lidt besvær, men gør konfigurationen forståelig og hurtigere.

**Kan jeg sætte ServerTokens forskelligt pr. website?**  
Nej. Ifølge Apache-dokumentationen gælder ServerTokens for hele serveren og kan ikke ændres pr. VirtualHost. Den styrer samtidig den versionsangivelse under fejlsider, som ServerSignature viser.

**Hvilken standardværdi har LimitRequestBody?**  
Siden Apache 2.4.54 er standarden 1 GiB, i version 2.4.53 og ældre var den ubegrænset. Sæt værdien passende til post_max_size i jeres PHP-konfiguration, så for store forespørgsler afvises allerede i webserveren.

## Kilder

- [Apache: Kernefunktioner (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: Sikkerhedsmeddelelser](https://www.php.net/)