WordPress sotto attacco DDoS a livello applicativo (L7): cosa fare nelle prime due ore

Un attacco DDoS applicativo, o Layer 7, non satura la banda: satura WordPress. Ogni richiesta arriva a PHP, apre una connessione a MySQL e occupa un worker per qualche centinaio di millisecondi. Ne bastano poche decine al secondo, distribuite su qualche migliaio di IP, per mandare in coda un server che per il provider "è raggiungibile". Questa guida copre le prime due ore: riconoscere l'attacco, dividere il lavoro tra sito e server, non sprecare tempo su contromisure che non abbassano le richieste.

Come si distingue un flood L7 da un picco di traffico vero?

Non dal carico, che sale in entrambi i casi, ma dalla forma delle richieste. Un picco legittimo (una newsletter, un passaggio in TV) ha un referrer coerente, colpisce le pagine effettivamente linkate, e ogni pagina si porta dietro CSS, JavaScript e immagini. Un flood chiede solo l'endpoint che costa di più, e lo chiede sempre uguale.

Tre comandi sul log degli accessi bastano per decidere. Il percorso cambia con il pannello (/var/log/apache2/, /var/log/nginx/, /usr/local/apache/domlogs/ su cPanel):

# 1. Quali URL vengono chiesti di più negli ultimi 50.000 accessi
tail -n 50000 access.log | awk '{print $7}' | cut -d'?' -f1 | sort | uniq -c | sort -rn | head -15

# 2. Quanti IP distinti e quanto pesa il primo
tail -n 50000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -5
tail -n 50000 access.log | awk '{print $1}' | sort -u | wc -l

# 3. Quali user agent, e quanti diversi
tail -n 50000 access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -10

I segnali che confermano il flood:

• gli URL in testa sono sempre gli stessi e tutti dinamici: xmlrpc.php, wp-login.php, /?s=qualcosa, admin-ajax.php, oppure archivi con parametri di filtro (?orderby=, ?filter_colore=, ?min_price=) che la cache non può servire;
• nessun IP domina: il primo pesa meno dell'1 percento e i distinti sono migliaia, spesso di reti residenziali o di proxy;
• user agent che ruotano: versioni di Chrome vecchie di anni, stringhe vuote, decine di combinazioni diverse;
• rapporto pagine/asset sballato: migliaia di richieste HTML e quasi nessuna a /wp-content/ o /wp-includes/;
• carico alto con MySQL quasi a riposo: uptime mostra un load ben sopra il numero di core, ps -eo comm | grep -c php-fpm (o lsphp su LiteSpeed) è al massimo configurato, mentre mysqladmin processlist mostra poche query e molte connessioni in Sleep.

Se invece i primi URL sono pagine reali con asset al seguito e Analytics vede sessioni umane, è un picco di traffico: il problema è la capacità, e vale il percorso della diagnosi delle performance.

Perché bloccare gli IP uno per uno non funziona?

Tre motivi:

1. Gli IP ruotano più in fretta di te. Una botnet o una rete di proxy residenziali usa ogni indirizzo per qualche decina di richieste e lo abbandona. Quando il tuo csf -d entra in vigore, quell'IP ha già finito.
2. Il blocco arriva troppo tardi nella catena. Se lo applica un plugin di sicurezza, la richiesta ha già avviato PHP, caricato WordPress e aperto la connessione al database: hai pagato il costo intero per poi dire "no". È il limite strutturale dei plugin di sicurezza.
3. La lista cresce e il risultato no. Mille IP in blacklist non sono mille richieste in meno se il conteggio al minuto resta quello.

Il criterio operativo è uno: se dopo cinque minuti di blocchi il numero di richieste al minuto non scende, smetti di bloccare IP e passa alla firma. Il conteggio si legge così:

# richieste al minuto negli ultimi 10 minuti
tail -n 100000 access.log | awk '{print substr($4,2,17)}' | uniq -c | tail -10

Cosa si fa sul sito nelle prime due ore?

Spettano a chi gestisce WordPress. Da soli non fermano un flood serio, ma riducono il costo di ogni richiesta e chiudono gli endpoint colpiti più spesso.

• Disattivare xmlrpc.php. Quasi nessun sito lo usa. Il blocco va fatto prima di PHP: su Apache in .htaccess con <Files xmlrpc.php>Require all denied</Files>, su nginx con location = /xmlrpc.php { return 403; }. Il filtro add_filter('xmlrpc_enabled', '__return_false') non basta: WordPress viene comunque caricato per rispondere di no.
• Proteggere wp-login.php. Rate limit per IP sulle POST (con Cloudflare, fail2ban o il modulo del web server), challenge sulle GET se il sito è dietro un proxy, registrazione disattivata se non serve.
• Servire tutto dalla cache pagina. Un flood su URL cacheabili muore contro la cache. Il trucco degli attaccanti è aggiungere parametri casuali (/?xyz=123) per forzare il miss: la cache va configurata per ignorare i parametri sconosciuti (vedi gli errori comuni di caching).
• Spegnere la ricerca interna se è lei il bersaglio. /?s= non è cacheabile e fa una query LIKE su tutto il contenuto. Per la durata dell'attacco si risponde 403 a ogni richiesta con s= nella query string, a livello di web server.
• Chiudere i filtri di archivio abusati. Su WooCommerce le combinazioni di filter_*, orderby e min_price sono infinite per costruzione e un crawler ostile le esplora tutte. Blocco per pattern dei parametri, non per IP.