Apache su mod_php apsauga

Trumpai: Su Apache ir mod_php PHP veikia tiesiogiai žiniatinklio serveryje. PHP komanda rizika dėl PHP2Shell būtent šiame veikimo režime vertina didžiausia, nes exploit buvo parodytas dar prieš pradedant vykdyti programos kodą. Pataisykite nedelsdami, visiškai paleiskite Apache iš naujo ir po to suplanuokite perėjimą prie PHP-FPM.

Kas yra mod_php ir kodėl dabar tai svarbu

Naudojant mod_php, Apache įkelia PHP kaip modulį į kiekvieną savo darbinį procesą. Kiekviena užklausa PHP failui vykdoma tiesiogiai tame procese. Ilgai tai buvo standartas ir tai paprasta nustatyti. Tačiau tai reiškia ir kad visos serverio svetainės veikia su tuo pačiu naudotoju, o PHP dalijasi procesu su žiniatinklio serveriu.

PHP2Shell apima pažeidžiamumus CVE-2026-109618 ir CVE-2026-109619, abu su CVSS v4.0 9,2. Antruoju atveju vidinė užklausos būsena po atminties atlaisvinimo gali išlikti ir būti panaudota vėlesnės užklausos tame pačiame procese. mod_php atveju PHP komanda nustatė didžiausią riziką. Pagrindą ir vertinimą rasite puslapyje Kodėl mod_php kelia didžiausią riziką.

Apache mod_php atpažinimas ir versijos patikra

Pirmiausia patikrinkite, ar jūsų Apache apskritai naudoja mod_php. Toliau pateiktos komandos tik skaito. Komandų ir paketų pavadinimai skiriasi priklausomai nuo distribucijos ir yra pavyzdžiai.

# Debian/Ubuntu: įkelti moduliai
apache2ctl -M 2>/dev/null | grep -i php

# RHEL šeima
httpd -M 2>/dev/null | grep -i php

# Koks MPM aktyvus? mod_php reikalauja prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Modulio paketo būsena (pavyzdžiai)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

Jei rodomas modulis, pavyzdžiui, php_module, veikia mod_php. Vien rodoma PHP versija nėra pataisos įrodymas, nes distribucijos pataisymus dažnai įdiegia kaip backport. PHP projekto ištaisytos versijos yra 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. Distribucijų paketų atveju lemia pakeitimų žurnalas su CVE numeriais.

Pataisykite ir visiškai paleiskite Apache iš naujo

Atnaujinimą įdiekite per paketų tvarkyklę. Kadangi PHP yra Apache procese, po to reikia iš naujo paleisti visą tarnybą. Konfigūracijos perkrovimas čia nėra saugus kelias.

# Debian/Ubuntu
systemctl restart apache2

# RHEL šeima
systemctl restart httpd

# Kontrolė: visų Apache procesų paleidimo laikas
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Visų Apache procesų paleidimo laikas turi būti vėlesnis nei atnaujinimas. Jei tame pačiame serveryje papildomai veikia PHP-FPM ar php-cgi, iš naujo paleiskite ir jas.

Pereinamosios priemonės Apache konfigūracijoje

php.net nurodo pereinamąsias priemones, kurios mažina riziką, bet nėra visiška apsauga. Su mod_php reikšmes nustatykite Apache konfigūracijoje per php_admin_value arba php_admin_flag, kad .htaccess ir programos jų negalėtų perrašyti.

# Pavyzdys: VirtualHost konfigūracijoje arba visame serveryje galiojančioje konfigūracijoje
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>

Su įkėlimo funkcija php.net nurodo post_max_size = 32M, o upload_max_filesize mažesnis. PHP 8.5 papildomai nustatoma fatal_error_backtraces=0. Nuorodą dėl memory_limit=-1 taikykite tik kartu su tarnybos atminties riba per cgroups, pavyzdžiui, su MemoryMax systemd papildyme, o ne per RLIMIT_AS ar RLIMIT_DATA. Po to visiškai paleiskite Apache iš naujo. Visos priemonės apžvalgoje: Skubios priemonės be pataisos.

Kelias šalin nuo mod_php

Po ūmaus pataisymo verta pereiti prie PHP-FPM. Tuomet PHP veikia savo procesuose, atskirai nuo žiniatinklio serverio. Kiekviena svetainė gali gauti savą baseiną (pool) su savu naudotoju, ribas galima nustatyti kiekvienam baseinui, o perkrovimai paveikia tik PHP. Apache PHP-FPM prijungia per mod_proxy_fcgi ir tuomet vietoj prefork gali naudoti modernesnį MPM, pavyzdžiui, event.

Perėjimą suplanuokite bandomojoje aplinkoje: sukurkite kiekvienai svetainei baseiną, pritaikykite failų teises naujiems naudotojams, .htaccess įrašus su php_value perkelkite į baseino nustatymus, atlikite apkrovos testus. Kaip atrodo tvarkinga sąranka, rodo Nginx su PHP-FPM apsauga; principai taikomi ir Apache su PHP-FPM.

Nepriklausomai nuo veikimo režimo galioja: pataisa nepašalina jau įterptos kenkėjiškos programinės įrangos. Išsaugokite žurnalus nuo 2026-10-20 ir patikrinkite serverį dėl pėdsakų.

Ieškant pėdsakų mod_php serveriuose verta pažvelgti į bendrą naudotoją. Kadangi visos svetainės veikia su Apache naudotoju, pavyzdžiui, www-data ar apache, užpuolikas, perėmęs vieną svetainę, paprastai gali skaityti ir keisti ir kitų failus. Todėl tikrinkite ne tik jums įtartinai atrodančią svetainę, bet ir visus serverio Document Root. Ypač atkreipkite dėmesį į PHP failus su neseniu pakeitimo laiku įkėlimų ir talpyklos kataloguose, į programos kodą, priklausantį Apache naudotojui, ir į nežinomus įrašus šio naudotojo crontab. Jei ką nors randate, pirmiausia išsaugokite būseną ir neskubėkite trinti, kad vėliau būtų galima atsekti priežastį.

Kaip PHP SOS padeda konkrečiai?

• Tikriname veikimo režimą, MPM ir paketų būseną ir vertiname, ar jūsų serveris tikrai pataisytas.
• Per PHP pataisų paslaugą įdiegiame atnaujinimą, visiškai paleidžiame Apache iš naujo ir dokumentuojame įrodymą.
• Iki pataisos pereinamąsias priemones nustatome taip, kad jų nebūtų galima perrašyti, ir apribojame atmintį tarnybos lygmeniu.
• Pagal serverio sutvirtinimą planuojame ir išbandome perėjimą prie PHP-FPM su atskirais baseinais.

Dažni klausimai

Šaltiniai

• php.net: saugumo pranešimai
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets