Come proteggere WordPress da attacchi DDoS e brute force

DDoS e brute force vengono quasi sempre nominati insieme, ma hanno in comune solo due cose: sono automatizzati e non si fermano mai. Per il resto sono attacchi opposti. Uno vuole rendere il tuo sito irraggiungibile, l’altro vuole entrarci. Confonderli porta a difendere la cosa sbagliata: nessun plugin di sicurezza fermerà mai un attacco volumetrico, e nessuna CDN ti protegge da qualcuno che ha indovinato la tua password.

Questa guida tiene le due cose separate: come funzionano davvero, come ti accorgi che sta succedendo, cosa configurare per fermarle e cosa fare mentre un attacco è in corso. Se invece cerchi l’elenco completo dei controlli di sicurezza da fare su un sito WordPress, quello sta nella checklist sicurezza WordPress: 25 controlli da fare, di cui questo articolo è l’approfondimento su due voci specifiche.

Se il sito è sotto attacco proprio adesso, salta direttamente alla sezione Cosa fare se l’attacco è già in corso: la parte teorica la leggi dopo.

DDoS e brute force: due attacchi diversi, due difese diverse

La differenza sta nell’obiettivo. Un DDoS punta alla disponibilità: vuole saturare qualcosa — banda, connessioni, processi PHP — finché il sito smette di rispondere. Un brute force punta all’accesso: vuole una credenziale valida, e per ottenerla ne prova migliaia. Il primo si vede subito, il secondo può andare avanti per mesi senza che nessuno se ne accorga.

Le due cose si incrociano in un punto solo, ed è quello che genera più confusione: un brute force distribuito abbastanza aggressivo produce un effetto DDoS. Migliaia di richieste POST al minuto su wp-login.php mettono in ginocchio un server anche se nessuna di quelle password è corretta. È il motivo per cui il primo sintomo di un brute force, spesso, è la lentezza del sito.

Come funziona un attacco DDoS

Il traffico arriva da una botnet: migliaia di dispositivi infetti — computer, router domestici, telecamere IP — che inviano richieste contemporaneamente. Il proprietario del dispositivo non ne sa nulla. Gli attacchi si dividono in tre famiglie, e la differenza non è accademica perché ognuna si ferma in un punto diverso della catena.

• Volumetrici: saturano la banda disponibile con traffico grezzo, spesso amplificato attraverso servizi DNS o NTP mal configurati. Si misurano in gigabit al secondo. Si fermano solo a monte, dove la banda è più larga della tua.
• Di protocollo: esauriscono le tabelle di connessione di server e firewall senza generare volume, come il classico SYN flood. Colpiscono l’infrastruttura di rete, non l’applicazione.
• Applicativi (livello 7): sono i più insidiosi per WordPress. Simulano richieste HTTP legittime, ma le concentrano sugli endpoint più costosi da servire.

Su un sito WordPress l’attacco applicativo ha un vantaggio strutturale: gli basta chiedere le pagine che la cache non può servire. Una ricerca interna (/?s=qualcosa) con una stringa sempre diversa aggira la cache e va dritta al database. Lo stesso vale per admin-ajax.php, per wp-cron.php e per le richieste POST al login. Poche centinaia di richieste al secondo su questi endpoint bastano a saturare i worker PHP di un hosting condiviso, mentre il resto del sito — quello servito dalla cache — continua ad andare benissimo. È il motivo per cui un attacco L7 spesso non sembra un attacco: sembra un sito che ha smesso di funzionare senza motivo.

Come funziona un attacco brute force

L’immagine del software che prova tutte le combinazioni possibili è ferma agli anni Novanta. Oggi i bot non tirano a indovinare: partono da informazioni che hanno già.

