Bot Scansioni continue sulla rete

I bot che scansionano continuamente la rete: cosa cercano su una VPS piccola

Quando metti online una VPS con un piccolo sito e qualche servizio, è facile pensare: «Cosa dovrebbe interessare a qualcuno di un server così?». La risposta è che non interessa a nessuno in particolare. A bussare alla tua porta non è una persona che ha scelto te, ma un programma che sta provando ogni indirizzo di internet, uno dopo l’altro, senza stancarsi mai.

In questo articolo vediamo come funzionano queste scansioni, che cosa cercano e che cosa abbiamo trovato nei log di due VPS reali, con tentativi osservati nell’arco di poche ore.

1. Come fanno a trovare un server

Lo spazio degli indirizzi IPv4 è piccolo: circa 4 miliardi di indirizzi. Per un programma come masscan o zmap è un numero gestibile: con la banda adatta, l’intera rete si può percorrere in pochi minuti, chiedendo a ogni indirizzo «c’è qualcuno in ascolto su questa porta?». Esistono poi servizi come Shodan e Censys che fanno questo di mestiere e pubblicano i risultati in un motore di ricerca consultabile da chiunque.

La conseguenza pratica è che un server nuovo viene scoperto in minuti o in poche ore. Non serve un dominio, non serve pubblicità: basta un indirizzo IP con una porta aperta.

2. Cosa cercano

Chi attacca in massa prova sempre le stesse cose, perché il costo di provarci è quasi zero. Le più comuni:

• SSH con password deboli: tentativi su root, admin, ubuntu e altri nomi utente comuni.
• Pannelli e database lasciati aperti: porte di amministrazione, interfacce web di servizi, database senza password.
• Vulnerabilità note di WordPress e dei suoi plugin: percorsi come quello di un plugin vulnerabile, provati su ogni sito senza sapere se il plugin è installato.
• wp-login.php e xmlrpc.php: forza bruta sulle password di WordPress, con XML-RPC che permette di provarne molte in una sola richiesta.
• File che non dovrebbero essere pubblici: .env, .git, copie di wp-config.php, con dentro password e chiavi di accesso.

3. Perché interessa anche un server piccolo

Una VPS, anche vuota, ha valore per chi la controlla:

• Potenza di calcolo e banda: per minare criptovalute, mandare spam o partecipare ad attacchi DDoS in una botnet.
• Un indirizzo IP «pulito»: usato come proxy per nascondere attività illecite o per scansionare altri bersagli. A pagarne il prezzo sei tu, con segnalazioni di abuso e, nei casi peggiori, la sospensione dell’account dal provider.
• Credenziali riutilizzate: se trovano una password valida, la provano su altri servizi.
• Un punto d’appoggio: da un server compromesso si può attaccare altro nella stessa rete.

4. Cosa abbiamo visto nei log

SSH: tentativi continui, con tecniche per aggirare i blocchi

Su una VPS, in circa 35 minuti, abbiamo contato 17 tentativi da 9 indirizzi diversi. I nomi utente provati: admin, ubuntu, ftpuser, linuxuser, labadmin, pilot, root e altri. Uno script ha provato perfino un utente chiamato %subdomain%: un segnaposto che il programma non aveva sostituito, la prova che dietro non c’è nessuno.

Alcuni bot sono più furbi: provano un solo accesso ogni 9-10 minuti dallo stesso indirizzo, restando sotto la soglia di Fail2ban (5 tentativi in 10 minuti) per non essere bannati. È la tecnica «low and slow», che si contrasta allargando la finestra di osservazione della jail.

sudo journalctl -u ssh --since '24 hours ago' | grep -Ei 'invalid user|authenticating user' | tail -30

XML-RPC: una raffica regolare

Un singolo indirizzo ha colpito xmlrpc.php ogni 10 secondi circa, per minuti, con una cadenza che tradisce uno script. Dopo il blocco di Nginx e la jail dedicata di Fail2ban, le sue richieste vengono respinte con un 403 prima ancora di arrivare a WordPress.

Il file .env e gli user agent falsi

Nel registro di Wordfence compariva una raffica di richieste a percorsi come ../../.env e /proc/self/environ, il tentativo di leggere file con password e variabili d’ambiente. Nello stesso istante, dallo stesso indirizzo, le richieste dichiaravano di essere crawler diversi: CCBot, cohere-ai, ClaudeBot, YouBot. Un solo indirizzo non può essere quattro crawler diversi: è uno script che cambia il nome dichiarato per sembrare rispettabile. Lo user agent è solo un’etichetta, e chiunque può scriverla. I crawler veri, tra l’altro, non cercano file .env.

Un plugin che non avevamo nemmeno

