Seguridad en WordPress: bloquea xmlrpc.php

Logotipo de WordPress sobre fondo azul

 

No es la primera vez que te damos indicaciones para reforzar la seguridad en WordPress, pero queremos seguir ampliando poco a poco con nuevos consejos. ¡Esperamos que te sean útiles!

 

El post de hoy trata sobre una vulnerabilidad específica, y es que últimamente hemos recibido correos de varios clientes, usuarios de WordPress, que están teniendo problemas con sus webs. El primero fue el caso de Antonio: te lo contamos en detalle por si utilizas WordPress y quieres blindarte contra este problema.

 

Antonio se puso en contacto con nosotros cuando vio que su web de WordPress no estaba funcionando. No podía acceder, no funcionaba el correo electrónico… Un cuadro, y encima en día laborable. Escribió un Ticket a Soporte pidiéndonos que lo ayudáramos cuanto antes, explicando el problema y adjuntando una captura.

 

Uno de nuestros técnicos de Soporte analizó el caso y vio que estaba sufriendo caídas periódicas por culpa de ataques de fuerza bruta desde direcciones IP de países como Holanda o Turquía. Para que nos entendamos: estos ataques implican peticiones numerosísimas a la web y finalmente impiden acceder a ella, porque el tráfico que generan de manera artificial es insostenible. En resumen, es un ataque DDoS contra tu web de WordPress.

 

En el caso de Antonio, Soporte técnico bloqueó las direcciones IP atacantes, levantó la web e informó a Antonio del problema y de la solución aplicada. Sin embargo, en los días siguientes recibimos más casos idénticos, por lo que nos dimos cuenta de que el archivo contra el que se realizaban todas esas peticiones era común en todos: el archivo xmlrpc.php.

 

Con esta nueva pista e investigando un poco por la red, vimos que este archivo sirve para poder postear de forma remota (es decir, para utilizar otra aplicación para publicar posts: Microsoft Word, Textmate, Thunderbird, tu smartphone…). En concreto, los ataques parecían tener como objetivo la obtención de la contraseña de administrador.

 

Como te puedes imaginar, ni a Antonio ni al resto de clientes que contactaron con nosotros les hacía ninguna gracia que alguien pudiera obtener esa contraseña contra su voluntad. Tampoco habían necesitado nunca utilizar su WordPress de forma remota, así que estuvieron de acuerdo en bloquear el acceso al archivo xmlrpc.php aunque a partir de ese momento quedara inservible (de todos modos, como decimos, no lo utilizaban).

 

Al quedar inaccesible el archivo xmlrpc.php atacado, y por muchas peticiones que se realicen constantemente, resulta imposible tirar la web utilizando este método. Y lo mejor es que es facilísimo bloquear el archivo. Desde Soporte técnico siempre intentamos explicar todo lo que hacemos en nuestras respuestas a los Tickets y, de hecho, algunos de estos clientes aplicaron la medida sin ayuda nuestra.

 

Solamente hay que modificar el fichero .htaccess añadiendo este trocito de código:

<Files xmlrpc.php>

order allow,deny

deny from all

</Files>

Si trabajas con la versión de Apache 2.4, añade las siguientes líneas:

<Files xmlrpc.php>

Require all denied

</Files>

Una vez hecho esto, tu web de WordPress queda completamente protegida contra los ataques realizados contra el archivo xmlrpc.php. Si nos necesitas, puedes ponerte en contacto con nosotros y lo haremos por ti sin ningún problema. Sabemos que mejorar la seguridad en WordPress es muy importante y estaremos encantados de ayudarte a conseguirlo. ¿Tienes dudas? Deja un comentario e intentaremos responderlas.

Andrea Barreiro

Andrea Barreiro

Andrea trabaja en Host Europe desde 2012. Es parte del equipo de marketing y supervisa la actividad en redes, el blog, actualiza la web, gestiona el email marketing y desarrolla otras iniciativas con nuestros clientes.

More Posts

