Come proteggere WordPress dagli attacchi brute force

Gli attacchi brute force contro WordPress automatizzano tentativi di accesso finché trovano una combinazione valida. Anche quando non riescono a entrare, possono consumare risorse, riempire i log e rallentare il sito. Cambiare soltanto l’indirizzo della pagina di login non risolve il problema: servono credenziali robuste, più fattori, limitazioni, monitoraggio e protezioni prima che le richieste raggiungano WordPress.

La strategia efficace distingue tipi di attacco e applica livelli complementari. Se una password è già stata rubata in un altro servizio, limitare migliaia di tentativi sullo stesso account può non bastare. Se invece una botnet distribuisce le richieste su molti indirizzi, un semplice blocco IP può essere facilmente aggirato.

Brute force, credential stuffing e password spraying

Nel brute force vengono provate molte password contro uno o pochi account. Nel credential stuffing vengono riutilizzate coppie email-password provenienti da violazioni di altri servizi. Nel password spraying poche password comuni vengono tentate su molti utenti per evitare blocchi per singolo account.

Le difese si sovrappongono ma non sono identiche. Password uniche riducono il credential stuffing; MFA protegge anche quando la password è nota; rate limiting e challenge rallentano automazione; monitoraggio tra account e indirizzi aiuta a riconoscere attacchi distribuiti.

1. Censire tutte le superfici di autenticazione

WordPress non si accede soltanto da wp-login.php. Considerate XML-RPC, REST API, password applicative, hosting, SFTP, database, pannello del provider, CDN e account email usato per il recupero. Proteggere la pagina visibile lasciando esposta una credenziale più potente crea una barriera incompleta.

Elencate utenti, ruoli, integrazioni e proprietari. Rimuovete account inutilizzati e cambiate quelli condivisi in identità nominative. Verificate quali sistemi possono creare o reimpostare un amministratore: email, hosting e dominio meritano almeno lo stesso livello di protezione di WordPress.

2. Usare password lunghe, uniche e gestite

Ogni account deve avere una password diversa, generata e conservata in un password manager affidabile. Evitate nomi dell’azienda, date, sequenze e variazioni prevedibili. Cambiare periodicamente password uniche senza segnali di compromissione può spingere a schemi più deboli; ruotatele quando sono condivise, esposte o sospette.

Non inviate password in chiaro via email o chat. Per collaboratori create account temporanei con il ruolo minimo e revocateli alla fine. L’utente “admin” non crea da solo la vulnerabilità, ma un nome prevedibile elimina una parte del lavoro dell’attaccante: usate identità individuali e non mostrate pubblicamente lo username di accesso quando evitabile.

3. Attivare la 2FA per gli account privilegiati

L’autenticazione a due fattori impedisce che la sola password sia sufficiente. Attivatela almeno per amministratori, editor con ampi privilegi e account che gestiscono hosting, dominio ed email. WordPress core non integra direttamente la 2FA: utilizzate un plugin mantenuto o un provider di identità compatibile.

Preferite chiavi di sicurezza o passkey quando disponibili, quindi applicazioni TOTP; SMS è meglio della sola password ma presenta limiti. Conservate codici di recupero fuori dal sito e provate la procedura per perdita del dispositivo. Evitate bypass permanenti che annullano il secondo fattore.

4. Limitare i tentativi in modo proporzionato

Rate limiting, ritardi progressivi e blocchi temporanei riducono l’automazione. Applicateli per account, indirizzo e altri segnali quando possibile. Blocchi permanenti o soglie troppo basse possono escludere utenti legittimi e diventare essi stessi uno strumento di disturbo.

Una protezione a livello CDN, proxy o server blocca richieste prima che avviino PHP e interroghino il database. Un plugin applicativo vede più contesto WordPress ma consuma comunque risorse. Nei siti esposti è utile combinare edge e applicazione, evitando regole duplicate che rendono difficile la diagnosi.

5. Usare challenge senza danneggiare l’accessibilità

CAPTCHA e sistemi anti-bot possono rallentare automazioni, ma non devono essere l’unica difesa. Preferite challenge adattive o non interattive per traffico sospetto. Verificate tastiera, screen reader, contrasto e possibilità di completare l’accesso senza risolvere immagini ambigue.

Controllate privacy, cookie e trasferimento di dati del fornitore scelto. Se la challenge non carica, prevedete una procedura alternativa sicura. Misurate falsi positivi e richieste di supporto, non soltanto il numero di bot bloccati.

6. Gestire XML-RPC secondo le funzioni usate

XML-RPC può essere utilizzato da applicazioni e integrazioni, ma è anche una superficie di autenticazione. Se il sito non ne ha bisogno, può essere disabilitato o ristretto. Se viene usato, applicate rate limiting, monitoraggio e regole compatibili con i servizi necessari.

