Cosa sono i bot: attacchi, rischi e come difendersi

Che cosa significa bot: un programma, non necessariamente un nemico

La parola bot deriva da robot e, nel contesto di Internet, indica un software che svolge compiti automaticamente. La definizione di Cloudflare comprende tanto gli strumenti utili quanto quelli impiegati in attività dannose. L’automazione è una caratteristica del funzionamento, non un giudizio sull’affidabilità: per distinguere i casi bisogna conoscere scopo e comportamento.

Immagina due programmi che visitano la stessa pagina: uno controlla periodicamente che sia raggiungibile, l’altro invia richieste per impedirne l’uso agli altri. Il fatto che entrambi agiscano senza una persona che clicca ogni volta non li rende equivalenti. La differenza è nell’attività svolta e nel suo impatto sul servizio.

In questa scheda parliamo dei bot informatici. Non dei BOT finanziari, cioè i Buoni ordinari del Tesoro. Anche scrivere la parola tutta in maiuscolo può creare ambiguità: nelle notizie di sicurezza ‘bot’ descrive normalmente un programma automatico, mentre il significato finanziario appartiene a un argomento completamente diverso.

A cosa servono i bot utili: ricerca, assistenza e controlli

Un web crawler visita le pagine seguendo collegamenti e raccogliendo informazioni. I motori di ricerca usano questi programmi per scoprire e analizzare contenuti: impedire indiscriminatamente ogni visita automatica può quindi ostacolare anche attività che il proprietario del sito desidera. Scansione e indicizzazione, peraltro, non sono sinonimi: una pagina visitata non è necessariamente inclusa nei risultati.

La documentazione Cloudflare sui bot distingue anche assistenti conversazionali e diversi impieghi legati all’intelligenza artificiale. Non tutti raccolgono dati per addestrare modelli: possono esserci crawler per la ricerca o agenti che operano su richiesta di un utente. Né tutti i bot usano l’intelligenza artificiale: bastano istruzioni programmate per automatizzare molte operazioni.

Un controllo della disponibilità concordato con il gestore, per esempio, non va confuso con una scansione ostile soltanto perché avviene di notte. La domanda utile è: questo accesso è previsto, identificabile e compatibile con il servizio? Autorizzazione e sostenibilità del carico aiutano a valutare anche automazioni che non hanno intenzioni criminali.

Quando un bot diventa uno strumento di attacco

Un attacco con bot sfrutta l’automazione per compiere attività dannose: compromettere account, disturbare un servizio o realizzare frodi. Non è necessario che il programma ‘entri nel computer’ della vittima. Può abusare di una funzione pubblicamente disponibile, come un modulo di accesso, ripetendone l’utilizzo in modo non consentito.

Bot e attività automatiche: scopi diversi richiedono valutazioni diverseFonte: Sintesi divulgativa dalle definizioni di Cloudflare, dalla guida agli attacchi automatici e dalle categorie di abuso descritte da OWASP.
Tipo di attività	Obiettivo	Distinzione importante
Crawler di ricerca	Scoprire e analizzare pagine	Non è un attacco per il solo fatto di essere automatico
Controllo di disponibilità	Verificare che un servizio risponda	Va riconosciuto e configurato con il gestore
Credential stuffing	Usare credenziali sottratte altrove	Un tentativo non equivale a un accesso riuscito
Spam automatico	Inviare messaggi o pubblicare contenuti indesiderati	Può colpire moduli e commenti senza violare il server
Raccolta automatica di contenuti	Estrarre informazioni dalle pagine	Scopo, autorizzazione e carico vanno valutati
DDoS	Rendere indisponibile un servizio	Indisponibilità e furto di dati non sono la stessa cosa

La tabella descrive comportamenti, non permette di classificare una richiesta osservando soltanto il suo nome o il Paese di provenienza.

Pensa a un modulo per richiedere un preventivo: dieci richieste reali aiutano un’azienda, mentre migliaia di messaggi fittizi possono rendere difficile trovare i clienti autentici. È un esempio illustrativo, non una soglia tecnica: il numero che crea un problema dipende dalle risorse e dall’organizzazione di quel servizio.

