Protezione brute force WordPress: cosa può fermare un plugin

Un plugin di sicurezza è bravo a rallentare chi tenta di indovinare le password. Non può fermare un'ondata di traffico. La protezione brute force di WordPress e la protezione DDoS sono due problemi distinti, e ciascuno si risolve a un livello diverso: gli account, WordPress stesso, il web server e il perimetro di rete che sta davanti a tutto.

Questo articolo passa in rassegna gli attacchi che si incontrano più spesso nei log: login falliti su wp-login.php, raffiche di richieste a xmlrpc.php, enumerazione degli utenti tramite API REST e picchi di traffico. Per ciascuno indica il livello che può davvero fermarlo. Ogni misura riporta anche una riga su ciò che non fa.

La protezione brute force di WordPress funziona a livelli

Il traffico arriva da internet e attraversa più livelli prima di raggiungere i dati. Più lontano da voi viene fermata una richiesta, meno costa. Una richiesta respinta da una CDN non tocca mai il server. Una richiesta respinta da un plugin WordPress ha già impegnato una connessione di rete, un processo del web server e un worker PHP.

Una mappatura di massima:

Limitazione dei tentativi di login: rallentare chi indovina le password su wp-login.php

La limitazione dei tentativi (login throttling) conta i login falliti e reagisce con ritardi crescenti, con il blocco temporaneo della fonte o con una verifica aggiuntiva (challenge). Di serie, WordPress non pone alcun limite. Un attaccante può provare password su wp-login.php alla velocità con cui il server risponde.

I limiti per indirizzo IP funzionano bene contro una singola fonte rumorosa. Funzionano meno contro una botnet che distribuisce i tentativi su migliaia di indirizzi, ciascuno sotto la soglia. Per questo servono anche limiti per nome utente. Venti fallimenti sull'account «admin» da venti IP diversi sono comunque uno schema riconoscibile.

I limiti per utente hanno però un'insidia. Con un blocco rigido, chiunque può chiudere fuori il vostro vero amministratore sbagliando password di proposito. Ritardi crescenti o una challenge sono preferibili a un blocco totale.

Due aspetti decidono se la limitazione aiuta o danneggia:

• L'IP del client. Dietro una CDN o un reverse proxy, ogni richiesta può sembrare provenire dall'indirizzo del proxy. Un plugin che vede solo quell'indirizzo limiterà tutti i visitatori insieme. L'errore opposto è altrettanto grave: se il plugin si fida dell'header X-Forwarded-For inviato da chiunque, gli attaccanti possono falsificare un IP nuovo a ogni richiesta e non vengono mai bloccati. Configurate il plugin, o il modulo real-IP del web server, in modo che accetti gli header inoltrati solo dagli intervalli IP del vostro proxy.
• La vostra via di rientro. Inserite nella allowlist l'IP dell'ufficio, se è statico, e conoscete il percorso di ripristino prima di averne bisogno.

Ciò che la limitazione non fa: non rende sicura una password debole o riutilizzata. Una password presente in un elenco di dati trapelati può funzionare al primo tentativo. La vera soluzione è un secondo fattore per ogni account con privilegi elevati, configurato come descritto in autenticazione a due fattori per gli amministratori WordPress.

XML-RPC: perché system.multicall trasforma una richiesta in molti tentativi

xmlrpc.php è attivo per impostazione predefinita in WordPress. È una vecchia interfaccia di pubblicazione remota e uno dei suoi metodi, system.multicall, esegue molte chiamate all'interno di un'unica richiesta HTTP. Un attaccante può quindi inserire in una sola POST un lungo elenco di tentativi nome utente/password.

In questo modo aggira le protezioni di login che controllano solo wp-login.php o che contano le richieste. Una riga nel log può corrispondere a centinaia di tentativi. Verificate che la limitazione conteggi anche i fallimenti di autenticazione via XML-RPC, oppure eliminate del tutto questa superficie d'attacco.

I pingback XML-RPC possono inoltre essere sfruttati per far inviare al vostro sito richieste verso terzi. È un motivo in più per disattivarli, se nulla li utilizza.

Prima di disattivare XML-RPC: verificare cosa lo usa ancora

