Pe scurt: open_basedir limitează directoarele la care are voie să acceseze PHP. Singură, este doar o barieră suplimentară. O izolare eficientă pe site apare abia în ansamblu: utilizator de sistem propriu, pool PHP-FPM propriu, dosar temporar propriu și accesuri proprii la baza de date. Atunci o intruziune într-un site rămâne limitată la acel site.
De ce izolarea decide paguba după PHP2Shell
Pe multe servere rulează mai multe site-uri unul lângă altul: site-ul firmei, un magazin, un site vechi de campanie, iar la agenții adesea zeci de proiecte ale clienților. Adesea ele împart un utilizator de sistem și un proces PHP. Dacă unul este compromis, toate celelalte sunt expuse.
PHP2Shell face acest risc palpabil. Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 permit executarea de cod malițios fără autentificare, indiferent de CMS. Potrivit rapoartelor din presă, o primă tentativă de atac a existat deja la 17.10.2026, iar patchurile au urmat la 21.10. Remedierea este actualizarea. Dacă un atac din perioada anterioară lovește unul sau zece site-uri decide însă izolarea.
La a doua vulnerabilitate se adaugă o idee în plus: potrivit proiectului PHP, starea internă a unei cereri poate persista într-un worker și poate fi folosită de o cerere ulterioară din același worker. Pool-urile separate pentru fiecare site fac ca site-urile să nu împartă oricum niciun worker.
Ce face open_basedir
Cu open_basedir stabiliți o listă de directoare. Funcțiile PHP pentru fișiere, precum fopen, include sau file_get_contents, refuză apoi accesul la tot ce este în afara listei. Un script introdus nu poate astfel citi fără probleme fișierele de configurare ale site-ului vecin.
Limitele sunt importante: verificarea are loc în interiorul PHP. Programele pornite în afara PHP nu îi sunt supuse, iar erorile din interpretor o pot ocoli. De aceea open_basedir aparține întotdeauna împreună cu funcțiile de sistem blocate, așa cum descrie ghidul Cum folosiți corect disable_functions, și mai ales cu separarea la nivelul sistemului de operare.
Izolarea pe site în patru straturi
O separare solidă se construiește pe mai multe straturi. Fiecare prinde ce nu reușește cel anterior.
| Strat | Măsură | Efect |
|---|---|---|
| Sistem de operare | utilizator de sistem propriu pentru fiecare site | fișierele altor site-uri nu pot fi citite |
| Procese PHP | pool PHP-FPM propriu, cu socket propriu | niciun worker comun, setări proprii |
| Configurare PHP | open_basedir, dosar propriu pentru tmp și sesiuni |
barieră suplimentară, fără fișiere temporare comune |
| Date | utilizator propriu de bază de date, cu drepturi doar asupra propriei baze | fără acces la datele clienților străini |
La o nevoie ridicată de protecție, de exemplu la magazine cu procesare de plăți sau la portaluri cu date de sănătate, se adaugă containere sau servere separate.
Configurarea open_basedir în pool-ul PHP-FPM
Exemplul următor arată un pool pentru un site cu utilizatorul propriu seite1. Adaptați căile și numărul versiunii la sistemul dumneavoastră.
; /etc/php/8.3/fpm/pool.d/seite1.conf
[seite1]
user = seite1
group = seite1
listen = /run/php/seite1.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = ondemand
pm.max_children = 10
php_admin_value[open_basedir] = /var/www/seite1/:/var/www/seite1-tmp/
php_admin_value[upload_tmp_dir] = /var/www/seite1-tmp/
php_admin_value[sys_temp_dir] = /var/www/seite1-tmp/
php_admin_value[session.save_path] = /var/www/seite1-tmp/sessions
php_admin_value[error_log] = /var/log/php/seite1.error.log
php_admin_flag[session.upload_progress.enabled] = off
Ultima linie setează totodată și măsura provizorie PHP2Shell de la php.net. Ea acționează doar din pool, php.ini sau configurația serverului, nu prin ini_set() sau .user.ini. Dosarele le creați cu drepturile potrivite:
sudo useradd --system --home /var/www/seite1 --shell /usr/sbin/nologin seite1
sudo mkdir -p /var/www/seite1-tmp/sessions
sudo chown -R seite1:seite1 /var/www/seite1-tmp
sudo chmod 700 /var/www/seite1-tmp
Cum ar trebui să arate drepturile în directorul web propriu-zis descrie ghidul Drepturile fișierelor pe serverul web.
Conectarea serverului web și verificarea rezultatului
În Nginx, fiecare site trimite către propriul socket. Astfel nicio cerere nu ajunge în pool-ul altui site.
server {
server_name seite1.example;
root /var/www/seite1/public;
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/seite1.sock;
}
}
Alte indicații despre această combinație găsiți la Cum securizați Nginx cu PHP-FPM. După repornire, verificați dacă pool-urile rulează într-adevăr separat:
sudo systemctl restart php8.3-fpm
# Fiecare pool ar trebui să ruleze sub propriul utilizator
ps -eo user,pid,cmd | grep "[p]hp-fpm: pool"
Testați apoi toate funcțiile site-ului: încărcări, prelucrarea imaginilor, cache-uri, sarcini programate. Mesajele de eroare cu mențiunea open_basedir restriction din logul de erori arată ce cale mai lipsește. Adăugați doar căile de care aplicația are cu adevărat nevoie și niciodată întregul sistem de fișiere.
Agențiile cu multe site-uri de clienți ar trebui să întrețină configurația pool-ului ca șablon. Astfel fiecare site nou primește separarea automat, în loc să fie nevoie să o adăugați ulterior. Contextul pentru acest caz îl găsiți la Partener de securitate pentru agenții.
Obstacole tipice la trecerea la noua configurare
Trecerea la pool-uri separate se poate planifica, dar are câteva capcane recurente. Cea mai frecventă privește bibliotecile folosite în comun: dacă, de exemplu, un framework sau un dosar cu fonturi se află în afara directorului site-ului, acea cale trebuie adăugată în open_basedir cu drept de citire. Este mai bine să aduceți astfel de dependențe în proiectul însuși.
A doua capcană sunt sesiunile. Dacă se schimbă locul de stocare, toți vizitatorii sunt deconectați o dată, iar coșurile de cumpărături în curs se pierd. Planificați de aceea trecerea într-un interval liniștit și anunțați-o intern.
În al treilea rând, sarcinile programate rulează adesea prin linia de comandă și deci sub alt utilizator decât site-ul. Verificați cronjoburile și cozile și lăsați-le să ruleze sub noul utilizator al site-ului, altfel apar fișiere cu proprietar greșit, pe care PHP nu le mai poate modifica ulterior.
În sfârșit, fiecare pool ar trebui să aibă limite proprii pentru procese și memorie. Un site care intră sub sarcină sau este atacat nu le poate astfel doborî și pe celelalte.
Cum ajută PHP SOS concret?
- Stabilim ce site-uri împart astăzi utilizatori, procese și baze de date.
- Configurăm pentru fiecare site utilizatori, pool-uri, dosare temporare și accesuri la baza de date proprii, fără a modifica aplicațiile.
- Testăm fiecare site după trecere și remediem țintit căile lipsă.
- Documentăm separarea ca șablon pentru proiectele viitoare.
Cum se încadrează acest lucru într-un concept de ansamblu descrie serviciul Securizarea serverelor web PHP.
Întrebări frecvente
Este open_basedir suficient pentru a separa site-urile între ele?
Nu. open_basedir este o barieră suplimentară în interiorul PHP, nu o separare strictă. Izolarea devine fiabilă abia cu utilizatori de sistem și pool-uri proprii pentru fiecare site, iar la o nevoie mai mare de protecție, cu containere sau servere separate.
De ce nu mai funcționează încărcările după ce am setat open_basedir?
De regulă lipsește din listă dosarul pentru fișiere temporare. Creați pentru fiecare site un dosar tmp propriu, treceți-l în open_basedir și setați upload_tmp_dir și sys_temp_dir pe acest dosar.
Poate o aplicație să anuleze singură open_basedir?
În timpul rulării, o aplicație poate doar să restrângă mai mult setarea, nu să o relaxeze. Setați totuși open_basedir prin php_admin_value în pool, pentru ca valoarea să fie fixată fără echivoc.
Este posibilă izolarea și la shared hosting?
Depinde de furnizorul de hosting. Multe oferte separă clienții prin utilizatori și procese PHP proprii. Întrebați cum este realizată separarea, mai ales dacă mai multe dintre site-urile dumneavoastră se află într-un singur pachet.