Anche un tentativo fallito merita la giusta interpretazione. Se il sistema respinge una password sbagliata, ha impedito quell’accesso; non significa che l’account sia già stato violato. Se invece risulta un accesso riuscito non riconosciuto, occorre verificare la sessione e le azioni compiute. Confondere tentativi e compromissioni rende più difficile scegliere una risposta proporzionata.

Perché vengono attaccati anche siti piccoli e appena aperti

Fra gli abusi catalogati da OWASP ci sono scansioni di vulnerabilità, account fittizi e uso improprio delle funzionalità applicative. Un’automazione può cercare opportunità su molti indirizzi, senza una selezione manuale di ogni vittima. Ricevere richieste sospette non dimostra quindi che qualcuno abbia scelto personalmente il titolare del sito come bersaglio.

Un negozio piccolo può essere interessante per il suo modulo di pagamento; un blog per i commenti; un sito aziendale per un pannello di amministrazione esposto. Questi esempi mostrano perché il valore per chi abusa del servizio non coincida necessariamente con il numero di lettori o con il fatturato del proprietario.

Non si può però ricostruire il movente da un contatore. Per parlare di estorsione, sabotaggio mirato o tentativo di furto servono elementi specifici. Dire ‘il sito è piccolo, quindi non può subire abusi’ è scorretto; dire ‘ci sono bot, quindi qualcuno ci sta perseguitando’ è una conclusione altrettanto ingiustificata.

Bot e botnet: qual è la differenza

Una botnet è una rete di dispositivi compromessi e controllati da un soggetto esterno, come illustra il rapporto ENISA sulle botnet. Possono farne parte computer e altri apparecchi connessi. Il proprietario di un dispositivo può non sapere che viene usato per attività altrui: essere coinvolti nel traffico non significa averlo deciso consapevolmente.

Il bot è il programma o agente automatico; la botnet è l’insieme coordinato di dispositivi compromessi. Un singolo programma che controlla le previsioni del tempo non è una botnet. Anche tanti accessi automatici non dimostrano, da soli, l’esistenza di una rete di macchine infette: possono provenire da infrastrutture e soggetti differenti.

Per il lettore la conseguenza pratica è duplice: proteggere i propri account non basta a mantenere sicuri tutti i dispositivi, e una pagina web protetta non rende automaticamente sicuro il router domestico. Aggiornamenti, configurazioni e credenziali degli apparecchi meritano attenzione distinta, soprattutto quando un dispositivo non riceve più supporto dal produttore.

DDoS: quando l’obiettivo è rendere il sito irraggiungibile

DoS significa negazione del servizio; DDoS indica la forma distribuita, con traffico proveniente da più sorgenti. L’obiettivo è esaurire risorse o capacità necessarie a rispondere agli utenti. Una botnet può contribuire a un DDoS, ma non è corretto usare i due termini come sinonimi o attribuire ogni rallentamento a dispositivi infetti.

Il National Cyber Security Centre britannico raccomanda di conoscere i punti del servizio che possono saturarsi, chiarire le responsabilità dei fornitori e preparare una risposta. Non esiste una promessa seria di rischio azzerato. La capacità del gestore di intervenire conta almeno quanto l’intervento sul singolo sito.

Un disservizio può anche dipendere da un guasto, da una modifica difettosa o da un aumento autentico di visitatori. Per distinguere i casi servono dati del periodo interessato. Inoltre, un DDoS riguarda la disponibilità: non prova che siano stati letti documenti privati o rubate password. Eventuali altri incidenti devono essere accertati separatamente.

Password rubate: credential stuffing, forza bruta e password spraying

Nel credential stuffing vengono provate coppie di nome utente e password già sottratte attraverso altre violazioni. Il riutilizzo della stessa password rende possibile che un problema nato su un servizio si trasferisca a un altro. Il sito preso di mira non deve necessariamente aver perso il proprio archivio di credenziali.

