Análisis de arañas de spam en servidores web

Hola,

Al ver el artículo Search engines that are no search engines, se me ha ocurrido examinar el log de Apache del servidor que da servicio a este weblog.

El problema de los logs de Apache es que pueden ser voluminosos. En este caso, el log de acceso analizado es de 3,1 MB (contiene registros desde las 03:10:16 a las 09:54:32 del 13/Nov/2007) hasta pero aprovecharemos la línea de comando para reducirlo a la mímina expresión y facilitar el análisis.

cat log.txt | grep -v «Windows» | grep -v «Firefox» | grep -v «Mozilla» | grep -v «Opera» | awk {‘print $12 $13 $14 $15 $16 $17’} | sort | uniq >> lista_filtrada.txt

Con esta orden de bash, quitamos del log todas las líneas que tengan Windows, Firefox, Mozilla y Opera, que son los principales palabras clave referidas a navegadores. Existe riesgo de que perdamos alguna araña que opere falsificando su firma diciendo que es alguno de estos navegadores, pero es un riesgo menor. Algunas arañas legítimas se perderán, ya que Googlebot o Yahoo! Slurp operan firmando como Mozilla.

Una vez filtrada la lista, podemos seguir depurándola para hacer el análisis más fácil. Por ejemplo, podemos eliminar peticiones seguras y conocidas, como las de (Google Feedfetcher), o Bloglines.

El resultado es el siguiente:

De un simple vistazo podemos ver algunos bots, crawlers y fuentes de referers conocidos y confiables, ya que no provocan abusos. Nos pueden gustar más o menos, pero se portan bien. Siempre pueden ser restringidos a nuestro antojo.

Entre las arañas/bots/referers que han aparecido, pues hay de todo. Por ejemplo, tenemos un acceso de BD-Brandprotect, una empresa que hace vigilancia de imagen corporativa y phishing. Este bot analiza imágenes legítimas expuestas en otros servidores, indicio habitual de la presencia de phishing. Recordemos que la mejor manera de vigilar el phishing tradicional es leer nuestros logs de servidor Web, y si vemos que nuestras imágenes, css y contenidos están siendo invocados desde otro servidor que no es el nuestro, mal asunto.

Aparece por ahí Baidu, un buscador japonés, y son numerosos los lectores de feeds que han aparecido, lo cual es normal tratándose de un blog. Tenemos Liferea, Feedeye, Feedreader, Attensa, Feedeachother …

Esta información es buena para tener una idea general, pero no sirve para hacer un análisis serio de las peticiones desde servicios de spam y maliciosos.

Los malos de la película

Centrándonos en arañas, al igual que las hay legítimas y respetuosas, las hay maliciosas, inoportunas, consumidoras de ancho de banda y lo que es peor: su único objetivo es examinar nuestro sitio web para ver si es una fuente adecuada para, sobre todo, inyectar spam a diestro y siniestro, bien al sitio en sí, bien a los usuarios que publican sus direcciones de correo.

Me gusta la clasificación de Kloth.net, según la cual, los principales malos de la película son:

1. Rastreadores de cuentas de correo. Su razón de ser es obtener direcciones de correo, que como podéis imaginar, engrosarán listas de spam.
2. Agentes que hacen uso inadecuado de robots.txt, que son los que de una manera deliberada, recorren los directorios /disallowed que hayamos especificado.
3. Agentes que ignoran robots.txt, que se caracterizan por respetar el fichero en primera instancia, pero que luego ignoran la directiva Disallow de robots.txt
4. Agentes que no miran robots.txt, a los que les da igual 8 que 80. Registran los sitios sin tan siquiera leer el fichero de robots.
5. Rastreadores de libros de firmas, que se especializan en libros de visitas y firmas, para obtener direcciones de correo para spam. Suelen ser muy agresivos.
6. Chinese Spambots, nombre que se le ha dado a rastreadores que no suelen perjudicar a los sitios, porque están mal programados, o son pruebas de concepto de usuarios aspirantes a spammers que no llegan a la categoría de ignorantes.

Los hay de muchos otros tipos, como los especializados en blogs, que buscan formularios de comentarios para poder inyectar spam al vuelo. De todos modos, los principales son los descritos.

Análisis de bots maliciosos a través de registros de servidor Web

Lo primero es disponer de una lista de los agentes maliciosos por excelencia. Yo me he fabricado mi propia lista, tomando listas que hay por ahí curculando por separado. Mi propuesta es la siguiente:

Agentes maliciosos identificados por nombre de agente (Fuente: Invision)

Es conveniente consultar otros listados de agentes maliciosos identificados por comportamiento inadecuado, u otros listados que sean relevantes. Yo suelo fijarme en un top-ten de bad bots y su actualización.

En mi caso, obtenemos los siguientes resultados

1. Agentes maliciosos según Invision

Las cadenas de Invision pueden conducir a falsos positivos, ya que no son lo suficientemente concretas. Para intentar evitar errores, extraemos un listado de IPs que podrían ser potencialmente sospechosas.

clear
echo ————————–
echo LISTADO DE IPS SOSPECHOSAS
echo ————————–
for i in $( awk ‘{print $2}’ invision.txt); do
grep $i log.txt | awk ‘{print $1}’ | sort | uniq
done

