Esta entrada está relacionada con una cuestión técnica, pero el causante indirecto es Kanye West, el esposo de la «influencer» (como dicen ahora), Kim Kardashian. Esta es una lección múltiple, primero porque veremos como puede afectar al hospedaje web un factor externo inesperado, también el poder que puede tener alguien con 98 millones de seguidores en Instagram, más de 50 millones de seguidores en Twitter y 30 millones de seguidores en Facebook, y por último, como una moda (de la que la mayoría no sabe ni su existencia), puede mover un mercado multimillonario.
Empezaré explicando como acabé metido en esto.
Alguien me llama para montar un servidor dedicado para una tienda web basada en Magento, esto no es nada especial, pero me dicen que la empresa que la está alojando en ese momento no consigue que se mantenga online, mi primer pensamiento fue, será que no saben lo que están haciendo, así que pedí las claves de root del servidor para analizarlo.
Al conectarme vi que, aunque efectivamente el que lo estaba administrando tenía algunas lagunas (esto se ve en cuanto faltan ciertos ajustes del kernel de Linux en sistemas con mucho tráfico), en realidad aquello no estaba tan mal instalado y el equipo era muy potente, pero efectivamente dejaba de responder en determinados momentos, algo que el administrador arreglaba a base de reinicios.
Hay que decir que Magento es una aplicación, en mi opinión, muy mal diseñada (lo mismo que Prestashop). Tengo pendiente una entrada sobre este tema así que lo dejo así de momento, pero baste con decir que los recursos que necesita para generar una página son absurdos, haciendo que su uso sin un caché sea imposible.
Con toda esta información en cuenta, me comprometí a hacer que la web funcionara (a veces me meto en unos líos tremendos, pero es mi trabajo), y dicho y hecho, a finales de 2016 el cliente me encargó el trabajo.
Como ya sabía que la cosa traería tela, les monté un servidor con doble procesador Xeon (32 cores), 100GB de RAM, discos SSD y una conexión de datos Premium multi-carrier, o dicho de otra forma un «pepinaco» de servidor. Instalé «las cosas», y lo puse en producción tras varios ajustes del kernel de Linux para optimizar el rendimiento al máximo.
Debo decir que estaba de lo más tranquilo hasta que el servidor empezó a ir lento, no era tanto como pasaba con el viejo servidor, que dejaba de responder, pero se saturaba. El caso es que las ventas de la web, aunque importantes, no justificaban el tráfico que estaba viendo, que era el equivalente a unos 20 millones de visitas, algo totalmente desproporcionado, así que empecé a analizar el tráfico (que es un trabajo ímprobo, pero necesario).
Vaya sorpresa me llevé al descubrir que había miles de conexiones por minuto desde IPs de varios centros de datos, de hecho, la gran mayoría del tráfico venía de centros de datos, no eran usuarios, así que analicé que estaban cargando desde esas IPs, fueron un par de días dándole duro al tcpdump y haciendo scripts en bash para filtrar los datos (esto sólo lo explico para que se vea que se un montón de administración de sistemas, por si algún reclutador IT de esos que me persiguen en Linkedin me quiere contratar XD).
Al final mi conclusión fue la siguiente (esto os va a encantar), estaban cargando cientos de veces por segundo las páginas que tenían las zapatillas de Kanye West que mi cliente vendía.
La páginas estaban desconectadas (devolvían error 404 o bien mostraban un producto agotado), pero esto le daba igual al o a los que estuvieran tumbando el servidor para cargar «nada», así que tenía que averiguar cual era la motivación de semejante comportamiento, que a todos los efectos se comportaba como un ataque de denegación de servicio.
Generar todo ese tráfico no es barato, si lo haces desde una botnet tal sea más barato porque es un acto ilegal que usa equipos comprometidos de terceros, pero desde IPs «consecutivas» de varios centros de datos es alguien gastando dinero para hacer esto desde redes de datos legítimas.
Así que llamé al cliente y le pregunté si alguien, que ellos supieran, podría querer tumbar su web… (cri, cri, cri), vaya, parece que les pilló por sorpresa.
Como un acto así tiene que tener una motivación (porque nadie gasta dinero por gastar), me puse a investigar cual podría ser el motivo, y lo descubrí…
El motivo es un mercado de 1000 millones de dólares para la venta de zapatillas deportivas de colección. Existe un mercado de cotización como el de la bolsa con una compraventa especulativa que cuando lo ves te deja sencillamente sin palabras. Existe mucha información sobre esto, pero visitando una sola página ya se puede uno hacer una idea, la página es «stockx.com».
Al parecer hay varios «indices de cotización», Jordan, Nike y Adidas. Las zapatillas no son para usar, sino un mero objeto de colección.
Me acordé entonces de un programa de «Pawn Stars» (traducido en España como «El precio de la historia»), un programa sobre una tienda de empeños de Las Vegas, donde la familia Harrison compra cosas de lo más raras. En ese programa en concreto alguien intentó venderles zapatillas Nike por valor de un millón de dólares diciendo que era una ganga, en su momento pensé que era una locura, pero viendo esto ya no me lo parece tanto.
El caso es que ya tenía un motivo. Las zapatillas de edición limitada de Kanye West que vendía mi cliente eran el motivo de que su web estuviera siendo atacada, los que estaban detrás de esas redes de datos, que recargaban las páginas millones de veces, querían detectar cuando se ponían a la venta para intentar comprarlas.
En el caso concreto de las zapatillas «Yeezy», hay muy pocas disponibles porque son ediciones limitadas, mi cliente me dijo que apenas tenían unos pocos pares y que normalmente se vendían en segundos.
La situación con estas zapatillas es tan rocambolesca que habían decidido sortearlas en vez de venderlas, así que realmente para comprar estas zapatillas en concreto ya no servía para nada intentarlo desde la tienda porque había que apuntarse al sorteo, pero los que habían programado aquel sistema de escaneado de la web no parecían estar al tanto de esto, simplemente cuando se producía un anuncio de disponibilidad de nuevas zapatillas en redes sociales, tumbaban la web para intentar comprarlas antes que nadie.
Solucionar esto pasaba por absorber un tráfico intenso, por ejemplo instalando algún servicio de tráfico descentralizado mediante un proxy (como Cloudflare), pero esto, me pareció un abuso para mi cliente. No tiene sentido tener que pagar más porque otros quieran aprovecharse de tu negocio, así que como ya había luchado antes contra este tipo de problemas (aunque no de forma tan grave), decidí abordar el problema usando otra estrategia (atentos reclutadores IT que aquí vais a flipar, podéis subir ya vuestras ofertas).
Lo primero que hice fue escribir reglas de filtrado para el IDS (Intrusion Detection System), este es un tipo de software que ejecuta una respuesta en reacción a unas reglas. El que usamos nosotros tiene ya escritas decenas de miles de estas reglas, pero ninguna para zapatilas deportivas, así que hice unas en las que la IP de cualquiera que tratara de cargar más de 3 veces la página de las Yeezy Boots de Kanye West, era bloqueada en el firewall.
Bueno, esto fue tremendamente efectivo, porque inmediatamente el servidor dejó de sobrecargarse, pero la gente que estaba detrás de esto no parecía dispuesta a rendirse y empezaron a hacer algo que sólo había visto en ataques desde botnets, empezaron a rotar las IPs.
Voy a hacer un pequeño inciso para explicar que es esto de rotar las IPs.
Cuando usando una red manejada por delincuentes (una botnet), quiere hacer un ataque por fuerza bruta, lo que hacen es intentar miles de veces contraseñas usando los llamados «ataques por diccionario». Esto consiste en probar contraseñas fáciles como «12345» o todo tipo de secuencias o palabras, partes del dominio de la víctima y otras combinaciones que la gente usa pensando ¿Quién va a querer acceder a mi web? (¡Sorpresa! si que quieren, y lo hacen, no uses esas contraseñas).
Lo que hacemos los administradores de sistemas es, como estaba explicando, usar reglas para bloquear estos intentos. En algunos gestores de contenidos como WordPress se puede instalar un plugin para hacer esto mismo, por ejemplo Wordfence, aunque en nuestros servidores tiene pocas ventajas porque ya hacemos desde el servidor las mismas comprobaciones y de forma mucho más rápida y efectiva.
Bueno, a lo que íbamos, el caso es que los que atacan los servidores no son tontos y usan contra-medidas a los IDS, la principal es ir rotando las IPs, algo contra lo que es muy difícil luchar si el que te ataca dispone de millones de IPs.
Así, en vez de intentar introducir miles de contraseñas desde una sola IP prueban una o dos desde cada IP (como si fuera un usuario legítimo). De esta forma las reglas del IDS no saltan, pero si tienes 10 millones de IPs y metes tres contraseñas desde cada una te da para 30 millones de intentos, aunque en realidad son más, porque al no hacer los intentos de forma consecutiva las pueden volver a usar ya que el IDS detecta los ataques desde cada IP en un periodo de tiempo, así que a todos los efectos en cuanto tienes unos pocos miles de IPs puedes hacer un ataque infinito sin ser detectado por el IDS.
Este mismo sistema es el que estaban usando para atacar esta web con una diferencia, las botnets usadas por delincuentes usan IPs de todas partes del mundo porque pertenecen a equipos comprometidos (máquinas infectadas con troyanos en su mayoría), pero quién estuviera detrás de estos escaneos ¿Tal vez algún «empresario» de la reventa de zapatillas?, estaba usando IPs consecutivas contratadas a varios centros de datos.
Este uso me permitió filtrar sus IPs por bloques enteros, por ejemplo (caso real), 104.166.64.1, 104.166.64.2, 104.166.64.3 … 104.166.64.255, están usando 255 IPs para cargar las páginas, al ser consecutivas se pueden filtrar todas enviando al drop este rango: 104.166.64.0/24
Al principio pensé que al filtrarles los primeros bloques desistirían, pero no, no lo hicieron.
Yo les bloqueada un rango y usaban otro. Al principio eran rangos de un proveedor de EEUU que se llama QuickPacket, LLC, pero cuando terminé por filtrar todo el centro de datos empezaron a usar otros. Al final terminé bloqueando decenas de miles de IPs de varios centros de datos (por increíble que pueda parecer), entre los que estaban todos estos…
- QuickPacket, LLC
- Alpha Geek Solutions, LLC
- Nobis Technology Group, LLC
- GHOSTnet
- Psychz Networks
- GCHAO LLC
- HostUS
- Voxility
- Colocation America Corporation
- Telebit Corporation
- Enzu Inc
- Ubiquity Server Solutions
- HOST1PLUS hosting services
- UK Dedicated Servers Limited
- Digital Energy Technologies Ltd
- Privax LTD
- BeastNode, LLC
- Areti Internet Ltd
En algunos de estos usaron tantos rangos de IPs que es imposible que fueran hackeadas así que evidentemente las estaban contratando. En cuanto filtraba un rango usaban otro.
No he podido saber si detrás de este comportamiento (que roza la legalidad), hay una sola persona o si son varias intentando lo mismo, pero llegado un momento empecé a detectar el uso de IPs desde varias universidades, algo que podría indicar el uso de recursos obtenidos de forma ilegal.
Los alumnos de las universidades pueden hacer un uso poco responsable de los recursos y es habitual que tengan equipos comprometidos, si este es el caso el uso es ilegal, aunque si fueron IPs contratadas creo que sería cuando menos poco ético.
El caso es que tras filtrar una veintena de centros de datos empecé a detectar tráfico desde varias IPs estas universidades cargando una y otra vez las mismas páginas de las zapatillas Yeezy:
- Universidad de Liverpool
- University of Stirling
- Columbia University
Llevo muchos años administrando servidores, en concreto hace 23 años que instalé el primer dedicado para correo (que tomen nota los reclutadores IT), pero nunca en todo este tiempo había visto algo tan rocambolesco.
Al final he conseguido que la web de mi cliente funcione bien, pero sigo detectando este tipo de escaneos de forma periódica. Aunque con mucha menos intensidad, no parece que estén dispuestos a cejar en su empeño, pero al menos los mantengo a raya con varios scripts que he escrito para analizar el tráfico.
Este caso, aunque extremo, no es único. Hay miles de bots escaneando nuestras webs con todo tipo de propósitos.
Enrique Dans, al que sigo hace años con interés, ha escrito varias entradas sobre esto de los bots, pero yo podría añadir algo más, en las webs que he analizado la mayor parte del tráfico provine de bots. He visto como en webs con miles de visitas tras hacer un análisis de tráfico resulta que apenas tienen unos pocos cientos de usuarios reales y este problema empeora cada día.
Este es uno de los factores que explica los CTR (Click Through Ratio), tan lamentables que tienen las campañas de anuncios en la mayoría de las webs, es porque los datos de tráfico están alterados por sanguijuelas que usan los recursos de nuestras webs para su propio beneficio, como el caso de las múltiples empresas de análisis de contenidos para vender servicios de marketing online (Majestic, Sistrix, Semrush, Ahrefs entre otras), bots buscando vulnerabilidades o haciendo ataques de fuerza bruta, y todo tipo de bots para propósitos de lo más diverso, que además, en su mayoría, desobedecen las instrucciones del famoso archivo «robots.txt» total o parcialmente, y esto incluye por ejemplo al bot de Microsoft (MSN Bot o BingBot), que lee las páginas a la velocidad que le da la gana, independientemente de lo que indique el propietario de la web. Parece que sólo Google mantiene un comportamiento ético en este sentido por lo que he podido constatar con mis pruebas.
Llevo casi cuatro años haciendo análisis de webs en producción y he desarrollado software para manejar el tráfico ilegítimo. Este software está en producción en uno de nuestros clientes, en el que hemos conseguido una mejora impresionante de los recursos necesarios para manejar su web, ahorrando miles de euros en costes del servidor. Así que este tipo de prácticas, contra las que incluso se está legislando en algunos sitios, produce costes reales e ilegítimos a los dueños de los sitios web de alto tráfico, encareciendo sin motivo real los costes operativos.
Deja una respuesta