Los Web Scrappers o ladrones de contenido son un tipo de robot o crawler que indexa contenido recopilando información y artículos de otras webs para -generalmente- duplicarlo, añadiendo bloques de publicidad y lucrarse con el esfuerzo de otros (cosa que vulnera licencias, todo sea dicho).

Este tipo de técnicas habitualmente generan mucha controversia, ya que a algunas personas les parece totalmente lícito, mientras que a otras les parece una estrategia abyecta.

Entrando un poco más en este tema encontramos los llamados planetas, que no son más que (en ámbitos web) un sitio web que recopila a través de feeds RSS los artículos de diferentes blogs o webs (normalmente siguiendo una misma temática o criterio).

Es una idea genial. Hay multitud de planetas muy interesantes que personalmente sigo (aunque siempre suelo leerlos desde la página original). Sin embargo, hay varios puntos que considero importantes como no permitir comentarios en el planeta, dirigir al lector a la web original, no incorporar publicidad, citar la fuente de los artículos u otros detalles que estarían restando mérito al autor del escrito.

¿Cómo puedo localizar web scrappers?

Es un tema bastante complicado, pero vamos a intentar simplificarlo. Para «robar» contenido, un scrapper o robot spammer (emails, comentarios, trackbacks, ...) tienen que acceder al feed RSS (usualmente llamado index.xml), así que vamos a aprovechar esa acción para encontrarlos. Necesitaremos acceso a nuestro fichero de logs, generalmente access.log o access_log. Si tenemos acceso SSH a nuestro servidor, mejor que mejor:

Con este comando conseguiremos separar los accesos al feed RSS, obteniendo la IP y el User Agent, ordenándolo por número de accesos. Finalmente, obtendremos un listado de los 25 accesos más frecuentes.

Hay que hacer notar que del listado resultante, varios accesos serán de usuarios desde navegadores o agregadores como Bloglines o Google reader. Añadiendo el siguiente pipe al comando anterior podríamos filtrar la mayoría de agregadores, quedando:

Después de esto, obtendríamos -ahora si- un listado más aproximado de usuarios «sin identificar» y posibles scrappers. Hay que ser muy cuidadoso e ir investigando cada entrada. Una serie de consejos:

• Verifica las últimas entradas primero: La primera cifra que aparece es el número de accesos, o lo que es lo mismo, el usuario que más frecuente accede a tu feed RSS. Interesa descubrir quienes son estos individuos.
• No bloquees agentes como Googlebot o MSNbot: Los buscadores también acceden a tu feed RSS. Asegurate de excluirlos de tu lista.
• Comprueba las IPs o hosts sospechosos: En Whois DomainTools puedes comprobar las ips para saber si son spammers conocidos.
• Investiga el User-Agent: Busca por google, en nuestro diccionario de robots, crawlers y spiders o en sus comentarios.
• Ojo con los User-Agents «Java/x.x.x»: En la mayoría de los casos, son bots maliciosos.

Si no estás seguro de que el usuario que miras sea un robot, siempre podrías investigar más en tus logs a ver en que otras páginas ha estado, a parte del feed RSS:

Finalmente, echa un ojo al artículo bloquear con .htaccess para saber como bloquear a los posibles scrappers que hayas encontrado.

Cada vez que nosotros (o algún sistema) accede a una página web determinada, este acceso es registrado en un log, donde se guardan varios datos, entre ellos el User-agent, que no es más que una identificación del sistema para que los webmasters conozcan de quién se trata.

Pero como siempre, la ley hace la trampa, y muchos robots maliciosos pululando por la red. A continuación voy a crear un pequeño diccionario con los crawlers, robots y spiders más famosos, alguna referencia y una breve descripción.

Evidentemente faltan muchos, pero me he preocupado de poner los más comunes (al menos desde mi experiencia). Confío en ir ampliando el diccionario según lleguen webmasters interesados en el tema. ¡No duden en comentar para ampliar la lista!

El último día hablaba sobre las recomendaciones para robots y crawlers mediante el robots.txt. Este sistema es un conjunto de indicaciones para que los crawlers no se «pierdan» y sepan en todo momento por donde pueden y deben ir.

¿Qué es lo que ocurre? Que cualquier persona me puede indicar que debo y que no debo tocar en su casa, pero en todo momento yo tengo la opción de hacerlo, aunque no deba. De eso vamos a tratar en este artículo, ¿Que ocurre si llega un crawler «listillo» que pasa olímpicamente de las recomendaciones que le hemos hecho? Pues que lo echamos a patadas de nuestra casa... ;)

Existe un fichero en los servidores web Apache (la mayoría de los servidores), llamado .htaccess, en el que puedes incluir información de control para dictar al servidor que hacer con tus visitantes y otro tipo de acciones.

