# Segnale d'allarme: il server web avvia una shell

> PHP-FPM o Apache avvia una shell? Come leggere l'albero dei processi, distinguere i casi innocui dalle tracce di intrusione e monitorare il modello nel tempo.

Fonte: https://phpsos.de/it/blog/webserver-startet-shell/  
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:** se PHP-FPM, Apache o un altro processo del server web avvia una shell come `sh` o `bash`, è uno dei segnali d'allarme più forti di un'intrusione tramite il sito. Verifichi l'albero dei processi, la riga di comando e la directory di lavoro della shell prima di terminare qualcosa. Singole shell brevi possono essere legittime; shell di lunga durata con strumenti di rete quasi mai lo sono.

## Perché questo modello dice così tanto

Un server web risponde a richieste. PHP-FPM, cioè il gestore di processi che esegue gli script PHP per il server web, normalmente non avvia per questo altri programmi. Una shell sotto il server web significa che del codice PHP ha richiamato deliberatamente un programma. O lo fa l'applicazione di proposito, oppure qualcun altro ha inserito del codice.

Per PHP2Shell non esistono Indicators of Compromise pubblicati e confermati, cioè nessun elenco di segni di riconoscimento fissi. Il rilevamento si basa sul comportamento. Secondo i rapporti di cui disponiamo, i processi del server web o di PHP-FPM che avviano una shell figurano tra i più forti segnali d'allarme generali. Vale per ogni vulnerabilità attraverso cui gli aggressori eseguono codice sul server. Una panoramica di altri indizi la dà [Sono già compromesso?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/).

Perché la shell è così importante per un aggressore? Con una vulnerabilità può dapprima impartire solo singoli comandi tramite il processo PHP. Una shell ne fa una comoda postazione di lavoro: può guardarsi intorno, scaricare strumenti, leggere credenziali dai file di configurazione e stabilirsi in modo permanente. Chi riconosce la shell riconosce quindi spesso l'aggressore nel momento in cui passa dal primo accesso al vero obiettivo.

## PHP-FPM avvia bash: leggere l'albero dei processi

Ogni processo su Linux ha un processo padre. La domanda è se una shell giri come figlia di un processo del server web. I comandi seguenti leggono soltanto:

```bash
# Albero dei processi con utente, PID del padre e ora di avvio
ps -eo user,pid,ppid,lstart,cmd --forest | grep -B2 -A4 -E "[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp"

# Shell che girano sotto utenti tipici del server web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) " | grep -E "[ /](ba|da)?sh( |$)"

# Albero a partire dal processo PHP-FPM più vecchio
pstree -alp "$(pgrep -o php-fpm)"
```

Se ha trovato una shell sospetta, le voci sotto `/proc` forniscono altri indizi, anch'esse solo in lettura:

```bash
PID=12345   # PID della shell sospetta
tr '\0' ' ' < /proc/$PID/cmdline; echo        # riga di comando completa
ls -l /proc/$PID/cwd /proc/$PID/exe            # directory di lavoro e file del programma
ls -l /proc/$PID/fd 2>/dev/null | grep socket  # connessioni di rete aperte
```

I nomi dei processi su Debian e Ubuntu sono spesso `php8.3-fpm` o simili; adatti i modelli di ricerca. Directory di lavoro in `/tmp`, `/dev/shm` o in cartelle di upload sono un segno evidente.

## Eccezioni legittime e veri segnali d'allarme

Alcune applicazioni richiamano programmi tramite PHP. In tal caso può nascere brevemente una shell, ad esempio quando PHP passa e-mail tramite `sendmail_path` o un'applicazione elabora immagini con uno strumento esterno. Tali shell vivono solo secondi e richiamano sempre lo stesso programma. Documenti una volta per tutte questi casi attesi; così ogni scostamento salta subito all'occhio, invece di perdersi in un'ondata di segnalazioni note.

| Osservazione | Piuttosto innocua se | Sospetta se |
|---|---|---|
| Shell breve sotto PHP-FPM | avvia un programma noto dell'applicazione | destinazione e scopo non sono chiari |
| Shell di lunga durata | mai | resta in esecuzione per minuti o ore |
| Strumenti di rete come processo figlio | nota interrogazione di aggiornamento o API dell'applicazione | seguono download in directory temporanee |
| Directory di lavoro | cartella di progetto dell'applicazione | `/tmp`, `/dev/shm`, cartella di upload |
| Momento | corrisponde a un'azione nota, ad esempio l'invio di e-mail | di notte, senza attività degli utenti, in modo ripetuto |

Se non sa se la Sua applicazione richiami programmi, chieda allo sviluppatore o cerchi nel codice funzioni come `exec`, `shell_exec`, `system`, `passthru`, `proc_open` e `popen`. Corrispondenze nel codice proprio sono normali, in file sconosciuti no.

## Monitorare in modo permanente invece di controllare una volta