La guida OWASP sulla protezione degli accessi distingue questo fenomeno dalla forza bruta, che prova molte password, e dal password spraying, che tenta poche password comuni su molti account. La distinzione serve a capire perché ‘ho scelto una password complicata’ non basta se quella stessa password è stata esposta altrove.

Esempio ipotetico: una persona usa la stessa password per una vecchia community e per la posta. Se la prima viene compromessa, un attaccante può provare quella combinazione anche sulla seconda. Non occorre indovinare la password carattere per carattere. Una credenziale diversa per ciascun servizio limita questo collegamento fra incidenti.

Spam, raccolta di contenuti e clic falsi: non c’è solo il DDoS

La guida al traffico dei bot comprende attività molto diverse dal sovraccarico. Un programma può inviare spam o raccogliere informazioni dalle pagine senza causare un’interruzione visibile. Un sito che continua a funzionare può quindi avere comunque un problema di abuso; la sola velocità di caricamento non racconta tutto.

La frode sui clic produce interazioni artificiali con gli annunci, invece di un interesse reale. Per un editore, molti clic non sono automaticamente un buon risultato. È importante non acquistare visite o interazioni presentate come una scorciatoia alla monetizzazione e non confondere un contatore in crescita con un pubblico che legge davvero.

Anche la raccolta automatica va descritta senza scorciatoie: analizzare prezzi con autorizzazione, copiare integralmente un articolo e generare richieste eccessive sono situazioni differenti. La parola scraping descrive una tecnica di estrazione, non risolve da sola ogni valutazione sul comportamento. Prima di reagire bisogna capire quali dati vengono richiesti e con quali effetti.

Come capire se il traffico automatico sta creando un problema

Per una prima verifica annota quando è iniziata l’anomalia, quale funzione non va e che cosa osservano gli utenti. ‘Il modulo non invia dalle 10:15’ è più utile di ‘il sito è pieno di hacker’. Conserva messaggi di errore e orari, distinguendo la tua esperienza dalle segnalazioni ricevute da altri.

Segnali sospetti: che cosa verificare prima di concludere che c’è un attaccoFonte: Griglia redazionale di Risposta.info basata sulle indicazioni di NCSC, sulla distinzione del traffico automatico e sulla verifica dei crawler Google.
Segnale osservato	Non dimostra da solo	Verifica utile
Picco di richieste	Un DDoS o un aumento di lettori reali	Orario, funzioni coinvolte, carico ed errori
Accessi da molti Paesi	L’identità o la nazionalità dell’attaccante	Comportamento e provenienza tecnica delle richieste
Molti errori 404	Una violazione riuscita	Quali percorsi sono richiesti e con quale frequenza
Tentativi di login respinti	Che qualcuno sia entrato nell’account	Accessi riusciti, avvisi e sessioni non riconosciute
Nome Googlebot nei registri	Che si tratti davvero di Google	Procedura ufficiale di verifica della sorgente
Pagina lenta o non disponibile	Che la causa sia necessariamente un bot	Stato del fornitore, modifiche recenti e risorse

Sono indizi da interpretare insieme. Non esiste un numero universale di richieste che separi traffico normale e attacco per qualunque sito.

Poi confronta, con l’assistenza tecnica, richieste ricevute, risposte del server e utilizzo delle risorse. Gli strumenti misurano oggetti diversi: una richiesta HTTP non equivale a una persona, e un lettore può generare più richieste caricando pagina, immagini e altri elementi. I dati di un sistema di statistiche non coincidono necessariamente con quelli dell’hosting.

La tabella di questa sezione è una griglia pratica di lettura, non un sistema automatico di diagnosi. Le verifiche devono restare circoscritte ai propri servizi o a quelli per cui si ha autorizzazione. Evita di pubblicare registri completi: possono contenere identificativi, indirizzi o altri dati da condividere soltanto con chi deve analizzare l’incidente.

Googlebot è autentico? Perché il nome del bot non basta

