Nginx ar PHP-FPM aizsardzība

Īsi: Nginx ar PHP-FPM gadījumā PHP2Shell ievainojamība atrodas PHP-FPM, nevis Nginx. Ielāpojiet visas PHP-FPM versijas, pilnībā pārstartējiet katru FPM pakalpojumu un to pierādiet ar procesu startēšanas laiku. Ilgtermiņa Nginx PHP-FPM drošībai svarīgi ir atsevišķi pūli, nepārrakstāmas vērtības un Nginx konfigurācija, kas neizpilda augšupielādētus failus.

Kā sadarbojas Nginx un PHP-FPM

Nginx statiskos failus piegādā pats un pieprasījumus PHP skriptiem caur FastCGI nodod PHP-FPM. PHP-FPM sastāv no galvenā procesa un vairākiem darbprocesiem, sagrupētiem pūlos. Viens darbprocess pēc kārtas apstrādā daudzus pieprasījumus.

Tieši tas ir svarīgi PHP2Shell gadījumā. CVE-2026-109619 gadījumā pieprasījuma iekšējais stāvoklis pēc atmiņas atbrīvošanas var saglabāties un to var izmantot vēlāks pieprasījums tajā pašā darbprocesā. CVE-2026-109618 gadījumā out-of-memory stāvoklis var pārtraukt PHP pieprasījuma inicializācijas vidū. Abas ievainojamības novērtētas ar CVSS v4.0 9.2 un labotas PHP 8.5.12, 8.4.27, 8.3.36 un 8.2.35.

Pārbaudiet esošo: versijas, pūli, procesi

Daudziem serveriem paralēli ir vairākas PHP-FPM versijas. Turpmākās komandas tikai lasa; pakotņu un pakalpojumu nosaukumi ir piemēri Debian/Ubuntu un RHEL saimei.

# Kuri FPM pakalpojumi darbojas?
systemctl list-units --type=service | grep -i fpm

# Kura versija ir aiz tiem? (piemērs Debian/Ubuntu)
php-fpm8.3 -v
# RHEL saime
php-fpm -v

# Uz kuriem sockets vai portiem Nginx pārsūta pieprasījumus?
nginx -T 2>/dev/null | grep -E 'fastcgi_pass'

