# Least Privilege: drepturile utilizatorului serverului web

> Utilizator de server web cu drepturi minime: fără shell, sudo sau cron, drepturi restrânse în baza de date, protecție systemd pentru PHP-FPM.

Sursa: https://phpsos.de/ro/blog/rechte-des-webserver-benutzers/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Utilizatorul serverului web sub care rulează PHP ar trebui, conform principiului drepturilor minime (Least Privilege), să citească doar ce are nevoie site-ul și să scrie doar acolo unde acesta își depune datele. Nu are shell de autentificare, drepturi sudo, cronjob-uri proprii și nici chei SSH, iar contul său de bază de date are voie doar să citească și să modifice date. Opțiuni systemd precum `ProtectSystem` și `PrivateTmp` limitează suplimentar PHP-FPM.

## Întrebarea de după intruziune: ce are voie să facă acest proces?

La PHP2Shell este vorba despre executarea de cod malițios de la distanță, fără autentificare. Dacă reușește, codul nu rulează într-un spațiu gol, ci ca un anumit utilizator: utilizatorul procesului PHP. Tot ce are voie să facă acest utilizator are voie, din acel moment, să facă și atacatorul.

Pe multe servere, acest „tot” este surprinzător de mult. Utilizatorul deține întregul cod de program, are un shell, își poate crea cronjob-uri proprii, iar contul de bază de date al aplicației are toate drepturile asupra tuturor bazelor de date. Pentru un atacator, aceasta este situația ideală pentru a se instala durabil.

