# Securizarea Nginx cu PHP-FPM

> Securitate Nginx PHP-FPM după PHP2Shell: verificați pool-urile și versiunile, reporniți workerii, setați php_admin_value și securizați Nginx.

Sursa: https://phpsos.de/ro/server/nginx-php-fpm/  
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:** La Nginx cu PHP-FPM, vulnerabilitatea PHP2Shell se află în PHP-FPM, nu în Nginx. Actualizați toate versiunile PHP-FPM, reporniți complet fiecare serviciu FPM și dovediți acest lucru cu orele de pornire ale proceselor. Pentru securitatea pe termen lung a Nginx cu PHP-FPM contează pool-urile separate, valorile care nu pot fi suprascrise și o configurație Nginx care nu execută fișiere încărcate.

## Cum colaborează Nginx și PHP-FPM

Nginx livrează singur fișierele statice și transmite cererile către scripturile PHP prin FastCGI la PHP-FPM. PHP-FPM constă dintr-un proces master și mai multe procese worker, grupate în pool-uri. Un worker procesează pe rând multe cereri.

Exact acest lucru este relevant pentru PHP2Shell. La CVE-2026-109619, starea internă a unei cereri poate rămâne după eliberarea memoriei și poate fi folosită de o cerere ulterioară din același worker. La CVE-2026-109618, o stare de memorie insuficientă (out-of-memory) poate întrerupe PHP chiar în timpul inițializării unei cereri. Ambele vulnerabilități sunt evaluate cu CVSS v4.0 9.2 și sunt remediate în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35.

## Verificați inventarul: versiuni, pool-uri, procese

Multe servere au mai multe versiuni PHP-FPM în paralel. Comenzile următoare doar citesc; numele pachetelor și ale serviciilor sunt exemple pentru Debian/Ubuntu și familia RHEL.

```bash
# Ce servicii FPM rulează?
systemctl list-units --type=service | grep -i fpm

# Ce versiune se află în spate? (exemplu Debian/Ubuntu)
php-fpm8.3 -v
# Familia RHEL
php-fpm -v

# Către ce socketuri sau porturi transmite Nginx?
nginx -T 2>/dev/null | grep -E 'fastcgi_pass'

# Pool-urile și utilizatorii lor
grep -RhE '^\[|^user|^listen' /etc/php/*/fpm/pool.d/ 2>/dev/null
```

Comparați fiecare intrare `fastcgi_pass` cu un pool care rulează. Astfel vedeți ce versiune PHP deservește ce site. La pachetele distribuției, jurnalul de modificări cu numerele CVE dovedește patchul, nu numărul de versiune singur.

O constatare frecventă la astfel de inventare sunt serverele pe care, de-a lungul anilor, au fost instalate mai multe versiuni PHP, dintre care doar una este efectiv folosită. Celelalte servicii FPM rulează totuși mai departe, adesea cu pool-uri standard care ascultă pe un socket sau port local. Din exterior nu sunt de obicei direct accesibile, dar rămân un risc inutil și prelungesc fiecare actualizare de urgență. Dezactivați și eliminați versiunile pe care nu le folosește niciun site, după ce ați verificat atribuirea prin intrările `fastcgi_pass`.

De asemenea, merită o privire asupra utilizatorului pool-urilor. Dacă toate pool-urile rulează ca `www-data` sau `nginx`, separarea dintre site-uri există doar pe hârtie. Cine preia un site poate citi atunci fișierele tuturor celorlalte, de exemplu fișiere de configurare cu parole de baze de date. Utilizatori de sistem proprii pentru fiecare pool și drepturi de fișiere potrivite creează aici o limită reală. Aceasta nu este o remediere pentru PHP2Shell, dar limitează clar paguba posibilă a unui atac reușit.

## Instalați patchul și reînnoiți toți workerii

După actualizarea pachetelor, reporniți fiecare serviciu PHP-FPM. Un reload înlocuiește workerii, dar o repornire completă reînnoiește și procesul master și este calea sigură după actualizările de securitate.

```bash
# Exemplu Debian/Ubuntu, pentru fiecare versiune instalată
systemctl restart php8.3-fpm
# Familia RHEL
systemctl restart php-fpm

# Control: ora de pornire a procesului master și a workerilor
ps -eo pid,lstart,cmd | grep -E 'php-fpm' | grep -v grep
```

