Varna konfiguracija Apache za PHP

Na kratko: Za varno konfiguracijo Apache za PHP povežite PHP prek PHP-FPM in mod_proxy_fcgi, izklopite .htaccess z AllowOverride None in nastavite ServerTokens Prod, ServerSignature Off, TraceEnable Off in Options -Indexes. LimitRequestBody uskladite z mejami PHP, nepotrebne module izklopite. Konfiguracija ne nadomešča posodobitve PHP, vendar napadalno površino občutno zmanjša.

Apache po PHP2Shell: več kot ponovni zagon

Upravljavci Apache so bili oktobra 2026 pod posebnim pritiskom. Ekipa PHP tveganje pri mod_php ocenjuje kot najvišje, ker je bil tam prikazan exploit, še preden se sploh izvede koda aplikacije. Akutne korake, torej popravljanje in popoln ponovni zagon, opisuje stran Zakaj mod_php nosi najvišje tveganje.

Po popravku ostane vprašanje, kako dobra je sama konfiguracija Apache. Zrasli strežniki pogosto nosijo nastavitve iz mnogih let: sezname map, odprte pravice .htaccess, module, ki jih nihče več ne potrebuje. Vsaka od njih lahko poznejšo napako naredi večjo, kot bi morala biti.

Ta prispevek opisuje vitko, varno osnovno konfiguracijo za Apache 2.4 s PHP-FPM. Primeri uporabljajo poti Debiana in Ubuntuja; pri družini RHEL ležijo datoteke pod /etc/httpd/.

Povezava PHP prek PHP-FPM namesto mod_php

S PHP-FPM PHP teče v lastnih procesih, ločeno od spletnega strežnika. Apache zahteve posreduje prek mod_proxy_fcgi. Po dokumentaciji Apache ima povezava prek SetHandler prednost pred ProxyPassMatch: Apache zahtevo najprej sam dodeli datoteki v datotečnem sistemu in šele nato preda PHP-FPM.

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

Module pod Debianom in Ubuntujem aktivirate z a2enmod proxy_fcgi. Kdor prehaja z mod_php, deaktivira modul PHP in nato preklopi z MPM Prefork na MPM Event. Ozadje starega načina delovanja pojasnjuje mod_php razloženo: PHP v procesu Apache.

Na strani PHP-FPM security.limit_extensions = .php sodi v vsak pool. Po priročniku PHP FPM sicer izvede tudi datoteke .phar.

Varna konfiguracija Apache za PHP: jedrne možnosti

Nekatere nastavitve veljajo za celoten strežnik in sodijo v lastno konfiguracijsko datoteko, na primer /etc/apache2/conf-available/haertung.conf, aktivirano z a2enconf haertung.

# Skrajšajte navedbe različic (mogoče samo za ves strežnik)
ServerTokens Prod
ServerSignature Off

# Izklopite metodo TRACE
TraceEnable Off

# Načeloma ne sprostite ničesar, spletne strani dovolite ciljno
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Naslednja tabela umešča najpomembnejše možnosti. Privzete vrednosti in učinek izvirajo iz dokumentacije Apache.

Pomembno pri AllowOverride: številne distribucije in navodila za CMS za spletni koren nastavijo AllowOverride All. S tem lahko vsaka datoteka .htaccess spreminja pravila Rewrite, handlerje in pri mod_php celo nastavitve PHP. Napadalec s pravicami pisanja v mapi za nalaganje tam lahko odloži lastno .htaccess. Z AllowOverride None je ta pot zaprta.

VirtualHost kot predloga

Naslednji VirtualHost združuje točke za posamezno spletno stran. Poti certifikatov, socket in imenike prilagodite. mod_ssl in mod_headers morata biti aktivna.

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

    # Zaprite nadzor različic in okoljske datoteke
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, v skladu s post_max_size = 32M
    LimitRequestBody 33554432

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

Dvojni Header unset ni pomota. Po dokumentaciji Apache glave iz mod_proxy_fcgi pristanejo v drugi notranji tabeli kot glave samega strežnika; z obema različicama ujamete oba primera. Nadaljnje glave, ki dejavno ščitijo obiskovalce, opisuje vodnik Varnostne glave za spletne strani.

Mape za nalaganje in predpomnilnik dodatno potrebujejo prepoved izvajanja. Kako najdete in zaprete vse zapisljive mape, piše pod Prepoved izvajanja PHP v mapah za nalaganje.

Počistite module in preverite rezultat

Vsak naložen modul je koda, ki se odziva na zahteve. Preverite, kateri moduli so aktivni, in izklopite, česar ne potrebujete. Tipični kandidati so autoindex, status brez omejitve dostopa, cgi in userdir.

# Prikaži aktivne module
apachectl -M | sort
# Primer Debian/Ubuntu: izklopite modul seznama map
sudo a2dismod autoindex
# Preverite konfiguracijo in šele nato znova naložite
sudo apachectl configtest && sudo systemctl reload apache2
# Preizkus od zunaj: TRACE naj vrne 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

Posebno pozornost si zasluži mod_status. Statusna stran prikazuje tekoče zahteve z naslovi in klicanimi potmi. Če jo potrebujete, dostop z Require ip omejite na svoja upravljalska omrežja. Enako velja za statusne strani PHP-FPM, ki so bile narejene dosegljive prek Apache.

Kot dodatna plast pred aplikacijo je lahko smiseln lasten požarni zid spletnih aplikacij; uvod opisuje Uporaba ModSecurity in OWASP Core Rule Set.

Sklep: red premaga posamezen ukrep

Varna konfiguracija Apache za PHP je sestavljena iz nekaj dobro razumljenih gradnikov. PHP teče prek PHP-FPM ločeno od spletnega strežnika, .htaccess se ne ovrednoti, navedbe različic in TRACE so izklopljeni, meje velikosti ustrezajo PHP, zapisljive mape pa ne izvajajo skriptov. Nobena od teh točk ni sama po sebi spektakularna. Skupaj poskrbijo, da napaka na enem mestu ne vodi takoj do prevzema strežnika.

Za vodstvo in vodje projektov je skoraj pomembnejša druga lastnost: urejena konfiguracija je sledljiva. Če so vsa pravila v VirtualHost namesto razpršena po ducatih datotek .htaccess, je ob naslednji kritični ranljivosti mogoče hitro preveriti, katera spletna stran je kako povezana. V razmerah, kot so bile oktobra 2026, to prihrani prav čas, ki šteje.

Prehod vseeno načrtujte umirjeno in s testnim okoljem. Prenagljen preklop z mod_php na PHP-FPM tik pred koncem tedna prej ustvari nove težave, kot jih reši.

Kako PHP SOS pomaga konkretno?

• Preverjanje stanja: preberemo celotno konfiguracijo Apache, vse aktivne module in vse datoteke .htaccess.
• Načrtovanje prehoda: kjer še teče mod_php, pripravimo preklop na PHP-FPM z lastnimi pooli za vsako spletno stran.
• Utrjevanje konfiguracije: nastavimo jedrne možnosti, pravila .htaccess prenesemo v VirtualHost in zapremo zapisljive mape.
• Preizkus in dokumentiranje: po vsaki spremembi spletne strani preverimo od zunaj in stanje zabeležimo v okviru utrjevanja strežnikov.

Pogosta vprašanja

Viri

• Apache: jedrne funkcije (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: varnostna obvestila