# Least Privilege: i permessi dell'utente del server web

> Utente del server web con privilegi minimi: niente shell, sudo né cron, diritti ridotti sul database e protezione systemd per PHP-FPM. Con verifiche.

Fonte: https://phpsos.de/it/blog/rechte-des-webserver-benutzers/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** l'utente del server web con cui gira PHP dovrebbe, secondo il principio dei privilegi minimi (Least Privilege), leggere solo ciò che serve al sito e scrivere solo dove il sito archivia i dati. Non ha una shell di login, né diritti sudo, né cronjob propri, né chiavi SSH, e il suo account del database può soltanto leggere e modificare dati. Opzioni di systemd come `ProtectSystem` e `PrivateTmp` delimitano ulteriormente PHP-FPM.

## La domanda dopo l'intrusione: che cosa può fare questo processo?

Con PHP2Shell si tratta dell'esecuzione di codice malevolo da remoto senza autenticazione. Se riesce, il codice non gira nel vuoto, ma come un utente ben preciso: l'utente del processo PHP. Tutto ciò che questo utente può fare, da quel momento lo può fare anche l'aggressore.

Su molti server è sorprendentemente tanto. L'utente possiede l'intero codice del programma, ha una shell, può creare cronjob propri, e l'account del database dell'applicazione ha tutti i diritti su tutti i database. Per un aggressore è la situazione ideale per insediarsi in modo duraturo.

