Attacco DDoS a WordPress: come proteggere wp-login.php e xmlrpc.php

WordPress fa girare una parte enorme dei siti del mondo, e per questo è il primo bersaglio di chiunque scriva un bot. Molti "attacchi DDoS" contro WordPress non sono nemmeno mirati: sono programmi che girano per Internet provando le stesse pagine su milioni di siti. Il problema è che bastano poche centinaia di richieste al secondo alle pagine giuste per bloccare un hosting condiviso.

Perché WordPress soffre così tanto

Una pagina di WordPress non in cache richiede di avviare PHP, caricare tutti i plugin e fare decine di interrogazioni al database. Un server normale ne regge qualche decina al secondo. Se un bot ne chiede centinaia, i processi PHP finiscono, le richieste si mettono in coda e il sito smette di rispondere a tutti.

Le pagine prese di mira sono quasi sempre le stesse.

wp-login.php

La pagina di accesso non può essere messa in cache e fa lavorare database e PHP a ogni tentativo. I bot la usano per provare password a raffica (brute force): anche quando non indovinano, il solo fatto di provare migliaia di volte al minuto basta a rallentare tutto.

xmlrpc.php

È una vecchia interfaccia per pubblicare da app esterne. Ha due difetti noti:

• permette di provare centinaia di password in una sola richiesta (la funzione system.multicall), aggirando molti limiti sui tentativi di accesso;
• la funzione pingback può essere sfruttata per far partire richieste dal tuo sito verso altri, trasformandolo in un complice involontario di attacchi.

Se non usi l'app di WordPress sul telefono, Jetpack o servizi che la richiedono esplicitamente, puoi spegnerla.

La ricerca interna

Una ricerca (/?s=parola) interroga il database ogni volta, e ogni parola diversa è una pagina nuova che nessuna cache ha già pronto. Un bot che cerca parole casuali è un modo semplice ed efficace per mettere in crisi un sito.

admin-ajax.php e wp-cron.php

Molti plugin usano admin-ajax.php per funzioni dinamiche, e wp-cron.php parte a ogni visita per eseguire le attività pianificate. Sotto attacco, entrambi moltiplicano il lavoro del server.

Le difese, dalla più semplice

1. Spegni xmlrpc.php se non ti serve

Con Nginx:

location = /xmlrpc.php { deny all; }

Con Apache, nel file .htaccess:

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

In alternativa esistono plugin che la disattivano, ma bloccarla dal server web è più efficace: la richiesta viene rifiutata prima ancora di avviare PHP.

2. Proteggi l'accesso

• usa password lunghe e l'autenticazione a due fattori per tutti gli amministratori;
• limita i tentativi di accesso con un plugin dedicato o con fail2ban sul server;
• se lavori sempre dagli stessi luoghi, puoi limitare /wp-admin e /wp-login.php ai tuoi indirizzi IP o ai paesi in cui lavori.

3. Metti in cache le pagine

Una pagina in cache non avvia PHP e non tocca il database: il server la consegna come un file. Un plugin di cache (o la cache dell'hosting) riduce il carico di dieci o cento volte per le pagine pubbliche, e da solo spesso basta a reggere un picco che prima faceva cadere il sito.

La cache non protegge però le pagine dinamiche (accesso, ricerca, carrello), ed è proprio lì che puntano gli attacchi.

4. Sposta cron su un'attività vera

Nel file wp-config.php:

define('DISABLE_WP_CRON', true);

e poi un'attività pianificata sul server che chiama wp-cron.php ogni cinque minuti. Così cron non parte più a ogni visita.

5. Metti WordPress dietro una CDN con protezione dai bot

Tutte le misure precedenti girano sul tuo server: aiutano, ma le richieste arrivano comunque fino a lui. Una CDN sposta la difesa davanti al server.

Con 1PrimeCDN:

• le pagine pubbliche e i file (immagini, CSS, JavaScript) vengono serviti dai nodi, e il server vede solo una frazione delle visite;
• ogni indirizzo IP ha un limite di richieste al secondo: chi lo supera viene rallentato e poi fermato;
• lo Shield dà un punteggio a ogni IP in base a come si comporta: chi prova password a raffica, chiede pagine sempre diverse per aggirare la cache o si presenta con un user agent automatico passa da una verifica o viene bloccato per un po', con il motivo scritto nel pannello;
• durante un attacco, la modalità «sotto attacco» fa passare tutti da una verifica di un secondo, mentre Google e Bing verificati continuano a entrare.

Chi ha fatto l'accesso a WordPress non viene servito dalla cache: le pagine richieste con un cookie di sessione arrivano sempre al sito, così l'area riservata e l'editor funzionano come prima.

6. Fai vedere a WordPress l'IP vero dei visitatori

Dietro una CDN, WordPress vede arrivare tutte le visite dagli indirizzi dei nodi. Plugin di sicurezza, statistiche e limiti sui tentativi di accesso devono leggere l'IP vero, che i nodi di 1PrimeCDN passano nell'intestazione X-Forwarded-For (e in X-PrimeCDN-Client-IP). Nel pannello, in Pull Zone → Origin, trovi le righe pronte da incollare in wp-config.php, con l'elenco dei nodi già dentro.

Riassunto

Se WordPress è già giù in questo momento, parti da sito sotto attacco DDoS: cosa fare subito o scrivici dalla pagina d'emergenza.