Cuando veo cosas como estas me saco el sombrero ante los rusos, son genios del spam, verdaderos maestros artistas del spam, virus, botnets, etc. El hecho es que desde hace algunos meses linuxito.com está siendo víctima de una nueva técnica de spam en los referals HTTP.



¿Qué son los referals HTTP?

Cada vez que se hace una solicitud (request) a un sitio, se incluye en el pedido un campo (header) llamado "referal" (es un error ortográfico del término referral), este campo posee la URL desde donde se originó dicha solicitud.

Veamos un ejemplo. Supongamos que abro un navegador y escribo "www.google.com" en la barra de direcciones. En esta solicitud, a uno de los servidores de Google, el campo "referal" está en blanco, ya que el pedido fue originado directamente por el usuario. A continuación escribo "hacking the system 4 fun" en la barra de búsqueda de Google y hago clic en el primer enlace, que me lleva al blog de Synflag: hackingthesystem4fun.blogspot.com. En esta segunda solicitud (también a servidores de Google, ya que está hospedado en Blogger), el campo "referal" será igual a "www.google.com" o algo similar (dependiendo de uestra localización geográfica). Esto se debe a que el pedido provino desde Google. De forma similar, si uno sigue un enlace a este blog, desde el blog de Synflag, el "referal" será "hackingthesystem4fun.blogspot.com".

De esta forma los webmasters pueden analizar desde dónde proviene el tráfico a sus sitios. Lógicamente, al ser información enviada desde los navegadores en los clientes (aunque se haga clic en un enlace, la solicitud se sigue originando desde el browser cliente), es muy fácilmente falsificable. Aunque en general se puede confiar en las estadísticas generadas por los referals, ya que se puede suponer que la mayoría de los usuarios no altera estos campos en las solicitudes.

Spam en referals: creía haberlo visto todo

Ahora bien, ¿este artículo no era acerca del spam? Entonces, ¿qué tienen que ver los referals con el spam? Bueno, resulta que los rusos (no sé si son exactamente los rusos quienes inventaron esta técnica, aunque varios de los dominios de spam en referals son de origen ruso, basta con hacer una búsqueda rápida en Google para comprobarlo) le encontraron la vuelta para enviar spam en referals. Es sencillamente brillante.

¿En qué consiste esta técnica? Consiste en explotar la curiosidad inherente en los seres humanos.

Al analizar el tráfico a nuestros sitios, un dato interesante es determinar desde donde llegan los usuarios. Además del tráfico proveniente desde motores de búsqueda y redes sociales, está el tráfico desde sitios que nos refieren (enlazan). Este incluso tal vez sea uno de los datos más importantes, porque es uno en los que se basa Google para determinar la importancia y posicionamiento de un sitio. Por lo tanto es importante conocer quiénes nos enlazan, determinar la calidad de los links, y saber qué artículos gustan más a las personas que nos puedan generar tráfico (a veces un artículo, tal vez mediocre para nosotros, le resulta interesante a la persona correcta: el editor de un sitio o blog mucho más importante que el nuestro).

Cada vez que descubrimos un referal nuevo en nuestras estadísticas, la curiosidad hace que visitemos el nuevo sitio que nos enlaza. Ya sea curiosidad, vanagloria, o tal vez para comprobar por qué nos enlazó y qué comentan sus usuarios de respecto a nuestro link. La cosa es que abrimos una pestaña y visitamos el referal. Y además es un comportamiento muy común los webmasters.

¡Basta ya de introducciones! ¿Cuándo llegamos a hablar de spam?

La cuestión es que a algún cerebro se le ocurrió inyectar referals para enviar spam a webmasters. ¿Cómo es esto? Simple. Se realizan miles de solicitudes a miles de sitios en Internet utilizando un referal falsificado, por ejemplo "BlackHatWorth.com". Entonces, cuando los webmasters analizan el tráfico a sus sitios, encuentran este nuevo referal y ¿qué hacen?: inmediatamente lo visitan para comprobar el nuevo link.