Le richieste possono dichiarare un nome nel campo User-Agent, ma quel nome non è una prova d’identità. Google documenta come verificare i propri crawler tramite gli intervalli IP pubblicati o controlli DNS coerenti in entrambe le direzioni. Chi gestisce il sito può affidare la verifica al proprio tecnico, senza basarsi soltanto sull’etichetta letta in un registro.

Non è prudente creare un’eccezione totale alle protezioni per qualsiasi richiesta che si presenti come Googlebot. Sarebbe come far entrare chiunque pronunci il nome di un fornitore conosciuto. Al contrario, bloccare automaticamente il crawler autentico può ostacolare l’accesso alle pagine da parte del motore di ricerca.

Una regola sensata separa identificazione e autorizzazione: prima si verifica chi sta chiedendo, poi si stabilisce cosa può fare. Lo stesso principio aiuta a valutare servizi di monitoraggio e integrazioni autorizzate. Le eccezioni devono essere documentate e verificabili, non basate sulla semplice somiglianza di un nome.

Robots.txt blocca gli attacchi? No, non è una protezione degli accessi

Il file robots.txt dà indicazioni ai crawler che le rispettano, ma non obbliga un programma ostile a fermarsi. Non sostituisce autenticazione, autorizzazioni o protezioni del server. Scrivere un percorso riservato nel file non lo rende privato: per proteggere informazioni riservate occorre un controllo effettivo degli accessi.

Per un sito pubblico, chiudere tutto ai motori di ricerca non è una scorciatoia per eliminare gli abusi: si rischia di ostacolare chi segue le regole senza fermare chi le ignora. Prima di modificare il file bisogna distinguere l’obiettivo: ridurre scansioni superflue, gestire la visibilità o difendere una funzione sono esigenze diverse.

Google precisa inoltre che un URL bloccato alla scansione può ancora apparire nei risultati se viene scoperto attraverso altri collegamenti. Per questo non bisogna confondere ‘non visitare’ con ‘non indicizzare’. Se la richiesta riguarda un contenuto davvero privato, il criterio resta semplice: deve essere inaccessibile a chi non è autorizzato, non soltanto sconsigliato ai crawler.

Come difendere un sito: limiti mirati, aggiornamenti e assistenza

Il rate limiting limita quante volte si può ripetere un’azione in un intervallo. Una pagina informativa, un accesso all’account e una richiesta costosa al database non hanno necessariamente le stesse esigenze. Una regola valida va tarata sulla funzione e verificata, non copiata come soglia universale da applicare a tutto il sito.

L’IP, da solo, non rappresenta sempre una persona: più utenti possono condividere una connessione e un abuso può arrivare da più indirizzi. Limiti troppo rigidi rischiano quindi di penalizzare persone legittime. Dopo una modifica va controllato che restino possibili le operazioni essenziali, compreso il recupero dell’account.

Per un piccolo progetto conviene chiedere al fornitore quali protezioni siano già comprese: mitigazione DDoS, filtro delle richieste sospette, registri disponibili e canale per le emergenze. Un firewall applicativo filtra richieste secondo regole, ma non sostituisce la manutenzione del software. Aggiornare componenti e rimuovere funzioni inutilizzate riduce esposizioni evitabili; un backup aiuta il ripristino, non blocca il traffico ostile.

CAPTCHA e falsi controlli ‘non sono un robot’

I controlli anti-automazione possono essere una parte della difesa, non una garanzia assoluta. OWASP raccomanda di combinare protezioni per gli accessi invece di affidarsi a un solo ostacolo. Per chi gestisce un sito conta anche l’esperienza delle persone: un controllo che impedisce sistematicamente agli utenti autentici di proseguire crea un problema a sua volta.

Attenzione però alle imitazioni. Microsoft Threat Intelligence descrive ClickFix: pagine ingannevoli presentano una verifica o una riparazione come pretesto per indurre la persona a eseguire comandi sul dispositivo. Il bersaglio è l’utente, non un bot da fermare. La ricerca documenta campagne che coinvolgono sia Windows sia macOS.