• Attacco a dizionario: liste di password reali, ordinate per frequenza d’uso. Le prime mille coprono una quota di account imbarazzante.
• Credential stuffing: coppie email/password prese da violazioni di altri servizi e riprovate sul tuo sito. Non è un attacco alla tua password, è un attacco alla password che hai riusato altrove. Contro questo, la lunghezza della password non serve a niente: serve che sia unica.
• Password spraying: poche password molto comuni provate su tanti username diversi. Serve proprio ad aggirare i blocchi dopo N tentativi falliti, perché su ogni singolo account i tentativi restano due o tre.
• Via XML-RPC: xmlrpc.php accetta le stesse credenziali del login, senza CAPTCHA e senza un indirizzo da nascondere. Il vecchio trucco di impacchettare centinaia di tentativi in una sola richiesta con system.multicall non funziona più dalla 4.4 (dicembre 2015): dopo il primo errore, gli altri tentativi della stessa richiesta vengono rifiutati senza essere verificati. Resta una porta che un contatore scritto sull’indirizzo della pagina di login non vede.
• Distribuito e lento: i bot ruotano user agent e indirizzi IP tramite proxy e VPN, e rallentano di proposito la frequenza per restare sotto le soglie di allarme. Un tentativo ogni pochi minuti da IP sempre diversi non fa scattare nessun blocco basato sull’IP.

Il punto pratico è questo: le difese basate sul conteggio dei tentativi per singolo IP funzionano contro gli attacchi rumorosi, che sono la maggioranza, ma non contro quelli distribuiti. Per quelli serve un secondo fattore, che rende la password corretta insufficiente.

Perché WordPress è un bersaglio

Non è una questione di qualità del software, è una questione di scala. WordPress gira su una quota enorme del web, il che significa che scrivere un bot che attacca WordPress ha un ritorno che nessun altro CMS offre: lo stesso script funziona su milioni di installazioni senza una riga di adattamento. L’attaccante non ti ha scelto. Ha scansionato un intervallo di indirizzi e il tuo sito ha risposto.

A questo si aggiunge che l’installazione predefinita è prevedibile per definizione: l’URL di login è noto, l’endpoint XML-RPC è attivo, la REST API espone la lista degli utenti, non esiste un limite ai tentativi di accesso e la 2FA non c’è. Sono tutte scelte ragionevoli per la compatibilità, e tutte informazioni gratuite per chi attacca.

Il terzo fattore è l’ecosistema: temi e plugin di terze parti, spesso installati e poi dimenticati. Non è solo il plugin obsoleto con una vulnerabilità nota, ma anche il caso in cui il codice arriva già compromesso a monte, come racconto negli attacchi supply chain su WordPress. Un brute force che riesce e una backdoor arrivata con un aggiornamento portano allo stesso risultato, da due strade diverse.

Vale la pena aggiungere una cosa che di solito si tace: anche l’attacco che fallisce ha un costo. Ogni tentativo di login consuma un processo PHP e una query al database, ogni richiesta bloccata occupa comunque una connessione. Un sito che regge un brute force continuo è un sito che sta pagando quel traffico in performance, ogni giorno.

Come capire se sei sotto attacco

I due attacchi si manifestano in modo diverso, ma i posti dove guardare sono gli stessi. Il primo è il log degli accessi del server, quello che trovi nel pannello dell’hosting o via SSH: è l’unica fonte che vede anche le richieste che WordPress non ha mai elaborato. Il secondo è il traffico in tempo reale del plugin di sicurezza — la sezione Live Traffic di Wordfence, per esempio — che invece ti dice cosa è successo dentro WordPress, con username tentati e geolocalizzazione. Il terzo, se usi una CDN, sono le analitiche dell’edge, che mostrano il traffico prima che arrivi al tuo server.

Questi sono i segnali che contano:

• Decine o centinaia di tentativi di login falliti nell’arco di pochi minuti, spesso sullo stesso username.
• Un volume anomalo di richieste POST verso wp-login.php o xmlrpc.php nel log del server.
• Picchi di CPU e RAM senza un corrispondente aumento di traffico reale, o worker PHP tutti occupati con errori 502 e 503.
• TTFB in salita mentre le immagini e i file statici continuano a caricare normalmente: è la firma tipica di un attacco applicativo.
• 404 anomali su file che non esistono (/wp-content/plugins/qualcosa/readme.txt): non è un attacco, è la scansione che lo precede.
• Email del plugin di sicurezza o dell’hosting che segnalano blocchi, o una richiesta esplicita del provider di ridurre il consumo di risorse.

