Cosa significa una segnalazione di abuso sul tuo VPS

Che cos’è realmente una segnalazione di abuso relativa a un VPS

Una segnalazione di abuso relativa a un VPS riguarda traffico proveniente dal tuo indirizzo IP. Viene inviata al contatto per gli abusi pubblicato per quel blocco di indirizzi. Il tuo host te la inoltra e indica un termine entro cui rispondere. Il contatto pubblicato appartiene all’azienda che detiene lo spazio di indirizzi. Per questo, la prima persona a leggere una segnalazione relativa al tuo server quasi mai sei tu. Il tuo host associa l’indirizzo IP e il timestamp al tuo account e te la inoltra.

La notifica non dimostra che tu abbia agito intenzionalmente. L’indirizzo IP è l’unico identificativo disponibile per chi invia la segnalazione. Un’applicazione compromessa che invia spam alle 03:00 genera la stessa segnalazione di una persona che invia spam alle 03:00. Per questo la parte importante è la risposta. Ti viene chiesto di indicare quale fosse la fonte del traffico e quali modifiche hai applicato.

Chi invia la segnalazione e come arriva al tuo host

Ogni blocco IP pubblico è registrato presso un registro Internet regionale (RIR): RIPE NCC, ARIN, APNIC, LACNIC o AFRINIC. Ogni registrazione pubblica un contatto per gli abusi, al quale vengono inviate le segnalazioni. Puoi consultare lo stesso record che legge il segnalante:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

I record RIPE contengono un oggetto ruolo abuse-c: con una riga abuse-mailbox:. I record ARIN contengono OrgAbuseEmail:. Qualunque indirizzo sia pubblicato in quel campo riceve il reclamo. Per questo una segnalazione relativa al tuo server arriva al tuo host, non alla tua casella di posta.

Di solito la segnalazione viene inviata da una macchina. Quattro categorie coprono quasi tutti i casi:

• Scanner automatizzati e honeypot. Una macchina registra un tentativo di connessione dal tuo IP e invia una segnalazione con l'estratto del log allegato.
• Feedback loop (FBL) gestiti dai provider di posta. Il destinatario fa clic sul pulsante della posta indesiderata e una copia del messaggio ritorna in formato ARF (abuse reporting format), un formato di posta strutturato per essere analizzato dalle macchine.
• Agenti per il copyright. Monitorano le swarm torrent o eseguono il crawling di URL pubblici, quindi inviano una notifica DMCA (digital millennium copyright act) che indica un file, il tuo IP e un timestamp in UTC.
• Gestori di blocklist e tecnici di rete, che inviano un messaggio breve con le righe problematiche estratte dai propri log.

Poiché la maggior parte delle prime segnalazioni viene generata automaticamente, rispondere con una contestazione non serve. Un fatto invece è decisivo: quale servizio era in esecuzione e quando è stato arrestato.

Perché l'avviso indica una scadenza

Anche il tuo host è un tenant. Il suo spazio di indirizzi si trova dietro carrier upstream ed è incluso nei database di reputazione gestiti da altri operatori. Le segnalazioni senza risposta peggiorano il punteggio dell'intero blocco, non soltanto del tuo indirizzo. Per questo la scadenza indicata è una pressione trasferita a valle. Leggi l'intervallo riportato nell'avviso e consideralo effettivo.

Quando una segnalazione senza risposta produce conseguenze, di solito viene applicata una null route, cioè il traffico verso quell'unico indirizzo IP viene scartato a monte, oppure viene sospesa l'istanza. In genere il fattore scatenante è il silenzio, non l'evento originario. Le misure applicabili a uno specifico host e le relative tempistiche sono indicate nella sua policy e nell'avviso stesso. Sono gli unici due documenti da citare, quindi non basarti su ciò che un forum sostiene che il provider consenta.

Spam in uscita: perché il mio VPS invia messaggi che non ho inviato

Il report indica che il tuo indirizzo IP ha consegnato messaggi a una spam trap oppure che i destinatari hanno contrassegnato i tuoi messaggi come posta indesiderata. Nella maggior parte dei casi, le cause rientrano in quattro categorie: un'applicazione web con un modulo di invio email privo di rate limiting, una credenziale SMTP sottratta e utilizzata da terzi, un mail server che inoltra messaggi per host non autorizzati oppure un accesso rubato a un'applicazione per newsletter. Inizia dalla coda, perché un mittente compromesso è normalmente visibile lì:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

