XMLRPC.PHP de WordPress ¿que es y como protegerlo?

Aprovechando que el impacto que están teniendo los ataques contra el XMLRPC.PHP de WordPress, me gustaría aclarar ciertos conceptos relacionados con este archivo que forma parte de WordPress y de paso explicar paso a paso como protegerse contra posibles ataques de fuerza bruta y denegación de servicio contra este archivo en una instalación de WordPress.

Como ya hemos hablado bastantes veces en este blog últimamente, muchas instalaciones de WordPress están siendo víctimas de ataques variados de diferentes formas: por un lado están las infecciones de malware o inyecciones de código y por el otro lado están los ataques externos contra algunas partes de WordPress como el archivo xmlrpc.php o el wp-login.php.

En este artículo vamos a ir por partes, vamos a ir explicando ciertos aspectos básicos e interesantes sobre el tema, ya que muchos hablan en sus blogs sobre los ataques al XMLRPC.PHP pero muy pocos saben lo que es el protocolo XMLRPC o la función que hace el archivo XMLRPC.PHP en WordPress.

 

Qué es el XMLRPC

El protocolo XMLRPC es un protocolo que utiliza XML para estructurar datos y el protocolo HTTP para la transmisión de esos datos estructurados en XML.
El protocolo XMLRPC fue desarrollado en 1998 por la empresa UserLand Software en colaboración con Microsoft, finalmente Microsoft considero que el protocolo XMLRPC era muy simple y lo convirtió en lo que ahora mismo se llama SOAP.

En WordPress, el protocolo XMLRPC actual como interfaz que actúa como API para aplicaciones externas y que nos permite interactuar con una instalación de WordPress utilizando aplicaciones o servicios externos.
Al funcionar como una interfaz externa es casi como una “puerta de entrada” por lo que esta puerta puede ser atacada fácilmente desde el exterior causando un alto consumo de recursos al ejecutarse una y otra vez el proceso de autentificación.

 

WordPress y el XMLRPC.PHP

Como hemos dicho anteriormente, en WordPress el protocolo XMLRPC está gestionado por el archivo XMLRPC.PHP que puedes encontrar en la raíz de la instalación de WordPress:

XMLRPC.PHP WordPress

Para comunicarse con una instalación de WordPress utilizando el protocolo XMLRPC debemos enviar peticiones HTTP mediante POST al archivo xmlrpc.php situado en la raíz de la instalación, con esto obtendremos una respuesta.
Si todo ha ido bien normalmente la respuesta obtenida es HTTP/1.1 200 OK.

Hasta la versión 3.5 WordPress traía de forma predeterminada el protocolo XMLRPC desactivado, desde la versión 3.5 viene activado por defecto, y ahí está el problema, ya que todas las instalaciones traen el protocolo XMLRPC activado y por defecto son vulnerables a ataques de denegación de servicio y fuerza bruta contra este protocolo.

Vamos a poner varios ejemplos de funciones REALES que hace el protocolo XMLRPC en WordPress:

  • El protocolo XMLRPC permite que programas de escritorio como Microsoft Word, Textmate o Mozilla Thunderbird se comuniquen con nuestra instalación de WordPress.
  • El protocolo XMLRPC permite la comunicación mediante pingbacks y trackbacks con otros blogs u otras instalaciones de WordPress.
  • El protocolo XMLRPC es el que permite que funcionen ciertas funciones del plugin Jetpack para WordPress que tiene comunicación directa con los servidores de Automattic.

Posiblemente se me quede alguna cosa más en el tintero que se puede hacer con el XMLRPC.PHP, pero en principio las nombradas anteriormente son las principales.

 

Ataques al XMLRPC.PHP

Desde hace algún tiempo (desde que el XMLRPC viene activado por defecto en WordPress) los ataques contra el XMLRPC ocurren de forma habitual, el problema es que estos ataques a veces son difíciles de detectar ya que pueden venir desde cientos de direcciones IP al mismo tiempo.
El problema de los ataques al XMLRPC.PHP ya no es solo que puedan encontrar la contraseña y entrar mediante fuerza bruta, sino que estos intentos de autentificación pueden llegar a consumir muchos recursos ya que todas las peticiones deben procesarse, ahí es donde aparece el problema, ya que en planes de hosting compartido con los recursos limitados, esto puede ser realmente un problema.

