Proteggere wp-login da attacchi brute force
Cos’è un attacco brute force su wp-login e perché è possibile
Un attacco brute force consiste in tentativi di accesso automatizzati e ripetuti su wp-login.php, in cui uno script prova combinazioni di nome utente e password (spesso da elenchi di credenziali già trapelate altrove) alla ricerca di una che funzioni. È possibile perché WordPress, nella sua configurazione predefinita, non impone alcun limite al numero di tentativi di accesso falliti: puoi provare a inserire una password sbagliata quante volte vuoi, senza che il sito rallenti o blocchi nulla da solo.
wp-login.php pubblicamente raggiungibile senza alcun limite
La causa di base, comune a ogni sito WordPress non protetto in modo specifico, è proprio questa: l’indirizzo di login è pubblico e prevedibile (tuosito.it/wp-login.php), e senza un meccanismo aggiuntivo che conti e limiti i tentativi falliti, uno script può provare migliaia di combinazioni senza alcun ostacolo, con l’unico limite dato dalla velocità della propria connessione.
xmlrpc.php che amplifica l’efficacia degli attacchi
Una causa che aumenta significativamente il rischio, spesso trascurata, riguarda il file xmlrpc.php: questa interfaccia, pensata per permettere a strumenti esterni (app mobile, editor remoti) di comunicare con WordPress, include una funzione (system.multicall) che permette di provare centinaia di combinazioni di credenziali in un’unica richiesta HTTP. Questo non solo rende l’attacco più veloce, ma può bypassare plugin di limitazione tentativi configurati per contare solo i tentativi di accesso passati direttamente da wp-login.php.
Username prevedibili ancora in uso
Un caso da citare, meno una causa tecnica e più una debolezza di configurazione, riguarda l’uso di nomi utente prevedibili come “admin” o il nome del dominio stesso: un attacco brute force deve indovinare sia il nome utente sia la password, e un nome utente scontato dimezza di fatto il lavoro necessario per chi tenta l’accesso.
Come capire se il sito sta subendo un attacco
Prima di attivare protezioni, un rapido controllo dei log conferma se il sito è già bersaglio di tentativi ripetuti, e ti dà un’idea della scala del problema.
Leggere i segnali nei log di accesso
Se il tuo hosting mette a disposizione un log degli accessi (spesso nel pannello, sotto voci come “Log accessi” o “Statistiche”), cerca un numero elevato di richieste verso wp-login.php o xmlrpc.php in un breve periodo di tempo, spesso da indirizzi IP diversi tra loro (segno di una rete distribuita di bot, non un singolo attacco isolato). Anche senza un log dedicato, un plugin di sicurezza installato di recente spesso mostra subito un numero sorprendentemente alto di tentativi di accesso falliti già nelle prime ore.
Verificare se xmlrpc.php è attivo e raggiungibile
Apri nel browser tuosito.it/xmlrpc.php: se il file risponde con un messaggio che conferma il funzionamento del servizio (invece di un errore 403 o 404), l’interfaccia è attiva e potenzialmente sfruttabile per amplificare un attacco, a meno che tu non usi effettivamente strumenti che ne hanno bisogno.
| Sintomo osservabile | Causa probabile |
|---|---|
| Numero elevato di richieste a wp-login.php nei log, da IP diversi | Attacco brute force distribuito in corso |
| Molte richieste concentrate su xmlrpc.php | Tentativo di sfruttare system.multicall per accelerare l’attacco |
| Un plugin di sicurezza segnala centinaia di tentativi falliti nelle prime ore dall’installazione | Il sito era già bersaglio di un attacco prima di essere protetto |
| xmlrpc.php risponde normalmente e non usi app esterne che ne hanno bisogno | Superficie di attacco aggiuntiva non necessaria, disattivabile |
| L’attacco sembra concentrato su un singolo nome utente prevedibile (admin) | Username scontato usato come punto di partenza per il tentativo |
Proteggere wp-login: limitare i tentativi di accesso
La soluzione più diretta ed efficace è imporre un limite al numero di tentativi di accesso falliti consentiti, bloccando temporaneamente chi lo supera prima ancora che possa provare un numero significativo di combinazioni.
Installare un plugin di limitazione tentativi
Installa un plugin dedicato (Limit Login Attempts Reloaded è tra i più diffusi e leggeri, oppure la funzionalità equivalente inclusa in Wordfence se già presente) e attivalo. Questi plugin intercettano ogni tentativo di accesso fallito e iniziano a contarli per ogni indirizzo IP, bloccando temporaneamente chi supera la soglia impostata.
Configurare soglia e durata del blocco
Nelle impostazioni del plugin, imposta un numero ragionevole di tentativi falliti consentiti prima del blocco (un valore troppo basso rischia di bloccare te stesso per un errore di battitura) e una durata del blocco che scoraggi i tentativi automatizzati senza essere eccessivamente punitiva per un errore umano occasionale — valori come 4-5 tentativi con un blocco iniziale di alcuni minuti, che si allunga progressivamente per gli IP recidivi, sono un compromesso comune.
Verificare che il blocco funzioni senza escludere te stesso
Prova a inserire volontariamente una password sbagliata alcune volte per confermare che il blocco scatti come previsto, poi verifica di poter comunque accedere correttamente una volta trascorso il tempo di blocco o inserendo la password corretta. Se il tuo indirizzo IP cambia spesso (connessione mobile, VPN), valuta se il plugin offre un’opzione di whitelist per il tuo IP abituale, per ridurre il rischio di bloccarti da solo.
Disattivare o limitare xmlrpc.php
Se non usi strumenti esterni che richiedono esplicitamente xmlrpc.php (alcune app mobile per la gestione di WordPress, servizi di pubblicazione automatica, o il sistema di pingback/trackback tra siti), la protezione più efficace è disattivarlo del tutto: molti plugin di sicurezza offrono questa opzione con un semplice interruttore, oppure puoi bloccare l’accesso al file direttamente tramite una regola nel file .htaccess. Se invece ti serve per qualche integrazione specifica, alcuni plugin permettono di limitare xmlrpc.php solo alle funzioni realmente necessarie, disabilitando in particolare system.multicall, il punto più sfruttato per amplificare gli attacchi.
Non riesci a risolvere? Intervento tecnico a distanza
Se non sei sicuro di come configurare correttamente un plugin di limitazione tentativi senza rischiare di bloccare l’accesso legittimo, se non sai se il tuo sito usa davvero xmlrpc.php per qualche integrazione, o se il sito continua a mostrare segnali di un attacco intenso nonostante le protezioni attivate, è possibile richiedere una verifica diretta della configurazione di sicurezza del sito: si valuta quali protezioni servono davvero per il tuo caso specifico e si configurano senza compromettere l’accesso legittimo.
Domande frequenti sulla protezione di wp-login da attacchi brute force
Un attacco brute force può riuscire ad accedere al mio sito? Sì, se la password è debole o già compromessa altrove: per questo limitare i tentativi va sempre affiancato da password robuste e uniche per ogni utente amministratore, non sostituito da esse.
Disattivare xmlrpc.php ha controindicazioni? Solo se usi effettivamente strumenti che ne dipendono (alcune app mobile di gestione WordPress, servizi di pubblicazione automatica): se non li usi, disattivarlo riduce semplicemente una superficie di attacco non necessaria.
Quanti tentativi falliti sono ragionevoli prima del blocco? Un valore tra 4 e 6 tentativi è un compromesso comune tra sicurezza e tolleranza per errori umani occasionali di battitura, con un blocco che si allunga progressivamente per chi continua a fallire ripetutamente.
Nascondere l’indirizzo di wp-login.php (cambiandolo) serve a qualcosa? Può ridurre il rumore di fondo dato dai bot più generici che colpiscono l’indirizzo standard, ma non sostituisce una vera limitazione dei tentativi: un attaccante mirato può comunque scoprire l’indirizzo personalizzato in altri modi.
Come faccio a sapere se sto già subendo un attacco in questo momento? Un plugin di limitazione tentativi mostra solitamente, già nel suo pannello, il numero di tentativi bloccati di recente: un numero elevato nelle prime ore dopo l’installazione conferma che il sito era già bersaglio prima di essere protetto.
Vuoi risolverlo con un intervento diretto? Se non sei sicuro di come proteggere correttamente wp-login senza rischiare di bloccare l’accesso legittimo, è possibile richiedere una verifica diretta della configurazione di sicurezza del sito, adatta al tuo caso specifico. → Richiedi assistenza tecnica.