La domanda difficile è un’altra: come distingui un attacco da un picco di traffico legittimo, che è la cosa migliore che possa capitarti? Tre criteri, in ordine di affidabilità. Il traffico vero si distribuisce su molte pagine diverse, l’attacco si concentra su uno o due endpoint. Il traffico vero ha referrer plausibili e user agent vari, l’attacco arriva senza referrer o con user agent ripetuti. Soprattutto: il traffico vero compare in Google Analytics, l’attacco no, perché i bot non eseguono JavaScript. Un server in ginocchio e un pannello di analytics piatto sono, insieme, la prova più rapida che quel traffico non è di persone.

Un’avvertenza prima di allarmarsi: la maggior parte dei siti lenti non è sotto attacco, è semplicemente configurata male. Se la lentezza è costante e non a ondate, prima di cercare un attacco conviene escludere le cause ordinarie — le sei cause reali di un sito WordPress lento coprono quasi tutti i casi.

Difendersi dagli attacchi DDoS

La difesa da un DDoS si costruisce a strati, e l’ordine conta: quanto più a monte fermi il traffico, tanto meno lavoro arriva al tuo server. Un plugin è l’ultimo strato possibile, non il primo.

Una CDN con mitigazione, davanti a tutto

È l’intervento con il rapporto costi-benefici più alto in assoluto, ed è il primo da fare. Una CDN mette una rete di server tra gli utenti e il tuo hosting: il traffico malevolo viene assorbito e filtrato lì, dove la capacità si misura in terabit. Cloudflare è lo standard di fatto in ambito WordPress e il piano gratuito include già la mitigazione DDoS di rete e una regola di rate limiting.

Cosa configurare, in concreto: una regola di rate limiting sui POST a /wp-login.php — sul piano gratuito è una regola sola, contata per IP, con finestra e blocco fissi a dieci secondi; il minuto di finestra arriva con il piano Pro, i dieci minuti di blocco con il Business — e una regola che blocchi del tutto /xmlrpc.php se non usi Jetpack o l’app mobile. Solo queste due regole tolgono di mezzo la grande maggioranza del traffico automatizzato, e lo fanno prima che tocchi il tuo server.

C’è un dettaglio che rende inutile tutto il resto se lo sbagli: la CDN protegge solo se l’indirizzo IP di origine non è raggiungibile direttamente. Se l’attaccante scopre l’IP del tuo server, la scavalca e attacca il server in diretta. L’IP di origine si perde nei posti più banali: un record DNS di posta puntato sullo stesso server, un vecchio record ftp. o cpanel. rimasto attivo, un certificato SSL storico. Vale la pena controllarli tutti quando attivi la CDN — è dieci minuti di lavoro che decide se lo strato serve o no.

La modalità “Under Attack” (o equivalente) presenta a ogni visitatore una verifica JavaScript prima di far passare la richiesta. Funziona molto bene, ma è una misura da emergenza: rallenta la navigazione di tutti e non va lasciata attiva come impostazione permanente.

Firewall applicativo o firewall cloud: la differenza che conta

Un Web Application Firewall analizza il contenuto delle richieste HTTP e blocca quelle che riconosce come attacchi: SQL injection, XSS, exploit di vulnerabilità note, pattern di brute force. Ma dove gira cambia tutto.

Un WAF applicativo come quello di Wordfence gira sul tuo server, in PHP. Quando entra in azione, la richiesta è già arrivata: ha già occupato una connessione e un processo. Contro gli exploit è efficacissimo, contro un attacco volumetrico non può nulla, perché il costo lo stai pagando comunque. Va installato in protezione estesa, la modalità in cui il firewall viene caricato prima di WordPress: senza quel passaggio, che richiede una modifica alla configurazione PHP guidata dal plugin, il firewall entra in gioco troppo tardi.