Come assegnare correttamente file e cartelle lo descrive la guida [Permessi dei file sul server web](https://phpsos.de/it/ratgeber/dateirechte-webserver/). Questo articolo guarda all'account stesso: accesso, diritti speciali, attività pianificate, database e i confini che pone systemd.

## Inventario: chi è l'utente del server web?

Per prima cosa si chiarisce quali utenti sono coinvolti. Con PHP-FPM ogni pool stabilisce con `user` e `group` sotto quale utente girano i suoi worker. Con mod_php, PHP gira come utente di Apache. Come collaborano master e worker in PHP-FPM lo spiega [PHP-FPM spiegato: gestore di processi, pool e worker](https://phpsos.de/it/php/php-fpm-erklaert/). I comandi seguenti leggono soltanto:

```bash
# Con quali utenti girano server web e PHP?
ps -eo user,group,cmd | grep -E "[p]hp-fpm|[n]ginx|[a]pache2|[h]ttpd" | sort | uniq -c
# Dati dell'account: directory home e shell (adattare l'utente)
getent passwd www-data
# L'utente ha diritti sudo?
sudo -l -U www-data
# Cronjob propri?
sudo crontab -l -u www-data
# Chiavi SSH nella directory home (su Debian/Ubuntu è /var/www)
sudo ls -la /var/www/.ssh 2>/dev/null
```

Annoti i risultati per ogni utente di pool. Se tutti i siti girano sotto lo stesso utente, questo è il primo punto della lista; come separarli lo descrive [Isolare i pool PHP-FPM per ogni sito](https://phpsos.de/it/blog/php-fpm-pools-isolieren/).

## Permessi dell'utente del server web: che cosa l'account non serve

La tabella seguente mostra ciò che un utente del server web in genere non richiede e come toglierlo.

| Diritto | Perché è pericoloso | Raccomandazione |
|---|---|---|
| Shell di login | Possibili accesso e uso interattivo | Shell `/usr/sbin/nologin` |
| Voci sudo | Via verso i privilegi di root | Nessuna voce, nemmeno per singoli comandi |
| Crontab propria | Backdoor duratura che sopravvive a ogni riavvio | Nessuna, limitare con `/etc/cron.allow` |
| Chiavi SSH | Accesso dall'esterno | Nessun `authorized_keys` |
| Proprietà del codice del programma | Il codice può essere modificato | Il proprietario è un utente di deploy |
| Scrittura fuori dalle cartelle dei dati | Deposito di codice malevolo | Solo upload, cache, temp |
| Diritti completi sul database | Database di altre applicazioni, accesso ai file tramite il database | Solo il proprio database, solo diritti sui dati |

La shell si imposta con `usermod -s /usr/sbin/nologin www-data`. Per cron vale quanto segue: se esiste `/etc/cron.allow`, solo gli utenti ivi elencati possono creare cronjob propri. Cronjob appena creati o chiavi SSH sconosciute sono un segno tipico che qualcuno si è insediato. Un segnale d'allarme particolarmente evidente lo descrive l'articolo [Segnale d'allarme: il server web avvia una shell](https://phpsos.de/it/blog/webserver-startet-shell/).

## Il database: limitare i diritti allo stretto necessario

L'account del database di un sito è di fatto un secondo utente del server web. Le sue credenziali si trovano nel file di configurazione dell'applicazione e sono leggibili dal codice iniettato. Per questo dovrebbe poter fare solo ciò che all'applicazione serve durante il funzionamento.

```sql
-- Esempio MySQL/MariaDB: un account per sito, solo diritti sui dati
CREATE USER 'seite1'@'localhost' IDENTIFIED BY 'hier-ein-langes-Zufallspasswort';
GRANT SELECT, INSERT, UPDATE, DELETE ON seite1.* TO 'seite1'@'localhost';
-- Verificare i diritti
SHOW GRANTS FOR 'seite1'@'localhost';
```

Diritti come `FILE`, `SUPER` o `GRANT OPTION` e l'accesso a `*.*` non servono a un account applicativo. Molti CMS richiedono in più `CREATE`, `ALTER`, `INDEX` e `DROP` per gli aggiornamenti. È più pulito un account separato per aggiornamenti e migrazioni, usato solo durante la manutenzione. Verifichi i requisiti nella documentazione del produttore.

## Delimitare ulteriormente PHP-FPM con systemd

systemd può limitare la visione del sistema che un servizio ha. Per PHP-FPM sono particolarmente adatte alcune opzioni della documentazione di systemd. Agiscono anche sul processo master, che parte come root.

```ini
# sudo systemctl edit php8.3-fpm
[Service]
# /usr, /boot e /etc in sola lettura
ProtectSystem=full
# /home, /root e /run/user invisibili
ProtectHome=true
# /tmp e /var/tmp propri solo per questo servizio
PrivateTmp=true
# nessuna estensione dei privilegi tramite setuid o capability dei file
NoNewPrivileges=true
```

Provi queste opzioni prima dell'uso in produzione. Se i siti si trovano in `/home`, `ProtectHome=true` impedisce l'accesso. `NoNewPrivileges=true` può disturbare i programmi che PHP richiama e che all'avvio cambiano i propri diritti di gruppo, ad esempio alcuni programmi di posta locali per la funzione PHP `mail()`. Proceda perciò per gradi:

1. Aggiungere un'opzione, riavviare il servizio, controllare `systemctl status php8.3-fpm`.
2. Provare le funzioni centrali del sito: accesso, moduli, invio di e-mail, upload, cronjob dell'applicazione.
3. Analizzare il log degli errori di PHP-FPM e dell'applicazione.
4. Solo allora aggiungere l'opzione successiva.

Infine il socket: secondo il manuale PHP riceve per impostazione predefinita i diritti `0660` per utente e gruppo del pool. Imposti `listen.owner` e `listen.group` in modo che possa connettersi solo il server web, non ogni utente locale.

> **Consiglio:**
> I privilegi minimi sono un atteggiamento di fondo, non un progetto una tantum. Ripeta l'inventario di questo articolo dopo ogni ristrutturazione e per ogni nuovo sito, perché i nuovi servizi portano spesso con sé diritti predefiniti generosi.

## Conclusione: l'aggressore eredita ciò che Lei consente

Il Least Privilege suona teorico, ma è una questione molto pratica: che cosa può fare chi esegue codice come utente del server web? Su un server con shell, voce sudo, crontab propria e un account del database con tutti i diritti la risposta è: quasi tutto. Su un server delimitato resta più facilmente un incidente su un singolo sito, che si può individuare e bonificare.

Il passaggio non richiede nuovo software, solo un inventario accurato e test graduali. Cominci dai punti che difficilmente possono rompere qualcosa, cioè shell, sudo e chiavi SSH, e proceda poi con i diritti del database e le opzioni di systemd.

## Come aiuta concretamente PHP SOS?

- **Verificare gli account:** per ogni pool e utente del server web rileviamo shell, voci sudo, cronjob, chiavi SSH e diritti sul database.
- **Ridurre i privilegi:** togliamo ciò che non serve e separiamo gli account di deploy, di esecuzione e di manutenzione.
- **Delimitare i servizi:** impostiamo le opzioni di protezione di systemd per gradi e proviamo il sito dopo ogni passo.
- **Mantenerlo nel tempo:** nell'ambito dell'[hardening del server](https://phpsos.de/it/leistungen/server-haertung/) documentiamo il concetto dei privilegi per le modifiche future.


## Domande frequenti

**Con quale utente gira PHP sul mio server?**  
Dipende dalla modalità di esecuzione. Con mod_php, PHP gira come utente di Apache, ad esempio www-data o apache. Con PHP-FPM ogni pool definisce il proprio utente con user e group; il processo master di solito gira come root, i worker come utente del pool. Il comando ps lo mostra in fretta.

**L'utente del server web ha bisogno di una shell di login?**  
No. Né Nginx né Apache né PHP-FPM richiedono un accesso interattivo per questo utente. Una shell come /usr/sbin/nologin impedisce che qualcuno acceda con questo account. I deployment passano da un utente dedicato.

**Perché nessun diritto sudo per www-data, nemmeno per un solo comando?**  
Perché il codice iniettato eredita proprio questi diritti. Anche un comando apparentemente innocuo, autorizzato in modo errato, può portare ai privilegi di root. I compiti che richiedono privilegi elevati vanno affidati a servizi o procedure separati, fuori dal server web.

**Serve contro PHP2Shell?**  
Non chiude la vulnerabilità: per questo servono l'aggiornamento di PHP e il riavvio di tutti i worker. Privilegi minimi limitano però ciò che un aggressore può fare dopo uno sfruttamento riuscito: modificare file, stabilirsi in modo duraturo, raggiungere altri siti.

## Fonti

- [Manuale PHP: configurazione di 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](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/)