Hace 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
Technorati tags: robot, bot, spider, robots.txt, htaccess, iptables
Una de esas palabras que se han puesto de moda con todo el tinglado de la web 2.0 es ajax. La primera vez que la escuchamos, a todos nos viene a la cabeza ese famoso limpiahogar. Pero debemos aclarar que se trata de una nueva tecnología web.