# Pūli un to lietotāji
grep -RhE '^\[|^user|^listen' /etc/php/*/fpm/pool.d/ 2>/dev/null

Salīdziniet katru fastcgi_pass ierakstu ar darbojošos pūlu. Tā redzēsiet, kura PHP versija apkalpo kuru vietni. Distributīvu pakotņu gadījumā ielāpu apliecina izmaiņu žurnāls ar CVE numuriem, nevis tikai versijas numurs.

Bieži sastopams atradums šādās inventarizācijās ir serveri, kuros gadu gaitā instalētas vairākas PHP versijas, no kurām patiešām lietota tikai viena. Pārējie FPM pakalpojumi tomēr turpina darboties, bieži ar noklusējuma pūliem, kas klausās lokālā socketā vai portā. No ārpuses tie parasti nav tieši sasniedzami, taču paliek nevajadzīgs risks un pagarina katru ārkārtas atjaunināšanu. Atspējojiet un noņemiet versijas, ko neizmanto neviena vietne, kad esat pārbaudījis piesaisti pēc fastcgi_pass ierakstiem.

Tāpat vērts apskatīt pūlu lietotāju. Ja visi pūli darbojas kā www-data vai nginx, nošķīrums starp vietnēm pastāv tikai uz papīra. Kas pārņem vienu vietni, var lasīt visu pārējo failus, piemēram, konfigurācijas failus ar datubāzes parolēm. Atsevišķi sistēmas lietotāji katram pūlam un atbilstošas failu tiesības rada īstu robežu. Tas nav PHP2Shell risinājums, taču būtiski ierobežo veiksmīga uzbrukuma iespējamo kaitējumu.

Ielāpa ieinstalēšana un visu darbprocesu atjaunošana

Pēc pakotņu atjauninājuma pārstartējiet katru PHP-FPM pakalpojumu. Reload gan aizstāj darbprocesus, bet pilnīga pārstartēšana atjauno arī galveno procesu un pēc drošības atjauninājumiem ir drošais ceļš.

# Piemērs Debian/Ubuntu, katrai instalētajai versijai
systemctl restart php8.3-fpm
# RHEL saime
systemctl restart php-fpm

# Kontrole: galvenā procesa un darbprocesu startēšanas laiks
ps -eo pid,lstart,cmd | grep -E 'php-fpm' | grep -v grep

Katram procesam jābūt startētam pēc atjauninājuma. Detalizēti tas aprakstīts lapā PHP-FPM un visu darbprocesu pārstartēšana.

Pagaidu vērtību iestatīšana pūlā

Kamēr versija nav ielāpota, php.net iesaka pagaidu pasākumus. Tie nesniedz pilnīgu aizsardzību. PHP-FPM vērtības iestatiet ar php_admin_value vai php_admin_flag pūlā, tad lietojumprogrammas tās ar ini_set() nevar pārrakstīt.

; Piemērs: /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

Ja augšupielādes funkcijas nav, php.net min post_max_size = 8M. PHP 8.5 gadījumā klāt nāk fatal_error_backtraces=0. Norādei par memory_limit=-1 nepieciešams atmiņas ierobežojums cgroup līmenī, piemēram, ar MemoryMax systemd papildinājumā FPM pakalpojumam. Nginx pielāgojiet client_max_body_size jaunajam post_max_size, lai lietotāji saņemtu saprotamus kļūdu paziņojumus. Pēc tam FPM pārstartējiet.

Nginx PHP-FPM drošības ilgtermiņa uzlabošana

Aiz akūtā gadījuma palīdz vairāki pamatnoteikumi, kas nākotnes ievainojamību gadījumos ierobežo kaitējumu:

• Viens pūls katrai vietnei ar savu sistēmas lietotāju, savu socketu un savu open_basedir robežu. Vairāk lapā open_basedir un izolācija katrai vietnei.
• Socket tiesības iestatīt tā, lai piekļūt var tikai Nginx, FPM portus uz āru neatvērt.
• Izpildīt tikai esošus skriptus: PHP location iestatīt try_files $uri =404;, lai Nginx PHP nenodod ceļus, kuru nav.
• Augšupielādes neizpildīt: augšupielāžu direktorijos aizliegt PHP izpildi. Norādes par to atrodamas lapā Failu augšupielāžu drošs ieviešums.
• Aizsargāt statusa lapas: pm.status_path un ping.path padarīt sasniedzamus tikai iekšēji.

# Piemērs: nekādas PHP izpildes augšupielāžu direktorijā
location ~* ^/uploads/.*\.php$ {
    deny all;
}

Katru izmaiņu pārbaudiet ar nginx -t, pirms pārlādējat Nginx. Turklāt fiksējiet, kādi pūli, versijas un īpašie noteikumi serverī pastāv. Šī īsā dokumentācija nākamās kritiskās ievainojamības laikā ietaupa vērtīgu laiku, jo nevienam nav vispirms jāmeklē, kura vietne pie kura pūla pieder.

Kā PHP SOS palīdz konkrēti?

• Mēs katru vietni piesaistām tās pūlam un PHP versijai un pārbaudām faktisko pakotņu stāvokli.
• Mēs ielāpojam, pārstartējam visus FPM pakalpojumus un dokumentējam procesu startēšanas laikus kā pierādījumu.
• Līdz ielāpam mēs pagaidu vērtības iestatām katram pūlam un ierobežojam atmiņu ar cgroup.
• Savas servera nostiprināšanas ietvaros mēs sakārtoti nošķiram pūlus, tiesības un augšupielāžu direktorijus.
• Aizdomu par ielaušanos gadījumā mēs uzņemamies Incident Response.

Biežāk uzdotie jautājumi

Avoti

• php.net: drošības paziņojumi
• PHP 8 ChangeLog
• OWASP Cheat Sheets
• BSI (Vācijas Federālā informācijas drošības birojs)