Un’altra richiesta, partita da una VPS dello stesso provider, ha provato un percorso che sfrutta una vulnerabilità di un plugin SMTP. Quel plugin sul sito non era installato: il bot prova la lista di tutti i plugin vulnerabili che conosce su ogni sito, senza sapere cosa c’è. Wordfence l’ha bloccata, e senza il plugin avrebbe comunque trovato un 404.

Nomi di altri siti che puntano al tuo IP

Alcune richieste arrivavano con nomi host che non erano il nostro dominio, come un finto servizio di gestione progetti o di repository. Il motivo: i provider riassegnano gli indirizzi IP, e un indirizzo che prima apparteneva a un altro server può avere ancora record DNS vecchi che puntano a lui. I bot che cercavano quei servizi arrivavano a noi, e trovavano un sito WordPress che rispondeva a qualsiasi nome.

La soluzione è un blocco «catch-all» in Nginx, che chiude la connessione per tutti i nomi sconosciuti:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
    server_name _;
    return 444;
}

Il codice 444 è speciale di Nginx: chiude la connessione senza inviare nemmeno una risposta. Il tuo sito, che ha il proprio server_name, continua a funzionare normalmente.

I numeri di un mese

Nel pannello di Wordfence il sito segnava 26.395 tentativi di forza bruta nell’ultimo mese, più 230 attacchi bloccati dalle regole del firewall, mentre nell’ultima settimana e nel giorno corrente i tentativi di forza bruta erano zero. Con ogni probabilità il calo dipende dalle difese descritte qui (login con indirizzo personalizzato, xmlrpc.php bloccato, Fail2ban), che fermano i bot prima che raggiungano WordPress. Sul grafico globale della stessa rete c’erano tra 5 e 9 milioni di attacchi bloccati ogni ora su tutti i siti protetti: la scala di un fenomeno che non sceglie i bersagli.

5. Come difendersi

La buona notizia è che a chi attacca in massa basta trovare qualcun altro più facile. Non devi essere imbattibile: devi smettere di essere il bersaglio più semplice. Le difese che hanno fatto la differenza:

• Chiavi SSH al posto delle password (e password disattivate): un bot non ha più niente da indovinare. Vedi l’articolo sull’accesso SSH con chiave.
• Fail2ban con jail per SSH, login WordPress e XML-RPC, per bloccare chi insiste. Vedi l’articolo su Fail2ban.
• Nginx configurato con attenzione: xmlrpc.php bloccato, file nascosti protetti, blocco di default per i nomi sconosciuti. Vedi l’articolo su ottimizzazione e hardening di Nginx.
• Aggiornamenti di sistema, WordPress e plugin: le vulnerabilità note sono la merce di scambio dei bot, e una versione aggiornata le chiude.
• Pochi servizi esposti: con sudo ss -tlnp vedi tutto ciò che ascolta su internet. Le porte che non devono essere pubbliche vanno chiuse dal firewall del provider o fatte ascoltare solo in locale.
• Password diverse per ogni servizio, in un gestore di password.
• Backup fuori dalla VPS, perché una copia sullo stesso server sparisce con lui.

6. Come ci si accorge di una compromissione

I segnali tipici sono un uso anomalo di CPU o banda, segnalazioni di abuso dal provider, processi o utenti sconosciuti, file strani in /tmp e un sito che mostra link o redirect che non hai messo tu. Alcuni controlli rapidi:

last -a | head -20
sudo ss -tlnp
cat ~/.ssh/authorized_keys
sudo crontab -l

Se sospetti che il server sia compromesso, spegnerlo non basta: perdi le tracce e al riavvio l’intruso c’è ancora. Il percorso corretto è isolare la macchina, conservare i log, reinstallare da zero, ripristinare i dati da un backup precedente alla compromissione e cambiare tutte le credenziali che erano sul server o che il server poteva raggiungere. Per questo i backup fuori dalla VPS contano più di qualsiasi altra difesa.

7. Quanta protezione serve davvero

La protezione va dimensionata su quanto costa perdere o veder rubare quei dati. Per un sito sperimentale che puoi rifare, un backup settimanale e le difese di base bastano. Chi tiene dati altrui (utenti, clienti, email) ha un problema diverso: lì un backup non risolve il furto dei dati, e valgono cifratura, backup frequenti e gli obblighi di legge come il GDPR.

Conclusione

I bot non ti hanno scelto: stanno provando tutti, e tu sei uno dei tanti. Per questo le difese vanno pensate come una routine e non come una reazione, e per questo bastano poche regole ben messe per uscire dalla lista dei bersagli più semplici. La parte interessante è che tutto questo si può osservare: i log del tuo server raccontano ogni giorno, con numeri precisi, quanto rumore c’è là fuori.