Aktuálna situácia: PHP2Shell. Dve kritické zraniteľnosti PHP (CVSS 9.2) umožňujú spustenie škodlivého kódu bez prihlásenia. Záplaty od 21. 10. 2026.Čo treba urobiť teraz →

Bezpečná konfigurácia Apache pre PHP

Apache je flexibilný a práve to ho robí náchylným na chybnú konfiguráciu. Takto napojíte PHP cez PHP-FPM, uzavriete .htaccess ako zadné vrátko a bezpečne nastavíte najdôležitejšie jadrové voľby.

Stav 5 min čítaniaHardening a konfigurácia

Stručne: Ak chcete Apache pre PHP bezpečne nakonfigurovať, napojte PHP cez PHP-FPM a mod_proxy_fcgi, vypnite .htaccess pomocou AllowOverride None a nastavte ServerTokens Prod, ServerSignature Off, TraceEnable Off a Options -Indexes. LimitRequestBody prispôsobte hraniciam PHP, nepotrebné moduly vypnite. Konfigurácia nenahrádza aktualizáciu PHP, výrazne však zmenšuje útočnú plochu.

Apache po PHP2Shell: viac než reštart

Prevádzkovatelia Apache boli v októbri 2026 pod zvláštnym tlakom. Tím PHP hodnotí riziko pri mod_php ako najvyššie, pretože tam bolo zneužitie predvedené ešte predtým, než vôbec beží kód aplikácie. Akútne kroky, teda záplatovanie a úplný reštart, opisuje stránka Prečo mod_php nesie najvyššie riziko.

Po záplate zostáva otázka, aká dobrá je samotná konfigurácia Apache. Narastené servery často nesú nastavenia z mnohých rokov: zoznamy adresárov, otvorené práva .htaccess, moduly, ktoré už nikto nepotrebuje. Každé z nich môže neskoršiu chybu zväčšiť viac, než by bolo nutné.

Tento príspevok opisuje štíhlu, bezpečnú základnú konfiguráciu pre Apache 2.4 s PHP-FPM. Príklady používajú cesty Debian a Ubuntu; v rodine RHEL ležia súbory pod /etc/httpd/.

Napojenie PHP cez PHP-FPM namiesto mod_php

S PHP-FPM beží PHP vo vlastných procesoch, oddelene od webového servera. Apache odovzdáva požiadavky cez mod_proxy_fcgi. Podľa dokumentácie Apache má napojenie cez SetHandler oproti ProxyPassMatch výhodu: Apache najprv sám priradí požiadavku súboru v súborovom systéme a až potom ju odovzdá PHP-FPM.

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

Moduly aktivujete pod Debian a Ubuntu pomocou a2enmod proxy_fcgi. Kto prechádza z mod_php, deaktivuje modul PHP a následne prejde z MPM Prefork na MPM Event. Súvislosti k starému spôsobu prevádzky vysvetľuje mod_php vysvetlený: PHP v procese Apache.

Na strane PHP-FPM patrí security.limit_extensions = .php do každého poolu. Podľa príručky PHP FPM inak vykonáva aj súbory .phar.

Apache bezpečne nakonfigurovať pre PHP: jadrové voľby

Niektoré nastavenia platia pre celý server a patria do samostatného konfiguračného súboru, napríklad /etc/apache2/conf-available/haertung.conf, aktivovaného pomocou a2enconf haertung.

# Skrátiť údaje o verzii (možné len na úrovni celého servera)
ServerTokens Prod
ServerSignature Off

# Vypnúť metódu TRACE
TraceEnable Off

# Zásadne nič neuvoľňovať, weby povoľovať cielene
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Nasledujúca tabuľka zaraďuje najdôležitejšie voľby. Štandardné hodnoty a účinok pochádzajú z dokumentácie Apache.

Direktíva Štandard Odporúčanie Prečo
ServerTokens Full Prod hlavička Server uvádza len „Apache“
ServerSignature Off Off žiadny riadok s verziou pod chybovými stránkami
TraceEnable on Off TRACE sa odmieta s 405
Options FollowSymlinks -Indexes, symlinky len podľa vlastníka žiadne zoznamy adresárov
AllowOverride None None .htaccess sa nevyhodnocuje
LimitRequestBody 1 GiB (od 2.4.54) zodpovedajúce post_max_size veľké požiadavky odmietať včas

Dôležité pri AllowOverride: mnohé distribúcie a návody k CMS nastavujú pre webový koreň AllowOverride All. Tým môže každý súbor .htaccess meniť pravidlá prepisovania, handlery a pri mod_php dokonca nastavenia PHP. Útočník s právami zápisu v priečinku s uploadmi tam môže uložiť vlastný .htaccess. S AllowOverride None je táto cesta uzavretá.

VirtualHost ako šablóna

Nasledujúci VirtualHost spája body pre jeden web. Cesty k certifikátom, socket a adresáre si prispôsobte. mod_ssl a mod_headers musia byť aktívne.

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

    # Zablokovať správu verzií a súbory prostredia
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, zodpovedá post_max_size = 32M
    LimitRequestBody 33554432

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

Dvojité Header unset nie je omyl. Podľa dokumentácie Apache pristanú hlavičky z mod_proxy_fcgi v inej internej tabuľke než hlavičky samotného servera; pomocou oboch variantov zachytíte oba prípady. Ďalšie hlavičky, ktoré aktívne chránia návštevníkov, opisuje sprievodca Bezpečnostné hlavičky pre webové stránky.