Lo primero que necesitamos es un sistema de estadísticas o mejor aún, acceso a nuestro fichero access.log, registro donde se guardan todos los accesos a nuestro servidor. En Dreamhost, el servidor donde tengo alojado mi blog (y uno de los más famosos), tiene acceso SSH/FTP y puedes ver sin ningún problema a estos registros.

Bien con un sistema de estadísticas, o con nuestro fichero access.log, nos interesa observar los accesos por petición (request), navegador o agente (user agent) o por ip. Desde una consola SSH podemos conseguir un listado de las IPs que más peticiones realizan:

Esta secuencia de comandos nos muestra las últimas 10.000 llamadas a nuestro servidor, agrupándolas por IPs y mostrando el número de peticiones realizado.

Esto nos servirá para tener una idea de que crawlers, robots o usuarios pueden estar sobrecargando nuestro servidor con demasiadas peticiones. Existe un programa bastante útil que yo utilizo para analizar los access.log, llamado Apache Log Viewer. La única y «minúscula» pega es que está en japonés.

  84 63.161.169.137
  85 crawl-66-249-67-236.googlebot.com
  91 81.177.8.166

Este no es un ejemplo real, pero imaginemos que esos son los resultados obtenidos. Tendríamos 84 peticiones de la IP que figura a su derecha. Si vamos a Inicio / Ejecutar / cmd y escribir nslookup IP podremos obtener el DNS inverso y saber a que compañía pertenece, o investigar un poco más con un analizador de logs o estadísticas y ver que accesos ha hecho.

¡Ojo! Que haga muchas peticiones no significa que sea un robot malvado. Puede que se trate de nuestro más fiel visitante o nuestro querido buscador de Google. Mucho cuidado con bloquear IPs sin pensarselo.

En mi caso resultó que la IP 81.177.8.166 realizaba bastantes peticiones, e investigando un poco más pude ver que eran a antiguos ficheros de un formulario que ya no existían. Probablemente un robot spam que sigue torpemente intentando enviar comentarios de SPAM, generando peticiones inútiles.

Si tenemos dudas la mejor opción es hacer un Whois y si nos parece que está realizando un ataque, enviar una queja al email de abuse del ISP que muestra en el whois.

Bloqueando por IPs

Si estamos completamente seguros de que la IP que hemos encontrado en nuestros logs nos está realizando ataques DoS o algún tipo de sobrecarga de peticiones, vamos a bloquearla. Para ello tenemos que editar el fichero .htaccess en la carpeta raíz de nuestro sitio vía SSH o FTP y escribir o modificar su contenido añadiendo:

Y no solo bloquear IPs, sino también rangos de IPs mediante sus clases: Deny from 81.0.0.0/8. Esto también es aplicable a crawlers que hemos añadido en el robots.txt y vemos días o semanas después (ojo, a veces no leen el robots.txt instantáneamente) que no hacen caso. Ahora toca que hagan caso a la fuerza mostrando un código de error 403 (prohibido) en lugar de lo que esperaban.

Bloqueando con SetEnvIfNoCase

Se nos plantea otra dificultad. Los robots que acceden ahora nunca tienen la misma IP, siempre son totalmente diferentes y sin relación:

• Bot 1: Su agente de usuario no varía, es Malvadobot/2.0.
• Bot 2: No tiene nunca el mismo agente de usuario, ni IP, pero accede siempre al fichero /sendemail.php, que no existe.
• Bot 3: Ninguno de los anteriores criterios es fijo, salvo que viene siempre (Referer) de la página http://www.spammers.com/.

¿Cómo los bloqueamos?

Con este código estamos identificando los criterios de los tres bots anteriores para asignarles una variable llamada spambot si casa con los criterios, y que si es así, bloqueará.

Bloqueando con ModRewrite

Existe otra alternativa para bloquear, que necesita el módulo mod_rewrite, y aunque se utiliza para reescribir direcciones, nos puede venir bastante bien para bloquear. Lo he dejado para el final, puesto que creo que es la alternativa más costoso en términos de computación, con respecto a los métodos anteriores.

En primer lugar activamos el motor del ModRewrite, y usamos los tres casos anteriores como condiciones con el RewriteCond. En caso de ser afirmativa, reescribimos mostrando un error 403, o también podemos usar un error 410 (Eliminado permanentemente) escribiendo [G] en lugar de [F]. En la página de documentación de ModRewrite hay mucha información para profundizar.

Ahora ya sabemos como bloquear. Hay que usarlo con mucho cuidado para no bloquear a usuarios legítimos y perder visitas.

El fichero robots.txt es un archivo de texto que dicta unas recomendaciones para que todos los crawlers y robots de buscadores cumplan (¡ojo! recomendaciones, no obligaciones). Pero comencemos por el principio.

Un crawler es un robot de una entidad (generalmente buscadores) que acceden a las páginas web de un sitio para buscar información en ella, añadirla en los buscadores, etc. También son llamados spiders, arañas, bots o indexadores.

Por ejemplo, Googlebot es el nombre del crawler del buscador Google. También existen otros como:

