Lühidalt: Igal serveris olevaval veebisaidil peaks olema oma PHP-FPM pool oma süsteemikasutaja ja oma soklis. Eraldatus muutub tõhusaks aga alles üksikasjade abil: soklõigused ainult veebiserverile, security.limit_extensions väärtusele .php, ei mingeid avalikult kättesaadavaid olekulehti, oma piirid protsessidele ja tööajale ning eraldatud logid. PHP2Shelli enda eest kaitseb ainult uuendus; poolid piiravad, kui kaugele rünnak ulatub.
Üks server, palju veebisaite, ühine risk
Paljudes serverites on aastatega kasvanud see, mida keegi niimoodi ei planeerinud. Ettevõtte veebisait, pood, 2019. aasta kampaanialeht ja testsüsteem töötavad kõrvuti, sageli sama kasutaja all ja samas poolis. Kui unustatud kampaanialeht kompromiteeritakse, on lahti ka poe klientide andmed.
PHP-FPM, PHP FastCGI protsessihaldur, lahendab selle poolidega: töölisprotsesside rühmad oma sätetega. Kuidas põhimõte töötab, selgitab PHP-FPM selgitus: protsessihaldur, poolid ja töölised. Eraldatud poolide ülesehitust oma kasutaja, oma ajutise kausta ja open_basedir-iga kirjeldab juhend open_basedir ja eraldatus veebisaitide kaupa. See artikkel läheb sammu kaugemale: kuidas kontrollite olemasolevaid poole ja millised sätted muudavad eraldatuse töökindlaks?
Oluline paigutus: PHP2Shelli puhul asuvad augud CVE-2026-109618 ja CVE-2026-109619 PHP interpretaatoris, mida kõik ühe PHP versiooni poolid jagavad. Oma pool ei takista ärakasutamist. Küll aga otsustab see, kas ründaja pärast jõuab ühe veebisaidini või kõigini.
PHP-FPM poolid oma kasutajaga: olemasoleva kontroll
Enne kui midagi muudate, hankige ülevaade. Järgmised käsud ainult loevad. Teed ja versiooninumbrid erinevad distributsiooniti:
# Kõik poolid koos kasutaja ja soklitega
grep -HE '^\s*(\[|user|group|listen)\s*' /etc/php/*/fpm/pool.d/*.conf
# Töötavad poolid ja nende kasutajad
ps -eo user,pid,cmd | grep '[p]hp-fpm: pool'
# Soklid ja nende õigused
ls -l /run/php/
# Kontrollige konfiguratsiooni vigade suhtes (ei muuda midagi)
sudo php-fpm8.3 -t
Pöörake tähelepanu kolmele mustrile: mitu veebisaiti samas poolis, poolid, mis töötavad kasutajana www-data või isegi root, ja soklid, millele saavad kõik kasutajad kirjutada. Iga neist õõnestab eraldatust.
Kui serveris töötab mitu PHP versiooni, on igaühel oma FPM-teenus oma poolikataloogidega. Kontrollige kõiki, mitte ainult versiooni, mille viimati seadistasite. Just vanad versioonid unustatud poolidega on risk, sest neid ei hooldata ega taaskäivitata sageli pärast uuendusi. Vihjeid leiate artiklist Mitu PHP versiooni ühes serveris. Märkige tulemus väikesesse tabelisse: veebisait, pool, kasutaja, sokkel, PHP versioon. See ülevaade on samas iga hilisema muudatuse alus.
Olulisemad sätted poolide kaupa
Järgmine ülevaade tugineb PHP käsiraamatu FPM-i konfiguratsioonile. Protsesside ja aegade väärtused sõltuvad teie koormusest ja rakendusest:
| Säte | Eesmärk | Soovitus |
|---|---|---|
user, group |
töölisprotsesside kasutaja | oma kasutaja iga veebisaidi jaoks, mitte kunagi root |
listen.owner, listen.group, listen.mode |
soklõigused | ainult veebiserveri rühm, režiim 0660 |
listen.acl_users |
ligipääs ACL-i kaudu omaniku asemel | kandke sisse ainult veebiserveri kasutaja |
security.limit_extensions |
käivitatavad laiendid | piirake laiendiga .php (vaikimisi .php .phar) |
clear_env |
keskkonnamuutujate tühjendamine | jätke vaikeväärtusele yes |
pm.max_children |
töölisprotsesside ülemmäär | piirake nii, et üks veebisait serverit täis ei koorma |
request_terminate_timeout |
rippuvate päringute katkestamine | seadke pikima legitiimse päringu järgi |
pm.status_path, ping.path |
olekuleht ja pingileht | seadke ainult vajaduse korral ja kaitske seestpoolt |
slowlog, request_slowlog_timeout |
aeglaste päringute logi | poolide kaupa eraldi faili |
Karastatud pooli väljavõte näeb välja nii:
; /etc/php/8.3/fpm/pool.d/shop.conf (väljavõte)
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
request_terminate_timeout = 60s
security.limit_extensions = .php
clear_env = yes
slowlog = /var/log/php/shop.slow.log
request_slowlog_timeout = 10s
php_admin_value[error_log] = /var/log/php/shop.error.log
Sätteid nagu memory_limit või session.upload_progress.enabled seate poolide kaupa käskudega php_admin_value ja php_admin_flag. Käsiraamatu järgi ei saa neid väärtusi ini_set() abil üle kirjutada. Rohkem artiklis php_admin_value: sätete kaitsmine ülekirjutamise eest.
Olekulehed ja töölise vahetus õigesti paigutatud
pm.status_path ja ping.path on aktiivsed ainult siis, kui need on seatud. Olekuleht näitab töötavaid päringuid, protsesse ja koormust. Seire jaoks on see kasulik, avalikult kättesaadavana aga tarbetu infoallikas ründajatele. Suunake need teed veebiserveris edasi ainult sisemistele aadressidele. Kuidas Nginx ja PHP-FPM turvaliselt koos töötavad, kirjeldab Nginxi ja PHP-FPM-i turvamine.
pm.max_requests määrab, mitme päringu järel töölisprotsess taaskäivitub; vaikimisi on 0, see tähendab mitte kunagi. Nullist suurem väärtus aitab aeglaselt kasvava mälukasutuse vastu. Kaitsena PHP2Shelli vastu see mõeldud ei ole: php.net ei nimeta seda üleminekumeetmete hulgas ja rõhutab, et täielikult kaitseb ainult uuendus. Pärast uuendust kehtib lisaks: kõik kõigi poolide töölised tuleb taaskäivitada, sest vanad protsessid töötavad muidu haavatava koodiga edasi.
Hoidke uute poolide jaoks mall ja looge iga uus veebisait sellega. Nii tekib eraldatus automaatselt, mitte ei paigaldata seda aastaid hiljem tagantjärele.
Tüüpilised vead üleminekul
Sagedaseim viga on uus pool, mis töötab küll oma kasutaja all, kuid mille failid kuuluvad endiselt kasutajale www-data. Siis ei tohi pool kirjutada sinna, kus peab, ja keegi seab õigused liiga heldeks. Selgitage enne, millised kaustad peavad olema kirjutatavad. Teine viga on ajastatud ülesanded, mis töötavad edasi vana kasutaja all ja loovad valet omanikuga faile. Kolmas on kõigi poolide ühine sessioonikaust, mis eraldatuse taas tühistab.
Testige pärast iga ümberlülitust veebisaidi sisselogimist, üleslaadimisi, vahemälusid ja ajastatud ülesandeid ning jälgige poolide vealogi.
Kuidas PHP SOS konkreetselt aitab?
- Kaardistame kõik poolid, kasutajad, soklid ja sätted ning näitame, kus veebisaidid täna protsesse või õigusi jagavad.
- Seadistame iga veebisaidi jaoks karastatud pooli, koos soklõiguste, laienditepiiri, ressursipiiride ja oma logidega.
- Kaitseme olekulehed, taaskäivitame kõik töölised kontrollitult ja testime iga veebisaiti.
- Serveri karastamise raames dokumenteerime eraldatuse mallina tulevaste projektide jaoks.
Korduma kippuvad küsimused
Miks peaks igal veebisaidil olema oma PHP-FPM pool?
Oma pool oma süsteemikasutajaga eraldab veebisaidid protsesside ja failiõiguste tasandil. Kui üks veebisait kompromiteeritakse, ei saa kood ilma lisatoiminguteta teiste faile lugeda. Lisaks saab piire ja sätteid määrata veebisaitide kaupa eraldi.
Kas oma pool kaitseb PHP2Shelli eest?
Ei. Augud asuvad PHP interpretaatoris endas, mida kõik poolid jagavad. Kaitse annab ainult uuendus parandatud versioonile koos kõigi töölisprotsesside taaskäivitamisega. Eraldatud poolid piiravad aga seda, kui kaugele eduka rünnaku mõju ulatub.
Mida security.limit_extensions teeb?
PHP käsiraamatu järgi piirab säte, milliseid faililaiendeid PHP-FPM põhiskriptina käivitab. Vaikimisi on .php ja .phar. Kes piirab selle laiendiga .php, takistab näiteks üleslaaditud pildifailide käivitamist PHP-na juhuks, kui veebiserver on valesti seadistatud.
Kas PHP-FPM olekuleht on ohtlik?
See reedab üksikasju töötavate protsesside ja päringute kohta. Kui see on kaitseta avalikult kättesaadav, hõlbustab see ründajatel orienteerumist. Käsiraamatu järgi on see aktiivne ainult siis, kui pm.status_path on seatud. Siis peaks veebiserver piirama tee sisemiste aadressidega.