Cum atribuiți corect fișierele și directoarele descrie ghidul [Drepturile de fișiere pe serverul web](https://phpsos.de/ro/ratgeber/dateirechte-webserver/). Acest articol se concentrează asupra contului în sine: autentificare, drepturi speciale, sarcini programate, baza de date și limitele pe care le trasează systemd.

## Inventariere: cine este utilizatorul serverului web?

Mai întâi stabiliți ce utilizatori sunt implicați. La PHP-FPM, fiecare pool stabilește prin `user` și `group` sub ce utilizator rulează worker-ii săi. La mod_php, PHP rulează ca utilizator Apache. Cum colaborează master și worker la PHP-FPM explică [PHP-FPM explicat: manager de procese, pool-uri și worker-i](https://phpsos.de/ro/php/php-fpm-erklaert/). Comenzile următoare doar citesc:

```bash
# Sub ce utilizatori rulează serverul web și PHP?
ps -eo user,group,cmd | grep -E "[p]hp-fpm|[n]ginx|[a]pache2|[h]ttpd" | sort | uniq -c
# Datele contului: director home și shell (adaptați utilizatorul)
getent passwd www-data
# Are utilizatorul drepturi sudo?
sudo -l -U www-data
# Eigene Cronjobs?
sudo crontab -l -u www-data
# Chei SSH în directorul home (la Debian/Ubuntu acesta este /var/www)
sudo ls -la /var/www/.ssh 2>/dev/null
```

Notați rezultatele pentru fiecare utilizator de pool. Dacă toate site-urile rulează sub același utilizator, acesta este primul punct de pe listă; cum le separați descrie [Izolarea pool-urilor PHP-FPM pe site](https://phpsos.de/ro/blog/php-fpm-pools-isolieren/).

## Drepturile utilizatorului serverului web: ce nu are nevoie contul

Tabelul următor arată ce nu are nevoie, de regulă, un utilizator de server web și cum îi retrageți aceste drepturi.

| Drept | De ce este periculos | Recomandare |
|---|---|---|
| Shell de autentificare | Autentificarea și utilizarea interactivă devin posibile | Shell `/usr/sbin/nologin` |
| Intrări sudo | Drum spre drepturi de root | Nicio intrare, nici pentru comenzi izolate |
| Crontab propriu | Backdoor permanent, care supraviețuiește oricărei reporniri | Niciuna, limitați prin `/etc/cron.allow` |
| Chei SSH | Autentificare din exterior | Fără `authorized_keys` |
| Proprietatea asupra codului de program | Codul poate fi modificat | Proprietar este un utilizator de deploy |
| Drepturi de scriere în afara directoarelor de date | Depunerea de cod malițios | Doar uploaduri, cache, temp |
| Drepturi depline în baza de date | Bazele de date ale altor aplicații, acces la fișiere prin baza de date | Doar baza proprie de date, doar drepturi asupra datelor |

Setați shell-ul cu `usermod -s /usr/sbin/nologin www-data`. Pentru cron se aplică următoarea regulă: dacă există `/etc/cron.allow`, doar utilizatorii menționați acolo au voie să-și creeze cronjob-uri proprii. Cronjob-urile nou create sau cheile SSH necunoscute sunt un semn tipic că cineva s-a instalat în sistem. Un semnal de alarmă deosebit de clar descrie articolul [Semnal de alarmă: serverul web pornește un shell](https://phpsos.de/ro/blog/webserver-startet-shell/).

## Baza de date: limitați drepturile la strictul necesar

Contul de bază de date al unui site este, practic, un al doilea utilizator de server web. Datele sale de acces se află în fișierul de configurare al aplicației și pot fi citite de codul introdus pe ascuns. De aceea ar trebui să aibă voie doar ce îi trebuie aplicației în funcționare.

```sql
-- Exemplu MySQL/MariaDB: cont propriu pentru fiecare site, doar drepturi asupra datelor
CREATE USER 'seite1'@'localhost' IDENTIFIED BY 'hier-ein-langes-Zufallspasswort';
GRANT SELECT, INSERT, UPDATE, DELETE ON seite1.* TO 'seite1'@'localhost';
-- Verificarea drepturilor
SHOW GRANTS FOR 'seite1'@'localhost';
```

Drepturi precum `FILE`, `SUPER` sau `GRANT OPTION` și accesul la `*.*` nu sunt necesare unui cont de aplicație. Multe CMS-uri au nevoie, pentru actualizări, suplimentar de `CREATE`, `ALTER`, `INDEX` și `DROP`. Mai curat este un cont separat pentru actualizări și migrări, folosit doar în timpul mentenanței. Verificați cerințele în documentația producătorului.

## Limitarea suplimentară a PHP-FPM cu systemd

systemd poate restricționa viziunea unui serviciu asupra sistemului. Pentru PHP-FPM sunt deosebit de potrivite câteva opțiuni din documentația systemd. Ele acționează și asupra procesului master, care pornește ca root.

```ini
# sudo systemctl edit php8.3-fpm
[Service]
# /usr, /boot și /etc doar pentru citire
ProtectSystem=full
# /home, /root și /run/user invizibile
ProtectHome=true
# /tmp și /var/tmp proprii, doar pentru acest serviciu
PrivateTmp=true
# fără extinderea drepturilor prin setuid sau capabilități de fișier
NoNewPrivileges=true
```

Testați aceste opțiuni înainte de utilizarea în producție. Dacă site-urile se află sub `/home`, `ProtectHome=true` împiedică accesul. `NoNewPrivileges=true` poate deranja programele apelate de PHP care își schimbă la pornire drepturile de grup, de exemplu unele programe locale de e-mail pentru funcția PHP `mail()`. De aceea procedați în pași:

1. Adăugați o opțiune, reporniți serviciul, verificați `systemctl status php8.3-fpm`.
2. Testați funcțiile de bază ale site-ului: autentificare, formulare, trimiterea e-mailurilor, uploaduri, cronjob-urile aplicației.
3. Analizați jurnalul de erori al PHP-FPM și al aplicației.
4. Abia apoi adăugați următoarea opțiune.

În final, socket-ul: potrivit manualului PHP, acesta primește implicit drepturile `0660` pentru utilizatorul și grupul pool-ului. Setați `listen.owner` și `listen.group` astfel încât să se poată conecta doar serverul web, nu orice utilizator local.

> **Sfat:**
> Drepturile minime sunt o atitudine, nu un proiect unic. Repetați inventarierea din acest articol după fiecare restructurare și după fiecare site nou, deoarece serviciile noi vin adesea cu drepturi implicite generoase.

## Concluzie: atacatorul moștenește ce permiteți dumneavoastră

Least Privilege sună a teorie, dar este o întrebare foarte practică: ce poate face cineva care execută cod ca utilizator de server web? Pe un server cu shell, intrare sudo, crontab propriu și un cont de bază de date cu toate drepturile, răspunsul este: aproape orice. Pe un server limitat, lucrurile rămân mai degrabă la un incident într-un singur site, care poate fi recunoscut și curățat.

Schimbarea nu cere software nou, ci doar o inventariere atentă și teste treptate. Începeți cu punctele care pot strica foarte puțin, adică shell, sudo și chei SSH, și treceți apoi la drepturile din baza de date și la opțiunile systemd.

## Cum ajută PHP SOS concret?

- **Verificarea conturilor:** Pentru fiecare pool și server web, înregistrăm utilizatorul, shell-ul, intrările sudo, cronjob-urile, cheile SSH și drepturile din baza de date.
- **Reducerea drepturilor:** Retragem ce nu este necesar și separăm conturile de deploy, de execuție și de mentenanță.
- **Limitarea serviciilor:** Setăm treptat opțiunile de protecție systemd și testăm site-ul după fiecare pas.
- **Menținerea pe termen lung:** În cadrul [întăririi serverului](https://phpsos.de/ro/leistungen/server-haertung/) documentăm conceptul de drepturi pentru modificările viitoare.


## Întrebări frecvente

**Sub ce utilizator rulează PHP pe serverul meu?**  
Depinde de modul de operare. La mod_php, PHP rulează ca utilizator Apache, de exemplu www-data sau apache. La PHP-FPM, fiecare pool își stabilește utilizatorul prin user și group; procesul master rulează de obicei ca root, iar procesele worker ca utilizatorul pool-ului. Comanda ps arată rapid acest lucru.

**Are nevoie utilizatorul serverului web de un shell de autentificare?**  
Nu. Nici Nginx, nici Apache, nici PHP-FPM nu au nevoie de o autentificare interactivă pentru acest utilizator. Un shell precum /usr/sbin/nologin împiedică pe oricine să se autentifice cu acest cont. Deployment-urile rulează printr-un utilizator separat.

**De ce nu are voie www-data să aibă drepturi sudo, nici măcar pentru o singură comandă?**  
Pentru că tocmai aceste drepturi le moștenește codul introdus pe ascuns. Chiar și o comandă aparent inofensivă, dacă este permisă greșit, poate duce la drepturi de root. Sarcinile care cer drepturi sporite aparțin unor servicii sau unor procese separate, în afara serverului web.

**Ajută acest lucru împotriva PHP2Shell?**  
Nu închide vulnerabilitatea; pentru aceasta este nevoie de actualizarea PHP și de repornirea tuturor proceselor worker. Drepturile minime limitează însă ce poate face un atacator după o exploatare reușită: să modifice fișiere, să se instaleze persistent, să ajungă la alte site-uri.

## Surse

- [Manualul PHP: configurarea FPM (user, listen.mode)](https://www.php.net/manual/en/install.fpm.configuration.php)
- [systemd.exec (ProtectSystem, PrivateTmp, NoNewPrivileges)](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html)
- [BSI IT-Grundschutz (Oficiul Federal German pentru Securitatea Informațiilor)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)