Il brute force è l’attacco più semplice che esista: provare, ancora e ancora, finché non si indovina. Il MITRE lo descrive (CAPEC-112) come una serie di tentativi contro un segreto di dimensione finita, il che implica che prima o poi riesce sempre, se lo si lascia fare. Tutta la difesa consiste quindi nel rendere l’operazione troppo lunga o troppo costosa perché valga la pena. Su WordPress, questo rumore di fondo inizia spesso già alla messa online di un sito.
Come funziona un attacco brute force
Un programma invia coppie di nome utente e password al modulo di login e osserva la risposta. Su WordPress, i bersagli abituali sono wp-login.php e xmlrpc.php. Il nome utente viene spesso indovinato in anticipo: admin, il nome del sito o il nome di un autore ottenuto con l’enumerazione degli utenti.
Le varianti
- Esaustivo: tutte le combinazioni possibili, realistico solo contro segreti molto corti.
- A dizionario: elenchi di password comuni, con varianti (maiuscola, anno, cifra finale). È la forma più diffusa contro i siti.
- Distribuito: il lavoro è ripartito tra migliaia di macchine compromesse (una botnet), ciascuna delle quali fa solo pochi tentativi.
- Con credenziali rubate: non si indovina più, si riprovano coppie provenienti da data breach. È il credential stuffing, parente stretto del brute force.
La documentazione di WordPress ricorda un effetto spesso sottovalutato: anche quando falliscono, questi tentativi consumano risorse e possono rallentare, o persino saturare, un server. Il nostro articolo sul brute force su WordPress mostra come individuarli nei tuoi log.
Come proteggersi
Le protezioni efficaci agiscono su più livelli. Il NIST, nella norma SP 800-63B, chiede di limitare a un massimo di 100 i tentativi falliti consecutivi su un account, e ammette soglie più basse. Chiede anche di rifiutare le password comuni o già compromesse al momento della loro creazione.
- Password lunghe e uniche, generate da un password manager: è ciò che rende inutile il dizionario.
- L’autenticazione a due fattori per tutti gli account con privilegi: una password scoperta non basta più.
- La limitazione dei tentativi, a livello di server o con un plugin. La nostra guida alle soglie e durate di blocco descrive le impostazioni e le insidie (proxy, rete condivisa).
- Meno porte aperte: disattivare XML-RPC se non serve, limitare
wp-login.phpper indirizzo IP o con una password lato server quando è possibile. - Un filtraggio a monte: un firewall applicativo o una CDN bloccano parte del traffico prima che raggiunga PHP, alleggerendo il server.
Per WordPress
WordPress non include né la limitazione dei tentativi né l’autenticazione a due fattori: serve un plugin o una regola sul server. Evita un account chiamato admin, riserva il ruolo di Amministratore a chi ne ha bisogno e controlla regolarmente l’elenco degli account con wp user list --role=administrator. Per le applicazioni esterne, preferisci le password per le applicazioni, revocabili una per una, alla password principale.
WP Masquerade sposta la pagina di login e blocca XML-RPC già nella versione gratuita. La versione Pro aggiunge la limitazione dei tentativi di login (da 3 a 30 errori, blocco da 1 a 60 minuti) con messaggi di errore neutri. Non è un firewall di rete: contro un attacco molto distribuito, la vera difesa resta una password unica e un secondo fattore.
Errori frequenti
- Contare solo sul cambio dell’indirizzo di login: riduce il rumore, ma non protegge una password debole.
- Sommare due plugin di limitazione che contano gli stessi errori: lo sblocco diventa un rompicapo.
- Dimenticare il proxy o la CDN: senza il ripristino del vero indirizzo IP, tutti i visitatori condividono lo stesso contatore.
- Imporre cambi di password periodici: il NIST chiede al contrario di non richiederli più, salvo sospetto di compromissione.