• Mediapartners-Google, que es el crawler que se encarga de revisar los anuncios de Google Adsense.
• Googlebot-Image, robot indexador de imagenes del buscador de Google.
• Slurp, crawler de indexación del buscador Yahoo!
• noxtrumbot, del buscador Noxtrum.
• Scooter, del buscador Altavista.

Y muchísimos más. Si establecemos un control en nuestro robots.txt, podremos conseguir una serie de beneficios:

• Impedir acceso a robots determinados: Puede parecer contradictorio, pero algunos crawlers no nos proporcionarán sino problemas. Algunos robots no son de buscadores, e incluso algunos robots no son ni amigos. Pero de eso ya hablaremos más tarde.
• Reducir la sobrecarga del servidor: Podrás controlar el flujo de algunos robots. Algunos de ellos son un verdadero descontrol de peticiones que pueden llegar a saturar tu servidor.
• Prohibir zonas: Nos puede interesar tener disponible una zona en nuestra web, que sea accesible para algunos, pero que no aparezca en buscadores.
• Eliminar contenido duplicado: Uno de los casos más importantes, que casi siempre es olvidado por los webmasters. Si eliminamos la duplicidad de contenido, los buscadores nos puntuaran muy alto, aumentando el flujo de visitas.
• Fijar mapas del sitio: También es posible acoplar un sitemap para indicar el buen camino a los robots.

¿Y entonces, que hay que hacer? Es muy sencillo.

Sólo tenemos que crear un fichero de texto robots.txt y comenzar a escribir en el. Partiré del siguiente ejemplo donde permitimos la entrada a todos los crawlers (igual que sin ningún robots.txt):

En User-agent debemos introducir el nombre del robot, y a continuación las rutas donde queremos prohibir que acceda. Algunos ejemplos:

• Disallow: / prohibe la entrada a todo el sitio.
• Disallow: /foro/ prohibe la entrada a los documentos del directorio foro.
• Disallow: permite la entrada a todo el sitio.

Es posible acumular varios Disallow bajo un mismo User-agent, pero no podemos utilizar varios User-agent encima de un Disallow. Bien, algún ejemplo:

Este código impide al crawler del buscador de Live (MSN) acceder a la página links.html, y las carpetas private y photos (y todo su contenido) de nuestro sitio.

Es posible ir acumulando reglas para distintos crawlers, formando un robots.txt más largo y completo. Cada vez que escribamos un User-agent deberemos dejar una linea en blanco de separación. Además, existe una ligera adaptación que permiten usar comodines ($ y *) en las rutas en algunos crawlers (sólo Googlebot y Slurp):

Se está indicando al robot de Yahoo, que no indexe los ficheros que terminen en .js (javascript), direcciones que empiecen por 2007 o 2006 (fechas), ni artículos con la palabra pagina (paginado de comentarios). Estos casos pertenecen a la idea de no indexar contenido duplicado.

En la mayoría de los blogs, puedes acceder a un mismo artículo por las direcciones:

• blog.com/articulo/titulo, la dirección principal.
• blog.com/2007/04/, el archivo del mes.
• blog.com/articulo/titulo/feed, feed RSS del artículo.
• blog.com/articulo/titulo/pagina/2, pagina 2 de comentarios.

Todo esto es contenido duplicado, una de las razones más importantes de penalización para un buscador, a no ser, claro, que te las ingenies para que sólo sea accesible desde una dirección. A la hora de ver los resultados te asombrarás lo bien que estarás quedando ante los ojos de Google, por ejemplo.

Si revisas estadísticas y demás, también puedes observar que a veces algunos crawlers «se pasan» revisando nuestro sitio, y funden a peticiones a nuestro pobre servidor. Existe una manera de tranquilizar a los robots:

Con esto le decimos al robot de noxtrum que espere 30 segundos entre cada acceso. Cuidado, porque Crawl-delay no lo soportan todos los crawlers (al menos MSNBot y Slurp si lo soportan, y Googlebot desde el panel de webmasters también).

Finalmente, podemos también incluir un mapa del sitio en nuestro robots.txt de la siguiente forma:

En RobotsTXT.org podrás encontrar documentación oficial si quieres profundizar y en esta búsqueda de Google encontrarás muchos robots.txt de ejemplo, incluso robots.txt optimizados para tu tipo de web. Además, también tienes un validador de robots.txt.

Recordar a todos que con el fichero robots.txt no podemos bloquear los accesos por «fuerza bruta». Robots.txt es una recomendación del webmaster a los buscadores, que como son «robots buenos», las seguirán al pie de la letra.

Existen otros «robots malos» (que buscan direcciones de correos o formularios para hacer SPAM) que no dudarán en acceder a los lugares que hayas prohibido si lo desean. Para bloquear estos, deberemos echar mano al fichero .htaccess, pero como decía Michael Ende, eso ya es otra historia...