Alcuni strumenti legittimi comunicano ancora con xmlrpc.php: vecchi programmi desktop per blogging e pubblicazione remota, configurazioni datate di app mobile, alcuni plugin connettori e integrazioni sviluppate anni fa. La connessione di Jetpack si è storicamente basata su XML-RPC, quindi, se lo usate, consultate la documentazione aggiornata.

Controllate prima i log di accesso. Su un tipico server Apache o nginx con il formato di log combined:

# Quali IP inviano richieste POST a xmlrpc.php?
grep "POST /xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Quali user agent?
awk -F'"' '/POST \/xmlrpc.php/ {print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Adattate il percorso al vostro server (ad esempio /var/log/apache2/access.log) e includete i log ruotati. Migliaia di richieste da IP che cambiano di continuo, con user agent generici, sono attacchi. Poche richieste da un unico IP di un servizio noto appartengono probabilmente a un'integrazione: chiedete alla vostra agenzia o al fornitore prima di interromperla.

Le opzioni sono due:

1. **Il filtro xmlrpc_enabled.** Disattiva i metodi XML-RPC che richiedono autenticazione e quindi ferma i tentativi di indovinare le password via XML-RPC. I metodi non autenticati, come i pingback, continuano a funzionare. Vedere il riferimento per sviluppatori di WordPress.
2. Bloccare il file a livello di server. Ferma tutto e PHP non viene nemmeno eseguito per queste richieste.

<Files xmlrpc.php>
    Require all denied
</Files>

location = /xmlrpc.php {
    deny all;
}

Dopo la modifica, verificate la pubblicazione, la vostra app e ogni servizio collegato. Annotate che cosa avete cambiato e perché, così che chi viene dopo di voi non lo «ripari» riportandolo com'era.

Enumerazione degli utenti via API REST e rate limiting anonimo

/wp-json/wp/v2/users elenca gli utenti che hanno pubblicato contenuti, inclusi i loro slug. /?author=1 reindirizza all'archivio dell'autore, che rivela lo slug nell'URL. Gli slug spesso coincidono con il nome di login, e così l'attaccante ha già metà delle credenziali.

Limitare l'endpoint degli utenti per i visitatori anonimi e bloccare le scansioni degli autori riduce il rumore della fase di ricognizione. I nomi utente, però, non sono segreti: nasconderli non è un controllo sufficiente da solo.

Applicare un rate limit alle richieste REST anonime aiuta contro lo scraping e le sonde automatiche. Applicatelo solo al traffico anonimo e verificate poi il risultato. L'editor a blocchi usa l'API REST per gli utenti autenticati e le integrazioni si autenticano con le Application Passwords (nel core da WordPress 5.6). Un limite che le colpisse bloccherebbe la modifica dei contenuti o un job di sincronizzazione, con cause difficili da individuare.

Ciò che non fa: il rate limiting non risolve la vulnerabilità di un endpoint REST di un plugin. Rallenta soltanto i tentativi di sfruttarla.

Perché un plugin non può fermare un attacco DDoS

Un plugin è codice PHP. Entra in azione solo dopo che una richiesta ha attraversato la rete, è stata accettata dal web server ed è stata passata a un worker PHP. Un flood volumetrico satura la banda, i limiti di connessione o il pool di worker PHP molto prima di quel punto. Anche se il plugin respingesse ogni richiesta in un millisecondo, ogni rifiuto occuperebbe comunque un worker, e un server ne ha un numero limitato.

I flood a livello applicativo sono un'altra cosa: molte richieste costose ma dall'aspetto valido, come ricerche o pagine non in cache. Qui un rate limiting più vicino all'applicazione aiuta in parte, ma solo fino alla capacità del server.

L'avviso di picco di traffico di un plugin è utile perché segnala che sta succedendo qualcosa. Non assorbe nulla. Qualsiasi prodotto che presenti un plugin WordPress come «protezione DDoS» ne esagera le capacità.

Cosa fa invece una CDN o un firewall edge, e cosa può aggiungere il web server