Una coda con migliaia di messaggi indirizzati a destinatari che non riconosci indica che il server sta inviando posta. Poi verifica chi ha eseguito l'autenticazione:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

Un account con un conteggio molto superiore agli altri corrisponde alla credenziale sottratta. Se /var/log/mail.log non esiste, nel sistema non è installato rsyslog e le stesse righe si trovano invece nel journal: sudo journalctl -t postfix --since '2 days ago'.

Se nessuno ha eseguito l'autenticazione, il mittente è un processo locale. Controlla le regole di relay e le connessioni aperte:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Un'installazione standard di Debian o Ubuntu con Postfix non inoltra messaggi per mittenti sconosciuti. Diventa un open relay quando mynetworks viene esteso manualmente a un'intera subnet di hosting, perché in questo modo ogni altro tenant della subnet viene considerato attendibile e può inviare messaggi tramite il server. Qualsiasi connessione alla porta 25 appartenente a un processo che non è il tuo mail server indica che uno script sta inviando posta autonomamente. Questo è il comportamento tipico di un'applicazione PHP compromessa.

Interrompi il flusso prima di iniziare l'analisi e conserva le prove:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL svuota la coda e distrugge anche il registro dei messaggi inviati, quindi crea prima una copia. Poi ruota tutte le credenziali utilizzate dall'applicazione, aggiorna l'applicazione e cerca ciò che l'intruso ha lasciato nel sistema. Nella maggior parte dei casi, un incidente di spam e una compromissione sono lo stesso evento. Segui quindi i passaggi di ripristino per un VPS compromesso invece di limitarti a svuotare la coda.

Scansione delle porte e attacchi brute force: come si presenta un container compromesso

Questo report contiene righe tratte dai log di un altro operatore. L’aspetto è il seguente:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

La causa è quasi sempre un servizio che si riteneva protetto dal firewall. Docker è un caso frequente. La pubblicazione di una porta con -p 6379:6379 scrive regole nelle catene DOCKER-USER e nat. Queste regole vengono valutate prima di quelle di ufw. Di conseguenza, ufw deny 6379 non blocca la porta e il database risponde all’intera Internet.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

Qualsiasi elemento in ss -ltnp associato a 0.0.0.0 o [::] è in ascolto sull’indirizzo pubblico. Quando deve raggiungerlo soltanto l’host, pubblica la porta sull’indirizzo di loopback, -p 127.0.0.1:6379:6379. La scelta della posizione corretta per un database è un problema distinto. Eseguire il database in Docker o sull’host illustra i compromessi delle due opzioni.

Per verificare se il tuo server sta eseguendo una scansione in questo momento:

sudo ss -tnp state syn-sent

Molte connessioni semiaperte verso numerose destinazioni diverse indicano una scansione in uscita in corso. Un log del kernel che si riempie di nf_conntrack: table full, dropping packet indica lo stesso problema da un’altra prospettiva: qualcosa sta aprendo molte più connessioni di quante questo server abbia motivo di aprire.

Ricrea un container compromesso invece di ripulirlo. Non puoi dimostrare cos’altro sia stato modificato al suo interno. Ricrealo quindi da un’immagine attendibile, ripristina soltanto dati attendibili e ruota le chiavi in possesso del container.

Avvisi di copyright: quale file hanno effettivamente visto

Un avviso DMCA indica un URL o un info hash torrent, il tuo indirizzo IP e un timestamp in UTC. Quasi tutti gli avvisi rientrano in due casi: una directory che il server web espone pubblicamente e che contiene file multimediali, oppure un client torrent che continua a distribuire i dati dopo il completamento del download.

Confronta il timestamp con l'access log. Il formato di log combined di nginx inserisce lo stato nel campo 9 e il percorso della richiesta nel campo 7:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

Prima di concludere che non è stato servito alcun file, controlla l'orologio. L'avviso usa l'UTC, mentre i log usano il fuso orario del server. Una differenza di alcune ore può farti cercare nell'intervallo sbagliato e portarti a segnalare un falso negativo:

timedatectl
sudo timedatectl set-timezone UTC