A diferencia de otro tipo de ataques, el ataque DDOS al archivo XMLRPC.PHP de WordPress es realmente fácil y solo tenemos que tener un ordenador con un sistema operativo Linux y algo de soltura en la consola de comandos de Linux para ejecutar la siguiente línea y atacar a quien nosotros queramos:

XMLRPC.PHP WordPress

El código está incompleto, más que nada para que a ningún gracioso se le ocurra empezar a atacar sitios web WordPress utilizando el ejemplo, el código anterior simplemente lo he puesto como ejemplo para que se vea lo fácil que es realizar un ataque al XMLRPC.PHP de cualquier instalación de WordPress.

Cuando una instalación de WordPress está bajo ataque al XMLRPC.PHP lo normal es que el uso de recursos de CPU se ponga a tope y el uso de memoria RAM sea también bastante alto:

XMLRPC.PHP WordPress

En este caso, cuando la web se encuentra bajo ataque, la web carga muy lenta y en ocasiones puede mostrar un error 500 – Internal Server Error como este:

XMLRPC.PHP WordPress

En el caso de un servidor VPS con recursos reducidos también puede ser que el servicio MySQL se pare al consumirse todos los recursos de RAM, en estos casos debemos tener extremo cuidado ya que puede dañarse la base de datos al “crashear” el proceso de MySQL.

 

 

Protección contra ataques al XMLRPC – Método 1

Existen varios métodos para protegernos contra ataques XMLRPC, y aunque ninguno de los métodos es 100% efectivo, sí que ayudan a mantener la estabilidad de la instalación aunque nos ataquen, evidentemente cuantos más recursos tengamos disponibles en nuestro servidor o en nuestro plan de hosting, más margen de maniobra tendremos en caso de que nos ataquen ya que dispondremos de más recursos.

El primer método de protección consiste en realizar varias modificaciones en varios archivos de WordPress para que no se encuentre el archivo XMLRPC.PHP y también para desactivar las funcionalidades de XMLRPC para que WordPress no muestre ningún error por ello.

Lo primero que vamos a hacer es borrar o cambiar el nombre del archivo XMLRPC.PHP que encontraremos en la raíz de nuestra instalación:

XMLRPC.PHP WordPress

Lo siguiente que debemos hacer es dirigirnos a nuestro archivo wp-config.php de WordPress (también se encuentra en la raíz de la instalación) y debajo de la última línea colocamos lo siguiente:

Tal y como se muestra en la siguiente imagen:

XMLRPC.PHP WordPress

Lo siguiente que debemos hacer es dirigirnos al archivo funcions.php del theme que tenemos activado y al final debemos añadir el siguiente código:

Este método es bastante simple, pero para usuarios poco acostumbrados a WordPress y al mundo web puede ser algo difícil, por esa razón existen otros métodos para desactivar el XMLRPC.PHP y evitar que nos puedan atacar.

 

Protección contra los ataques al XMLRPC – Método 2

El segundo método es mucho más simple desde el punto de vista de un usuario principiante en WordPress, pero yo cuando lo uso, hasta me quedo algo intranquilo a pesar de que sé que es efectivo y que realmente hace lo mismo que en el método 1 pero de forma automatizada y aprovechando un poco las posibilidades que tienen los plugins en una instalación de WordPress.

XMLRPC.PHP WordPress

En este método 2 usaremos el plugin XMLRPC Attacks Blocker, un plugin gratuito que puede ser descargado desde el repositorio de plugins de WordPress y que permite desactivar el XMLRPC.PHP casi por completo.

Puedes encontrar más información acerca de este plugin para WordPress en la siguiente dirección URL: https://es.wordpress.org/plugins/xmlrpc-attacks-blocker/

La ventaja que tiene usar este plugin es que podríamos incluso seleccionar un único usuario al que le permitiremos acceder mediante el protocolo XMLRPC, además, nos permite bloquear mediante el .htaccess a todas las direcciones IP que intenten utilizar nuestro archivo XMLRPC.PHP una vez desactivado el protocolo.
Sin duda, esta última funcionalidad nombrada es lo que realmente distingue este método del método 1.

 

Protección contra ataques al XMLRPC – método 3

El método 3 de protección contra ataques XMLRPC en WordPress es realmente rudimentario, es más, se basa en bloquear el acceso al XMLRPC.PHP usando el archivo .htaccess, haciendo una redirección a un error 403.