Un WAF cloud come Sucuri o Cloudflare gira a monte: il traffico passa da loro e arriva al tuo server già filtrato. Ferma anche quello che il WAF applicativo non può fermare, ma richiede di far transitare il DNS dal servizio e ha un costo mensile quando serve la versione completa.

I due strati convivono bene, perché lavorano in punti diversi della catena. Quello che non deve succedere è installare due firewall applicativi sullo stesso sito: si contendono le stesse regole, si annullano a vicenda e producono blocchi imprevedibili su traffico legittimo.

Cosa può fare il server, e cosa deve fare l’hosting

Se il sito è su VPS hai a disposizione strumenti che a livello applicativo non esistono. Fail2ban legge i log di Nginx o Apache e blocca a livello di firewall di sistema gli IP che superano una soglia: agisce prima di PHP, quindi il costo di ogni richiesta bloccata crolla. Un limite sensato al numero di worker PHP-FPM evita che un picco esaurisca la memoria e porti giù l’intera macchina — meglio qualche richiesta in coda che un server che va in swap.

Su hosting condiviso o gestito questi strati non li controlli tu, ed è giusto pretenderli dal provider: protezione DDoS a livello di rete, rate limiting sugli endpoint sensibili e un supporto raggiungibile mentre l’attacco è in corso. È una domanda che vale la pena fare prima di firmare, non durante l’emergenza. E resta il punto di realtà su cui vale la pena essere onesti: contro un attacco volumetrico serio, quello che satura la banda a monte, non esiste configurazione di WordPress che tenga. Quel tipo di attacco si ferma sulla rete di chi ti ospita o sulla CDN, e da nessun’altra parte.

Difendersi dagli attacchi brute force

Qui la logica si ribalta: non devi assorbire volume, devi rendere inutile il fatto che qualcuno provi. Le misure che seguono sono in ordine di efficacia reale, non di popolarità.

Limitare i tentativi e bloccare progressivamente

WordPress, di suo, accetta tentativi di login all’infinito. Un limite — tre o cinque tentativi falliti, poi blocco temporaneo dell’IP con durata crescente a ogni recidiva — elimina di colpo tutti gli attacchi rumorosi, che sono la stragrande maggioranza. Lo fanno Wordfence, Kadence Security, All-In-One Security (AIOS) o, se preferisci qualcosa di leggero, Limit Login Attempts Security da solo.

Due accorgimenti: metti in whitelist il tuo IP, se è statico, per non chiuderti fuori da solo; e verifica che il blocco valga anche per i tentativi via XML-RPC e per i moduli che non passano da wp-login.php, non solo per la pagina di login — da quali porte passano i tentativi di login, e come si verifica dal terminale, l’ho scritto nella guida su come proteggere il login. Il limite ai tentativi è la misura più efficace contro i bot ordinari e la più debole contro quelli distribuiti su migliaia di IP: da sola non basta, ed è il motivo per cui il prossimo punto conta più di questo.

Autenticazione a due fattori su tutti gli account che contano

È l’unica misura che rende irrilevante il successo di un brute force: anche con la password corretta, senza il secondo fattore non si entra. Se dovessi tenere una sola voce di questo articolo, sarebbe questa.

Attivala su tutti gli account Amministratore ed Editore, con app TOTP (Google Authenticator, Authy, 1Password) e non via SMS, che è il canale più debole dei tre disponibili. Wordfence Login Security la offre gratuitamente anche senza il plugin completo. Genera e conserva i codici di riserva: senza, il primo telefono perso diventa un problema di accesso serio. Se sul sito ci sono più collaboratori, imponila per ruolo invece di lasciarla facoltativa — la 2FA opzionale la attiva solo chi già non era il problema.

Username, password e utenti che non servono più

Nessun account deve chiamarsi admin, né come il dominio: è la metà del lavoro regalata all’attaccante, che a quel punto deve indovinare solo la password. Le password devono essere lunghe e uniche per questo sito: contro il credential stuffing la lunghezza non serve a niente se quella stessa password è finita in una violazione altrove. Un password manager risolve il problema alla radice, ed è l’unico modo realistico di avere credenziali diverse ovunque.