Una CDN o un firewall edge si colloca davanti al vostro hosting, su una rete molto più grande della vostra. Può assorbire e filtrare i flood, applicare rate limit e regole anti-bot prima che il traffico vi raggiunga, servire pagine dalla cache quando il server è in difficoltà e sottoporre a challenge le richieste a wp-login.php e xmlrpc.php. Una volta attivata, proteggete il server di origine: consentite nel firewall del server solo gli intervalli IP della CDN. Altrimenti gli attaccanti possono aggirare la CDN e raggiungere direttamente l'indirizzo reale del server.

Sul web server, il [modulo limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html) di nginx può limitare i tentativi di login prima che parta PHP. Dietro una CDN o un reverse proxy configurate prima il modulo real-IP (fidandovi solo degli intervalli del vostro proxy); altrimenti $binary_remote_addr è l'indirizzo del proxy e tutti i visitatori condividono un unico limite:

# contesto http
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;

# contesto server
location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    # mantenete qui le vostre righe fastcgi_pass / include esistenti
}

fail2ban segue un approccio diverso: legge i log e blocca al firewall chi insiste, il che costa meno che rispondere in PHP. Dietro una CDN, così com'è, non funziona: il firewall del server vede solo gli indirizzi della CDN, quindi i blocchi vanno applicati alla CDN (o tramite la sua API). Con un hosting gestito, chiedete quale protezione di rete offre già il provider.

Anche qui ci sono dei limiti. Un firewall edge non corregge password deboli né plugin vulnerabili. E non serve contro ciò che un attaccante può fare dopo aver effettuato l'accesso, tema di disattivare l'editor di file di WordPress.

Un ordine di attuazione per le piccole imprese europee

1. Password robuste e uniche e 2FA per ogni amministratore ed editor.
2. Limitazione dei tentativi di login con limiti per IP e per nome utente, rilevamento corretto dell'IP del client e un percorso di ripristino collaudato.
3. La decisione su XML-RPC: controllare i log, poi usare il filtro o un blocco a livello di server.
4. Restrizioni sull'enumerazione degli utenti e limiti alle richieste REST anonime.
5. Una CDN o un firewall edge con server di origine protetto, per i siti in cui il fermo costa denaro.

Il tema riguarda anche la conformità. L'art. 32, par. 1, lett. b), del GDPR richiede la capacità di assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi (GDPR su EUR-Lex). Per i soggetti rientranti nell'ambito della direttiva NIS2, l'art. 21, par. 2, lett. j), include l'autenticazione a più fattori tra le misure minime (NIS2 su EUR-Lex). Per i dettagli, consultate la normativa nazionale di recepimento della NIS2 del vostro Paese.

Il plugin Security Audit & Compliance di secaudit.eu offre limitazione dei tentativi di login, disattivazione di XML-RPC, rate limiting per le richieste REST anonime e avvisi sui picchi di traffico. Non è una protezione DDoS: per quella serve una CDN o un firewall edge. → secaudit.eu

Prossimo passo: completate il resto della checklist di sicurezza per WordPress. Se nei log compaiono già accessi riusciti che non riconoscete, passate invece ai segnali di un sito compromesso.

FAQ

Disattivare XML-RPC rompe Jetpack o la mia app?

È possibile. Cercate nei log eventuali client XML-RPC legittimi e consultate la documentazione aggiornata del fornitore. Il filtro xmlrpc_enabled è l'opzione più morbida, il blocco a livello di server la più rigida. Dopo l'una o l'altra, verificate che tutto funzioni.

Rinominare wp-login.php ferma il brute force?

Riduce il rumore dei bot più semplici, ma non è un controllo di sicurezza. Gli attaccanti possono comunque trovare la pagina di login o ricorrere a XML-RPC. Servono anche la limitazione dei tentativi e la 2FA.

Il mio plugin di sicurezza basta durante un DDoS?

No. Contattate il vostro provider di hosting o il fornitore della CDN. Il filtraggio al perimetro e la cache sono ciò che mantiene il sito raggiungibile.

La limitazione dei tentativi può chiudermi fuori?

Sì, se l'IP del client viene rilevato in modo errato o se sbagliate più volte la password. Inserite il vostro IP nella allowlist e tenete pronto l'accesso WP-CLI o SFTP per disattivare il plugin.

Questo articolo è un'informazione di carattere generale e non costituisce consulenza legale.