Correggi quindi la causa. Rimuovi o limita l'accesso al file, disabilita l'elenco delle directory con autoindex off; nel blocco location di nginx e associa il client torrent a un'interfaccia diversa da quella pubblica. Nella risposta indica il file, la modifica applicata e l'ora in cui l'hai eseguita. Se ritieni errata la contestazione, si tratta di una questione legale tra te e il mittente; l'avviso indica come contestarla. Il tuo host non è il soggetto che deve decidere in merito, quindi un ticket che contesta il merito della segnalazione non porterà a nulla.

Elenchi di blocklist: perché la posta in uscita ha smesso di funzionare

Questo problema spesso si manifesta senza alcuna e-mail in arrivo. La posta in uscita smette semplicemente di essere accettata e il messaggio di mancato recapito ne indica il motivo:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

Per verificare una presenza in elenco, inverti i quattro ottetti dell'indirizzo IP e interroga la zona dell'elenco:

dig +short 10.113.0.203.zen.spamhaus.org

Una risposta vuota indica che l'indirizzo non è presente in quell'elenco. Una risposta 127.0.0.x indica che lo è; l'ultimo ottetto specifica quale sottoelenco ha rilevato la corrispondenza. Una risposta nell'intervallo 127.255.255.x indica che la query è stata rifiutata invece di ricevere una risposta, in genere perché è passata attraverso un resolver pubblico di grandi dimensioni, non gestito dal servizio gratuito. Esegui nuovamente la query usando il resolver del server per ottenere un risultato effettivo.

La rimozione dall'elenco avviene sul sito dell'operatore della blocklist, non tramite il tuo host, e resta valida solo se prima risolvi la causa. In caso contrario, il trap che ha inserito il tuo indirizzo nell'elenco lo farà nuovamente alla prossima e-mail. Dopo la rimozione, anche altri due elementi determinano se la posta funzionerà. Il record PTR, cioè il nome DNS inverso dell'indirizzo IP, è gestito dal tuo host. Chiedi quindi di impostarne uno che risolva allo stesso indirizzo e usa quel nome come HELO. Inoltre, un indirizzo riassegnato da un precedente cliente può avere una reputazione che non hai creato tu. Conviene informarsi prima di dedicare una settimana alla modifica del DNS. La configurazione corretta dei record SPF (sender policy framework) e DKIM (domainkeys identified mail), insieme alla policy DMARC che li collega, è descritta integralmente in la guida alla gestione di un server di posta autonomo con Mailcow.

Infrastruttura di relay, quando le segnalazioni di abuso fanno parte dell'attività

Se gestisci un nodo di uscita Tor, una VPN pubblica o un proxy per conto di terzi, ricevere segnalazioni relative a traffico che non hai generato è un normale costo operativo. L'obiettivo è fare in modo che il sistema risulti chiaramente un relay, non un server compromesso. Imposta il reverse DNS su un nome descrittivo, pubblica sulla porta 80 una breve pagina informativa che spieghi a cosa serve l'indirizzo, rispondi rapidamente alle segnalazioni di abuso usando la stessa spiegazione e applica le policy disponibili nel software per bloccare le porte che generano più segnalazioni. Usa un indirizzo IP dedicato e, idealmente, anche un'istanza dedicata, in modo che un null route applicato a quell'indirizzo non renda indisponibile anche la tua applicazione web. Chiedi conferma al provider prima di iniziare, perché le attività consentite variano da un'azienda all'altra e talvolta anche tra diversi blocchi IP. Questa verifica va fatta con il provider, non in una discussione su un forum. Gestire un nodo di uscita Tor su un VPS descrive in dettaglio la exit policy e la pagina informativa.

Come rispondere in modo da chiudere il ticket

• Pubblica un contatto che qualcuno controlli. La RFC 2142 prevede che abuse@ e postmaster@ del tuo dominio siano gli indirizzi che i segnalanti provano per primi. Ospita quella casella su un sistema diverso dal server che protegge, perché un'istanza sospesa non può recapitare la notifica che comunica la sospensione.
• Conserva i log abbastanza a lungo da poter rispondere. Non puoi rispondere a una segnalazione sul traffico di dodici giorni fa se il log è stato ruotato dopo sette giorni. Controlla journalctl --disk-usage, imposta MaxRetentionSec=90d in /etc/systemd/journald.conf, quindi esegui sudo systemctl restart systemd-journald. I log web e di posta vengono ruotati secondo una pianificazione propria in /etc/logrotate.d/.
• Mantieni il server su UTC, così un timestamp nella segnalazione corrisponde a un timestamp nei log senza dover effettuare conversioni.
• Separa ciò che attira segnalazioni da ciò che non puoi perdere. Usa un indirizzo per la posta e un altro per l'applicazione web; esegui i servizi relay su un'istanza separata. Un'azione applicata a un IP riguarda tutto ciò che si trova dietro quell'IP.
• Rispondi entro la finestra prevista anche se l'indagine non è terminata. Una risposta interlocutoria che indica una scadenza costituisce una risposta completa per il primo passaggio.

