12

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

Comentarios sobre "Seguridad en WordPress: bloquea xmlrpc.php"

  1. Pingback: Solución al error de IFTTT con el plugin iThemes Security para Wordpress -MacActual

    1. Andrea BarreiroAndrea Barreiro Autor

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

      Responder
  2. Carlos del rio

    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

    Responder
    1. Andrea BarreiroAndrea Barreiro Autor

      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.

      Responder
  3. Quique

    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

    Responder
    1. Beatriz CorchadoBeatriz Corchado

      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!

      Responder
  4. Quique

    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

    Responder
    1. Beatriz CorchadoBeatriz Corchado

      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! 🙂

      Responder
  5. Dudoso

    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.

    Responder
    1. Beatriz CorchadoBeatriz Corchado

      ¡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! 🙂

      Responder

Deja un comentario

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