L’endpoint xmlrpc.php rappresenta uno dei principali vettori di attacco su WordPress. Costantemente bersagliato da botnet per attacchi brute force amplification e amplificazione DDoS, disabilitarlo alla radice azzera il consumo computazionale su PHP.
Metodo 1: Blocco a livello Web Server (Consigliato)
Intercettare la chiamata sul web server prima che raggiunga PHP azzera il consumo di CPU e RAM, bloccando l’attacco direttamente sul perimetro.
Se il server usa Apache (.htaccess): Inserisci questa direttiva nel file .htaccess nella cartella principale del sito:
# Blocco accesso XML-RPC (Apache 2.4+)
<Files xmlrpc.php>
Require all denied
</Files>Se il server usa NGINX: Inserisci questa regola all’interno del blocco server { ... }:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 403;
}Metodo 2: Disattivazione via PHP (Filtro WordPress)
Se non hai accesso ai file di configurazione del web server, puoi disattivare il protocollo direttamente dal core di WordPress. Inserisci questo snippet all’interno di un file .php nella cartella wp-content/mu-plugins/ (es. in hardening.php):
add_filter( 'xmlrpc_enabled', '__return_false' );Verifica e Collaudo
Per verificare che la protezione sia attiva, apri il terminale ed esegui una chiamata HTTP diretta verso il file:
curl -I -X POST https://tuodominio.it/xmlrpc.phpSe la risposta restituisce lo stato HTTP/1.1 403 Forbidden (o 404 Not Found), il vettore di attacco è bloccato e il server è protetto.
💡 Fuori dal terminale: cosa significa in parole povere?
- Cos’è xmlrpc.php: È una porta di comunicazione introdotta oltre vent’anni fa per consentire ad applicazioni esterne (come vecchie app per smartphone o servizi di blogging remoto) di interagire con WordPress.
- Il problema di sicurezza: Oggi è quasi del tutto obsoleta, sostituita dalle moderne REST API, ma rimane attiva di default. I bot la usano per attacchi “ad amplificazione”: con una singola richiesta HTTP possono testare centinaia di combinazioni di password contemporaneamente, saturando la memoria RAM e la CPU del server.
- La nostra soluzione: Abbiamo chiuso questo canale direttamente a monte sul web server (Apache o NGINX) e tramite filtro PHP. Qualsiasi richiesta diretta viene respinta istantaneamente con un errore 403 Forbidden senza interpellare il database né consumare risorse computazionali.