¿Qué es xmlrpc.php en WordPress, para qué sirve y cómo desactivarlo de forma segura?
Es posible que si en algún momento hemos utilizado la aplicación de WordPress.com o Jetpack, hayamos experimentado errores de conexión en algún momento y nos hayamos enfrentado al error 'No pudimos realizar una solicitud XML-RPC a su sitio web.', que fue muy habitual cuando a partir de la versión 3.5 de WordPress se habilitó XMLRPC por defecto.
Esto se debía principalmente a que la aplicación que intentábamos conectar (una de las más utilizadas y el principal motivo de este cambio en XMLRPC fue la aplicación de WordPress.com). Era externa a nuestro WordPress y necesitaba conectarse a través de XMLRPC con el mismo.
- ¿Es seguro mantener xmlrpc.php activo?
- Principales riesgos y ataques relacionados con el xmlrpc.php
- Ataques de fuerza bruta
- Abuso de PingBanks para DDoS
- Cómo comprobar si xmlrpc está habilitado
- Cómo desactivar o proteger xmlrpc.php en WordPress
- Utilizar un plugin
- Modificar fichero .htaccess

¿Qué es xmlrpc.php y para qué se utiliza en WordPress?
Si utilizas WordPress seguramente has visto en alguna ocasión el archivo xmlrpc.php. No obstante, dado que es un fichero que no suele utilizarse para escribir en el mismo, como sí puede ocurrir con el wp-config.php o el .htaccess, en ocasiones se pasa más por alto.
Aun así, este fichero cumple una tarea muy importante en nuestra web, ya que su principal función es permitir la conexión de nuestra instalación de WordPress con otras aplicaciones remotas, lo que nos permitiría por ejemplo publicar contenido, realizar actualizaciones o conectar la instalación con otros servicios (como Jetpack, uno de los más conocidos).
Es importante tener en cuenta que actualmente el protocolo XMLRPC se utiliza menos, ya que parte de las funciones han pasado a gestionarse actualmente con REST API.
¿Es seguro mantener xmlrpc.php activo?
Dado que xmlrpc.php se utiliza menos para algunas tareas, es posible que la primera opción que pensemos tras esto sería que simplemente se podría prescindir del mismo como parte de WordPress, no obstante, por ahora se conserva como parte del núcleo de WordPress por cuestiones de compatibilidad principalmente y porque algunas tareas aún lo requieren.
El fichero xmlrpc.php no supone un problema de seguridad en sí mismo, no obstante, sí puede utilizarse como 'puerta de entrada' para ataques a nuestra instalación, por lo que salvo que nuestra instalación por algún motivo específico requiera que esté activo por la configuración que tiene la web o las funciones que necesitamos utilizar, puede deshabilitarse para prevenir que se utilice de forma que afecte de negativamente a la instalación.
Principales riesgos y ataques relacionados con el xmlrpc.php
Ataques de fuerza bruta
El principal problema del uso de xmlrpc.php para este tipo de ataques es la utilización del método 'system.multicall', ya que permite enviar varias solicitudes en una única petición HTTP, lo que hace que estos ataques de fuerza bruta tengan mayor magnitud, al poder comprobar miles de contraseñas con 4 o 5 peticiones HTTP y que de esta forma, algunas herramientas de seguridad dependiendo de su configuración, no detecten esto como un intento de acceso por fuerza bruta (ya que es un número de peticiones reducido, pero realizando al mismo tiempo miles de comprobaciones).
Abuso de PingBanks para DDoS
Un pingback es una notificación automática entre blogs para avisar de que en un blog se ha realizado alguna mención al otro blog (siempre que ambas instalaciones tengan los pingbacks activos).
Actualmente, no se utilizan tanto como hace unos 8/10 años, por lo que es menos habitual hacer uso de ellos y, por tanto, también utilizarlos para este tipo de ataques a la web, e incluso gran parte de las instalaciones pueden tenerlo deshabilitado.
Podemos deshabilitar los pingbacks en la instalación para evitar que se haga uso de esta funcionalidad, si no los utilizamos, desde "Ajustes > Comentarios" desmarcar 'Permitir avisos de enlaces de otros blogs (pingbacks y trackbacks) en las nuevas entradas' e 'Intentar avisar a cualquier blog enlazado desde la entrada'.
No obstante, los pingbacks utilizan también XMLRPC y esto permite hacer una alta cantidad de peticiones desde diversas IPs, lo que dificulta, por un lado, bloquearlas y además ese número de peticiones podría afectar al servidor, que podría llegar a saturarse.
En este artículo puedes ver más información sobre los ataques DDoS: https://raiolanetworks.com/blog/ataque-ddos-todo-lo-que-necesitas-saber/
Cómo comprobar si xmlrpc está habilitado
Para comprobar si xmlrpc.php está habilitado en nuestro sitio web, tenemos principalmente 2 alternativas:
- Utilizar herramientas web como https://xmlrpc.blog/, donde tendremos que insertar la URL de la web que queremos comprobar y, si está activo, obtendremos el siguiente mensaje (si no está activo, obtendremos un error 405 o 403).
- Realizar una petición al fichero correspondiente: https://dominio.tld/xmlrpc.php (sustituyendo dominio.tld por el nuestro). En caso de que esté activo, obtendremos lo siguiente:
Si no está activo, la notificación será diferente (generalmente un 403 o un 404):
Cómo desactivar o proteger xmlrpc.php en WordPress
Si no utilizamos ninguna función que dependa de xmlrpc.php, podemos deshabilitarlo en nuestra web.
Utilizar un plugin
Podemos hacerlo con un plugin como 'Disable XML-RPC-API': https://es.wordpress.org/plugins/disable-xml-rpc-api/, que desactivará xmlrpc automáticamente al instalarlo.
Esta es una alternativa muy interesante si utilizamos Jetpack, ya que incluye una opción para añadir una excepción para Jetpack.
Si utilizamos Perfmatters por ejemplo, podemos utilizarlo también para desactivar XMLRPC desde el apartado 'General'.
En caso de que utilicemos algún plugin de seguridad específico, es aconsejable que revisemos también si cuenta con esta opción. En el caso de SolidSecurity (anterior iThemes Security) podemos hacerlo desde "Ajustes > Avanzado > Ajustes de WordPress":
Modificar fichero .htaccess
También podemos desactivar xmlrpc.php insertando el siguiente código en el .htaccess:
Order Deny,Allow Deny from all
Esto nos evita instalar un plugin adicional, si ninguno de los que utilizamos permite esta función, aunque es aconsejable tener en cuenta que el fichero .htaccess es editable generalmente, por lo que si en algún momento se desconfigura este código, XMLRPC volvería a estar funcional en la web.
Chris
11/10/2015 a las 22:24Mu bien explicado todo. Gracias.