# Apache ar mod_php aizsardzība > Apache mod_php pēc PHP2Shell: atpazīt darbības režīmu, ielāpot PHP moduli, pilnībā pārstartēt Apache un sakārtoti sagatavot pāreju uz PHP-FPM. Avots: https://phpsos.de/lv/server/apache-mod-php/ Aktuāls uz: 25.10.2026 Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6 **Īsi:** Apache ar mod_php PHP darbojas tieši tīmekļa serverī. PHP komanda PHP2Shell radīto risku tieši šajā darbības režīmā vērtē kā augstāko, jo exploit tika demonstrēts, vēl pirms tiek izpildīts lietojumprogrammas kods. Ielāpojiet nekavējoties, pilnībā pārstartējiet Apache un pēc tam plānojiet pāreju uz PHP-FPM. ## Kas ir mod_php un kāpēc tas tagad ir svarīgi Ar mod_php Apache ielādē PHP kā moduli katrā savā darbprocesā. Katrs pieprasījums PHP failam tiek izpildīts tieši šajā procesā. Tas ilgu laiku bija standarts, un to ir viegli iestatīt. Taču tas nozīmē arī: visas servera vietnes darbojas ar vienu un to pašu lietotāju, un PHP dala procesu ar tīmekļa serveri. PHP2Shell ietver ievainojamības CVE-2026-109618 un CVE-2026-109619, abas ar CVSS v4.0 9.2. Otrajā 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šā procesā. mod_php gadījumā PHP komanda konstatējusi augstāko risku. Fonu un klasifikāciju skatiet lapā [Kāpēc mod_php rada augstāko risku](https://phpsos.de/lv/php2shell/mod-php-risiko/). ## Apache mod_php atpazīšana un versijas pārbaude Vispirms pārbaudiet, vai jūsu Apache vispār izmanto mod_php. Turpmākās komandas tikai lasa. Komandu un pakotņu nosaukumi atšķiras atkarībā no distributīva un ir piemēri. ```bash # Debian/Ubuntu: ielādētie moduļi apache2ctl -M 2>/dev/null | grep -i php # RHEL saime httpd -M 2>/dev/null | grep -i php # Kurš MPM ir aktīvs? mod_php prasa prefork apache2ctl -V 2>/dev/null | grep -i mpm # Moduļa pakotnes stāvoklis (piemēri) dpkg -l | grep libapache2-mod-php rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common' ``` Ja parādās modulis, piemēram, `php_module`, darbojas mod_php. Parādītā PHP versija vien nav ielāpa pierādījums, jo distributīvi labojumus bieži ievieš kā backportu. PHP projekta labotās versijas ir 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Distributīvu pakotnēm noteicošais ir izmaiņu žurnāls ar CVE numuriem. ## Ielāpošana un Apache pilnīga pārstartēšana Ieinstalējiet atjauninājumu ar pakotņu pārvaldību. Tā kā PHP atrodas Apache procesā, pēc tam jāpārstartē viss pakalpojums. Konfigurācijas pārlādēšana šeit nav drošais ceļš. ```bash # Debian/Ubuntu systemctl restart apache2 # RHEL saime systemctl restart httpd # Kontrole: visu Apache procesu startēšanas laiks ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep ``` Visiem Apache procesiem jārāda startēšanas laiks pēc atjauninājuma. Ja tajā pašā serverī papildus darbojas PHP-FPM vai php-cgi, pārstartējiet arī šos pakalpojumus. > **Rīkoties nekavējoties:** > Ja jūsu PHP versijai ielāpa vēl nav, BSI iesaka tīmekļa serveri uz laiku atvienot no tīkla. mod_php gadījumā tas ir īpaši svarīgi, jo uzbrukums var darboties pirms lietojumprogrammas koda. ## Pagaidu pasākumi Apache konfigurācijā php.net min pagaidu pasākumus, kas samazina risku, bet nesniedz pilnīgu aizsardzību. mod_php gadījumā vērtības iestatiet ar `php_admin_value` vai `php_admin_flag` Apache konfigurācijā, lai `.htaccess` un lietojumprogrammas tās nevarētu pārrakstīt. ```apache # Piemērs: VirtualHost vai servera mēroga konfigurācijā php_admin_flag session.upload_progress.enabled off php_admin_value post_max_size 8M php_admin_value upload_max_filesize 6M ``` Ja ir augšupielādes funkcija, php.net min `post_max_size = 32M`, un `upload_max_filesize` zem tā. PHP 8.5 gadījumā klāt nāk `fatal_error_backtraces=0`. Norādi par `memory_limit=-1` ieviesiet tikai kopā ar pakalpojuma atmiņas ierobežojumu ar cgroups, piemēram, ar `MemoryMax` systemd papildinājumā, nevis ar `RLIMIT_AS` vai `RLIMIT_DATA`. Pēc tam pilnībā pārstartējiet Apache. Visi pasākumi vienuviet: [Tūlītēji pasākumi bez ielāpa](https://phpsos.de/lv/php2shell/sofortmassnahmen-ohne-patch/). ## Ceļš prom no mod_php Pēc akūtā ielāpa ir vērts pāriet uz PHP-FPM. Tad PHP darbojas savos procesos, nošķirti no tīmekļa servera. Katrai vietnei var piešķirt savu pūlu ar savu lietotāju, ierobežojumus var iestatīt katram pūlam, un pārstartēšana skar tikai PHP. Apache PHP-FPM pieslēdz ar `mod_proxy_fcgi` un tad prefork vietā var izmantot modernāku MPM, piemēram, event. Pāreju plānojiet testa vidē: katrai vietnei izveidot pūlus, failu tiesības pielāgot jaunajiem lietotājiem, `.htaccess` ierakstus ar `php_value` pārnest uz pūla iestatījumiem, veikt slodzes testus. Kā izskatās sakārtota uzbūve, parāda lapa [Nginx ar PHP-FPM aizsardzība](https://phpsos.de/lv/server/nginx-php-fpm/); pamatprincipi attiecas arī uz Apache ar PHP-FPM. Neatkarīgi no darbības režīma: ielāps nenoņem jau ievadītu ļaunprātīgu programmatūru. Saglabājiet žurnālus no 2026. gada 20. oktobra un pārbaudiet serveri, vai tajā nav pēdu. Pēdu meklēšanā mod_php serveros vērts pievērst uzmanību kopīgajam lietotājam. Tā kā visas vietnes darbojas ar Apache lietotāju, piemēram, `www-data` vai `apache`, uzbrucējs, kas pārņēmis vienu vietni, parasti var lasīt un mainīt arī pārējo failus. Tāpēc pārbaudiet ne tikai to vietni, kas šķiet aizdomīga, bet visus Document Root serverī. Īpaši pievērsiet uzmanību PHP failiem ar nesen mainītu datumu augšupielāžu un kešatmiņas direktorijos, programmas kodam, kas pieder Apache lietotājam, un nezināmiem ierakstiem šī lietotāja crontab. Ja kaut ko atrodat, vispirms saglabājiet stāvokli un neizdzēsiet pārsteidzīgi, lai cēloni vēlāk varētu izsekot. ## Kā PHP SOS palīdz konkrēti? - Mēs pārbaudām darbības režīmu, MPM un pakotņu stāvokli un novērtējam, vai jūsu serveris patiešām ir ielāpots. - Ar [PHP ielāpu pakalpojumu](https://phpsos.de/lv/leistungen/php-patch-service/) mēs ieinstalējam atjauninājumu, pilnībā pārstartējam Apache un dokumentējam pierādījumu. - Līdz ielāpam mēs pagaidu pasākumus iestatām nepārrakstāmi un ierobežojam atmiņu pakalpojuma līmenī. - Savas [servera nostiprināšanas](https://phpsos.de/lv/leistungen/server-haertung/) ietvaros mēs plānojam un testējam pāreju uz PHP-FPM ar atsevišķiem pūliem. ## Biežāk uzdotie jautājumi **Kā noteikt, vai mans serveris izmanto mod_php?** Ja Apache ir ielādējis PHP moduli, tas moduļu sarakstā parādās kā php_module vai ar versijas numuru nosaukumā. Turklāt phpinfo izvadē sadaļā Server API ir ieraksts Apache 2.0 Handler. Šādu testa failu nekavējoties izdzēsiet. **Kāpēc mod_php PHP2Shell gadījumā ir īpaši kritisks?** Saskaņā ar PHP komandu risks tur ir visaugstākais; exploit tika demonstrēts, vēl pirms tiek izpildīts lietojumprogrammas kods. Tāpēc arī labi uzturēta lietojumprogramma neaizsargā. Ātram atjauninājumam tāpēc ir augstākā prioritāte. **Vai pēc atjauninājuma pietiek ar Apache reload?** Drošs ir pilnīgs pakalpojuma restarts, jo PHP atrodas Apache procesos kā modulis. Pēc tam pārbaudiet visu Apache procesu startēšanas laiku. Procesi, kas vecāki par atjauninājumu, nedrīkst palikt. **Vai pāreja uz PHP-FPM ir darbietilpīga?** Parasti to var labi saplānot: instalēt PHP-FPM, izveidot pūlus, Apache pārslēgt uz proxy_fcgi un no prefork pāriet uz citu MPM. Iepriekš pārbaudiet to vides kopijā. ## Avoti - [php.net: drošības paziņojumi](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI (Vācijas Federālā informācijas drošības birojs)](https://www.bsi.bund.de/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)