# Apache su mod_php apsauga > Apache mod_php po PHP2Shell: atpažinkite veikimo režimą, pataisykite PHP modulį, visiškai paleiskite Apache iš naujo ir tvarkingai parenkite perėjimą prie PHP-FPM. Šaltinis: https://phpsos.de/lt/server/apache-mod-php/ Būsena: 2026-10-25 Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6 **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ą](https://phpsos.de/lt/php2shell/mod-php-risiko/). ## 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. ```bash # 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. ```bash # 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. > **Veikti nedelsiant:** > Jei jūsų PHP versijai pataisos dar nėra, BSI (Vokietijos Federalinė informacijos saugumo tarnyba) rekomenduoja laikinai atjungti žiniatinklio serverį nuo tinklo. Esant mod_php tai ypač svarbu, nes ataka gali suveikti prieš programos kodą. ## 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. ```apache # Pavyzdys: VirtualHost konfigūracijoje arba visame serveryje galiojančioje konfigūracijoje php_admin_flag session.upload_progress.enabled off php_admin_value post_max_size 8M php_admin_value upload_max_filesize 6M ``` 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](https://phpsos.de/lt/php2shell/sofortmassnahmen-ohne-patch/). ## 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](https://phpsos.de/lt/server/nginx-php-fpm/); 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ą](https://phpsos.de/lt/leistungen/php-patch-service/) į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ą](https://phpsos.de/lt/leistungen/server-haertung/) planuojame ir išbandome perėjimą prie PHP-FPM su atskirais baseinais. ## Dažni klausimai **Kaip sužinoti, ar mano serveris naudoja mod_php?** Jei Apache įkėlė PHP modulį, jis modulių sąraše rodomas kaip php_module arba su versijos numeriu pavadinime. Be to, phpinfo išvestyje prie Server API matysite įrašą Apache 2.0 Handler. Tokį bandomąjį failą nedelsiant ištrinkite. **Kodėl mod_php PHP2Shell atveju ypač kritiškas?** PHP komandos duomenimis, ten rizika didžiausia; exploit buvo parodytas dar prieš pradedant vykdyti programos kodą. Todėl neapsaugo net gerai prižiūrima programa. Greitas atnaujinimas yra aukščiausio prioriteto. **Ar po atnaujinimo pakanka Apache reload?** Saugu visiškai paleisti tarnybą iš naujo, nes PHP kaip modulis yra Apache procesuose. Po to patikrinkite visų Apache procesų paleidimo laiką. Procesų, senesnių už atnaujinimą, likti negali. **Ar perėjimas prie PHP-FPM sudėtingas?** Dažniausiai jį gerai galima suplanuoti: įdiegti PHP-FPM, sukurti baseinus (pool), perjungti Apache į proxy_fcgi ir pakeisti prefork į kitą MPM. Prieš tai išbandykite aplinkos kopijoje. ## Šaltiniai - [php.net: saugumo pranešimai](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI](https://www.bsi.bund.de/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)