Primero introducimos lo siguiente en el .htaccess del sitio web (en caso de usar un servidor web compatible con archivos .htaccess):

Lo siguiente que debemos hacer es añadir el siguiente código al funcions.php del theme activo en la instalación de WordPress:

De los cuatro métodos aquí mencionados, este es el único método que yo personalmente no utilizaría.

 

Protección contra ataques al XMLRPC – Método 4

Este método también es mediante plugin, pero la técnica utilizada por el plugin cambia, de hecho, es bastante curiosa.
El plugin Stop XML-RPC Attack es un plugin que añade unas líneas al .htaccess del sitio web que simplemente bloquean todo el tráfico entrante al archivo XMLRPC.PHP excepto el tráfico que entra desde rangos de direcciones IP pertenecientes a los servidores de Automattic, es decir, que de esta forma funciona Jetpack.

Sin duda, un método simple, pero bastante curioso, ya que nos permite seguir utilizando el plugin Jetpack for WordPress sin ningún problema.

Puedes encontrar más información acerca de este plugin para WordPress en la siguiente dirección URL: https://es.wordpress.org/plugins/stop-xmlrpc-attack/

 

¿Tienes una web bajo ataque?

¿Estas alojado con nosotros? ¿Crees que tu WordPress está siendo atacado? Si eres cliente nuestro contacta con nosotros sin compromiso y te intentaremos ayudar de la mejor forma posible.

¿No tienes tu web alojada con nosotros? Si buscas un hosting que te ayude con los ataques XMLRPC.PHP contacta con nosotros sin compromiso e intentaremos ayudarte.

Share on twitter
Compartir en Twitter
Share on facebook
Compartir en Facebook
Share on pinterest
Compartir en Pinterest

¿Te gusta el blog?

Apúntate al boletín y te enviaremos los mejores artículos una vez al mes.

¿Te ayudamos?

Escríbenos si tienes dudas o necesitas una solución específica. Nuestros expertos te ayudarán en todo lo posible.

Sé el primero en enterarte de ofertas, sorteos y novedades.

Tenemos 50 comentarios en

"XMLRPC.PHP de WordPress ¿que es y como protegerlo?"

