Indice dei contenuti dell'articolo:
Il costo nascosto dei siti compromessi su server di hosting condiviso
Chi gestisce un server di hosting condiviso — che sia uno stack LAMP/LEMP, cPanel, Plesk, DirectAdmin o un’infrastruttura custom — si è quasi certamente trovato ad affrontare questo scenario: uno dei centinaia di siti web ospitati sul server viene compromesso, e prima che qualcuno se ne accorga, ha silenziosamente inviato migliaia di email di spam per ore, a volte per giorni interi.
Le conseguenze sono immediate e devastanti. L’indirizzo IP del server finisce nelle principali blacklist come Spamhaus, Barracuda e SORBS. Tutti i clienti legittimi di quel server smettono improvvisamente di poter inviare email. Il data center apre un ticket di abuso. La reputazione dell’IP — e spesso dell’intero range — viene compromessa. E la parte peggiore? Capire quale sito sia il responsabile è come cercare un ago in un pagliaio.
Ma le conseguenze non finiscono qui. Un server che invia spam consuma risorse CPU, memoria e banda di rete in modo anomalo. I processi PHP-FPM dei siti compromessi possono saturare i worker disponibili, causando rallentamenti a tutti gli altri siti ospitati sullo stesso server. In scenari estremi, il provider upstream può decidere di sospendere l’intero server o addirittura nullo-routare l’IP. E non dimentichiamo le implicazioni legali: la normativa anti-spam (CAN-SPAM negli USA, GDPR in Europa, il D.Lgs. 196/2003 in Italia) prevede responsabilità anche per chi, per negligenza, permette l’invio di comunicazioni commerciali non sollecitate dalla propria infrastruttura.
Questo è un problema con cui ci confrontiamo quotidianamente in Managed Server, ed è la ragione per cui abbiamo sviluppato SMTP Connection Monitor — uno strumento open source che risolve il problema in pochi secondi.
Perché gli approcci tradizionali non funzionano
Prima di approfondire la nostra soluzione, è importante capire perché i metodi convenzionali per identificare una fonte di spam su un server condiviso risultano così frustranti e, nella maggior parte dei casi, del tutto inadeguati.
I log di posta non raccontano tutta la storia. Controllare /var/log/maillog o /var/log/mail.log mostra mittenti e destinatari delle email, ma su un server multi-tenant con pool PHP-FPM separati per ogni utente, l’utente di sistema che ha originato l’invio è spesso assente o inaffidabile. Se lo script compromesso utilizza la funzione mail() nativa di PHP, l’email passa attraverso l’MTA locale (Postfix, Exim) che la logga come proveniente dall’utente del web server — non dal singolo proprietario del sito. Su un server con 200 siti, questo non aiuta affatto.
Le connessioni SMTP dirette sono completamente invisibili ai log di posta. Il malware PHP moderno è sofisticato. Invece di usare mail(), apre connessioni socket dirette verso server SMTP esterni utilizzando librerie come PHPMailer, SwiftMailer, Symfony Mailer, o chiamate raw a fsockopen() e stream_socket_client(). Queste connessioni bypassano completamente l’MTA locale. Non appaiono in nessun log di posta. Le email vengono spedite direttamente dal processo PHP ai server SMTP di Gmail, Outlook, o a relay di botnet, e i vostri log mostrano il nulla assoluto.
Gli strumenti di rete non hanno contesto a livello di processo. Si potrebbe lanciare tcpdump o ngrep e vedere le connessioni TCP verso la porta 587, ma tutto ciò che si ottiene è IP sorgente (il vostro server) e IP di destinazione. Non c’è modo di sapere quale processo, quale utente o quale sito abbia iniziato quella connessione. Su un server con centinaia di pool PHP-FPM attivi, questa informazione è praticamente inutile.
strace è impraticabile su scala. Attaccare strace a ogni worker PHP-FPM su un server di produzione non è realistico. Introduce un overhead significativo sulle performance, è fragile (un worker che muore e viene ricreato sfugge al trace), e richiederebbe di tracciare potenzialmente centinaia di processi contemporaneamente.
Le soluzioni PHP-side hanno controindicazioni. Approcci come auto_prepend_file o disable_functions nel php.ini richiedono modifiche alla configurazione PHP per ogni pool, possono rompere la funzionalità di siti legittimi, aggiungono latenza a ogni singola richiesta PHP, e non coprono i casi in cui lo spammer usa un binario compilato o uno script in un altro linguaggio.
SMTP Connection Monitor: la soluzione
SMTP Connection Monitor è un programma leggero scritto in C che sfrutta il sottosistema di audit del kernel Linux per intercettare e loggare ogni connessione in uscita verso le porte SMTP (25, 465, 587 e 2525) in tempo reale. Per ogni connessione, mostra esattamente chi l’ha iniziata: lo username di sistema, il nome del processo, il PID, l’IP di destinazione e la directory di lavoro corrente.
Lo strumento è disponibile su GitHub con licenza MIT: https://github.com/MarcoMarcoaldi/smtp-monitor
Funziona in tre modalità: un’interfaccia terminale interattiva basata su ncurses con output colorato e controlli da tastiera, una modalità testo su stdout per il piping verso altri strumenti, e una modalità di logging su file per il monitoraggio continuo in background.
Architettura tecnica: come funziona sotto il cofano
L’architettura tecnica è ciò che rende questo strumento sia affidabile che efficiente. Ecco cosa succede quando lo lanciate.
Iniezione delle regole di audit nel kernel
All’avvio, il monitor inietta regole di audit nel kernel tramite auditctl:
auditctl -a always,exit -F arch=b64 -S connect -k smtp_mon_<PID>
auditctl -a always,exit -F arch=b32 -S connect -k smtp_mon_<PID>Queste regole istruiscono il kernel a generare un evento di audit ogni volta che un qualsiasi processo sul sistema invoca la syscall connect() — la chiamata di sistema usata per iniziare una connessione di rete. Le regole coprono sia l’ABI a 64 bit che quella a 32 bit per intercettare ogni possibile chiamante. Quando il monitor termina, le regole vengono automaticamente rimosse, senza lasciare alcuna traccia nel sistema.
Parsing del log in tempo reale con inotify
Anziché aprire un socket netlink raw verso il sottosistema di audit del kernel (il che entrerebbe in conflitto con auditd e potenzialmente comprometterebbe l’infrastruttura di audit esistente), il monitor legge /var/log/audit/audit.log in tempo reale utilizzando l’API inotify di Linux. Pensatelo come un tail -F altamente ottimizzato implementato in C puro.
Questo design coesiste perfettamente con auditd. Non è necessario stoppare, riavviare o riconfigurare il demone di audit. Il monitor legge semplicemente lo stesso file di log che auditd scrive.
Gestisce inoltre la rotazione dei log in modo trasparente. Monitorando la directory padre per eventi IN_CREATE, rileva quando il file di log viene ruotato (nuovo inode) e riapre automaticamente il nuovo file, senza perdere nemmeno un evento.
Correlazione multi-record tramite serial number
Il sottosistema di audit di Linux non emette un singolo record per evento — emette più record correlati da un numero seriale comune nel campo msg=audit(TIMESTAMP:SERIAL). Per una syscall connect(), si trovano tipicamente tre record correlati:
Record SYSCALL — contiene i metadati del processo: PID, UID, effective UID (euid), percorso dell’eseguibile e nome del comando.
Record SOCKADDR — contiene l’indirizzo del socket raw (saddr) sotto forma di blob binario codificato in esadecimale, che include la famiglia di indirizzi, la porta di destinazione e l’indirizzo IP.
Record CWD — contiene la directory di lavoro del processo al momento della syscall.
Il monitor mantiene una cache circolare di 4.096 record SYSCALL recenti. Quando arriva un record SOCKADDR, ne estrae il numero seriale, cerca il SYSCALL corrispondente nella cache, decodifica l’indirizzo del socket in formato hex, e se la porta di destinazione corrisponde a una porta SMTP, crea un evento con tutte le informazioni correlate.
Decodifica dell’indirizzo del socket
Il campo saddr è un dump esadecimale della struttura sockaddr del kernel. Per IPv4, il formato è: 2 byte per la famiglia di indirizzi (0200 = AF_INET), 2 byte per la porta in network byte order, e 4 byte per l’indirizzo IP. Per IPv6: 2 byte per AF_INET6 (0A00), 2 byte per la porta, 4 byte di padding, e 16 byte per l’indirizzo IPv6 completo.
Il monitor decodifica entrambi i formati, li converte in stringhe IP leggibili tramite inet_ntop(), e filtra automaticamente le connessioni a localhost per evitare falsi positivi.
Risoluzione dell’Effective UID: il dettaglio che fa la differenza
Questo è un aspetto critico per l’hosting condiviso. Quando PHP-FPM è configurato con pool per singolo utente (come dovrebbe sempre essere in un ambiente multi-tenant), ogni pool gira sotto un utente di sistema diverso. Il record SYSCALL dell’audit contiene sia uid (UID reale) che euid (UID effettivo). Il monitor utilizza l’euid perché riflette correttamente l’identità dell’utente sotto cui il worker PHP-FPM sta effettivamente operando.
Il parser dei campi utilizza un matching a parola intera con rilevamento dei confini per evitare un bug insidioso: cercare ingenuamente uid= nella riga di audit matcherebbe anche fsuid=, suid= o auid= come sottostringhe, producendo risultati completamente errati. Il nostro parser verifica che il carattere che precede il nome del campo sia un separatore di parola (spazio, due punti, o inizio stringa).
Come ulteriore fallback, se l’euid è 0 (root), il monitor legge direttamente /proc/PID/status per ottenere l’UID effettivo reale. Questo gestisce i casi limite in cui il record di audit potrebbe riflettere il processo master piuttosto che il worker.
Reverse DNS asincrono
Premendo [R] nell’interfaccia interattiva si abilita la risoluzione DNS inversa, che viene eseguita in un thread dedicato in background. Questo significa che l’interfaccia non si blocca mai in attesa di una query DNS. I risultati vengono memorizzati in una cache thread-safe di 512 entry, cosicché ogni IP unico viene risolto una sola volta. Il resolver utilizza getnameinfo() con il flag NI_NAMEREQD per ottenere i record PTR, permettendo di visualizzare hostname come mail-wr1-f108.google.com accanto agli IP raw.
Thread safety e architettura multi-thread
Il programma utilizza tre thread concorrenti: il thread principale gestisce l’I/O del terminale e il rendering dell’interfaccia ncurses; il thread lettore del log legge e parsa il file di audit in tempo reale; il thread RDNS resolver risolve i DNS inversi in background. Tutte le strutture dati condivise — buffer degli eventi, cache SYSCALL, cache DNS — sono protette da lock pthread_mutex_t per garantire la consistenza in scenari di alta concorrenza.
Installazione e utilizzo
Lo strumento si compila come un singolo binario con sole due dipendenze: ncurses e pthreads.
# Installazione delle dipendenze di compilazione
# RHEL / AlmaLinux / Rocky / CentOS:
sudo dnf install gcc ncurses-devel
# Debian / Ubuntu:
sudo apt install gcc libncurses-dev
# Compilazione
gcc -O2 -o smtp-monitor smtp-monitor.c -lncurses -lpthread
# Esecuzione
sudo ./smtp-monitorPer la modalità interattiva, lanciatelo senza argomenti. Vedrete un’interfaccia terminale a schermo intero con eventi colorati per protocollo, un indicatore di stato LIVE/PAUSED, e controlli da tastiera per scrolling, pulizia, toggle RDNS e altro.
Per il monitoraggio continuo in produzione, utilizzate la modalità logging su file:
sudo nohup ./smtp-monitor -f /var/log/smtp-connections.log &Il formato di output è una riga per connessione:
[2026-02-18 13:39:28] USER=sito-compromesso.it PID=1087389 PROC=php-fpm PORT=587 DST=2a00:1450:4001:c21::6c CWD=/home/sito-compromesso.it/htdocs
[2026-02-18 13:39:30] USER=altrosito.com PID=1087401 PROC=php-fpm PORT=465 DST=2a01:4f8:1c1c:5870::1 CWD=/home/altrosito.com/htdocs
[2026-02-18 13:40:15] USER=root PID=29441 PROC=postfix/smtp PORT=25 DST=5.75.214.156 CWD=/var/spool/postfixIn cinque secondi di lettura di quel log, sapete esattamente quale utente — e quindi quale sito web — sta inviando posta verso server SMTP esterni.
Workflow operativo nella pratica
Ecco come utilizziamo tipicamente questo strumento in uno scenario reale di incident response.
Step 1: Avvio del monitoraggio. Non appena si nota spam in uscita (alert da blacklist, ticket del data center, coda di posta anomala, Munin o Zabbix che segnalano connessioni SMTP inusuali), si accede via SSH al server e si lancia il monitor in modalità log.
Step 2: Identificazione dell’utente. Entro pochi minuti (o secondi, se lo spam è attivamente in corso), appariranno entry ripetute da uno o due account utente che effettuano connessioni SMTP. La colonna USER indica immediatamente quale account hosting è compromesso.
Step 3: Investigazione dell’account. La colonna CWD restringe la ricerca alla document root. A questo punto si controllano i file modificati di recente, si cercano script PHP sospetti, webshell caricati, plugin CMS non aggiornati, o temi nulled contenenti backdoor.
Step 4: Contenimento. Si sospende il pool PHP-FPM dell’utente compromesso, si blocca l’accesso SMTP in uscita con iptables/nftables per quell’utente specifico, oppure si mettono in quarantena i file compromessi.
Step 5: Documentazione. Il file di log fornisce evidenze temporali di ogni singola connessione, utili sia per la comunicazione con il cliente che per la risposta ai report di abuso dei provider upstream.
Per un monitoraggio proattivo, è possibile combinare il file di log con analisi da shell:
# Top utenti SMTP nell'ultima ora
sudo ./smtp-monitor -l | tee /tmp/smtp.log &
sleep 3600 && kill %1
awk '{print $2}' /tmp/smtp.log | sort | uniq -c | sort -rn | head -20Lo strumento si integra facilmente anche con Fail2ban per il blocco automatico degli utenti che superano soglie predefinite di connessioni SMTP, e con logrotate per la gestione automatica della rotazione dei file di log.
Impatto sulle performance
Una preoccupazione comune quando si parla di monitoraggio basato sull’audit del kernel è l’impatto sulle performance. La regola di audit su connect() aggiunge effettivamente un piccolo overhead a ogni connessione di rete sul sistema — non solo quelle SMTP. Su server molto trafficati che gestiscono centinaia di connessioni concorrenti al secondo, abbiamo misurato un impatto inferiore all’1-2% di CPU.
Il monitor stesso è estremamente leggero. Dorme su inotify e si risveglia solo quando vengono scritti nuovi dati nel log di audit. Il consumo di memoria è di circa 15-20 MB, dominato dal buffer degli eventi e dalla cache di correlazione. Il thread RDNS resolver è completamente asincrono e non blocca mai la cattura degli eventi.
Aspetto fondamentale: le regole di audit vengono rimosse automaticamente all’uscita del monitor, quindi non c’è alcun overhead residuo quando lo strumento non è in esecuzione. Potete lanciarlo per il tempo necessario alla diagnosi e poi chiuderlo senza preoccupazioni.
Confronto con gli altri approcci
Nel corso degli anni abbiamo sperimentato numerosi approcci diversi. Ecco come SMTP Connection Monitor si posiziona rispetto alle alternative.
Il parsing dei log di posta funziona solo per le email inviate attraverso l’MTA locale. Le connessioni SMTP dirette da PHP sono completamente invisibili. Inoltre non identifica in modo affidabile l’utente di sistema responsabile.
tcpdump e ngrep possono intercettare il traffico di rete ma non sono in grado di indicare quale processo o quale utente abbia iniziato la connessione. Su un server multi-tenant, questo è il tassello mancante che rende lo strumento inutile per la nostra esigenza.
strace può identificare il processo ma è estremamente invasivo. Attaccarlo a centinaia di worker PHP-FPM su un server di produzione è impraticabile e introduce un degrado significativo delle performance.
PHP auto_prepend_file può loggare i nomi degli script ma richiede la modifica della configurazione PHP per ogni pool. È fragile, può rompere il funzionamento di siti legittimi, e aggiunge latenza a ogni singola richiesta PHP servita dal server.
eBPF / bpftrace è tecnicamente eccellente ma richiede kernel recenti, tooling BCC/bpftrace installato e configurato, e un livello di competenza specialistica che la maggior parte degli amministratori di hosting non ha. È la soluzione giusta per gli ingegneri kernel, non per le operazioni quotidiane di gestione hosting.
SMTP Connection Monitor si colloca nel punto ideale: visibilità a livello kernel, zero modifiche al codice, zero alterazioni alla configurazione PHP, zero disruption ai servizi esistenti, e un deployment semplice basato su compilazione ed esecuzione di un singolo binario.
Limitazioni
Nessuno strumento è perfetto, e la trasparenza sui limiti è importante per una valutazione informata.
Il monitor richiede privilegi di root. La gestione delle regole di audit e l’accesso a /proc per la risoluzione degli UID necessitano di permessi elevati.
Non è in grado di identificare lo specifico script PHP responsabile della connessione. PHP-FPM legge il file .php in memoria e lo chiude prima di eseguire il codice, quindi il percorso dello script non è disponibile in /proc/PID/fd al momento della connessione. Tuttavia, la colonna CWD mostra la document root, il che identifica immediatamente l’account hosting e il sito web coinvolto — informazione sufficiente per procedere all’investigazione.
Su server molto trafficati, il tracing di tutte le syscall connect() aumenta il volume del log di audit. Il monitor processa solo gli eventi relativi a porte SMTP, ma auditd scrive comunque tutto su disco. Assicuratevi che la vostra rotazione dei log di audit sia configurata adeguatamente per gestire il volume aggiuntivo.
Scaricalo e provalo
SMTP Connection Monitor è open source con licenza MIT.
GitHub: https://github.com/MarcoMarcoaldi/smtp-monitor
È un singolo file C di circa 1.100 righe, senza dipendenze esterne oltre a ncurses e pthreads. Si compila in meno di un secondo. Gira su qualsiasi distribuzione Linux con supporto kernel audit — che oggi significa praticamente tutte: AlmaLinux, Rocky Linux, CentOS, RHEL, Debian, Ubuntu e derivate.
Se gestite infrastrutture di hosting condiviso e avete mai perso ore nel tentativo di rintracciare la fonte di uno spam outbreak, provate questo strumento. Potrebbe risparmiarvi un intero pomeriggio di debugging — e forse anche l’ennesimo ticket di abuso dal data center.