Priečinky s uploadmi a cache navyše potrebujú zákaz vykonávania. Ako nájdete a zablokujete všetky zapisovateľné priečinky, uvádza Zákaz vykonávania PHP v priečinkoch s uploadmi.

Vyradiť moduly a overiť výsledok

Každý načítaný modul je kód, ktorý reaguje na požiadavky. Skontrolujte, ktoré moduly sú aktívne, a vypnite to, čo nepotrebujete. Typickí kandidáti sú autoindex, status bez obmedzenia prístupu, cgi a userdir.

# Zobraziť aktívne moduly
apachectl -M | sort
# Príklad Debian/Ubuntu: vypnúť modul zoznamov adresárov
sudo a2dismod autoindex
# Skontrolovať konfiguráciu a až potom znova načítať
sudo apachectl configtest && sudo systemctl reload apache2
# Test zvonka: TRACE má vrátiť 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

Osobitnú pozornosť si zaslúži mod_status. Stavová stránka ukazuje bežiace požiadavky s adresami a otváranými cestami. Ak ju potrebujete, obmedzte prístup pomocou Require ip na vaše správcovské siete. To isté platí pre stavové stránky PHP-FPM, ktoré sa sprístupnili cez Apache.

Dôležité

AllowOverride neprestavujte bez prípravy. Najprv prevezmite pravidlá zo všetkých súborov .htaccess do VirtualHost a web otestujte na kópii. Inak po opätovnom načítaní prestanú fungovať presmerovania a pekné adresy URL.

Ako dodatočná vrstva pred aplikáciou môže byť zmysluplná vlastná Web Application Firewall; úvod opisuje Nasadenie ModSecurity a OWASP Core Rule Set.

Záver: poriadok prekonáva jednotlivé opatrenie

Bezpečná konfigurácia Apache pre PHP pozostáva z niekoľkých dobre pochopených stavebných prvkov. PHP beží cez PHP-FPM oddelene od webového servera, .htaccess sa nevyhodnocuje, údaje o verzii a TRACE sú vypnuté, limity veľkosti zodpovedajú PHP a zapisovateľné priečinky nevykonávajú skripty. Žiadny z týchto bodov nie je sám osebe pôsobivý. Spolu zabezpečujú, že chyba na jednom mieste nevedie okamžite k prevzatiu servera.

Pre vedenie spoločnosti a zodpovedných za projekty je takmer dôležitejšia druhá vlastnosť: upratanú konfiguráciu možno sledovať. Ak sú všetky pravidlá vo VirtualHost namiesto roztrúsených v desiatkach súborov .htaccess, pri najbližšej kritickej zraniteľnosti sa dá rýchlo skontrolovať, ktorý web je ako napojený. V situácii ako v októbri 2026 to ušetrí práve ten čas, na ktorom záleží.

Prechod napriek tomu plánujte v pokoji a s testovacím prostredím. Unáhlená zmena z mod_php na PHP-FPM tesne pred víkendom skôr vytvára nové problémy, než ich rieši.

Ako konkrétne pomáha PHP SOS?

  • Preveriť stav: prečítame celú konfiguráciu Apache, všetky aktívne moduly a všetky súbory .htaccess.
  • Naplánovať prechod: kde ešte beží mod_php, pripravíme prechod na PHP-FPM s vlastnými poolmi pre každý web.
  • Sprísniť konfiguráciu: nastavíme jadrové voľby, pravidlá .htaccess prevezmeme do VirtualHost a zablokujeme zapisovateľné priečinky.
  • Testovať a dokumentovať: po každej zmene weby preveríme zvonka a stav zaznamenáme v rámci sprísnenia servera.

Časté otázky

Mal by som ešte používať mod_php?

Pre nové inštalácie odporúčame PHP-FPM cez mod_proxy_fcgi. Tím PHP hodnotí riziko PHP2Shell pri mod_php ako najvyššie. S PHP-FPM beží PHP oddelene od webového servera, s vlastnými používateľmi pre každý web a vlastnými hranicami.

Prečo AllowOverride None, ak moje CMS potrebuje .htaccess?

Súbor .htaccess môže vytvoriť každý, kto smie zapisovať vo webovom koreni, aj votknutý kód. S AllowOverride None Apache takéto súbory nevyhodnocuje. Pravidlá vášho CMS potom jednorazovo prevezmete do VirtualHost. Je to trochu námahy, konfigurácia sa však stane zrozumiteľnou a rýchlejšou.

Môžem ServerTokens nastaviť pre každý web inak?

Nie. Podľa dokumentácie Apache platí ServerTokens pre celý server a nedá sa meniť pre každý VirtualHost. Zároveň riadi údaj o verzii pod chybovými stránkami, ktorý zobrazuje ServerSignature.

Akú štandardnú hodnotu má LimitRequestBody?

Od Apache 2.4.54 je štandard 1 GiB, vo verzii 2.4.53 a staršej bol neobmedzený. Hodnotu nastavte podľa post_max_size vo vašej konfigurácii PHP, aby sa príliš veľké požiadavky odmietli už vo webovom serveri.

Zdroje

Okamžitý kontakt

Každá hodina sa počíta. Napíšte nám hneď.

Stručne opíšte systém, verziu PHP a svoje pozorovanie. Ozveme sa, vyjasníme situáciu a budeme pracovať na diaľku, kým nebude incident uzavretý a zdokumentovaný.

Okamžitá pomoc