Poi c’è la parte che quasi nessuno fa: passare in rassegna Utenti e rimuovere gli account che non servono più. Il collaboratore di due anni fa con ruolo Amministratore e una password mai cambiata è una superficie d’attacco a tutti gli effetti. Assegna a ciascuno il ruolo minimo che gli serve davvero per lavorare: chi scrive articoli non ha bisogno di installare plugin.

CAPTCHA e scoring comportamentale sui moduli

Un sistema anti-bot sul modulo di login blocca gli script prima che la password venga anche solo verificata. Le opzioni sensate oggi sono due: reCAPTCHA v3, invisibile, che assegna un punteggio al comportamento dell’utente, e Cloudflare Turnstile, che fa lo stesso lavoro senza profilazione pubblicitaria ed è preferibile se tieni al profilo privacy del sito.

Attivalo su login, registrazione, recupero password e commenti — non solo sul login, che è l’errore più comune: il modulo di recupero password è un ottimo strumento di enumerazione degli utenti e viene quasi sempre lasciato scoperto.

Cambiare l’URL di login: cosa fa davvero

Spostare il login da /wp-login.php a un indirizzo personalizzato, con un plugin come WPS Hide Login, viene spesso presentato come una misura di sicurezza. Non lo è, ed è più utile dirlo chiaramente: è riduzione del rumore. I bot che cercano l’URL standard non lo trovano più e il carico sul server cala, a volte in modo molto visibile nei log. Ma chi ti sta prendendo di mira davvero trova comunque il nuovo indirizzo, e l’attacco via XML-RPC o REST API non passa nemmeno da lì.

Vale la pena farlo per il beneficio sulle risorse, sapendo che è un accorgimento a bassa priorità: se devi scegliere dove investire mezz’ora, mettila sulla 2FA. E annota il nuovo indirizzo da qualche parte prima di disconnetterti.

Chiudere gli altri ingressi: XML-RPC e REST API

Il modulo di login non è l’unica porta. xmlrpc.php accetta le stesse credenziali del login, senza CAPTCHA e da un indirizzo che non si nasconde: se non usi Jetpack, l’app mobile di WordPress o un client di pubblicazione remota, disattivalo del tutto — meglio ancora, bloccalo a livello di CDN o di server, così la richiesta non arriva nemmeno a PHP.

La REST API, dal canto suo, di norma espone la lista degli utenti su /wp-json/wp/v2/users, e lo stesso risultato si ottiene con /?author=1. Non è una vulnerabilità, è il comportamento previsto, ma consegna a chiunque gli username reali del sito — cioè metà di ogni credenziale. Prova quei due indirizzi sul tuo sito adesso: se vedi gli username, hai trovato la ragione per cui i tentativi di login arrivano proprio su quei nomi. Diversi plugin di sicurezza permettono di bloccare l’enumerazione con una singola impostazione. Se invece WordPress sta servendo un frontend headless, quell’endpoint non si può bloccare: è il modo in cui il sito viene letto. Va limitato nella frequenza e ristretto ai percorsi che il frontend interroga davvero.

Quali strumenti servono davvero

La regola è una sola: un solo firewall applicativo, più eventualmente strumenti che coprono funzioni che gli mancano. Sommare tre plugin di sicurezza non triplica la protezione, moltiplica i conflitti e il carico. Sui criteri per valutare un plugin prima di installarlo — manutenzione, storico delle vulnerabilità, quantità di codice che aggiunge — ho scritto più in dettaglio nella guida ai migliori plugin per la sicurezza WordPress.

Una configurazione che copre bene il caso normale: Cloudflare davanti con due regole, un plugin di sicurezza completo in protezione estesa, 2FA su tutti gli amministratori, anti-bot sui moduli. Sono quattro cose, non quindici.

Cosa fare se l’attacco è già in corso

Ordine di intervento, dal più urgente. L’obiettivo delle prime tre mosse è tornare raggiungibile; quello delle successive è capire se qualcuno è entrato.

