Un attacco brute force, o attacco a forza bruta, consiste nel provare ripetutamente credenziali o possibili password fino a trovare una combinazione valida. È un metodo semplice nel principio, ma può diventare molto efficace quando i tentativi sono automatizzati, distribuiti tra numerosi indirizzi IP o rivolti contro password deboli e riutilizzate.
Il problema non riguarda soltanto WordPress. Un attacco brute force può colpire il login di un sito web, un account cloud, una VPN, un server SSH o altri servizi che accettano credenziali. In altri casi l’attaccante non interagisce neppure con il servizio: se riesce a ottenere gli hash delle password, può tentare di recuperarne il valore offline.
Il brute force è quindi solo una parte del problema più ampio degli attacchi alla sicurezza informatica. Capire come avvengono i tentativi è importante perché la difesa cambia radicalmente tra un attacco online al login, un password spraying, il credential stuffing e il cracking offline di password già sottratte.
In questa guida vediamo le differenze, i segnali da controllare e soprattutto quali difese hanno realmente senso, con una sezione specifica dedicata a WordPress.
Cos’è un attacco brute force
Nel significato più immediato, il brute force è un processo di tentativi ripetuti: l’attaccante prova password diverse finché il sistema ne accetta una.
La classificazione MITRE ATT&CK dedicata al Brute Force usa però il termine in senso più ampio e comprende password guessing, password cracking, password spraying e credential stuffing. Nella pratica è utile distinguere questi comportamenti, perché non hanno tutti lo stesso punto di partenza e non vengono fermati esattamente nello stesso modo.
Un attacco può essere completamente esaustivo, provando molte combinazioni possibili, ma nella realtà gli aggressori cercano spesso di ridurre il lavoro. Password comuni, parole di dizionario, credenziali già compromesse e pattern prevedibili permettono di concentrare i tentativi sulle combinazioni che hanno maggiori probabilità di successo.
Brute force, attacco a dizionario, password spraying e credential stuffing: le differenze
La distinzione proposta dall’OWASP Authentication Cheat Sheet è particolarmente utile per capire cosa sta succedendo dietro una sequenza di login falliti.
| Tecnica | Come funziona | Obiettivo tipico |
|---|---|---|
| Brute force / password guessing | Prova molte password contro uno o pochi account | Indovinare una credenziale sconosciuta |
| Attacco a dizionario | Usa liste di password, parole e varianti considerate probabili | Ridurre lo spazio dei tentativi |
| Password spraying | Prova una o poche password comuni contro molti account | Evitare i lockout concentrati su un singolo utente |
| Credential stuffing | Prova coppie username/password provenienti da precedenti violazioni | Sfruttare il riutilizzo delle credenziali |
| Password cracking offline | Confronta candidati contro hash già ottenuti | Recuperare la password senza interrogare il servizio originale |
Il confine terminologico non è identico in ogni framework. MITRE considera, per esempio, password spraying e credential stuffing sottotecniche della categoria Brute Force; OWASP le presenta come attacchi distinti quando spiega le difese sull’autenticazione.
La differenza operativa è più importante dell’etichetta. Provare diecimila password contro un account e provare una password su diecimila account producono pattern diversi, e una protezione che guarda soltanto il numero di errori per singolo utente può intercettare bene il primo caso ma essere meno efficace contro il secondo.
Come funziona un attacco brute force
Per capire quali contromisure funzionano bisogna separare due scenari: attacchi online e attacchi offline.
Nel primo caso l’aggressore invia tentativi al sistema che deve autenticare l’utente. Nel secondo possiede già materiale come hash delle password e può effettuare le verifiche sui propri sistemi.
Questa distinzione cambia completamente la superficie difensiva.
Attacchi online contro login, SSH, VPN e applicazioni web
In un attacco online ogni tentativo deve arrivare a un servizio reale.
Può essere una pagina di login, un servizio SSH, una VPN, un pannello amministrativo o qualsiasi altra interfaccia che verifichi username e password.
Il sistema bersaglio può quindi osservare i tentativi e reagire. È qui che entrano in gioco:
- rate limiting;
- ritardi progressivi;
- lockout controllati;
- MFA;
- challenge anti-bot;
- WAF;
- analisi degli indirizzi IP e della reputazione del traffico;
- monitoraggio dei pattern di autenticazione.
L’aggressore può però distribuire i tentativi tra indirizzi IP differenti, usare botnet o rallentare artificialmente il ritmo. Bloccare semplicemente un IP dopo alcuni errori non equivale quindi a risolvere il problema.
Una difesa efficace deve considerare più segnali: account coinvolti, sorgenti, frequenza, user agent, comportamento e contesto della richiesta.
Attacchi offline contro password hash e credenziali sottratte
Lo scenario offline è diverso.
Se un attaccante riesce a ottenere gli hash delle password, per esempio dopo la compromissione di un database, può provare password candidate sui propri sistemi. Non deve più inviare una richiesta al sito per ogni tentativo.
Questo significa che CAPTCHA, rate limiting del login e blocco degli IP non possono rallentare quel processo.
La sicurezza dipende molto di più dalla qualità delle password e da come vengono archiviate.
La Password Storage Cheat Sheet di OWASP raccomanda algoritmi specificamente progettati per rendere costosa la verifica delle password e l’uso di un salt univoco. Il salt rende inoltre inefficaci le classiche tabelle precalcolate usate negli attacchi rainbow table contro archiviazioni deboli.
Il punto pratico è importante: la stessa parola “brute force” può descrivere un bot che martella una pagina di login oppure milioni di verifiche eseguite lontano dal server bersaglio. Le difese non sono intercambiabili.
Perché password corte, comuni o riutilizzate aumentano il rischio
Una password non è debole soltanto perché manca un simbolo.
Le regole moderne sulla sicurezza delle password attribuiscono molta più importanza a lunghezza, unicità e resistenza agli elenchi di password conosciute rispetto alla vecchia formula “maiuscola + minuscola + numero + carattere speciale”.
Le indicazioni NIST SP 800-63B non raccomandano di imporre regole compositive arbitrarie. Per una password usata come unico fattore prevedono una lunghezza minima di 15 caratteri e richiedono inoltre controlli contro password comuni, prevedibili o già compromesse.
Questo non significa che 15 caratteri siano una soglia universale che rende automaticamente sicura qualsiasi password. È un riferimento normativo per chi progetta sistemi di autenticazione, non una formula matematica applicabile a ogni scenario.
Per l’utente la strategia rimane più semplice: password lunghe, uniche per ogni servizio e gestite con un password manager affidabile.
Il riutilizzo è particolarmente pericoloso perché trasforma una violazione avvenuta altrove in un possibile accesso al tuo account attraverso credential stuffing.
Quali tipi di attacchi brute force esistono
Le tecniche possono combinarsi. Un aggressore raramente è obbligato a scegliere tra “brute force puro” e “dizionario” come fossero categorie isolate: può partire dalle opzioni più probabili e ampliare progressivamente i tentativi.
Brute force semplice
È il modello più vicino all’idea letterale di forza bruta: provare sistematicamente molti possibili valori.
Il costo cresce con la dimensione dello spazio da esplorare. Per questo una password lunga e non prevedibile cambia molto più dello scambio di una lettera minuscola con una maiuscola in una password corta e comune.
Negli attacchi online la velocità viene limitata dal servizio bersaglio e dalle sue difese. Nel cracking offline il vincolo dipende invece dall’algoritmo usato per memorizzare le password e dalla capacità di calcolo disponibile.
Attacco a dizionario e brute force ibrido
Un attacco a dizionario non parte da tutte le combinazioni possibili. Utilizza parole, password frequenti e valori considerati probabili.
Un approccio ibrido può poi trasformare questi candidati aggiungendo numeri, variazioni, suffissi o altri pattern tipici delle password create dagli utenti.
È proprio per questo che una password apparentemente “complessa” può essere ancora debole quando segue schemi prevedibili.
Reverse brute force e password spraying
Nel modello tradizionale si prendono uno o pochi account e si provano molte password.
Nel password spraying si fa quasi il contrario: una password comune, o una lista molto piccola, viene provata su numerosi account.
L’obiettivo è anche evitare le difese che bloccano un account dopo molti errori consecutivi. Un sistema che osserva soltanto la quantità di errori del singolo utente può quindi perdere il pattern complessivo.
Questo è uno dei motivi per cui i lockout troppo semplici non dovrebbero essere l’unica difesa.
Credential stuffing: perché è simile ma non è la stessa cosa
Nel credential stuffing l’attaccante non sta necessariamente cercando di indovinare una password.
Dispone già di coppie username-password ottenute da precedenti violazioni e le prova contro altri servizi nella speranza che l’utente abbia riutilizzato le stesse credenziali.
La difesa più importante cambia di conseguenza: una password molto lunga non aiuta se quella stessa password è già stata rubata e viene riutilizzata altrove.
Per questo password uniche, controllo delle credenziali compromesse e autenticazione multifattore sono così importanti.
Come capire se è in corso un attacco brute force
Un singolo login fallito non dimostra nulla. Anche decine di errori possono dipendere da utenti reali, configurazioni errate o applicazioni che continuano a usare vecchie credenziali.
Quello che interessa è il pattern.
Login falliti, username inesistenti e pattern anomali
Tra i segnali da analizzare ci sono numerosi errori di autenticazione concentrati nel tempo, tentativi verso account inesistenti, accessi distribuiti su molti utenti, improvvisi picchi di richieste al login e sequenze di fallimenti seguite da un’autenticazione riuscita.
MITRE include proprio questi comportamenti tra le strategie di detection per il brute force.
Anche la distribuzione conta. Centinaia di tentativi provenienti dallo stesso indirizzo IP sono facili da riconoscere. Un attacco distribuito tra molte sorgenti, con frequenza ridotta per ciascuna, è più difficile da distinguere dal traffico normale.
Per questo i log di autenticazione sono più utili quando permettono di correlare almeno:
utente, timestamp, risultato, origine della richiesta e contesto dell’accesso.
Perché bloccare un singolo indirizzo IP spesso non basta
Un IP block può essere utile contro una sorgente chiaramente abusiva, ma è una misura tattica.
Botnet, proxy e infrastrutture distribuite consentono di cambiare origine. Inoltre un indirizzo può essere condiviso da più utenti legittimi.
Anche l’approccio opposto può creare problemi: una policy di lockout troppo aggressiva può essere sfruttata per bloccare intenzionalmente gli account di utenti reali. MITRE segnala esplicitamente questo rischio quando tratta le policy di account lockout.
Quindi il criterio corretto non è “blocca dopo tre errori e hai risolto”. È rallentare l’automazione senza trasformare il meccanismo di difesa in un problema per gli utenti legittimi.
Come proteggersi dagli attacchi brute force
Non esiste una singola impostazione che renda inutile ogni tentativo.
Il modello più robusto è a strati: ridurre la probabilità che una password sia indovinabile, rendere meno conveniente automatizzare i tentativi, aggiungere un secondo fattore e intercettare il traffico anomalo prima possibile.
Password lunghe, uniche e non compromesse
Una buona password dovrebbe prima di tutto essere unica.
Se viene utilizzata anche su un altro servizio, una violazione esterna può trasformarsi immediatamente in credential stuffing contro il tuo account.
La lunghezza aumenta inoltre lo spazio delle possibilità e rende il guessing esaustivo più costoso. Per questo conviene usare un password manager: permette di generare e conservare credenziali lunghe senza costringerti a memorizzarle.
Le vecchie regole compositive possono ancora aumentare lo spazio dei caratteri in alcune condizioni, ma non dovrebbero diventare il criterio principale. Una password breve e prevedibile non diventa automaticamente robusta perché termina con !1.
MFA, autenticazione a due fattori e passkey
Anche una password robusta può essere rubata.
L’autenticazione a due fattori riduce la dipendenza dalla sola password perché richiede un ulteriore fattore per completare l’accesso.
Questo è particolarmente efficace contro password guessing e credential stuffing: trovare o possedere la password non è più sufficiente.
Quando il servizio le supporta, le passkey possono spostare ulteriormente il modello di autenticazione lontano dalle password tradizionali. Sono basate su credenziali crittografiche e progettate anche per offrire una maggiore resistenza al phishing.
Password, MFA e passkey non vanno però messe tutte sullo stesso piano: le passkey possono sostituire l’autenticazione tramite password in sistemi compatibili, mentre la 2FA aggiunge normalmente un fattore a un processo che può ancora includere la password.
Rate limiting, lockout e bot challenge
Il rate limiting riduce il numero di richieste che una sorgente o un determinato contesto può effettuare in un certo intervallo.
È uno dei controlli più direttamente legati al costo di un brute force online: meno tentativi possono essere verificati, più l’automazione diventa lenta.
Il lockout agisce invece sull’account dopo una serie di errori. Può essere utile, ma bisogna evitare soglie troppo aggressive che rendano semplice provocare un denial of service contro utenti reali.
Le challenge anti-bot aggiungono un ulteriore segnale. In un sito web può essere utile, per esempio, presentare Cloudflare Turnstile alle richieste considerate sospette invece di sottoporre indiscriminatamente ogni visitatore a una verifica.
Nessuna di queste misure è sufficiente da sola. Un attaccante distribuito può cambiare IP; un password spraying può mantenere basso il numero di errori per singolo account; una challenge mal progettata può creare soltanto attrito.
WAF e CDN: bloccare i tentativi prima che raggiungano l’applicazione
Quando possibile, conviene fermare il traffico automatizzato prima che venga elaborato dall’applicazione.
Un WAF, Web Application Firewall, può applicare regole, rate limit e challenge a monte del server applicativo.
Il vantaggio non è soltanto legato all’autenticazione.
Anche un brute force che non riesce a trovare la password può generare un numero elevato di richieste. Se ogni tentativo avvia PHP, interroga il database e carica l’applicazione, l’attacco può comunque consumare risorse.
Bloccare o rallentare la richiesta all’edge riduce questo costo.
Monitoraggio e alert sugli accessi sospetti
La prevenzione non sostituisce l’osservabilità.
Gli alert possono evidenziare:
- aumenti improvvisi dei login falliti;
- accessi riusciti dopo sequenze anomale di errori;
- tentativi verso username inesistenti;
- distribuzione degli errori su molti account;
- cambiamenti insoliti nelle provenienze degli accessi;
- attività inattesa sugli account amministrativi.
Il monitoraggio serve anche a evitare conclusioni affrettate. Un picco di errori non è automaticamente prova di compromissione; deve essere interpretato insieme agli altri eventi.
Brute force su WordPress: come proteggere davvero il login
WordPress merita un approfondimento specifico perché è un bersaglio molto comune dei bot automatici, ma la strategia efficace non consiste nell’installare un plugin casuale e dimenticare il problema.
La stessa documentazione ufficiale WordPress sugli attacchi brute force oggi mette al centro difesa multilivello, 2FA, rate limiting, WAF, challenge anti-bot, controllo di XML-RPC e monitoraggio.
Per una visione più ampia dell’hardening puoi affiancare queste misure alla nostra guida alla sicurezza WordPress.
wp-login.php e wp-admin: cosa proteggere
Il punto di autenticazione standard è wp-login.php; /wp-admin/ rappresenta invece l’area amministrativa e può reindirizzare al login quando l’utente non è autenticato.
I bot conoscono perfettamente questi percorsi. Non ha quindi senso basare la sicurezza sull’idea che nessuno sappia dove si trovi il login.
Le difese principali dovrebbero agire sul processo di autenticazione:
password uniche → 2FA o passkey → rate limiting → challenge quando necessaria → WAF/edge → monitoring.
Anche il numero degli amministratori conta. Un account che non necessita di privilegi amministrativi non dovrebbe mantenerli per comodità.
XML-RPC: quando limitarlo o disabilitarlo
xmlrpc.php permette ad applicazioni e servizi esterni di comunicare con WordPress.
Può però essere sfruttato anche come superficie per tentativi automatizzati di autenticazione. La guida ufficiale WordPress richiama in particolare l’attenzione sul metodo system.multicall.
Se non utilizzi XML-RPC, puoi valutarne la disattivazione.
Se invece serve a Jetpack, applicazioni mobili o integrazioni effettivamente utilizzate, bloccarlo indiscriminatamente potrebbe rompere quelle funzionalità. In questo scenario è preferibile limitarlo, monitorarlo e applicare regole WAF o rate limiting appropriate.
La decisione corretta è quindi:
non usato → valuta la disattivazione;
usato → proteggi e limita, invece di bloccare alla cieca.
Plugin WordPress o WAF: dove conviene applicare il rate limiting
Un plugin di sicurezza può controllare i tentativi di accesso e applicare lockout direttamente in WordPress.
Funziona, ma c’è una differenza architetturale importante: per intervenire, WordPress e PHP devono comunque ricevere almeno parte delle richieste.
Un WAF, un reverse proxy o una protezione offerta dall’hosting può invece fermare l’abuso prima che la richiesta raggiunga l’applicazione.
Per un piccolo numero di tentativi la differenza può essere trascurabile. Durante un attacco intenso diventa più importante.
Per questo sceglierei, quando disponibile:
protezione edge/server come primo filtro + protezioni applicative WordPress come secondo livello.
Non è necessario installare cinque plugin diversi che tentano di fare la stessa cosa.
Wordfence, Turnstile e 2FA: difese complementari, non alternative
Wordfence può limitare i tentativi di login, gestire lockout e controllare alcune configurazioni legate all’autenticazione e a XML-RPC.
Turnstile può invece aggiungere una challenge anti-bot nei punti appropriati.
La 2FA interviene ancora più avanti: anche quando la password viene indovinata o sottratta, richiede un ulteriore fattore.
Le tre tecnologie rispondono quindi a domande differenti:
| Livello | Domanda |
|---|---|
| Rate limiting / firewall | Possiamo rallentare o fermare l’automazione? |
| Turnstile / challenge | Questa richiesta sembra provenire da un utente reale? |
| 2FA | La password da sola è sufficiente per entrare? |
Il valore sta nella combinazione, non nel trovare “il miglior plugin brute force”.
Cambiare l’URL di login riduce il rumore, ma non basta
Cambiare il percorso standard del login può ridurre una parte dei bot opportunistici che cercano automaticamente wp-login.php.
Può quindi avere una funzione pratica, soprattutto per diminuire rumore e richieste automatiche non sofisticate. Se vuoi applicare questa misura trovi una guida specifica su come cambiare l’URL della pagina di accesso a WordPress.
Non considerarla però una sostituzione di 2FA, rate limiting o WAF.
Un endpoint “nascosto” può essere scoperto e non protegge automaticamente altre superfici di autenticazione. La stessa documentazione WordPress tratta oggi questo approccio come misura secondaria, non come difesa centrale.
Nascondere la porta non equivale a installare una serratura migliore.
Cosa fare se stai subendo un attacco brute force
Se i log mostrano un attacco in corso, la priorità non è iniziare a bloccare manualmente decine di IP uno alla volta.
Serve prima capire se i tentativi sono solo falliti o se esiste un possibile accesso riuscito.
Contenere i tentativi senza bloccare inutilmente gli utenti reali
Se l’attacco è online, puoi aumentare temporaneamente rate limiting e challenge sul punto di autenticazione, bloccare sorgenti chiaramente abusive e verificare che WAF o protezioni dell’hosting stiano intercettando correttamente le richieste.
Controlla però gli effetti sugli utenti reali.
Un lockout troppo severo applicato durante un password spraying può creare un secondo problema: l’attaccante può provocare il blocco di molti account senza averne compromesso nessuno.
Su WordPress conviene controllare almeno wp-login.php, eventuale traffico a xmlrpc.php, log del plugin di sicurezza e log disponibili a livello di hosting, proxy o CDN.
Quando cambiare le credenziali e verificare una possibile compromissione
Una sequenza di login falliti non richiede automaticamente di cambiare tutte le password.
La situazione cambia se:
- compare un login riuscito anomalo;
- un account amministrativo mostra attività inattesa;
- esistono credenziali note come compromesse;
- vengono creati utenti o privilegi non autorizzati;
- compaiono modifiche che non riconosci;
- ci sono altri indicatori di compromissione.
In quel caso il problema non è più soltanto “bloccare il brute force”. Devi trattare l’evento come una possibile violazione: revocare o sostituire le credenziali coinvolte, verificare sessioni e account, controllare l’integrità del sistema e determinare cosa sia realmente accaduto.
Su WordPress questo significa evitare di confondere prevenzione brute force e scansione malware. Una scansione è utile per cercare segnali di compromissione, ma non impedisce a un bot di provare password sul login.
Conclusione
Un attacco brute force è semplice come concetto: provare credenziali fino a trovarne una valida. Difendersi bene è meno banale, perché sotto la stessa famiglia convivono password guessing, password spraying, credential stuffing e cracking offline.
La decisione più importante è capire dove avviene l’attacco.
Se i tentativi raggiungono un login online, puoi intervenire con rate limiting, WAF, challenge anti-bot, MFA e monitoraggio. Se l’aggressore possiede già gli hash delle password e lavora offline, contano soprattutto qualità delle password e corretta archiviazione crittografica. Se usa credenziali rubate, diventano determinanti password uniche e un secondo fattore.
Su WordPress applicherei la stessa logica a strati: password uniche, 2FA o passkey, rate limiting possibilmente prima di PHP, protezione di wp-login.php e xmlrpc.php, WAF e monitoraggio. Cambiare l’URL del login può ridurre parte del rumore automatico, ma deve restare una misura complementare.
Il criterio da ricordare è semplice: non cercare una singola impostazione che “blocchi il brute force”. Riduci progressivamente le possibilità dell’attaccante e assicurati che una password, anche se scoperta, non basti da sola a compromettere l’account.