Errori XML-RPC: disabilitare endpoint

XML-RPC è un protocollo legacy di WordPress per accesso remoto. Negli ultimi anni è fonte di attacchi (brute force, DDoS amplification). Vediamo quando disabilitarlo, quando mantenerlo, e come WP Error Monitor traccia gli errori XML-RPC.

A cosa serve XML-RPC oggi

WordPress XML-RPC è usato da: 1) app mobile WordPress (alternative: REST API), 2) plugin di pingback/trackback (sempre meno usati), 3) Jetpack per sincronizzazione (può usare anche WP.com auth), 4) integrazione con strumenti vintage tipo Windows Live Writer. La maggior parte dei siti moderni può disabilitarlo senza impatti.

Errori tipici XML-RPC

1) 405 Method Not Allowed se disabilitato male, 2) attacchi brute force che generano migliaia di fail login al minuto, 3) DDoS via pingback amplification (WordPress vecchio risponde con request a URL arbitrari), 4) memory exhausted durante system.multicall malformati. WP Error Monitor cattura tutti questi con tag 'context=xmlrpc'.

Come disabilitare in sicurezza

1) Soft disable via filter: add_filter('xmlrpc_enabled’, '__return_falsè) in mu-plugin; 2) Hard disable webserver: blocca POST a xmlrpc.php in nginx/Apache, return 403; 3) Plugin: Disable XML-RPC mantiene solo Jetpack se necessario. Verifica con WP Error Monitor che dopo il fix non ci siano regressioni su client legittimi.

Application Passwords come alternativa

WP 5.6+ introduce Application Passwords: password specifiche per app, revocabili individualmente. Sostituiscono XML-RPC e Cookie auth per integrazioni: app mobile, sync esterni. Generazione: wp-admin profilo Application Passwords. L’auth è via Basic Authentication header HTTPS. WP Error Monitor traccia uso Application Passwords come tag 'auth=app_password’ e segnala accessi anomali (IP nuovo, geolocation cambiata).

Fail2ban e brute force XML-RPC

Anche dopo disabilitazione XML-RPC, gli attacker continuano a provare: il traffico maligno arriva al webserver. Fail2ban riconosce pattern brute force in access.log e banna IP via iptables. Setup tipico: /etc/fail2ban/filter.d/wp-xmlrpc.conf con regex per match POST /xmlrpc.php, /etc/fail2ban/jail.d/wordpress.conf con ban time 3600s. WP Error Monitor riceve eventi fail2ban via syslog: dashboard mostra IP bannati e geolocation.

Pingback amplification attack

XML-RPC supporta pingback: tu fai post link, altro WP riceve notifica con tua URL. Storia famosa: gli attacker abusano pingback per amplificare DDoS: mandano migliaia di pingback request a centinaia di WP innocui, ognuno fa request HTTP all’URL vittima. La vittima riceve traffico amplificato 100x. Per evitare di essere amplificatore (non per protezione propria): disabilita pingback con plugin Disable XML-RPC Pingback o filter xmlrpc_methods che rimuove pingback.ping. Verifica con curl: 'curl -d ... https://sito.it/xmlrpc.php' deve restituire faultCode 32601 (method not found).

Application-specific endpoint

Per app mobile e integrazioni che richiedono XML-RPC-like functionality, considera endpoint custom con REST API: più moderno, sicuro, manutenibile. Esempio: invece XML-RPC method 'mt.getPostCategories', endpoint REST /wp-json/myapp/v1/categories/{post_id}. Auth via Application Passwords. WP Error Monitor traccia uso REST custom endpoint con tag 'rest_namespace' permettendo audit di chi usa quale endpoint. Decommissioning XML-RPC diventa più facile quando hai già la sostituzione pronta.

Audit XML-RPC checklist

Audit XML-RPC checklist per ogni sito WordPress gestito: 1) verifica con curl se /xmlrpc.php risponde (deve dare 403 se disabilitato), 2) controlla wp_options 'enable_xmlrpc' value (deprecated ma alcuni vecchi siti ne sono affetti), 3) review mu-plugins per filter xmlrpc_enabled, 4) check webserver config per location /xmlrpc.php, 5) WP Error Monitor dashboard per traffico /xmlrpc.php ultimi 30gg, 6) fail2ban log per banned IP, 7) integrazioni che dipendono da XML-RPC documentate. Checklist eseguita ogni 6 mesi per ogni sito, output salvato in audit log.

Procedura passo-passo

1. Apri WP Error Monitor e filtra 'context = xmlrpc' negli ultimi 30gg.
2. Identifica volume traffico legittimo vs malevolo (controlla IP/user agent).
3. Se 99% è brute force, puoi disabilitare senza impatti.
4. Disabilita via webserver: location ~ ^/xmlrpc.php { deny all; return 403; }.
5. In alternativa filter PHP: aggiungi xmlrpc_enabled=false in mu-plugin.
6. Verifica che plugin essenziali (Jetpack) abbiano alternative configurate.
7. Monitora WP Error Monitor per 7gg post-disable per regressioni.
8. Riattiva selettivamente se necessario per client specifici.
9. Migra integrazioni da XML-RPC a Application Passwords.
10. Configura fail2ban con jail dedicato per WordPress.

Errori comuni e come risolverli

• Jetpack rotto dopo disable: Configura Jetpack a usare REST API auth invece XML-RPC.
• App mobile WordPress non funziona: Usa WP Mobile App con REST API auth (Application Passwords).
• Brute force continua nonostante disable: Disable a livello nginx (return 403): plugin disable non blocca la richiesta a livello server.
• App Password non funziona dietro proxy: HTTP Basic auth richiede HTTPS: setup proxy correttamente.
• Fail2ban non banna: Verifica regex con fail2ban-regex e access.log path corretto.

Domande frequenti

D: REST API è sicura come XML-RPC era?
R: Più' moderna, autenticazione con Application Passwords o JWT. Meno attack surface.

D: Devo disabilitare anche /wp-json?
R: No, REST API è attiva e moderna. Limitala via permission_callback.

D: WP Error Monitor traccia XML-RPC anche se disabilitato?
R: Sì, cattura tentativi falliti via webserver log se integrazione attiva.

D: App Passwords sono sicure?
R: Sì, revocabili individualmente, HTTPS-only, no XSS exposure (no cookie).

D: Fail2ban impatta utenti legittimi?
R: Tune maxretry alto (es. 20) per evitare false positives.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.