Fiecare proces trebuie să fi pornit după actualizare. Detalii găsiți la [Repornirea PHP-FPM și a tuturor workerilor](https://phpsos.de/ro/php2shell/php-fpm-neustart/).

> **Important:**
> Un patch nu elimină programele malițioase introduse anterior. Păstrați jurnalele de acces și de erori Nginx începând cu 20.10.2026 și verificați site-urile pentru urme.

## Setați valori provizorii în pool

Cât timp o versiune nu este actualizată, php.net recomandă măsuri provizorii. Ele nu oferă o protecție completă. În PHP-FPM setați valorile cu `php_admin_value`, respectiv `php_admin_flag`, în pool; astfel aplicațiile nu le pot suprascrie prin `ini_set()`.

```ini
; Exemplu: /etc/php/8.3/fpm/pool.d/website.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
```

Fără funcție de încărcare, php.net indică `post_max_size = 8M`. Pe PHP 8.5 se adaugă `fatal_error_backtraces=0`. Pentru indicația privind `memory_limit=-1` aveți nevoie de o limită de memorie la nivel de cgroup, de exemplu prin `MemoryMax` într-o completare systemd pentru serviciul FPM. Adaptați în Nginx `client_max_body_size` la noul `post_max_size`, pentru ca utilizatorii să primească mesaje de eroare ușor de înțeles. Apoi reporniți FPM.

## Îmbunătățiți durabil securitatea Nginx cu PHP-FPM

Dincolo de cazul acut, câteva reguli de bază ajută să limiteze paguba la vulnerabilitățile viitoare:

- **Un pool pentru fiecare site**, cu utilizator de sistem propriu, socket propriu și limită proprie `open_basedir`. Mai multe la [open_basedir și izolarea pentru fiecare site](https://phpsos.de/ro/ratgeber/open-basedir/).
- **Drepturile socketului** setate astfel încât să acceseze doar Nginx; nu deschideți porturi FPM către exterior.
- **Executați doar scripturi existente:** în locația PHP setați `try_files $uri =404;`, astfel încât Nginx să nu transmită către PHP căi care nu există.
- **Nu executați încărcările:** interziceți execuția PHP în directoarele de încărcare. Indicații găsiți la [Implementarea sigură a încărcărilor de fișiere](https://phpsos.de/ro/ratgeber/datei-upload-sicher/).
- **Protejați paginile de stare:** faceți `pm.status_path` și `ping.path` accesibile doar intern.

```nginx
# Exemplu: fără execuție PHP în directorul de încărcare
location ~* ^/uploads/.*\.php$ {
    deny all;
}
```

Verificați fiecare modificare cu `nginx -t` înainte de a reîncărca Nginx. Consemnați în plus ce pool-uri, versiuni și reguli speciale există pe server. Această scurtă documentație economisește timp prețios la următoarea vulnerabilitate critică, pentru că nimeni nu trebuie să caute mai întâi ce site depinde de ce pool.

## Cum ajută PHP SOS concret?

- Atribuim fiecare site pool-ului și versiunii sale PHP și verificăm starea reală a pachetelor.
- Actualizăm, repornim toate serviciile FPM și documentăm orele de pornire ale proceselor ca dovadă.
- Până la patch, setăm valorile provizorii pentru fiecare pool și limităm memoria prin cgroup.
- În cadrul [securizării serverelor](https://phpsos.de/ro/leistungen/server-haertung/) separăm curat pool-urile, drepturile și directoarele de încărcare.
- La suspiciunea unei intruziuni preluăm [răspunsul la incidente](https://phpsos.de/ro/leistungen/incident-response/).


## Întrebări frecvente

**Este suficient systemctl reload pentru PHP-FPM după o actualizare?**  
Un reload reînnoiește workerii, dar procesul master poate păstra codul vechi. După o actualizare de securitate, o repornire completă a serviciului este calea sigură. Verificați apoi ora de pornire a procesului master și a workerilor.

**Trebuie repornit Nginx după o actualizare PHP?**  
Nginx însuși nu conține PHP și nu trebuie repornit pentru patchul PHP. Trebuie repornite toate serviciile PHP-FPM. Dacă modificați în același timp configurația Nginx, verificați-o înainte de reîncărcare cu nginx -t.

**De ce pool-uri separate pentru fiecare site?**  
Fiecare pool rulează cu utilizator propriu și limite proprii. Dacă un site este compromis, atacatorul nu ajunge fără alte condiții la fișierele celorlalte. În plus, valorile provizorii pot fi setate țintit pentru fiecare pool.

**Este pm.max_requests o protecție împotriva PHP2Shell?**  
Nu, nu înlocuiește un patch. Valoarea limitează câte cereri procesează un worker înainte de a fi înlocuit. Aceasta poate scurta durata de viață a stărilor din proces, dar nu este o remediere indicată de php.net.

## Surse

- [php.net: anunțuri de securitate](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [BSI: Oficiul Federal German pentru Securitatea Informațiilor](https://www.bsi.bund.de/)