Non bloccate xmlrpc.php senza verificare Jetpack, app mobili, pubblicazione remota o altre dipendenze. Testate in staging e controllate i log dopo il rilascio. Lo stesso principio vale per REST API e password applicative: non disabilitate funzioni generali quando è sufficiente revocare credenziali o limitare permessi.

7. Proteggere wp-login.php e wp-admin al livello giusto

Un WAF o reverse proxy può applicare reputazione IP, challenge e rate limiting prima del server. Per aree amministrative riservate a poche persone può essere utile una VPN, allowlist gestita o autenticazione aggiuntiva, considerando connessioni mobili e continuità operativa.

Nascondere l’URL di login riduce parte del rumore, ma è sicurezza per oscurità e non sostituisce le difese. Protezioni generiche su tutta la cartella wp-admin possono rompere admin-ajax.php e funzioni del front-end. Applicate regole mirate, documentate e testate.

8. Aggiornare e ridurre i privilegi

Un accesso ottenuto tramite password diventa più grave se l’account può installare codice o se tema e plugin contengono vulnerabilità. Aggiornate WordPress, componenti e PHP con backup e test. Rimuovete plugin inutilizzati e software non mantenuto.

Usate ruoli minimi per il lavoro quotidiano e limitate gli amministratori. Disabilitare l’editor di file nella dashboard può contenere una modalità di modifica, ma non ferma un attaccante con accesso completo al server. La difesa deve includere permessi dei file, hosting e credenziali infrastrutturali.

9. Monitorare tentativi e accessi riusciti

Registrate tentativi falliti, successi, nuovi dispositivi, cambi di ruolo, creazione utenti e reimpostazioni password. Correlate molti account dallo stesso indirizzo e lo stesso account da molte sorgenti. Una botnet distribuita può restare sotto la soglia di un semplice contatore per IP.

Impostate avvisi utili con responsabile e azione. Proteggete i log da modifiche e conservateli abbastanza a lungo per investigare. Non raccogliete dati senza limiti: definite finalità, accesso e conservazione in modo proporzionato.

10. Evitare che l’attacco rallenti il sito

Migliaia di richieste a login o XML-RPC possono saturare processi PHP e database. Monitorate carico, tempi di risposta e codici HTTP durante i picchi. Portate rate limiting e bot management il più vicino possibile al bordo della rete, mantenendo una configurazione che non blocchi utenti o integrazioni.

La cache di pagina non protegge l’autenticazione, perché il login deve rimanere dinamico. Scalare il server senza filtrare il traffico abusivo aumenta il costo ma non elimina la causa. Collaborate con hosting o CDN quando il volume supera le possibilità del plugin.

11. Preparare il recupero di un account compromesso

Definite in anticipo chi può sospendere un account, modificare DNS, accedere all’hosting e ripristinare il sito. Conservate backup separati, codici di recupero e contatti del provider. Una procedura scritta evita decisioni improvvisate durante l’incidente.

Se un accesso riesce, non limitatevi a cambiare password. Revocate sessioni e password applicative, ruotate chiavi e credenziali collegate, controllate utenti, file, plugin, task programmati, email e DNS. Determinate il punto di ingresso e monitorate dopo il ripristino.

12. Verificare le difese senza attaccare il sito pubblico

In staging provate password errata, account bloccato, 2FA, recupero, challenge e revoca di sessione. Verificate utenti dietro NAT, reti mobili e collaboratori autorizzati. Controllate che gli avvisi arrivino e che sia possibile sbloccare un falso positivo in sicurezza.

Non eseguite test massivi non autorizzati sul sito online. Per valutazioni di carico e sicurezza concordate limiti, finestre e contatti con hosting e proprietario. Ogni modifica deve avere backup, documentazione e rollback.

Checklist anti brute force WordPress

• Inventario di account e superfici di login.
• Password uniche conservate in un password manager.
• 2FA per amministratori e sistemi collegati.
• Rate limiting e blocchi temporanei al livello edge/server.
• Challenge accessibili per traffico sospetto.
• XML-RPC e password applicative limitati alle funzioni necessarie.
• WordPress, plugin, tema e PHP aggiornati.
• Ruoli minimi e account temporanei revocati.
• Log e avvisi su fallimenti, successi e anomalie.
• Piano di recupero provato e backup separati.

Approfondite l’autenticazione a due fattori, l’hardening di WordPress e gli errori comuni di sicurezza aziendale. LBCOMPANY interviene in tutta Italia su attacchi, recupero e protezione WordPress: consultate i servizi.