Zabezpečenie Nginx s PHP-FPM

Stručne: Pri Nginx s PHP-FPM je zraniteľnosť z PHP2Shell v PHP-FPM, nie v Nginx. Zaplátajte všetky verzie PHP-FPM, úplne reštartujte každú službu FPM a preukážte to časmi spustenia procesov. Pre dlhodobú bezpečnosť Nginx a PHP-FPM sa počítajú samostatné pooly, hodnoty, ktoré sa nedajú prepísať, a konfigurácia Nginx, ktorá nespúšťa nahrané súbory.

Ako spolupracujú Nginx a PHP-FPM

Nginx statické súbory doručuje sám a požiadavky na skripty PHP odovzdáva cez FastCGI do PHP-FPM. PHP-FPM pozostáva z hlavného procesu a viacerých procesov workerov, zoskupených do poolov. Jeden worker spracúva postupne mnoho požiadaviek.

Práve to je pre PHP2Shell relevantné. Pri CVE-2026-109619 môže vnútorný stav požiadavky po uvoľnení pamäte zostať zachovaný a použiť ho neskorší požiadavok v tom istom workeri. Pri CVE-2026-109618 môže stav Out of Memory prerušiť PHP uprostred inicializácie požiadavky. Obe zraniteľnosti majú hodnotenie CVSS v4.0 9.2 a sú opravené vo verziách PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35.

Kontrola stavu: verzie, pooly, procesy

Mnohé servery majú paralelne viac verzií PHP-FPM. Nasledujúce príkazy iba čítajú; názvy balíkov a služieb sú príkladmi pre Debian/Ubuntu a rodinu RHEL.

# Ktoré služby FPM bežia?
systemctl list-units --type=service | grep -i fpm

# Aká verzia za tým stojí? (príklad Debian/Ubuntu)
php-fpm8.3 -v
# Rodina RHEL
php-fpm -v

# Na aké sockety alebo porty Nginx odovzdáva?
nginx -T 2>/dev/null | grep -E 'fastcgi_pass'

# Pooly a ich používatelia
grep -RhE '^\[|^user|^listen' /etc/php/*/fpm/pool.d/ 2>/dev/null

Porovnajte každý záznam fastcgi_pass s bežiacim poolom. Takto uvidíte, ktorá verzia PHP obsluhuje ktorý web. Pri balíkoch distribúcie záplatu dokladá changelog s číslami CVE, nie samotné číslo verzie.

Častým nálezom pri takýchto inventúrach sú servery, na ktorých sa v priebehu rokov nainštalovalo viac verzií PHP, z ktorých sa skutočne používa len jedna. Ostatné služby FPM bežia aj tak ďalej, často so štandardnými poolmi počúvajúcimi na lokálnom sockete alebo porte. Zvonka bývajú spravidla priamo nedostupné, ale zostávajú zbytočným rizikom a predlžujú každú núdzovú aktualizáciu. Verzie, ktoré nepoužíva žiadny web, vypnite a odstráňte po tom, ako ste priradenie overili podľa záznamov fastcgi_pass.

Rovnako sa oplatí pozrieť sa na používateľa poolov. Ak všetky pooly bežia ako www-data alebo nginx, oddelenie medzi webmi existuje len na papieri. Kto prevezme jeden web, môže potom čítať súbory všetkých ostatných, napríklad konfiguračné súbory s heslami k databáze. Vlastní systémoví používatelia pre každý pool a vhodné práva k súborom tu vytvoria skutočnú hranicu. Nejde o nápravu PHP2Shell, ale výrazne to obmedzuje možnú škodu úspešného útoku.

Nasaďte záplatu a obnovte všetkých workerov

Po aktualizácii balíkov reštartujte každú službu PHP-FPM. Reload síce nahradí workerov, ale úplný reštart obnoví aj hlavný proces a po bezpečnostných aktualizáciách je bezpečnou cestou.

# Príklad Debian/Ubuntu, pre každú nainštalovanú verziu
systemctl restart php8.3-fpm
# Rodina RHEL
systemctl restart php-fpm

# Kontrola: čas spustenia hlavného procesu a workerov
ps -eo pid,lstart,cmd | grep -E 'php-fpm' | grep -v grep

Každý proces musí byť spustený po aktualizácii. Podrobne to opisuje stránka Reštart PHP-FPM a všetkých workerov.

Nastavte prechodné hodnoty v poole

Kým verzia nie je zaplátaná, php.net odporúča prechodné opatrenia. Neposkytujú úplnú ochranu. V PHP-FPM nastavte hodnoty pomocou php_admin_value, resp. php_admin_flag v poole, aplikácie ich potom cez ini_set() nemôžu prepísať.

; Príklad: /etc/php/8.3/fpm/pool.d/website.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M

Bez funkcie nahrávania php.net uvádza post_max_size = 8M. Pri PHP 8.5 pribúda fatal_error_backtraces=0. Pre upozornenie k memory_limit=-1 potrebujete obmedzenie pamäte na úrovni cgroup, napríklad cez MemoryMax v doplnku systemd pre službu FPM. V Nginx prispôsobte client_max_body_size novej hodnote post_max_size, aby používatelia dostali zrozumiteľné chybové hlásenia. Potom FPM reštartujte.

Trvalo zlepšite bezpečnosť Nginx a PHP-FPM

Nad rámec akútneho prípadu pomáha niekoľko základných pravidiel, ktoré pri budúcich zraniteľnostiach obmedzia škodu:

• Jeden pool pre každý web s vlastným systémovým používateľom, vlastným socketom a vlastnou hranicou open_basedir. Viac na stránke open_basedir a izolácia pre každý web.
• Práva k socketom nastavte tak, aby mal prístup iba Nginx, nikdy neotvárajte porty FPM smerom von.
• Spúšťajte len existujúce skripty: v location pre PHP nastavte try_files $uri =404;, aby Nginx neodovzdával PHP cesty, ktoré neexistujú.
• Nespúšťajte nahrané súbory: v adresároch na nahrávanie zakážte spúšťanie PHP. Upozornenia k tomu nájdete na stránke Bezpečná implementácia nahrávania súborov.
• Chráňte stavové stránky: pm.status_path a ping.path sprístupnite iba interne.

# Príklad: žiadne spúšťanie PHP v adresári na nahrávanie
location ~* ^/uploads/.*\.php$ {
    deny all;
}

Každú zmenu skontrolujte pomocou nginx -t, skôr než Nginx znova načítate. Zaznamenajte si aj to, aké pooly, verzie a osobitné pravidlá na serveri existujú. Táto krátka dokumentácia ušetrí pri ďalšej kritickej zraniteľnosti cenný čas, pretože nikto nemusí najprv hľadať, ktorý web patrí ku ktorému poolu.

Ako konkrétne pomáha PHP SOS?

• Priradíme každý web jeho poolu a verzii PHP a skontrolujeme skutočný stav balíkov.
• Záplatujeme, reštartujeme všetky služby FPM a ako dôkaz zdokumentujeme časy spustenia procesov.
• Do vydania záplaty nastavíme prechodné hodnoty pre každý pool a obmedzíme pamäť cez cgroup.
• V rámci spevnenia servera (hardening) čisto oddelíme pooly, práva a adresáre na nahrávanie.
• Pri podozrení na vlámanie preberáme reakciu na incident (Incident Response).

Časté otázky

Zdroje

• php.net: bezpečnostné hlásenia
• PHP 8 ChangeLog
• OWASP Cheat Sheets
• BSI