Nginx ja PHP-FPM turvamine

Lühidalt: Nginxi ja PHP-FPM-i puhul asub PHP2Shelli turvaauk PHP-FPM-is, mitte Nginxis. Paigake kõik PHP-FPM versioonid, käivitage iga FPM teenus täielikult uuesti ja tõendage seda protsesside käivitusaegadega. Nginx PHP-FPM turvalisuse jaoks pikas perspektiivis loevad eraldatud poolid, üle kirjutamatud väärtused ja Nginxi seadistus, mis ei käivita üleslaaditud faile.

Kuidas Nginx ja PHP-FPM koos töötavad

Nginx edastab staatilised failid ise ja annab päringud PHP skriptidele FastCGI kaudu edasi PHP-FPM-ile. PHP-FPM koosneb ühest master-protsessist ja mitmest tööprotsessist (worker), mis on rühmitatud poolidesse. Üks tööprotsess töötleb järjest palju päringuid.

Just see on PHP2Shelli jaoks oluline. Turvaaugu CVE-2026-109619 puhul võib päringu sisemine olek jääda pärast mälu vabastamist alles ja seda võib kasutada hilisem päring samas tööprotsessis. Turvaaugu CVE-2026-109618 puhul võib Out-of-Memory seisund katkestada PHP päringu lähtestamise keskel. Mõlemad turvaaugud on hinnatud CVSS v4.0 skaalal 9,2 ja parandatud versioonides PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35.

Kontrollige olemasolevat: versioonid, poolid, protsessid

Paljudel serveritel on paralleelselt mitu PHP-FPM versiooni. Järgmised käsud ainult loevad; paketi- ja teenusenimed on näited Debiani/Ubuntu ja RHEL-i perekonna jaoks.

# Millised FPM teenused töötavad?
systemctl list-units --type=service | grep -i fpm

# Milline versioon nende taga on? (näide Debian/Ubuntu)
php-fpm8.3 -v
# RHEL-i perekond
php-fpm -v

# Millistele soklitele või portidele Nginx edastab?
nginx -T 2>/dev/null | grep -E 'fastcgi_pass'

# Poolid ja nende kasutajad
grep -RhE '^\[|^user|^listen' /etc/php/*/fpm/pool.d/ 2>/dev/null

Võrrelge iga fastcgi_pass kirjet töötava pooliga. Nii näete, milline PHP versioon teenindab millist veebisaiti. Distributsioonipakettide puhul tõendab paika CVE-numbritega muudatuslogi, mitte ainult versiooninumber.

Selliste inventuuride sage leid on serverid, kuhu on aastate jooksul paigaldatud mitu PHP versiooni, millest tegelikult kasutatakse ainult ühte. Ülejäänud FPM teenused töötavad siiski edasi, sageli vaikepoolidega, mis kuulavad kohalikku sokklit või porti. Väljastpoolt ei ole need enamasti otse kättesaadavad, kuid jäävad tarbetuks riskiks ja pikendavad iga kiiret uuendust. Lülitage välja ja eemaldage versioonid, mida ükski veebisait ei kasuta, pärast seda kui olete seose fastcgi_pass kirjete kaudu üle kontrollinud.

Samuti tasub vaadata poolide kasutajat. Kui kõik poolid töötavad kasutajana www-data või nginx, on veebisaitide eraldatus ainult paberil. Kes võtab ühe veebisaidi üle, saab siis lugeda kõigi teiste faile, näiteks andmebaasiparoolidega seadistusfaile. Eraldi süsteemikasutajad iga pooli jaoks ja sobivad failiõigused loovad siin päris piiri. See ei ole PHP2Shelli vastane abinõu, kuid piirab eduka rünnaku võimalikku kahju märgatavalt.

Paigaldage paik ja uuendage kõik tööprotsessid

Pärast paketiuuendust käivitage iga PHP-FPM teenus uuesti. Reload asendab küll tööprotsessid, kuid täielik taaskäivitus uuendab ka master-protsessi ja on pärast turvauuendusi kindel tee.

# Näide Debian/Ubuntu, iga paigaldatud versiooni kohta
systemctl restart php8.3-fpm
# RHEL-i perekond
systemctl restart php-fpm

# Kontroll: master- ja tööprotsesside käivitusaeg
ps -eo pid,lstart,cmd | grep -E 'php-fpm' | grep -v grep

Iga protsess peab olema pärast uuendust käivitatud. Üksikasjalikult on seda kirjeldatud lehel PHP-FPM-i ja kõigi tööprotsesside taaskäivitus.

Seadke ajutised väärtused poolis

Kuni versioon pole paigatud, soovitab php.net ajutisi meetmeid. Need ei paku täielikku kaitset. PHP-FPM-is seadke väärtused poolis käskudega php_admin_value ja php_admin_flag, siis ei saa rakendused neid funktsiooniga ini_set() üle kirjutada.

; Näide: /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

Ilma üleslaadimisfunktsioonita nimetab php.net post_max_size = 8M. PHP 8.5 puhul lisandub fatal_error_backtraces=0. Märkuse memory_limit=-1 jaoks vajate mälupiirangut cgroupi tasemel, näiteks MemoryMax abil FPM teenuse systemd täiendusfailis. Kohandage Nginxis client_max_body_size uue post_max_size järgi, et kasutajad saaksid arusaadavad veateated. Seejärel käivitage FPM uuesti.

Parandage Nginx PHP-FPM turvalisust püsivalt

Lisaks ägedale juhtumile aitavad mõned põhireeglid piirata kahju tulevaste turvaaukude korral:

• Üks pool iga veebisaidi kohta oma süsteemikasutaja, oma sokli ja oma open_basedir piiriga. Rohkem lehel open_basedir ja eraldatus veebisaitide kaupa.
• Sokli õigused seadke nii, et ligi pääseb ainult Nginx, ärge avage FPM-i porte väljapoole.
• Käivitage ainult olemasolevaid skripte: seadke PHP location'is try_files $uri =404;, et Nginx ei annaks PHP-le edasi teekondi, mida pole olemas.
• Ärge käivitage üleslaadimisi: keelake üleslaadimiskataloogides PHP käivitamine. Näpunäiteid leiate lehelt Failide üleslaadimine turvaliselt.
• Kaitske olekulehti: muutke pm.status_path ja ping.path kättesaadavaks ainult seestpoolt.

# Näide: PHP käivitamine üleslaadimiskataloogis keelatud
location ~* ^/uploads/.*\.php$ {
    deny all;
}

Kontrollige iga muudatust käsuga nginx -t, enne kui Nginxi uuesti laete. Pidage lisaks arvet, millised poolid, versioonid ja erireeglid serveris on. See lühike dokumentatsioon säästab järgmise kriitilise turvaaugu korral väärtuslikku aega, sest keegi ei pea esmalt otsima, milline veebisait mis pooli külge kuulub.

Kuidas PHP SOS konkreetselt aitab?

• Seostame iga veebisaidi selle pooli ja PHP versiooniga ning kontrollime tegelikku paketi seisu.
• Paigame, käivitame kõik FPM teenused uuesti ja dokumenteerime protsesside käivitusajad tõendina.
• Kuni paigani seame ajutised väärtused poolide kaupa ja piirame mälu cgroupi kaudu.
• Serveri karastamise raames eraldame korralikult poolid, õigused ja üleslaadimiskataloogid.
• Sissemurdmise kahtluse korral võtame üle intsidendile reageerimise.

Korduma kippuvad küsimused

Allikad

• php.net: turvateated
• PHP 8 ChangeLog
• OWASP Cheat Sheets
• BSI