Situația actuală: PHP2Shell. Două vulnerabilități critice PHP (CVSS 9.2) permit cod malițios fără autentificare. Patchuri din 21.10.2026.Ce este de făcut acum →

mod_php explicat: PHP în procesul Apache

La mod_php, PHP se află în fiecare proces Apache. Este simplu, dar puțin flexibil și, după PHP2Shell, cel mai riscant mod de operare. Cum funcționează și cum îl recunoașteți.

Stadiu 5 min de cititCunoștințe PHP

Pe scurt: mod_php este PHP ca modul în serverul web Apache. Fiecare proces Apache conține atunci un interpretor PHP complet și execută singur codul PHP; SAPI se numește apache2handler. Este simplu de configurat, dar leagă PHP de Apache, cere de obicei MPM-ul prefork și permite abia o separare între site-uri. Manualul PHP îl descurajează pentru instalările noi, iar la PHP2Shell echipa PHP încadrează riscul cel mai sus la mod_php.

Ce este mod_php?

La mod_php, Apache încarcă PHP ca modul propriu în procesele sale. Nu există un serviciu PHP separat: când Apache trebuie să livreze un fișier .php, același proces care a primit cererea execută și codul PHP. Mulți ani aceasta a fost calea standard de a opera PHP și este răspândită până astăzi pe serverele mai vechi și în unele imagini Docker.

Potrivit manualului PHP, ca modul de server, PHP își citește configurația o singură dată, la pornirea serverului web. Modificările din php.ini și actualizările modulului acționează de aceea abia după o repornire a Apache.

Important pentru înțelegere: procesele Apache trăiesc mult. Un proces primește multe conexiuni una după alta, înainte de a fi înlocuit; câte, reglează directiva Apache MaxConnectionsPerChild. Interpretorul PHP încorporat rămâne în acest timp același. Cine înlocuiește biblioteca libphp de pe disc nu schimbă nimic în procesele care rulează.

Pentru conducere și responsabilii de proiect, se poate rezuma așa: la mod_php, serverul web și PHP sunt o unitate. Cine atinge una, o afectează pe cealaltă. O actualizare PHP înseamnă o repornire a serverului web, o eroare în PHP rulează cu drepturile serverului web, iar o separare între mai multe site-uri de pe același server este abia posibilă.

Cum este integrat mod_php?

Manualul PHP arată integrarea în doi pași: încărcarea modulului și stabilirea fișierelor pe care PHP trebuie să le prelucreze.

LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Manualul recomandă FilesMatch cu SetHandler în loc de doar AddType, pentru ca fișierele încărcate, precum bild.php.jpg, să nu fie executate ca PHP. Pe Debian și Ubuntu, pachete precum libapache2-mod-php8.3 și comenzile a2enmod și a2dismod preiau această muncă.

Dacă mod_php este activ se poate verifica în modul doar de citire:

apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # familia RHEL
apachectl -V | grep -i mpm               # MPM activ (prefork, worker, event)

Prefork, Thread Safety și resurse

Apache distribuie cererile printr-un modul de procesare multiplă (MPM). Potrivit manualului PHP, mod_php necesită MPM-ul prefork, dacă PHP nu a fost compilat cu Zend Thread Safety (--enable-zts). Majoritatea pachetelor de distribuție sunt compilate fără Thread Safety.

Prefork înseamnă: un proces pentru fiecare conexiune simultană, iar fiecare proces poartă un interpretor PHP complet. Chiar și cererile pentru imagini sau fișiere CSS ocupă astfel un proces cu PHP în bagaj. Aceasta costă memorie și limitează sarcina pe care o poate suporta un server.

Caracteristică mod_php PHP-FPM
Unde rulează PHP? în fiecare proces Apache în serviciu propriu
MPM Apache de obicei prefork event este posibil
Utilizator pentru fiecare site nu, totul ca utilizator Apache da, pentru fiecare pool
Repornirea PHP doar cu Apache independent de Apache
Setări pe director php_value în .htaccess pool sau .user.ini

