In breve: i processi sospetti sui server Linux si riconoscono da poche caratteristiche: file di programma cancellato o in /tmp, /dev/shm o in una directory web, nome che imita un processo di sistema, utente insolito, connessioni di rete permanenti o carico elevato senza motivo. Con comandi di sola lettura verifichi se il file di programma appartenga a un pacchetto installato e conservi i ritrovamenti prima di terminare qualcosa.
Cosa significa «sospetto» per un processo
Su un server web girano centinaia di processi. La maggior parte appartiene al sistema operativo, al server web, al database o a PHP. Un aggressore che ha potuto eseguire codice attraverso una vulnerabilità come PHP2Shell cerca di non dare nell'occhio in mezzo a essi. Sceglie nomi poco appariscenti e deposita i programmi dove l'utente del server web può scrivere.
Per la verifica aiuta conoscere lo stato normale. Chi sa quali servizi debbano girare su un server, sotto quali utenti e con quale carico, riconosce molto più in fretta gli scostamenti. Se manca questa conoscenza, conviene usare per confronto l'elenco dei processi di un server analogo e non sospetto.
Una singola caratteristica non è ancora una prova. Decisiva è l'interazione. Un processo con il nome di un thread del kernel, che gira sotto www-data, è stato avviato da /dev/shm e mantiene una connessione verso l'estero è un caso chiaro. Come verificare il caso particolare di una shell sotto il server web lo descrive Segnale d'allarme: il server web avvia una shell.
Primo quadro in cinque comandi
Tutti i comandi leggono soltanto. Li esegua come root per vedere tutti i processi e salvi gli output in un file fuori dalla directory web.
# 1. Tutti i processi con utente, PID del padre, ora di avvio, CPU e riga di comando
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Processi il cui file di programma è stato cancellato
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Processi che girano da directory temporanee o web
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Processi con connessioni di rete
ss -tunap
# 5. Panoramica dei processi degli utenti del server web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
I nomi utente differiscono a seconda di distribuzione e pannello; Plesk e altri pannelli eseguono spesso PHP sotto l'utente del rispettivo cliente. Adatti l'elenco al Suo ambiente.
Legga gli output guardando l'ora di avvio. I processi in esecuzione dall'ultimo riavvio del server di solito appartengono al sistema. I processi avviati nel cuore della notte o nei giorni dopo il 17 ottobre e che non corrispondono a nessun servizio meritano attenzione. Confronti anche il numero di processi PHP con quanto consente la configurazione dei pool; un numero nettamente maggiore di processi sotto un utente del server web è un indizio.
Processi sospetti su Linux: caratteristiche tipiche
| Caratteristica | Perché spicca | Possibile spiegazione innocua? |
|---|---|---|
| File di programma «(deleted)» | gli aggressori cancellano i file dopo l'avvio | sì, dopo gli aggiornamenti dei pacchetti fino al riavvio |
Luogo di avvio /tmp, /dev/shm, cartella di upload |
lì possono scrivere tutti o il server web | raramente |
Nome tra parentesi quadre come [kworker] |
imita i thread del kernel | no, se dietro c'è un file di programma |
| Carico di CPU permanentemente alto senza motivo | tipico dei cryptominer | sì, con job batch o indicizzazione |
| Processo padre 1 e utente del server web | staccato dal server web, continua a girare in modo autonomo | raramente |
| Connessione a una destinazione sconosciuta | controllo o fuga di dati | sì, con aggiornamenti e API |
I veri thread del kernel non hanno un file di programma; ls -l /proc/PID/exe per loro non restituisce alcun percorso. Se un processo con nome da kernel rimanda a un file, è mimetizzato. Con un carico elevato senza motivo riconoscibile aiuta l'articolo Cryptominer sul server web.
Controprova: il file di programma appartiene a un pacchetto?
Quasi tutti i programmi legittimi su un server provengono dalla gestione dei pacchetti. Un file di programma che non appartiene a nessun pacchetto non è automaticamente dannoso, ma merita uno sguardo attento.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: a quale pacchetto appartiene il file?
rpm -qf "$EXE" # famiglia RHEL
sha256sum /proc/$PID/exe # somma di controllo, funziona anche con file cancellato
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # variabili d'ambiente
Se il file di programma è cancellato, sha256sum /proc/$PID/exe lo legge comunque dal processo in esecuzione. Questa somma di controllo va nella documentazione. Una copia del file dovrebbe farla solo chi sa come conservarla in sicurezza.
Limiti della verifica sul sistema in esecuzione
Tutti i comandi qui sopra si fidano del sistema che sta verificando. In un'intrusione ordinaria tramite il sito con i diritti dell'utente del server web è accettabile. Se un aggressore ha ottenuto i diritti di root, può nascondere processi e falsificare gli output. Allora il server mostra solo ciò che l'aggressore consente.
Indizi in tal senso sono le contraddizioni: carico senza processo visibile, connessioni che il firewall vede ma ss no, o programmi di sistema modificati. In tali casi la verifica va fatta su un'immagine conservata. Sui sistemi in esecuzione si aggiunge spesso un salvataggio della memoria di lavoro, perché alcuni programmi dannosi esistono solo lì e sul disco lasciano poche tracce. Questo salvataggio deve avvenire prima di un riavvio e richiede strumenti ed esperienza adatti. Perché dovrebbe farlo prima di una reinstallazione lo spiega Conservare le prove prima di reinstallare.
Non termini i processi sospetti come primo passo. Spesso un cron job o un servizio li riavvia, e con il processo scompaiono dalla memoria riga di comando, connessioni e file di programma cancellato.
Verificare gli avvii automatici e i passi successivi
Un processo dannoso che sparisse dopo un riavvio sarebbe inutile per gli aggressori. Perciò a ogni ritrovamento di processo appartiene la domanda su cosa lo avvii. Oltre ai cron job entrano in questione soprattutto i servizi systemd, che un aggressore con diritti di root può creare. Spiccano i servizi con nomi generici il cui file di programma si trova in una directory insolita e i file unit nati dopo il 17 ottobre.
# Servizi in esecuzione e file unit modificati di recente
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# Una libreria viene inserita in ogni processo? Normalmente il file non esiste.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Una voce in /etc/ld.so.preload è rara sui normali server web e un forte indizio di manipolazione con diritti di root. Come verificare per intero le attività pianificate lo descrive Riconoscere i cron job nascosti come backdoor.
Seguono poi i passi successivi in quest'ordine:
- Conservare output e somme di controllo con l'ora.
- Cercare la persistenza: cron job, servizi e timer systemd, chiavi SSH.
- Chiarire l'origine: log a partire dal 20 ottobre, nuovi file nella directory web.
- Isolare il server e pianificare bonifica o ricostruzione.
Una panoramica di tutti i segni tipici dopo PHP2Shell la dà Sono già compromesso?.
Come aiuta concretamente PHP SOS?
- Valutare i processi: verifichiamo elenco dei processi, file di programma e connessioni e inquadriamo ogni ritrovamento.
- Conservare in modo probatorio: con l'analisi forense IT conserviamo memoria di lavoro e supporti dati prima che qualcosa venga modificato.
- Trovare la persistenza: cerchiamo i meccanismi che riavviano i processi dannosi.
- Concludere: bonifichiamo o ricostruiamo e documentiamo l'incidente fino alla chiusura.
Domande frequenti
Da cosa riconosco un processo sospetto su Linux?
Caratteristiche tipiche sono un file di programma cancellato, un luogo di avvio in /tmp o /dev/shm, un nome che imita un processo di sistema, un utente insolito e connessioni di rete permanenti. Singole caratteristiche sono indizi, più insieme un sospetto serio.
Cosa significa «(deleted)» in /proc/PID/exe?
Il file di programma del processo è stato cancellato dopo l'avvio. Succede legittimamente dopo gli aggiornamenti dei pacchetti, finché il servizio non si riavvia. Per i processi da cartelle temporanee o sotto l'utente del server web è un tipico comportamento di mimetizzazione.
Posso fidarmi dell'output di ps?
In un'intrusione ordinaria di solito sì. Se però un aggressore ha ottenuto i diritti di root, può manipolare strumenti e output. Allora è più affidabile una verifica dall'esterno, ad esempio su un'immagine conservata.
Devo terminare un processo sospetto con kill?
Non come prima cosa. Conservi prima riga di comando, file di programma, connessioni e ora di avvio. Un processo terminato non rivela più nulla, e spesso un cron job o un servizio lo riavvia comunque.