Inicio

Pensamientos

Ver entrada

Avatar de jesus   jesus   25/03/2014 a las 06:37
Cómo denegar el acceso a robots, bots, spiders, crawlers y spammers
Foto: Cómo denegar el acceso a robots, bots, spiders, crawlers y spammers

Una herramienta muy típica y útil para todos los sitios web es un registro de accesos a tu web; te da información sobre cuántos accesos tienes, la carga a la que se ve sometido el servidor web, cuántos accesos son reales y cuántos son de bots, de qué país te visita la gente, cómo han llegado a tu web... aunque sea por curiosidad, parece una herramienta my atractiva.

Pues bien, el viernes pasado implementé una herramienta que me hace esto y que me sirve para filtrar los accesos por distinto criterio, y me di cuenta de que tenía miles de visitas de robots, algunos de ellos "benignos", algunos de ellos más bien "malignos". Con maligno me refiero a que acceden mucho y me reportan poco o nada. O incluso a que vienen sólo para joder (hay robots que recogen información sólo para producir spam o para tratar de robar información).

¿Qué es un robot/bot/crawler?

Para quien no lo sepa, un robot o bot, es una aplicación que se dedica a acceder recursos y que tiene un comportamiento programado. Muchas compañías utilizan robots para seguir enlaces web y recopilar más enlaces, contenidos web, y posteriormente hacer estudios estadísticos de todo ello. Google lo hace, Yahoo lo hace y muchos otros buscadores o directorios web lo hacen. El término crawler o web crawler hace referencia a los bots que se cuelan en una web para extraer su información. Yo he programado alguno para sacar datos de tablas de resultados de algunos sitios web de cierto cliente, por ejemplo.

¿Cuál es el peligro o el perjuicio de los bot?

De entrada no tiene por qué haber ningún problema con los robots. Es normal que existan, y además hay maneras de decirle cómo quieres que se comporte en tu web, si puede acceder a ciertos archivos e incluso directorios o quedarse fuera. El problema es que muchos de ellos tienen un comportamiento abusivo, como hacer demasiadas peticiones seguidas (sobrecargando de manera innecesaria tu servidor) o no seguir las directrices que les especificas (por ejemplo con el archivo robots.txt).

La cosa ya tiene pelotas cuando la principal misión de ese robot es recoger información de productos comerciales de sus clientes para hacer analíticas, o cuando están recopilando información para luego ofrecerte servicios SEO (¡te estrujan antes de que les pidas ningún servicio!), o cuando están revisando tus contenidos multimedia buscando infracciones de copyright... o simplemente porque quieren hacer acopio de artículos que luego serán presentados en sus propias plataformas (también llamado robar contenido, en mi pueblo).

Yo personalmente opto por denegar el acceso a los robots que me resultan molestos o innecesarios, o que simplemente creo que se aprovechan de mala manera de mis contenidos.

¿Cómo le puedo decir a un robot que se comporte?

Es posible decirle a un robot que no quieres que entre en un subdirectorio o recurso, o incluso que te deje en paz del todo. Para ello, los administradores web cuentan con al menos dos recursos:

  • fichero(s) robots.txt
  • fichero(s) .htaccess

En primer tipo de fichero podemos decir simplemente quiénes NO pueden acceder a qué directorio o URL relativas, discriminando por el campo user-agent del robot. El user-agent identifica el tipo de client, típicamente un navegador aunque también hay muchos otros, que solicita contenidos de tu sitio web. Como complemento, también se pueden agregar etiquetas META a la cabecera HTML para indicar que se sigan o no se sigan los enlaces en la página actual. Los robots deben seguir las directrices de este fichero, pero en la realidad hay muchos que no lo hacen. Éste es el principal problema de robots.txt, que los robots malos no te van a hacer ni caso.

El fichero .htaccess es una herramienta del servidor web Apache que permite escribir muchas y diversas directivas, y en nuestro caso, permite redirigir o denegar el acceso a IP's, rangos de IP's y user-agents. Este método debería de ser más efectivo y drástico que el primero, pero también es cierto que a veces las reglas a escribir en dicho fichero se vuelven complicadas y el fichero se vuelve ilegible. Las reglas de un archivo .htaccess afectan al directorio donde se encuentran y a todo lo que cuelga de él, y son muy potentes. Existen muchos archivos .htaccess disponibles en internet que puedes usar, el problema es que contienen listas enormes de robots que harán que tu aplicación tenga una respuesta más lenta, con lo que no se sabe si es peor el remedio o la enfermedad.