1. Conferma che sia un attacco. Guarda il log degli accessi e le analitiche: traffico concentrato su un endpoint, nessun referrer, analytics piatti. Se invece il traffico è distribuito e reale, il problema è di capacità, non di sicurezza, e la risposta è diversa.
2. Alza la barriera a monte. Attiva la modalità sotto attacco della CDN, blocca /xmlrpc.php e, se il traffico arriva in modo evidente da una nazione o da un provider con cui non lavori, blocca temporaneamente quella provenienza. È una misura da rimuovere dopo, non da lasciare lì.
3. Avvisa l’hosting. Loro vedono il traffico prima di te e possono filtrare a livello di rete. Aprire il ticket subito, non dopo tre ore di tentativi, cambia i tempi di risoluzione.
4. Verifica se qualcuno è entrato. Cerca nei log un login riuscito da un IP che non riconosci. Controlla la lista Utenti: un amministratore nuovo che non hai creato è la prova che l’attacco è finito. Guarda anche le attività pianificate e i file modificati di recente.
5. Se hai dubbi, invalida tutto. Cambia le password di tutti gli amministratori e rigenera le chiavi salt in wp-config.php: tutte le sessioni attive vengono buttate fuori, compresa quella di un eventuale intruso. Poi attiva la 2FA, se non c’era.
6. Se la compromissione è confermata, ripristina. Serve un backup precedente all’intrusione, e quindi serve sapere quando è avvenuta: ripristinare quello sbagliato significa rimettere online anche la backdoor. Se non hai backup con questa profondità, è la prima cosa da sistemare dopo l’emergenza — un backup automatico su storage esterno è il modo per non trovarsi in questa situazione una seconda volta.
7. Chiudi l’emergenza. Rimuovi le regole temporanee, disattiva la modalità sotto attacco e verifica che il sito risponda normalmente. Se il downtime è durato ore o Google ha segnalato il sito, richiedi la reindicizzazione da Search Console.

Cosa controllare ogni mese

Le difese si configurano una volta, ma decadono da sole: un token scade, un plugin cambia comportamento dopo un aggiornamento, un collaboratore se ne va e il suo account resta. Cinque minuti al mese bastano per non accorgersene troppo tardi.

• Apri il report del plugin di sicurezza: quanti blocchi, su quali endpoint, con quali username tentati. Una variazione netta rispetto al mese prima è un’informazione.
• Controlla la lista utenti e i ruoli: nessun account nuovo che non riconosci, nessun Amministratore che dovrebbe essere Editore.
• Verifica che le notifiche arrivino davvero, mandandoti un avviso di prova. Un sistema di allerta mai testato è un sistema che scoprirai rotto nel momento peggiore.
• Applica gli aggiornamenti in sospeso — la finestra tra la pubblicazione di una vulnerabilità e il suo sfruttamento di massa si misura in ore, non in settimane: la procedura completa di aggiornamento spiega come farlo senza rompere niente.
• Verifica che l’ultimo backup esista, sia completo e sia su una destinazione remota.

Se vuoi estendere il controllo oltre questi due attacchi — permessi dei file, superficie esposta, integrità del core, test di ripristino — i 25 controlli di sicurezza WordPress coprono tutto il resto nello stesso formato verificabile.

Domande frequenti

Da qui in avanti

Se dovessi ridurre tutto l’articolo a quattro azioni, sarebbero queste: metti una CDN davanti al sito con due regole sugli endpoint di login, attiva la 2FA su tutti gli amministratori, limita i tentativi di accesso e chiudi XML-RPC se non lo usi. Coprono la quasi totalità di quello che passa da un sito WordPress normale, e si fanno in un pomeriggio.

Il resto è manutenzione ordinaria: le difese non sono uno stato che raggiungi, sono qualcosa che si consuma. Il controllo mensile qui sopra esiste proprio per accorgersi quando smettono di funzionare, invece di scoprirlo il giorno in cui serve.

Se preferisci che questa configurazione la faccia io — protezione a monte, hardening degli accessi, monitoraggio e verifica di quello che è già successo sul tuo sito — puoi vedere come lavoro sulla sicurezza dei siti WordPress.