Generalmente el referal falsificado (en este caso "BlackHatWorth.com") termina redirigiendo a un sitio de compras en Internet (por ejemplo "aliexpress.com") utilizando un enlace personalizado que le genera ingresos por publicidad al spammer.

Esta técnica de spam es brillante por donde se la mire. Aunque, tiene un par de consecuencias graves. La primera es que, para que un referal quede en las primeras posiciones en la estadística de un sitio, se requieren entre cientos y miles de solicitudes (dependiendo del tráfico del sitio target) que pueden ser periódicas o en ráfaga. Lo que puede provocar desde una degradación del servicio hasta una denegación del mismo (DoS). La segunda, más grave desde mi punto de vista, es que el blanco de esta técnica son personas con un cierto nivel técnico que generalmente no son víctimas de spam o scams a través de otros medios (por ejemplo correo electrónico). Por lo que, más que para publicidad, puede ser utilizada para atacar individuos que administran sistemas.

Mi recomendación ("el que se quema con leche ve la vaca y llora") es que antes de seguir un nuevo referal (y sobre todo si es sospechoso) hacer una consulta DNS (con dig o netstat en GNU/Linux, netstat en Windows, drill en FreeBSD) y por qué no también un whois para tratar de determinar quién es el responsable por el dominio.

Otros dominios que se utilizan con este fin son:

Iskalko.ru
Lomb.co
Lombia.co
Econom.co
Darodar.com
ILoveVitaly.Com
Priceg.com

¿Cómo evitar estos ataques de spam en referals?

Lo que se puede hacer es denegar todos los accesos cuyo referal proviene de un dominio sospechoso.

Para implementar esta protección se puede utilizar un archivo .htaccess, en la raíz de nuestro sitio, que incluya las siguientes directivas de Apache:

SetEnvIfNoCase Referer BlackHatWorth.com spam=yes
SetEnvIfNoCase User-Agent BlackHatWorth.com spam=yes
SetEnvIfNoCase Referer Iskalko.ru spam=yes
SetEnvIfNoCase User-Agent Iskalko.ru spam=yes
SetEnvIfNoCase Referer Lomb.co spam=yes
SetEnvIfNoCase User-Agent Lomb.co spam=yes
SetEnvIfNoCase Referer Lombia.co spam=yes
SetEnvIfNoCase User-Agent Lombia.co spam=yes
SetEnvIfNoCase Referer Econom.co spam=yes
SetEnvIfNoCase User-Agent Econom.co spam=yes
SetEnvIfNoCase Referer Darodar.com spam=yes
SetEnvIfNoCase User-Agent Darodar.com spam=yes
SetEnvIfNoCase Referer ILoveVitaly.Com spam=yes
SetEnvIfNoCase User-Agent ILoveVitaly.Com spam=yes
SetEnvIfNoCase Referer Priceg.com spam=yes
SetEnvIfNoCase User-Agent Priceg.com spam=yes
Order allow,deny
Allow from all
Deny from env=spam

Para lograr una mayor protección, se pueden también bloquear las direcciones IP de los spammers:

Order allow, deny
Deny from 78.110.60.230
Deny from 193.227.240.37
Deny from 193.227.240.38
Allow from all

Actualización (7/9/2015). Recientemente descubrí que este ataque no afecta a nuestros sitios, el ataque va dirigido directamente a Google, y las peticiones nunca llegan a nuestros sitios. Por ende no tiene sentido aplicar las reglas de filtrado anteriores en la configuración de Apache/Nginx. Lo que hacen los spammers es tomar nuestro código de Analytics (públicamente accesible) y utilizarlo para atacar nuestra cuenta de Google Analytics. El ataque no nos afecta, sólo afecta a Google, y la consecuencia es que aparecen estos molestos resultados. Nada más que eso.

Existen muchas guías y tutoriales para configurar adecuadamente nuestra cuenta de Google Analytics y así evitar el referral spam.


Tal vez pueda interesarte


Compartí este artículo