Una prima risposta breve e specifica consente di chiudere la maggior parte dei ticket:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

Indica ciò che sai e ciò che non hai ancora verificato. Il silenzio fa pensare a un server non gestito, e il percorso di escalation esiste per i server non gestiti. Che queste attività rientrino o meno nelle tue responsabilità dipende dal prodotto acquistato: questa è la differenza pratica tra hosting VPS gestito e non gestito. Con un piano non gestito, il tenant è il team responsabile della sicurezza.

Come appare quando tutto funziona

Un reclamo per abuso è innanzitutto un problema di routing. Una segnalazione relativa a un indirizzo viene inviata al soggetto responsabile di quell'indirizzo e inoltrata alla persona che può risolvere il problema. Gli aspetti sotto il tuo controllo sono l'indirizzo di contatto, la conservazione dei log, il modo in cui i servizi sono distribuiti tra gli indirizzi IP e la rapidità della risposta. Se questi elementi sono gestiti correttamente, la maggior parte delle segnalazioni si chiude dopo un solo scambio. Le stesse pratiche aiutano a chiarire la questione più ampia di quanto sia sicuro l'hosting VPS, perché il server che nessuno monitora è quello che finisce nei log di qualcun altro.

FAQ

Un reclamo per abuso significa che il mio VPS è stato violato?

Non di per sé, ma è la prima possibilità da escludere. Il report dimostra soltanto che del traffico è uscito dal tuo IP. Lo spam in uscita e la scansione delle porte sono causati molto più spesso da un'applicazione o da un container compromesso che dal titolare dell'account. Controlla quindi la coda di posta con sudo postqueue -p e i socket in ascolto con sudo ss -ltnp prima di ogni altra cosa. Le segnalazioni relative a copyright e blocklist hanno caratteristiche diverse: di solito indicano qualcosa che stai eseguendo intenzionalmente.

Quanto tempo ho per rispondere a una segnalazione di abuso?

Il termine è indicato nella segnalazione che hai ricevuto e varia in base all'host e alla categoria. Le segnalazioni relative a copyright e spam trap tendono ad avere i termini più brevi. Considera il termine indicato come effettivo e invia una breve risposta interlocutoria prima della scadenza, anche se stai ancora individuando la causa. Per chi gestisce il ticket, l'aspetto importante è che una persona stia lavorando al problema e che il traffico sia stato interrotto.

Il mio IP è presente in una blocklist. Il mio host può rimuoverlo?

No. La rimozione dalla lista viene eseguita dal gestore della lista, sul relativo sito, e il tuo host non può controllare il suo database. Il tuo host può invece gestire il record PTR, cioè il nome DNS inverso del tuo IP. Si tratta di una richiesta separata che conviene presentare nello stesso momento. Risolvi il problema di invio prima di chiedere la rimozione dalla lista, perché la spam trap che ha inserito il tuo IP nella lista lo inserirà di nuovo al messaggio successivo.

Devo dire al mio host che cosa è successo realmente?

Devi comunicare informazioni sufficienti per chiudere il ticket: quale era l'origine del problema e quando si è interrotto. Non devi fornire un rapporto forense né i dati dei tuoi utenti. Una risposta vaga è peggiore di una risposta breve, perché chi gestisce la segnalazione e non riesce a vedere che cosa è cambiato non ha motivo di considerare il caso risolto.

Posso ignorare un report automatico proveniente da uno scanner?

No. I report automatici vengono conteggiati e le segnalazioni ripetute relative a un singolo IP aumentano il punteggio associato all'intero blocco di indirizzi del tuo host. È così che un caso limitato può trasformarsi in un'escalation. La tua risposta può essere costituita da un solo paragrafo. Di solito chi genera automaticamente la segnalazione non la legge mai, ma lo fa la persona che gestisce il ticket presso il tuo host. È quella persona a decidere che cosa accadrà alla tua istanza.