De aceea, manualul recomandă pentru toate instalările moderne PHP-FPM cu mod_proxy_fcgi: gestiune mai bună a resurselor, separarea proceselor, repornirea PHP fără repornirea Apache și compatibilitate cu MPM-ul event, care este standard din Apache 2.4. Bazele se află la PHP-FPM explicat.

Setări cu .htaccess, php_value și php_admin_value

Cu mod_php, setările PHP pot fi făcute direct în configurația Apache. Manualul distinge aici modurile de modificare: intrările cu INI_PERDIR pot fi în php.ini, .htaccess sau httpd.conf, intrările cu INI_SYSTEM doar în php.ini sau httpd.conf.

# În configurația VirtualHost: blocat pentru aplicație
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Posibil în .htaccess, dar poate fi suprascris de aplicație
php_value max_execution_time 60

php_admin_value și php_admin_flag sunt permise doar în configurația serverului, nu în .htaccess. Exact această distincție este importantă la măsurile provizorii pentru PHP2Shell, deoarece valori precum session.upload_progress.enabled nu trebuie să poată fi resetate de aplicație.

mod_php și PHP2Shell: de ce riscul este cel mai mare

Echipa PHP încadrează riscul PHP2Shell cel mai sus la mod_php: acolo a fost demonstrat un exploit înainte ca vreun cod al aplicației să ruleze. Pluginurile de securitate sau verificările din CMS vin astfel prea târziu. La aceasta se adaugă faptul că, la mod_php, PHP rulează cu drepturile și în memoria serverului web. Încadrarea detaliată se află la De ce mod_php prezintă cel mai mare risc.

Pentru operatori se aplică de aceea:

  1. Actualizați modulul PHP la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, respectiv la un backport confirmat.
  2. Reporniți complet Apache, nu doar reload, și verificați ora de pornire a proceselor.
  3. Setați valorile provizorii prin php_admin_value în configurația serverului, dacă actualizarea nu este încă posibilă.
  4. Apoi planificați trecerea la PHP-FPM, așa cum este descris la Securizarea Apache cu mod_php.

Cum ajută PHP SOS concret?

  • Recunoaștere: Verificăm pe ce servere rulează mod_php, cu ce MPM și din ce sursă de pachete.
  • Patch: Actualizăm modulul PHP, repornim complet Apache și dovedim starea.
  • Securizarea perioadei de tranziție: Acolo unde actualizarea este blocată, setăm măsurile de la php.net blocate în configurația serverului.
  • Trecerea: În cadrul întăririi serverului migrăm, cu testare, la PHP-FPM cu pool-uri proprii.

Întrebări frecvente

De ce se numește mod_php, dacă modulul se numește php_module?

mod_php este denumirea colocvială pentru PHP ca modul Apache. În configurație se încarcă cu LoadModule; manualul PHP dă ca exemplu LoadModule php_module modules/libphp.so. Versiunile mai vechi foloseau nume precum php7_module sau php5_module.

De ce are nevoie mod_php de MPM-ul prefork?

Potrivit manualului PHP, mod_php necesită MPM-ul prefork, dacă PHP nu a fost compilat cu Zend Thread Safety. Majoritatea pachetelor de distribuție sunt compilate fără Thread Safety. Prefork pornește un proces propriu pentru fiecare conexiune simultană, ceea ce consumă mai multă memorie.

Funcționează liniile php_value din .htaccess și cu PHP-FPM?

Nu. php_value și php_flag din .htaccess sunt directive Apache ale modulului PHP și acționează doar cu mod_php. Sub PHP-FPM, asemenea setări aparțin pool-ului sau, pentru valorile permise, unui .user.ini.

Trebuie să renunț imediat la mod_php?

Mai întâi vine actualizarea PHP, cu repornirea completă a Apache. Trecerea la PHP-FPM este apoi rezonabilă, dar ar trebui planificată și testată. Ea nu închide PHP2Shell, deoarece și PHP-FPM este afectat.

Surse

Contact imediat

Fiecare oră contează. Scrieți-ne acum.

Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.

Ajutor imediat