Un'istantanea con `ps` coglie solo le shell in esecuzione in quel momento. I processi di breve durata sfuggono. Più affidabile è registrare in modo permanente gli avvii di programmi da parte dell'utente del server web. Su Linux lo fa il servizio di audit auditd con una regola per gli avvii di programmi dell'utente del server web. La valutazione avviene in lettura:

```bash
# Mostrare gli avvii di programmi registrati sotto una chiave di regola (chiave come esempio)
sudo ausearch -k web_exec --start today -i | grep -E "exe=|proctitle="
```

Come sia fatta la regola dipende da distribuzione e ID utente; la provi prima, perché sui server molto carichi nascono molte voci.

Due integrazioni rendono il monitoraggio affidabile. Primo, i log dovrebbero andare anche a un sistema centrale, perché un aggressore con diritti di root può cancellare i log locali. Secondo, serve un allarme: un avvio di programma dell'utente del server web che non figuri in un breve elenco di programmi attesi dovrebbe generare una segnalazione, non solo una voce di log. Chi già usa una soluzione per il rilevamento su endpoint o server può riprodurre lì la stessa regola. In via preventiva con `disable_functions` si può bloccare ciò che l'applicazione non richiede. Non chiude una vulnerabilità nell'interprete, ma rende più difficile il passo successivo di un aggressore. I dettagli sono in [Usare correttamente disable_functions](https://phpsos.de/it/ratgeber/disable-functions/).

## Cosa fare se trova una shell sotto il server web

1. **Documentare:** salvare l'output di `ps`, la riga di comando, la directory di lavoro e le connessioni aperte in un file fuori dalla directory web.
2. **Non ripulire:** non cancellare file e non terminare processi prima di aver conservato le tracce.
3. **Isolare:** scollegare il server dalla rete o limitare fortemente l'accesso.
4. **Cercare la causa:** verificare log, nuovi file e persistenza come i cron job, vedi [Individuare processi sospetti sui server Linux](https://phpsos.de/it/blog/verdaechtige-prozesse-linux/).
5. **Cambiare gli accessi:** tutte le password e le chiavi che si trovavano sul server si considerano note.

Se l'applicazione gira in container, vale lo stesso principio in piccolo. Una shell nel container PHP è sospetta quanto su un server classico, e le immagini dei container spesso la contengono solo perché l'immagine di base la porta con sé. Prima di riavviare il container conservi il suo stato, perché con il container scompaiono anche le tracce nel file system volatile.

Verifichi inoltre i dintorni. Un aggressore con una shell su un server web cerca spesso di raggiungere da lì altri sistemi, ad esempio il database, l'archivio dei backup o le interfacce di gestione interne. Le credenziali nei file di configurazione dell'applicazione glielo rendono facile.

> **Agire subito:**
> Una shell di lunga durata sotto PHP-FPM su un server con dati dei clienti è un incidente di sicurezza. La tratti come tale: conservare, isolare, elaborare in modo strutturato, far verificare gli obblighi di notifica.

## Come aiuta concretamente PHP SOS?

- **Inquadrare il riscontro:** verifichiamo albero dei processi, righe di comando e connessioni e distinguiamo il comportamento dell'applicazione dalle tracce di intrusione.
- **Conservare le tracce:** conserviamo lo stato del sistema in modo tracciabile prima di modificare qualcosa.
- **Gestire l'incidente:** con l'[incident response](https://phpsos.de/it/leistungen/incident-response/) guidiamo dal contenimento alla chiusura documentata.
- **Mettere in sicurezza nel tempo:** configuriamo la registrazione degli avvii di programmi e limitiamo le funzioni PHP al necessario. Come lavori internamente PHP-FPM lo spiega [PHP-FPM spiegato](https://phpsos.de/it/php/php-fpm-erklaert/).


## Domande frequenti

**Ogni shell sotto PHP-FPM è un attacco?**  
Non ogni shell. Alcune applicazioni richiamano deliberatamente programmi tramite PHP, ad esempio per l'elaborazione di immagini o l'invio di e-mail, e in tal caso può nascere brevemente una shell. Diventa sospetto se la shell resta in esecuzione più a lungo, avvia strumenti di rete o lavora da directory insolite.

**Devo terminare subito il processo sospetto?**  
Prima documentare, poi agire. Conservi dati del processo, riga di comando, directory di lavoro e connessioni di rete. Poi isoli il server. Una terminazione affrettata distrugge tracce e non impedisce all'aggressore di tornare.

**Esistono per PHP2Shell segni di riconoscimento confermati?**  
No. Non esistono Indicators of Compromise pubblicati e confermati. Le shell sotto il server web sono un segnale d'allarme generale per le intrusioni tramite applicazioni web, non specifico per PHP2Shell.

**Come impedisco che PHP avvii shell?**  
Tramite disable_functions si possono bloccare funzioni come exec, shell_exec, system e proc_open, se l'applicazione non ne ha bisogno. Non chiude una vulnerabilità nell'interprete PHP, ma ne rende più difficile lo sfruttamento.

## Fonti

- [BSI: Ufficio federale tedesco per la sicurezza informatica](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: segnalazioni di sicurezza](https://www.php.net/)