14 respuestas a “Seguridad en WordPress: bloquea xmlrpc.php”

  1. […] – Al final de la página, desplegamos el menú XML-RCP – necesario para el funcionamiento de aplicaciones móviles y Jetpack, entre otras – y seleccionamos “OFF” para que la implementación xml-rcp de la que hace uso WordPress funcione a pleno rendimiento. Aquí no existe otra opción, debes valorar entre poder hacer uso de IFTTT o desactivar xml-rcp. Si deseas obtener más información sobre los riesgos de activar este protocolo, puedes hacerlo en el siguiente enlace. […]

  2. Manuel dice:

    ¡Gracias por la información! Configurado 🙂

    • Andrea Barreiro Andrea Barreiro dice:

      ¡De nada, Manuel! Todo lo que podamos hacer para mejorar la seguridad en WordPress, es poco. ¡Un saludo!

  3. Carlos del rio dice:

    Buenas tardes, me parece muy interesante el articulo ya que he tenido varios problemas. Intenté hacer lo que explican pero después me aparece esto al cargar la página
    Internal Server Error

    The server encountered an internal error or misconfiguration and was unable to complete your request.

    Please contact the server administrator, xxxxxxxxxx and inform them of the time the error occurred, and anything you might have done that may have caused the error.

    More information about this error may be available in the server error log.

    Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

    el archivo después de editarlo queda así
    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    order allow, deny
    deny from all

    # END WordPress

    ¿Está correcto?
    Muchas gracias

    • Andrea Barreiro Andrea Barreiro dice:

      Hola, Carlos:
      Creo que el problema está en que estás introduciendo el código donde no es 🙂 Verás, tiene que afectar exclusivamente al archivo xmlrpc.php. Si lo introduces en medio de las líneas de WordPress, tendrás como resultado el error que me comentas. Tienes que introducir el código que te indico en el post en el archivo .htaccess, pero fuera de las líneas de WordPress, de manera independiente.
      No sé si ahora me he explicado mejor. Si eres cliente nuestro, puedes ponerte en contacto con nuestro soporte y comentarles que te echen una mano, ¡vas de parte mía! 😉 Un saludo y gracias por leernos.

    • AleFerrari dice:

      Debes ponerlo luego de la línea # END WordPress y debes incluir las cuatro líneas indicadas:

      order allow,deny
      deny from all

      Con eso va ok

  4. Quique dice:

    Buenos días,
    tengo esas lineas añadidas tal y como describes en el .htacsess pero en el registro de errores a través de cPanel veo nuevas lineas del siguiente estilo cada 10 minutos. No sé si esas lineas no acaban de solucionar el problema o será otra cosa?
    [Thu Jan 19 10:35:49 2017] [error] [client 193.127.190.21] client denied by server configuration: /home/viajablo/public_html/xmlrpc.php
    [Thu Jan 19 10:35:49 2017] [error] [client 193.127.190.21] client denied by server configuration: /home/viajablo/public_html/xmlrpc.php
    [Thu Jan 19 10:00:06 2017] [error] [client 65.208.151.115] client denied by server configuration: /home/viajablo/public_html/xmlrpc.php

    • Beatriz Corchado Beatriz Corchado dice:

      Hola Quique,

      Ese log indica que las reglas que has configurado en tu .htaccess están funcionando correctamente 😉 La intención de este post es impedir que se realicen esas peticiones a xmlrpc y es exactamente lo que están haciendo.

      ¡Muchas gracias por seguirnos! ¡Un saludo!

  5. Quique dice:

    Gracias Beatriz!
    Tengo como 200 de esas lineas a diario desde hace meses. Entiendo que estoy parando ataques pero esto es lo único que podemos hacer para evitarlos? Aunque no puedan acceder, puede que ralenticen a tengan un impacto en la página?
    Por otro lado, ¿no podría ser un plugin o parte del theme que trate de acceder a este archivo? me parece muy fuerte un ataque tan periódico y continuo durante tanto tiempo…

    Gracias!
    Quique

    • Beatriz Corchado Beatriz Corchado dice:

      Hola Quique,

      Si el ataque es muy grande, sí que puede llegar a afectar, aunque estas medidas reducirían, en gran parte, los efectos que puede generar. Si fuese de un plugin o theme la IP no cambiaría, sería siempre la misma y, probablemente, la propia del alojamiento. Puedes comprobar que tu sitio no está siendo utilizado para un ataque DDOs a través de xmlrpc con la siguiente herramienta: http://labs.sucuri.net/?is-my-wordpress-ddosing.

      De todas maneras, si eres cliente nuestro, puedes contactar con el equipo de Soporte a través del correo soporte@hosteurope.es o llamando al 910 867 658. Estarán encantados de aclarar todas tu dudas y de ayudarte en lo que sea necesario.

      ¡Muchas gracias y saludos! 🙂

  6. Dudoso dice:

    Un ataque DDos no es lo mismo que un bot mal programado de robo de contraseñas mediante fuerza bruta. Si un servicio entero se cae por un ataque spam de WordPress (que sufren todos los WordPress continuamente) la culpa es de una mala configuración del server.

    Es bastante más fácil y lógico implementar una medida a nivel de servidor que pretender que miles de clientes sin conocimientos técnicos se pongan a realizar parches en su WordPress.

    • Beatriz Corchado Beatriz Corchado dice:

      ¡Hola!

      Claro, lo que comentas es cierto y es necesaria una buena configuración del servidor para evitar problemas así. En el caso de Antonio, su aplicación sí estaba recibiendo un ataque que le estaba dejando sin recursos y por eso estos problemas. Se alojaba en hosting compartido y el ataque a través de XML-RPC estaba siendo detenido por las medidas de seguridad del servidor. Por este motivo, los problemas afectaban sólo a su sitio y no al resto de usuarios.

      En el momento que lo analizamos, detectamos el problema y le ayudamos a resolverlo.

      Realmente si no utilizas este protocolo, lo recomendable es bloquearlo. Si con estos pasos te parece complicado, hay plugins que encontrarás en el repositorio oficial de wordpress para tal fin.

      Muchas gracias por tu comentario y ¡buen fin de semana! 🙂

  7. Juan dice:

    “El post de hoy trata sobre una vulnerabilidad específica,”. ¿Cuál es esa vulnerabilidad específica? Un ataque de fuerza bruta o de DDoS es una vulnerabilidad genérica de cualquier web dinámica. Ni es un problema específico de WordPress ni del archivo xmlrpc.php. No se porque se perpetúa este mito de riesgo de seguridad en el archivo xmlrpc,php.

  8. María Acibeiro María Acibeiro dice:

    ¡Hola Juan! Es cierto lo que nos comentas, realmente no existe ninguna vulnerabilidad específica en estos ficheros, pero lo cierto es que la mayoría de los ataques por fuerza bruta o DDos que recibe WordPress van dirigidos a uno de estos ficheros. Como dices, este tipo de ataques pueden hacerse contra cualquier fichero de una web dinámica, pero la principal intención es conseguir acceso al panel de administración de la aplicación y esto no solo lo permite el wp-login.php sino también el xmlrpc.php, por eso es objetivo de mayor número de ataques.

    La principal función de este fichero es permitir el acceso desde aplicaciones externas, como Microsoft Word o Thunderbird y la mayor parte de los usuarios con un nivel de conocimientos básicos de WordPress no lo utilizan. Por eso nosotros recomendamos bloquearlo. Al fin y al cabo, si no lo utilizas, es una forma de evitar tráfico excesivo e innecesario.

    Como te decía al principio, es verdad que no es un problema en concreto de ese fichero, pero si no lo necesitas, sería recomendable que probaras este tipo de medidas de seguridad. Existen otros métodos para evitar ataques a este fichero como el uso de plugins como XMLRPC Attacks Blocker, disponible en el repositorio oficial de WordPress o el plugin Stop XML-RPC Attack.

    ¡Muchas gracias por tu aportación!
    Un saludo

Deja un comentario

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