Pe scurt: La drepturile fișierelor pe serverul web se aplică un principiu: utilizatorul sub care rulează PHP are voie să citească propriul cod, dar nu să-l modifice. Drepturi de scriere primesc doar dosarele de încărcări, cache și tmp, iar acolo nu se execută PHP. Drepturi precum 777 nu au ce căuta pe un server de producție.
De ce fac drepturile fișierelor diferența după o intruziune
Când atacatorii execută cod pe un server printr-o vulnerabilitate, acest cod rulează cu drepturile procesului PHP. Ce are voie acest utilizator, are voie și atacatorul. Tocmai aici se decide dacă dintr-o intruziune devine o ușă din spate permanentă.
Cu PHP2Shell, acest scenariu a devenit foarte concret în octombrie 2026. Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 permit executarea de cod malițios fără autentificare. Sunt corectate din 21.10.2026 în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Drepturile bune ale fișierelor nu împiedică un atac, dar împiedică un cod introdus să rescrie durabil aplicația dumneavoastră.
În multe instalări, întregul cod aparține utilizatorului serverului web, pentru ca actualizările să funcționeze la un clic. Este comod, dar tocmai constelația pe care o caută atacatorii.
Principiul de bază: separați proprietarul de utilizatorul de execuție
Este sensibilă o împărțire în două roluri. Un proprietar, de exemplu un utilizator de deploy, deține fișierele și aplică actualizările. Procesul PHP rulează sub alt utilizator și are drept de citire doar prin grup.
| Zonă | Proprietar : grup | Drepturi fișiere | Drepturi dosare |
|---|---|---|---|
| Codul programului | deploy : seite1 | 640 | 750 |
| Configurare cu parole | deploy : seite1 | 640 | – |
| Încărcări, cache, tmp | seite1 : seite1 | 640 | 750 |
| Loguri | root sau seite1 | 640 | 750 |
Serverul web propriu-zis, de exemplu Nginx, are nevoie la PHP-FPM doar de acces de citire la fișierele statice, precum imaginile și CSS. Acesta îl obțineți prin grup sau printr-o regulă de acces țintită. Cine operează mai multe site-uri dă fiecăruia un utilizator de execuție propriu; cum se îmbină acest lucru cu pool-urile explică ghidul open_basedir și izolarea pe site.
Verificarea drepturilor fișierelor pe serverul web
Înainte să modificați ceva, faceți-vă o imagine de ansamblu. Comenzile următoare nu modifică nimic.
# Sub ce utilizator rulează procesele PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Fișiere și dosare care pot fi scrise de oricine
find /var/www -perm -o+w -ls
# Fișiere care aparțin utilizatorului serverului web (exemplu www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Drepturile fișierelor de configurare
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Intrările care pot fi scrise de oricine sunt aproape întotdeauna o greșeală. Fișierele PHP care aparțin utilizatorului de execuție arată că acesta își poate modifica codul. Atrag atenția și fișierele individuale al căror proprietar sau ale căror drepturi diferă de cele ale fișierelor vecine. Acesta poate fi un indiciu de fișiere introduse, așa cum descrie ghidul Cum recunoașteți și eliminați un webshell.
Corectarea drepturilor: pas cu pas
Modificați drepturile doar după o salvare și, pe cât posibil, mai întâi într-un mediu de test. Dacă există suspiciunea unei intruziuni, salvați înainte urmele, deoarece proprietarii și mărcile de timp sunt atunci mijloace de probă.
SITE=/var/www/seite1
# Proprietar: utilizatorul de deploy, grup: utilizatorul de execuție
sudo chown -R deploy:seite1 "$SITE"
# Dosare 750, fișiere 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Doar aceste dosare are voie PHP să le scrie (adaptați căile la aplicație)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Verificați apoi complet site-ul: pagina de start, autentificarea, formularele, încărcarea imaginilor, cache-urile. Ce dosare trebuie să scrie o aplicație se găsește în cerințele de sistem ale producătorului, pe pagina sa oficială.
Un chmod -R 777 pentru a rezolva rapid o problemă deschide serverul pentru orice utilizator local și orice proces introdus. Corectați în schimb proprietarul și grupul.
Împiedicarea execuției PHP în dosarele inscriptibile
Drepturile de scriere sunt la jumătate la fel de periculoase dacă acolo nu poate rula cod. Blocați execuția PHP în dosarele de încărcări și de cache, la nivelul serverului web. Pentru Apache, în configurația VirtualHost:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Pentru Nginx este suficient un bloc location care respinge cererile către fișiere PHP din aceste dosare. Regula aparține configurației serverului, nu unui .htaccess din dosarul de încărcări, pe care un atacator cu drepturi de scriere l-ar putea modifica din nou.
Complementar, merită o privire asupra umask a utilizatorului de deploy, pentru ca fișierele noi să nu fie create automat prea deschise. O valoare de 027 duce la 640 pentru fișiere și 750 pentru dosare. Pe serverele proprii, această responsabilitate vă aparține integral; ce mai intră acolo descrie Cum securizați singur serverele root și vServer.
Cazuri speciale: panouri de hosting, shared hosting și deployment-uri
Nu orice server poate fi configurat după manual. Panouri de hosting precum Plesk sau cPanel creează utilizatori și drepturi proprii și le resetează la unele acțiuni. Modificați drepturile acolo, pe cât posibil, prin funcțiile panoului sau verificați după actualizările panoului dacă setările dumneavoastră se mai aplică.
La shared hosting aveți de obicei un singur utilizator pentru tot. O separare a proprietarului de utilizatorul de execuție nu este atunci posibilă. Cu atât mai importante sunt drepturile restrânse pe fișierele de configurare, lipsa drepturilor 777 și dezactivarea execuției PHP în dosarele de încărcări, în măsura în care furnizorul de hosting o permite.
Cine lucrează cu deployment-uri automate ar trebui să seteze drepturile chiar în scriptul de deployment. Altfel, fiecare versiune nouă restabilește vechea stare, prea deschisă. O verificare scurtă la finalul deployment-ului, de exemplu cu comanda pentru fișiere inscriptibile de mai sus, prinde în mod fiabil asemenea regrese și poate fi integrată fără efort mare în orice pipeline.
Cum ajută PHP SOS concret?
- Inventariem proprietarii, drepturile și utilizatorii de execuție ai tuturor site-urilor de pe server.
- Stabilim un concept de drepturi care se potrivește aplicației și modului dumneavoastră de actualizare.
- Aplicăm drepturile și blocările de execuție și testăm apoi complet site-ul.
- Documentăm conceptul, pentru ca deployment-urile și actualizările să nu-l slăbească din nou.
Cum se încadrează acest lucru într-o securizare de durată descrie serviciul Securizarea serverelor web PHP.
Întrebări frecvente
Sunt vreodată în regulă drepturile 777?
Pe un server de producție practic niciodată. Cu 777, orice utilizator al sistemului poate crea și modifica fișiere. Dacă o aplicație nu rulează fără 777, de regulă proprietarul este setat greșit, nu drepturile sunt prea strânse.
De ce nu ar trebui să aibă serverul web voie să-și modifice propriile fișiere?
Pentru că un cod introdus rulează cu drepturile serverului web. Dacă serverul web are voie să scrie fișiere PHP, un atacator poate manipula scripturi existente sau poate crea uși din spate noi. Dacă separați proprietarul de utilizatorul de execuție, codul rămâne protejat la scriere.
Cum actualizez un CMS dacă serverul web nu are voie să scrie?
Actualizările se fac atunci prin proprietar, de exemplu prin WP-CLI, Composer sau deployment, nu prin butonul de actualizare din backend. Este puțin mai laborios, dar, în schimb, un cod introdus nu poate modifica fișierele programului.
Ce drepturi are nevoie fișierul de configurare cu parola bazei de date?
Cât mai puține posibil: lizibil pentru utilizatorul PHP, pentru nimeni altcineva. Obișnuite sunt 640 cu grupul potrivit sau 400, dacă utilizatorul PHP este el însuși proprietarul.