Pe scurt: Cu PHP disable_functions blocați funcțiile prin care PHP execută comenzi de sistem, de exemplu exec, shell_exec sau proc_open. Aceasta îngreunează atacatorilor pasul următor după o intruziune. Setarea acționează doar din php.ini sau din pool-ul FPM, trebuie să se potrivească aplicației și nu înlocuiește o actualizare.
De ce are sens disable_functions tocmai acum
La PHP2Shell este vorba despre executarea de cod malițios de la distanță, fără autentificare. Cele două vulnerabilități CVE-2026-109618 și CVE-2026-109619 se află în interpretorul PHP însuși, corectate în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Actualizarea este singura cale de a le închide.
Securizarea acționează cu un nivel mai târziu. Cine poate executa o dată cod pe un server vrea, de regulă, să meargă mai departe: să pornească comenzi de sistem, să descarce instrumente, să instaleze o ușă din spate permanentă. Mulți dintre acești pași trec prin câteva funcții PHP. Dacă ele sunt blocate, drumul devine mai anevoios și mai vizibil.
disable_functions nu este de aceea un substitut pentru patchuri, ci un element pentru cazul în care, în ciuda tuturor precauțiilor, trece totuși ceva. Aceasta se aplică vulnerabilităților viitoare la fel ca PHP2Shell.
Ce poate și ce nu poate PHP disable_functions
Setarea elimină funcțiile menționate din mediul de execuție. Dacă un script apelează o funcție blocată, PHP se oprește cu o eroare. Blocarea se aplică oricărui cod care rulează în acel proces PHP, deci și codului introdus.
Ar trebui să cunoașteți limitele:
- Setarea nu este un spațiu de protecție închis. Extensiile PHP, erorile din interpretor sau programele din afara PHP o pot ocoli.
- Nu împiedică un atacator să citească sau să scrie fișiere la care utilizatorul PHP are acces. Pentru aceasta răspund drepturile fișierelor și izolarea.
- Acționează doar din php.ini sau ca
php_admin_value. Nu poate fi setată cuini_set(),.user.inisau.htaccess.
disable_functions aduce cel mai mult împreună cu un php.ini curat, cu utilizatori proprii pentru fiecare site și cu drepturi restrictive ale fișierelor. Bazele le găsiți în ghidul Cum configurați php.ini în siguranță.
Ce funcții ar trebui să blocați
Pentru site-urile tipice, fără nevoie de comenzi de sistem, s-a dovedit utilă lista următoare. Ea cuprinde funcții pentru pornirea proceselor și pentru controlul proceselor în rulare.
| Grup | Funcții | Utilizare legitimă tipică |
|---|---|---|
| Execuția de comenzi | exec, shell_exec, system, passthru |
prelucrarea imaginilor, backupuri prin script |
| Deschiderea proceselor | proc_open, popen |
Composer, instrumente PDF, trimiterea de e-mailuri |
| Controlul proceselor | proc_nice, proc_terminate, proc_get_status |
cozi de așteptare, joburi în fundal |
| Administrarea proceselor | pcntl_exec, pcntl_fork |
de regulă doar în linia de comandă |
| Semnale și drepturi | posix_kill, posix_setuid |
rar în funcționarea web |
Ca configurare arată astfel:
; php.ini al modului de operare web, de ex. /etc/php/8.3/fpm/php.ini
disable_functions = exec,shell_exec,system,passthru,proc_open,popen,proc_nice,proc_terminate,proc_get_status,pcntl_exec,pcntl_fork,posix_kill,posix_setuid
Dacă lista nu se aplică tuturor site-urilor de pe server, setați-o pentru fiecare pool FPM. După reîncărcare, verificați ce listă se aplică efectiv în acel pool:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (extras)
php_admin_value[disable_functions] = exec,shell_exec,system,passthru,proc_open,popen
Verificați aplicația în prealabil: așa evitați întreruperile
Cine setează lista nevalidat riscă ca redimensionarea imaginilor, facturile PDF sau trimiterea e-mailurilor să nu mai funcționeze brusc. Căutați de aceea în prealabil în cod funcțiile afectate:
# Unde și cât de des sunt folosite funcțiile în cod?
grep -rnoE "\b(exec|shell_exec|system|passthru|proc_open|popen|pcntl_exec)\s*\(" /var/www/meine-seite --include="*.php" \
| cut -d: -f1 | sort | uniq -c | sort -rn | head -30
Rezultatele nu înseamnă automat că funcția este necesară în funcționare. Multe biblioteci verifică mai întâi dacă o funcție este disponibilă și altfel ocolesc. Decisiv este un test într-un mediu de staging, cu toate fluxurile importante: comandă, factură, trimiterea formularelor, încărcarea imaginilor, sarcinile programate.
Dacă o aplicație cere obligatoriu una dintre aceste funcții, verificați cerințele de sistem ale producătorului pe pagina sa oficială. Adesea sarcina poate fi mutată într-un pool separat sau într-un script din linia de comandă, care nu este accesibil prin web.
Activarea setării și verificarea efectului
După modificare, PHP trebuie să recitească configurația. Verificați apoi valoarea în modul de operare al site-ului dumneavoastră, nu în linia de comandă:
sudo systemctl reload php8.3-fpm
php-fpm8.3 -i | grep "^disable_functions"
# Verificați în logul de erori apelurile funcțiilor blocate
sudo grep -i "has been disabled" /var/log/php/*.log | tail -20
Mesajele din logul de erori sunt valoroase și mai târziu. Dacă apar brusc acolo apeluri ale unor funcții blocate, deși aplicația dumneavoastră nu le folosește, aceasta poate indica cod introdus. Cum procedați mai departe descrie ghidul Cum recunoașteți și eliminați un webshell.
Greșeli tipice la folosirea disable_functions
În practică, securizarea eșuează rareori din motive tehnice, ci din detalii mărunte. Aceste greșeli sunt deosebit de răspândite:
- Fișier greșit modificat: Lista se află doar în php.ini al liniei de comandă, iar site-ul rulează prin PHP-FPM și rămâne neprotejat.
- Fără repornire: Fișierul este corect, dar procesele care rulează lucrează încă cu configurația veche.
- Blocare prea largă: Funcții precum
ini_setsaumailsunt blocate odată cu celelalte, iar fluxuri importante se opresc neobservat. Erorile se observă atunci adesea abia după zile, de exemplu prin confirmări de comandă care nu mai pleacă. - Setat o dată, niciodată verificat: După o mutare, o schimbare a versiunii PHP sau o reinstalare prin panoul de hosting, lista a dispărut.
- Falsă senzație de siguranță: Blocarea este înțeleasă ca substitut al actualizărilor. Ea nu închide însă nicio vulnerabilitate din interpretor.
Includeți de aceea verificarea valorii active în rutina dumneavoastră după fiecare actualizare PHP. O privire scurtă este suficientă, costă puțin timp și împiedică pierderea tăcută a unei securizări.
La mai multe site-uri pe un server: creați pentru fiecare site un pool propriu, cu listă proprie. Complementar, open_basedir limitează directoarele la care PHP are voie să acceseze.
Cum ajută PHP SOS concret?
- Verificăm codul și fluxurile aplicației dumneavoastră în privința folosirii funcțiilor critice.
- Stabilim pentru fiecare site o listă de blocare potrivită și o testăm înainte de punerea în producție.
- Combinăm blocarea cu pool-uri, drepturi ale fișierelor și înregistrare în loguri, într-un concept de securizare coerent.
- Documentăm setările și monitorizăm logul de erori pentru apeluri suspecte.
Cum decurge acest lucru ca pachet complet descrie serviciul Securizarea serverelor web PHP.
Întrebări frecvente
Pot seta disable_functions prin ini_set() sau .htaccess?
Nu. Setarea acționează doar din php.ini sau ca php_admin_value în pool-ul FPM, respectiv în configurația Apache. Nu poate fi setată în timpul rulării, iar aplicația nu poate nici să deblocheze din nou funcțiile blocate.
Protejează disable_functions împotriva PHP2Shell?
Nu. PHP2Shell afectează interpretorul PHP însuși, iar vulnerabilitatea se închide doar prin actualizare. Funcțiile blocate pot totuși restrânge marja de manevră a unui atacator după o exploatare reușită.
De ce php -i arată altă listă decât site-ul meu?
Linia de comandă citește adesea un php.ini propriu. Pentru site contează configurația PHP-FPM, mod_php sau LiteSpeed. Verificați de aceea valoarea în modul de operare prin care rulează site-ul dumneavoastră.
Ce aplicații au nevoie de proc_open sau exec?
Depinde de aplicație. Tipice sunt prelucrarea imaginilor prin programe externe, generarea PDF, trimiterea de e-mailuri prin sendmail sau instrumente precum Composer. Verificați în cod și în cerințele de sistem ale producătorului.