Una pagina che, per ‘dimostrare che sei umano’, chiede di aprire il Terminale, PowerShell o la finestra Esegui e incollare comandi va trattata come sospetta. Non eseguire le istruzioni: chiudi la pagina e raggiungi il servizio dall’indirizzo conosciuto. Se hai già eseguito un comando, chiedi assistenza tecnica; non limitarti a ricaricare il sito come se fosse stato un normale CAPTCHA.

Come proteggere i propri account dai tentativi automatici

Usa una password lunga e diversa per ogni servizio, conservata in un gestore affidabile, e attiva l’autenticazione a più fattori dove disponibile. La Federal Trade Commission raccomanda di iniziare dagli account più sensibili, fra cui posta, banca e pagamenti. Un secondo fattore aggiunge una barriera quando una password viene sottratta.

Quando il servizio lo permette, valuta passkey o chiavi di sicurezza: la guida OWASP le include fra le difese contro l’abuso delle credenziali. Non approvare notifiche di accesso che non hai richiesto e non consegnare codici a chi si presenta come assistenza. Un codice valido può diventare inutile come protezione se lo passi direttamente a un truffatore.

Per controllare un avviso, apri l’app o il sito ufficiale senza usare il collegamento contenuto in un messaggio inatteso. Il tentativo di indurti a consegnare credenziali rientra nel phishing, che può accompagnare gli abusi automatici ma non è la stessa cosa. Se hai perso l’accesso alla posta, segui i passaggi ufficiali descritti nella scheda su come recuperare una password Gmail, senza pagare presunti recuperatori.

Cosa fare subito se sospetti un attacco

Se riguarda un sito che amministri, segnala il problema al fornitore indicando dominio, orario e sintomi concreti. Chiedi di distinguere traffico filtrato, richieste arrivate al server e disservizi effettivi. Un rapporto che dice ‘bloccate molte richieste’ può indicare una protezione al lavoro, non necessariamente un’interruzione del servizio o una violazione riuscita.

Il NCSC insiste sulla preparazione della risposta e sul coordinamento con i fornitori. Evita di modificare insieme DNS, filtri e applicazione senza un piano: diventa difficile capire quale intervento abbia aiutato e quale abbia provocato nuovi guasti. Conserva le evidenze e concorda modifiche mirate con chi può valutare l’infrastruttura.

Se riguarda un account, controlla accessi e sessioni attraverso il servizio ufficiale; in presenza di accessi non riconosciuti cambia la password, verifica i recapiti di recupero e usa le funzioni per chiudere le sessioni sospette. Se sono coinvolti pagamenti, contatta subito l’intermediario tramite canali noti. Non rispondere con scansioni o azioni contro gli indirizzi che compaiono nei registri.

Un contatore alto non significa più lettori, né prova un attacco

Esempio puramente illustrativo: un rapporto mostra diecimila richieste, un altro poche decine di sessioni. Non puoi sottrarre il secondo numero dal primo e chiamare la differenza ‘hacker’. I due indicatori misurano cose diverse e possono applicare filtri diversi. Prima di interpretare la distanza bisogna conoscere origine e definizione di ciascun dato.

Per un editore o un negozio la domanda finale non è soltanto ‘quanti bot vedo?’, ma ‘le persone riescono a leggere, acquistare o accedere in sicurezza?’. I numeri acquistano significato se vengono collegati a risultati verificabili: operazioni riuscite, errori, disponibilità e anomalie degli account. Nessun singolo indicatore riassume tutte queste dimensioni.

La regola pratica è dunque distinguere prima di bloccare: bot utili, raccolte non desiderate e attacchi veri richiedono risposte diverse. Proteggi ciò che deve essere privato, limita gli abusi sulle funzioni esposte e verifica gli effetti sugli utenti. L’obiettivo non è eliminare ogni automazione da Internet, ma permettere alle persone e ai servizi autorizzati di continuare a funzionare.

Verifica le informazioni