Ya, pero... ¿qué escribo en robots.txt para bloquear el acceso a un robot?

Muy fácil. El estándar es muy sencillo, todas las directivas son de denegación de acceso, así que lo suyo es poner algo como esto:

Para directorios (y sus subdirectorios), y archivos que no quieres que sean accedidos:

User-agent: *

Disallow: /privado

Disallow: /ejecutables

Disallow: /publico/secreto.html

Para denegar el acceso a todo el sitio, por ejemplo, se podría poner esto en raíz:

User-agent: *

Disallow: /

Por supuesto puedes denegar el acceso a un único robot:

User-agent: robotMalo 

Disallow: /

 

O también hacer una especie de lista blanca de robotos, y denegar el acceso a los demás:

User-agent: Googlebot

User-agent: Slurp

User-agent: msnbot

User-agent: Mediapartners-Google*

User-agent: Googlebot-Image

User-agent: Yahoo-MMCrawler

Disallow: 

User-agent: *

Disallow: /

Hay algunas variantes más, pero creo que con esto es suficiente para empezar a poner un poco de orden cuando los robots empiezan a hacer de las suyas. La principal desventaja, como digo, es que los robots maliciosos realmente se van a pasar por el arco del triunfo (por los cojones, vaya), cualquier cosa que le digas en el robots.txt, porque no hay nada técnicamente hablando que les fuerze a hacerlo

Cómo bloquear el acceso a robots malos desde .htaccess

Este método debería de ser más efectivo que el anterior porque no es algo que los robots puedan hacerte caso o no, sino que es algo que el servidor web Apache usa como directriz cada vez que recibe una petición de un cliente.

Sin embargo, como digo, puede no funcionar del todo bien (he tenido problemas parametrizando el servidor de cierto foro de política famosillo que estaba al borde de explotar por culpa de tanto robot), y además, hace que Apache sirva las respuestas más lento.

Este método hace uso del mod_rewrite de Apache, redirigiendo peticiones URL a otros sitios... como una página/respuesta 404 (recurso no encontrado). 

Con .htaccess se pueden banear user-agent e IP's.

Banear user-agents y mandarles un "acceso denegado":

RewriteCond %{HTTP_USER_AGENT} .*DotBot.* [OR]

RewriteCond %{HTTP_USER_AGENT} ^Gigabot.* [OR]

RewriteCond %{HTTP_USER_AGENT} ^Ezooms.* [OR]

RewriteCond %{HTTP_USER_AGENT} ^SISTRIX.* [OR]

RewriteRule ^.* - [F]

Banear IP's sería también fácil y efectivo... si no fuera porque buscadores como el chino Baidu cuenta con miles de IP's:

order allow,deny

deny from 127.0.0.1 # banea esa ip 

deny from 127.0.0.1/17 # banea de la 1 a la 17

allow from all # y permitimos el acceso al resto

Yo personalmente desaconsejaría esta solución, porque al final se acaba con ficheros .htaccess infinitos. Los hay para descargar de Internet bastante sofisticados, con expresiones regulares y listas negras enormes... pero como ya he mencionado antes, cada web, cada tema, cada país es diferente, y lo que a alguien de Nebraska le funciona, no tiene por qué ser lo que tú necesitas.

¿Se pueden prevenir accesos a nivel de programación?

Sí, y es lo que yo hago en esta web. La ventaja de este método es que puedes reusar el código en diversas aplicaciones, además de que puedes recoger datos y luego verlos o hacer estadísticas con ellos. En principio no es una solución que debiera consumir demasiados recursos, vamos, que es rápido.