Donde invision.txt es el listado de agentes según Invision, y log.txt es nuestro log de accesos de Apache. En mi ejemplo, aparecen 258 IPs que debemos investigar.

2. ¿Geolocalizamos?

Puede resultar útil para cazar cosas sospechosas.

clear
for i in $(awk {‘print $1’} ips_sospechosas.txt); do
echo $i | tr -d ‘\n’
/usr/bin/geoiplookup $i | sed ‘s/GeoIP Country Edition/ Geolocalizacion/’
done

En nuestro caso, el listado de países, tras aplicar la geolocalización y descartando las IPs no geolocalizables, es el siguiente:

3. ¿Alguna de esas IPs está bloqueada en listas de spam?

Lo ideal es casar la lista de IPs sospechosas con algún listado DNSBL de IPs habituales en el spam. La mayoría son gratuítas si las usamos vía web, y en consultas poco masivas, pero requieren ser compradas o licenciadas para disponer de los listados fuentes. Algunos recursos para tales fines son los siguientes:

Spamhaus Block List
SORBS DNSBL
Distributed Sender Blackhole List
Distributed Realtime Block List
Dynamic Realtime Blackhole List
Black-Hole DNS List for blocking Malware and Spyware
linux.ie: What is a DNS Blacklist?
Declude’s list of known DNS-Based spam databases
The 0spam DNSBL
Jørgen Mash’s list of DNSBL Databases

Nosotros usaremos una lista abierta, que tenéis en http://www.heise.de/ix/nixspam/nixspam.blackmatches

4. Finalmente, tenemos a los spammers identificados

Dependerá de la calidad de la lista negra que usemos y de la bondad del log de accesos de Apache el que cacemos a los spammers que merodean. La lista negra que hemos utilizado no es una lista especializada en agentes de rastreo maliciosos, así que siempre conviene analizar nuestros resultados con cautela.

En nuestro ejemplo real, han aparecido las siguientes IPs candidatas a ser fuente de spam:

125.245.81.226 es un proxy abierto según dnsbl.njabl.org.
207.248.40.20 está listada en el CBL (Composite Blocking List)
207.248.45.11 está listada en el CBL (Composite Blocking List)
213.162.200.19 está listada en el CBL (Composite Blocking List)
74.134.53.191 está listada en el PBL (Policy Block List)

5. Evaluación de la actividad de los spammers

– Geolocalización: KR, Korea, Republic of

125.245.81.226 – – [13/Nov/2007:05:29:39 +0100] «POST /wp/wp-comments-post.php HTTP/1.0» 200 0 «-» «Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)»

Este spammer ha conseguido meter un comentario de spam en el blog (un trackback, concretamente) empleando un proxy abierto.

* Acciones recomendables ante el evento: bloqueo de la IP mediante .htaccess

* Recomendable: Analizar si el agente Mozilla/4.0 debe estar en disallow en robots.txt

– Geolocalización: MX, Mexico

Proxy para minado de datos, sin actividad ni huellas relevantes (todas las huellas con agente Mozilla/5.0). 76 peticiones GET entre las 13/Nov/2007:04:37:58 +0100 y las 13/Nov/2007:04:52:48 +0100, lo que concuerda con una actividad normal de navegación. Un probable falso positivo.

– Geolocalización: MX, Mexico

Sin actividad ni huellas relevantes (todas las huellas con agente Mozilla/5.0). Similar al anterior. Falso positivo.

– Geolocalización: ES, Spain

213.162.200.19 – – [13/Nov/2007:08:40:35 +0100] «GET /wp/wp-includes/images/smilies/icon_smile.gif HTTP/1.1» 304 – «-» «Mozilla/4.0 (compatible;)»

Un caso de error 304 Not Modified sin la mayor trascendencia. Conviene nuevamente estudiar si el agente Mozilla/4.0 debe ser puesto en disallowed, aunque todo apunta a un falso positivo.

74.134.53.191 – Geolocalización: US, United States

74.134.53.191 – – [13/Nov/2007:04:02:19 +0100] «POST /wp/wp-comments-post.php HTTP/1.0» 403 201 «http://www.sahw.com/wp/archivos/2006/11/03/microsoft-firma-un-acuerdo-de-cooperacion-con-novell/» «Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; KTXN)»

Este spammer ha conseguido meter un comentario de spam en el blog (en el artículo que aparece) empleando un proxy abierto.

* Acciones recomendables ante el evento: bloqueo de la IP mediante .htaccess

* Recomendable: Analizar si el agente Mozilla/4.0 debe estar en disallow en robots.txt

Conclusiones

Como hemos podido comprobar, el spam tiene un origen claro, y ese no es otro que el rastreo de sitios web. Hay muchas más fuentes, pero nos hemos centrado en una de ellas, y hemos visto con profundidad cómo es posible identificar a los spammers en función a las trazas y pistas que nos dejan.

Como todo en esta vida, tomar decisiones sobre gestión de spam es un problema de coste-beneficio. En el caso de un blog personal, es mucho más rentable confiar en filtros antispam y en actuar manualmente cuando un spammer haga diana. Sin embargo, en un blog corporativo o en un blog comercial de amplio espectro, el riesgo reputacional puede hacer aconsejable que tomemos medidas adicionales, que se pueden basar, entre otras cosas, en el análisis proactivo de los logs del servidor.

Un saludo,