50 respuestas

  1. Hola Álvaro, sobre incluir el código en el archivo functions.php, cuando trabajas con un tema child, es en éste donde hay que incluirlo ? Gracias !!

  2. Hola, gracias por el dato, voy a probarlo. Solo una duda, en el instructivo indica modificar el archivo wp-config.php y en la imagen están modificando el archivo wp-config-sample.php
    Cual es entonces? O hay que modificar ambos?
    Saludos y gracias de nuevo!

    1. No, tienes que modificar solo el wp-config.php, lo que ocurre es que en el preciso momento no podíamos modificar el wp-config.php.
      Corregiremos eso para que nadie se lie con esto.

      Un saludo.

  3. Muchas gracias por este tutorial, esta explicado de forma clara y sencilla. Gracias por el aporte. saludos!

    1. Hola Modesto, con el robots.txt solo bloquearías a los buscadores, no a los bots malintencionados.

      Un saludo.

  4. Hola he usado el método 4 ya que estaba teniendo ataques y de hecho, aún usando el plugin, el consumo de cpu del server es bestial. También he bloqueado el rango de ips atacante. Alguna forma de evitar los ataques al servidor y que la cpu no se vea afectada?
    Por cierto, estoy usando el Wordfence, que opinas de este plugin?

    1. Hola, para mi Wordfence es el mejor plugin de seguridad para WordPress y mas ahora que le han añadido el WAF.

      Si quieres que los ataques no afecten al servidor, debes bloquear los ataques en el firewall del servidor (CSF por ejemplo) o en el firewall de red si tienes esa posibilidad.

      Un saludo.

      1. Hola, llevo unas semanas que cada día se cae el servidor una o dos veces debido a este problema. He utilizado diferentes métodos y aun habiendo deshabilitado el fichero xmlrpc.php, encuentro en el log de apache peticiones «random» a ficheros inexistentes que terminan por tirar el servidor.

        Y aún devolviendo un 500 las peticiones a xmlrpc.php el uso de cpu se disparaba por lo que volvía a caerse el servidor.

        Estoy utilizando un vps en digitalocean y seguido varios de sus tutoriales pero sigo sin poder mitigar la amenza. También vengo utilizando cloudflare y creo que, a raíz de que llegara al tope en la tabla que tienen en su versión gratuita donde añaden ips amenzantes en su firewall, ha sido cuando he empezado a tener este tipo de problemas, a pesar de haber quitado bastantes reglas para que puedan volver a añadirse de forma automática como hasta ahora venía haciendo y habiendo metido estas de forma manual con ufw.

        Voy a probar ese plugin a ver que tal es

        1. Hola, si el servidor se cae en esta situación puede que el ataque sea muy fuerte o que el servidor no este correctamente optimizado.
          Nosotros trabajamos con fail2ban y con reglas propias para mitigar este tipo de ataques, de esta forma los ataques no llegan a ejecutar PHP y por lo tanto no saturan el servidor.

          Un saludo.

  5. Muy interesante. Pero qué se puede hacer si se quiere utilizar un servicio – que no es jetpack – que necesita conectarse con este archivo? Quiero conectar mi blog con Postable (postable.io) y no puedo justamente porque en el hosting (raiola claramente ) hay una redirección puesta al archivo /xmlrpc.php

    1. Hola Luca, contacta con soporte tecnico, creo que te podrán dar una solución basada en añadir una regla al WAF del servidor.

      Un saludo.

      1. Gracias Álvaro.
        De momento he quitado la redirección y he añadido uno de los plugins que comentas, dejando el acceso al archivo sólo para la cuenta del administrador. Y ahora el enlace con Postable funciona. Espero que la web siga siendo segura, aunque creo que sí…

        1. Hola Luca, no te preocupes, seguira siendo segura, de todas formas si detectamos ataques los bloqueamos manualmente.

          Un saludo.

  6. xmlrpc.php
    Me dice una herramienta de análisis que tengo este enlaçe roto. es decir… que la url no lleva a ninguna parte: Method Not Allowed405

    Alguien sabe como puedo solucionar esto.

    Muchas gracias

    1. Hola Ceci, debes contactar con tu proveedor de hosting para solucionar el problema, también debes revisar si tienes algo bloqueando el XMLRPC.PHP para peticiones externas.

  7. Muchas gracias, muy bueno todos los artículos, realmente muy interesantes y siempre aportando contenido de forma accesible.
    Me queda una duda sobre la protección a XMLRPC ¿Sólo con el método 4 se puede utilizar jetpack?
    Además, los plugin dicen no recibir actualizaciones desde hace unos dos años ¿aún serán efectivos?

    1. Hola Romina, el plugin del método 4 teóricamente debería dejar funcionar Jetpack, pero no lo he probado últimamente, en todo caso, si provoca un error, te enteras rápido, ya que va a aparecer un error de conexión con los servidores de Automattic en el panel de Jetpack.

      Un saludo.

      1. excelente articulo! instale el plugin y hace lo del .htaccess y coloca en allow las ip de jetpack asi que sigue funcionando sin problemas

  8. Hola!!
    Que opinas sobre bloquear xmlrpc.php desde mismo apache? El sitio que administro no usa xmlrpc en absoluto y después de un par de ataques que tiraron el sitio lo desactive mediante «deny from all» en la configuración del virtual host de apache. Fue la solución más rápida que pude ejecutar al momento (aunque sigue escribiendo logs en el fichero de apache que ya no afectan el performance del server) en lo que configuro fail2ban para bannear las ips atacantes.
    Saludos!!

    1. Hola Alvaro, si tienes acceso a la configuración de Apache es una opcion mas, y hasta mas afectiva, ya que cuanto mas «de raiz» es la solución, menos impacta en el rendimiento del servidor, aunque no todos los usuarios tienen los conocimientos o la posibilidad de implementar este tipo de soluciones.

      Un saludo.

      1. Hola, Iván:

        Puedes optar por usar el siguiente código para bloquear todo:

        Si quieres usar algo más refinado, complicado pero con más control puedes usar ModSecurity.

        Un saludo!

  9. Alvaro, me han gustado el método 2 ya que te da la opción de bloquer la ip de quien te ataca , pero aun me preocupa que quede bloqueado API que utilizo para comunicarme con otros servicios como Twitter, ¿no sé si estos se afectarían? te consulto antes de proceder. Ha ademas se que he recibido ataque pero hasta el momento no veo mayor afectación solo que mi hosting me dice que quien me ataca y ademas he visto que mi trafico incrementa, pero no se lo puedo atribuir al ataque porque esta dentro de mi crecimiento normal de trafico.

    1. Hola Franklin, ¿lo notas a nivel rendimiento o en algo en especial? Si los ataques no te afectan, creo que puedes omitir los ataques.

      Un saludo.

  10. Excelente dato, ese error me apareció recientemente en uno de mis sitios, no soy programador pero voy a intentar la primera opcion que la veo mas segura, porque estuve revisando los plugins pero no me parece buna idea cargar el sitio con plugins. Muchas gracias nuevamente por el dato, lo voy a poner en práctica.

  11. Hola!, vaya tema. Tengo instalado el Pluguin Redirection, ya que hice la migracion desde Blogger, y en los reportes de errores 404s me aparece 1 intento de entrada a /xmlrpc.php, esto quiere decir que el pluguien redirection lo identifico como url no existente. Por eso me aventure a buscar de que se trataba este archivo, y me encontre con toda esta informacion que brindas en tu post.

    Invetsigando un poco mas, encontre otra opcion que propone eliminarlo directamente al archivo /xmlrpc.php y agregar las siguientes lineas de codigo en el archivo functions.php

    function removeHeadLinks() {
    remove_action(‘wp_head’, ‘rsd_link’);
    remove_action(‘wp_head’, ‘wlwmanifest_link’);
    }
    add_action(‘init’, ‘removeHeadLinks’);

    y deshabilitar la funcionalidad XML-RPC de las opciones de WordPress

    Quisiera saber que tan efectiva y recomendable puede ser esta opcion, si el archivo no es utilizado para sacarle provecho.

    1. El problema es que si eliminas el archivo xmlrpc.php y bloqueas su funcionamiento, algunas funcionalidades de WordPress van a quedar descolgadas y no podrás instalar algunos plugins como Jetpack.

      Un saludo.

    1. Hola, Artur:

      En efecto, mucho mejor, ¡gracias por la recomendación!

      Ahora mismo optamos por usar modSecurity para proteger nuestros hostings sin necesidad de plugins.

      Un saludo.

  12. Excelente explicación, yo no uso pingback y trackbacks, tampoco el plugin jetpack ¿Cual método me recomiendas?

    1. Hola, Erickson:

      te recomiendo el primer método. Es rápido de usar y se mantendrá si en el futuro migras de hosting, cambias de tema o usas un servidor web distinto.

      ¡Cualquier cosa nos dices!

      Un saludo.

  13. Que método o plugin recomendais actualmente para bloquear los ataques por fuerza «bruta» y que siga funcionando las actualizaciones de los plugins por Automattic

    1. Hola Alex, pues la verdad es que creo que para este tipo de cosas el único que sigue en pie y que no ha cambiado mucho es Ninja Firewall.

  14. Hola Alvaro, Excelente artículo, ya vi que no pasa de moda.
    Yo uso el tema Newspaper con Divi, desde hace como un mes el uso de CPU y Mmemoria se disparó, he instalado un par de plugins y aún así no bajan los parametros. Aunque han disminuido algo los errores HTTP 5xx. El que más ocurre es el 503

    Tengo instalados los plugins -Anti-Malware Security and Brute-Force Firewall y el WP-Cerber security, este segundo tiene una opción Desactivar XML-RPC – Bloquear el acceso al servidor XML-RPC (incluyendo pingbacks y trackbacks). Eso ayudaría a reducir los ataques?

    Probaría pero no sé si el tema utiliza el XML-RPC o el mismo servidor. Qué me aconsejas?

    1. Hola Hugo, y….la pregunta es…¿sabes seguro que es por el XMLRPC? Porque si no es de eso, igual lo estas empeorando con tantos plugins de seguridad…

      Lo digo porque…actualmente los ataques al XMLRPC son casi inexistentes, hubo un BOOM, pero ahora han bajado mucho y los WAF de los servers los detectan al instante.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Utilizamos cookies propias y de terceros para obtener información estadística, mostrar publicidad personalizada a través del análisis de tu navegación, así como para interactuar en redes sociales. Si continúas navegando, consideramos que aceptas nuestra Política de cookies. ACEPTAR

Aviso de cookies