En mi caso, haciendo uso de algunas de las características de mi propio framework, tengo dos plugin que se ejecutan en dos momentos distintos del ciclo de vida de la aplicación:

  • bloqueador de accesos: una clase con una lista negra de user-agents y de IP's, y con varios métodos para filtrar los accesos y registrarlos. Si una petición proviene de alguien en la lista negra, se registra el acceso en la tabla para tal efecto, y acto seguido se para la ejecución de la aplicación, enviando al cliente un amable e informativo "please, fuck off".  Este código se ejecuta prácticamente al princpio de todo el proceso, de tal manera que el servidor no pierde tiempo ni recursos en accesos maliciosos
  • Registro de accesos: otra clase con varios métodos para registrar peticiones a la aplicación. Se ejecuta al final del ciclo de vida de la aplicación, cuando YA se ha enviado la respuesta al cliente. De esta manera, la respuesta es enviada sin demora, y las acciones necesarias se pueden ejecutar más tarde, sin perjuicio de los tiempos de respuesta de la aplicación

Lo suyo es ir mirando el registro de accesos y valorar quién es un cliente malo y quién uno bueno. Cuando se detecta un uso abusivo de recursos por parte de alguna IP o de algún cliente con un user-agent especial, se le manda a la lista negra y punto. Que no te dé ninguna pena.

Algunos robots malos a evitar...

Que conste que la lista podría ser mucho más larga (de hecho, la iré actualizando, supongo). Además, dependiendo de la temática, sitios que te enlazan, idioma y país, la lista podría cambiar drásticamente. Aún así, para España, lo mejor es denegar el acceso al menos a cualquier cliente cuyo user-agent incluya estos nombres. Ahí van algunos robots a banear:

  1. ahrefs: Coñazo monumental de robot. No para de acceder, sin descanso, a tus páginas web. En algunos casos, repite la misma petición una y otra vez ¿para qué? Supuestamente es el robot de una empresa de SEO, que no entiende que no es bienvenida si no pide permiso antes. También ofrece servicios a empresas para darles a conocer dónde y cómo se mencionan sus productos. A mí costa no van a hacer dinero, lo siento
  2. Dotbot: Recorre internet buscando webs de comercio electrónico para recoger precios y demás. No entiendo qué anda buscando en páginas que no son tiendas online
  3. Ezooms: no se sabe a ciencia cierta qué anda buscando, aunque algunos especulan que recoger información sobre uso de meteriales protegidos con copyright. No tiene dueño o autor confirmados, y encima hace peticiones absurdas al servidor, así que fuera de aquí
  4. URLAppendBot: Amazon lo bloquea en su nube por defecto; la compañía ofrece servicios SEO y buscan contenidos protegidos por copyright. No son bienvenidos tampoco
  5. SISTRIX: Otros consultores SEO que se vuelven muy pesados. La gente les tiene manía
  6. SEOkicks: Empresa alemana de SEO y análisis web a la que tampoco quiero ni en pintura
  7. 360Spider: Buscador chino (Igual que Baidu), que no banería si no fuera porque hacen demasiadas consultas seguidas. La verdad es que prefiero descargar el servidor un poco para que el resto de bots y usuarios tengan una respuesta más rápida

Además, yo tengo baneadas estas dos URL, de sendos SEOs y spammers: ¨"201.27.155.191" (SEO brasileño molesto), y "46.161.41.24" (spammer profesional).

La lista podría continuar, pero por ahora diría que ésos son los principales entes molestos.

 


Visto: 3296 veces   Compartir en Menéame Compartir en Twitter Compartir en Facebook Compartir en Delicious

Imágenes relacionadas:

Ese soy yo Pablito y Sophia Retrato de Sophia con Minolta XD-5 III Ese soy yo Yo en el fuerte español en Keelung
 #1 Avatar de jesus   jesus   26/03/2014 a las 03:28
Actualizado con ejemplos

 #2 Avatar de   Invitado: flavio   06/12/2016 a las 22:26
hola, Gracias por tu articulo fue muy claro, pero me quedo una duda, hola, en caso de que desee bloquear un subdirectoio, se aplcaría así?: Disallow: /Directorio/subdirectorio_bloqueado/ o así?: Disallow: /Directorio/subdirectorio_bloqueado o se debe usar otra mécanica??? Gracias y ojala puedas responder

 #3 Avatar de jesus   jesus   07/12/2016 a las 11:00
Hola flavio, gracias por tu pregunta. La web oficial usa esta nomenclatura: Disallow: /directorio1/directorio2/, con slash al final. http://www.robotstxt.org/robotstxt.html Saludos!


Aviso Legal Contacto Mapa del sitio Colabora Buscador Acerca de esta web Acerca del autor
DeSastreCajón, corriendo sobre jMVC