Qué hacer ante un robot agresivo

robotHace unos días vimos que la carga del servidor de Nireblog subía espectacularmente en un horario en el que no suele tener mucha. Tras comprobar que había más de 700 tareas entre apache y mysql, hice un netstat y constaté que la mayoría de las conexiones venían de una sola dirección ip. Se trataba de un bot agresivo de Attributor que estaba haciendo peticiones a diestro y siniestro (del orden de unas 10 por segundo). Tras denegar la ip mediante iptables, recuperamos la carga. Pero eso sólo fue una solución temporal, dado que usan más direcciones y ayer nos volvió a tocar con otra diferente. Así que os voy a contar una serie de soluciones que podemos aplicar ante estos robots chupa-conexiones.

  • Fichero robots.txt: cuando un robot visita una página, lo primero que solicita es http://www.lapagina.com/robots.txt. En ese documento se le indica si tiene permitido el acceso o no. Esto, claro está, si es un bot bien programado o con buenas intenciones (por ejemplo, las arañas que se usan para extraer direcciones de correo a las que enviar spam no siguen el protocolo ;-)). Por tanto, esta solución puede que no nos valga de mucho. Para decirle que no pase, pondríamos lo siguiente:

    User-agent: attributor.com
    Disallow: /

    Para más información sobre el funcionamiento de este fichero, pasaros por robotstxt.org. Además también tenéis un completo listado de User Agents con las ip’s que suelen usar.

  • Fichero .htaccess: si el bot deja su nombre en el campo user-agent, podremos denegar su acceso en este fichero de la siguiente forma:

    RewriteCond %{HTTP_USER_AGENT} ^.*attributor.*$
    RewriteRule ^.* – [F,L]

    Con esto le estamos diciendo a nuestro apache que, a todas las peticiones que le lleguen en las que el campo User Agent tenga la palabra attributor, les devuelva el código 403 : Forbidden.
    Expliquemos más a fondo la expresión regular que se usa:

    • ^ indica que es el comenzamiento de la URL
    • .* cualquier cadena alfanumérica
    • $ indica que es el final de la URL

    Como vemos, esto nos librará de conexiones a base de datos, porque no se sirve nada, pero no de las conexiones a nuestro servidor web. Aunque si queremos pagar al bot con su misma moneda, podemos modificar la acción de la regla y en vez de hacer que se deniegue el acceso, se puede redirigir a la página del bot en cuestión (en nuestro caso a www.attributor.com).
    Recordad que para usar .htaccess tenemos que tener habilitado el modulo mod_rewrite de apache.

    Para comprobar si nos está funcionando correctamente este método, podemos hacer una petición simulada desde aquí, donde podemos introducir el User Agent a mano y hacer una petición a nuestra web.

  • Iptables: si ni siquiera queremos que trabaje nuestro servidor web, podemos rechazar las peticiones con nuestro firewall. Aunque para eso deberemos conocer las direcciones ip que usa el bot. Si las sabemos, podemos agregar la siguiente regla:

    iptables -A INPUT -s 64.41.145.240 -j LOG –log-prefix «[BLOQ]=>»
    iptables -A INPUT -s 64.41.145.240 -j DROP

    La primera línea hace que se registre el bloqueo en el log de iptables (en el caso de debian es /var/log/syslog ) y la segunda hace que todos los paquetes que lleguen de esa dirección sean descartados. Si no sabemos todas las direcciones que usan los bots, también podemos aplicar la siguiente solución que nos presentó Ricardo Galli: usar el módulo recent de iptables para que descarte las conexiones si un cliente ha intentado hacer más de 30 en 10 segundos

Lorena Fernández Álvarez (@loretahur)

Ingeniera salsera. Actualmente, directora de comunicación digital de la Universidad de Deusto. Miembro del grupo experto de la Comisión Europea Gendered Innovations para analizar el impacto de no incorporar la perspectiva de género en la Inteligencia Artificial. Colabora en el programa de radio “Hoy por Hoy Bilbao” de la Cadena SER desde 2009 con una sección sobre nuevas tecnologías. Además, es jurado del premio Ada Byron a la mujer tecnóloga y mentora del proyecto Inspira STEAM, un proyecto que busca el fomento de la vocación científico-tecnológica entre las niñas. Ha creado junto a Pablo Garaizar e Iñigo Maestro el juego de mesa Nobel Run.

12 thoughts on “Qué hacer ante un robot agresivo

  1. Así se ha quedado el bicho.

    Ya sería la leche redirigirles a la URL desde la que hacen la petición que a su vez les volvería a redirigir y así hasta el infinito o hasta que eche humo su servidor.

    Enhorabuena por el trabajo, ni en verano nos dejan en paz.

  2. Me postro a sus pies por su enorme conocimiento…
    ¿Me podría pasar unas tarifas actualizadas por su trabajo?
    😀

  3. Mírate este post de Manz, la parte donde dice: Bloqueando con SetEnvIfNoCase

    Puede ser una opción interesante para detectar bichos de esos.

  4. @david: parece que en el verano tienen más tiempo para hacer el mal 😉

    @chiqui: ya sabe que para usted hay tarifa de amigo 😉

    @liamngls: con SetEnvIfNoCase se puede hacer lo mismo que con ModRewrite. Lo malo de ambos es que tienes que contar con un patrón que se repita. Por eso me gusta la solución de Ricardo. Ahí no tiene que intervenir el administrador 🙂

    @iñaki: igual podemos hacer un taller de robots xDDD

  5. «Si no tienen ojos, no pueden matar y no te los puedes follar, no son robots» (Muchachada Nui)

    Ahora en serio, gran post 😉

  6. El rollo del .htaccess no mola demasiado y como te descuides puede
    causar otros problemas.

    El robots.txt, protege de los indexadores de los buscadores, pero no de bots hechos a mala leche.

    El iptables es la mejor opción, pero hay que conocer las IPs para poder filtrarlas. Un truco es hacerlo dinámico, para que cierre
    automáticamente aquellas IPs que sean muy petardas y tengan muchas conexiones por minuto… el problema que tiene es que te cargas a todo aquel que venga de algún proxy (de empresas o de isps).

  7. O_o!!! waauuhhhh eres un chica!! no crei que pudiera ver tal suceso!!, realmente no crei que existiera una mujer que publicara de mysql y apache!! un saludote!

  8. @ikusnet: mil gracias por el comentario 😉

    @sharysce: es lo que tiene ser administradora de sistemas, que terminas aprendiendo un poquito de todo. Ojalá llegue un día en que esto no nos sorprenda 🙂

Deja una respuesta

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