¿Cómo se puede detener a un bot de AWS que envía 2 mil millones de solicitudes al mes?

• En la infraestructura de AWS surgió un problema inesperado de solicitudes web masivas
• Se reportó un aumento repentino del tráfico, de 200 millones a 2 mil millones al mes
• El análisis de logs confirmó solicitudes repetitivas desde un User-Agent específico
• Aunque se consultó al equipo de soporte de AWS, no se obtuvo una solución clara
• Surge la necesidad de evaluar varios métodos de bloqueo, como reglas de firewall, bloqueo por User-Agent, etc.

---

Introducción al problema

• Un usuario de AWS planteó una pregunta sobre un fenómeno en el que su servidor web recibió 2B (2 mil millones) de solicitudes durante un mes
• Estas solicitudes provenían de un bot que usaba un User-Agent específico y constituyen tráfico anómalo que no coincide con patrones normales de uso
• El aumento repentino del tráfico implica el riesgo de incremento de costos y sobrecarga del sistema

Análisis de la causa

• La mayoría de las enormes cantidades de solicitudes ingresaban desde rangos de IP sospechosos de AWS
• A través de los registros de acceso, se identificó que la causa era un bot o script específico
• Existe un patrón común en el User-Agent, por lo que es posible aplicar filtrado

Respuesta previa y limitaciones

• Aunque se consultó al equipo de soporte de AWS, no se recibió una medida decisiva
• Este tipo de solicitudes masivas tiene un alto potencial de provocar interrupciones del servicio y aumentar la carga de costos

Dirección de solución y puntos a considerar

• Se evalúa la necesidad de diversas políticas de bloqueo, como agregar reglas de firewall, bloquear tráfico según el User-Agent y aplicar una lista negra de IP
• A largo plazo, surge la necesidad de fortalecer el sistema de monitoreo de tráfico y diseñar un esquema de detección y bloqueo automático de accesos anómalos

[GN⁺]

Comentario de Hacker News

• Tengo experiencia probando redirecciones 30x, por ejemplo usando una respuesta 301 para enviar a archivos enormes alojados por empresas que no me agradan; si logras que esa instancia de AWS descargue 70 mil ISO de Windows al mismo tiempo, seguro se van a dar cuenta. Además, aunque no es tan fácil con Cloudflare, también se puede usar la llamada estrategia de “tar pit”: recibir la solicitud y luego enviar la respuesta un carácter a la vez, con 30 segundos de retraso por cada carácter. Con encabezados/respuestas de 10 KB por solicitud y 700 solicitudes por segundo, parecería que el servidor es absurdamente lento.
  • Si no te gusta una empresa específica como destino del 301, recomiendan poner algo como Amazon.
  • La estrategia de recibir la solicitud y responderla lentamente, carácter por carácter, parece justo lo opuesto a un ataque DDoS Slow Loris. Una explicación de ese ataque está disponible en Cloudflare; es decir, en vez de que el atacante use conexiones lentas, el defensor responde con conexiones lentas.
  • Como alternativa, también se podría redirigir con 301 a un sitio oficial del gobierno de .sg para que las autoridades locales se encarguen.
  • Señalan que el tráfico entrante en AWS es gratis, así que aunque el dueño de la instancia reciba una enorme cantidad de datos, AWS no le cobrará extra por eso.
• Otra opción es hacer que operar un bot claramente malicioso resulte caro en términos de recursos. Algo como un gzip bomb puede funcionar si el bot es vulnerable, pero incluso simplemente esperar unos 10 segundos antes de responder puede hacer que consuma unas 7,000 conexiones/puertos en el servidor del bot. La mayoría de los procesos de Linux no aguantarían eso y terminarían muriendo. Es fácil de implementar con nginx + mod-http-echo.
  • De hecho, hay gente que ya implementó esta estrategia; se puede ver en listas de user agents dentro de código open source, y la implementación en sí es muy sencilla. El código relacionado se puede revisar aquí.
  • Los clientes de AWS tienen que pagar por el tráfico saliente, pero también da curiosidad si habría una forma de hacer que AWS o Cloudflare nos envíen a nosotros tráfico voluminoso en sentido inverso.
  • Pasé por algo parecido. Sufrimos scraping malicioso repetido para extraer los precios de nuestro sitio, y como el catálogo tenía millones de productos, calcular los precios dinámicamente consumía muchísimos recursos. Una avalancha repentina de solicitudes casi dejó fuera de servicio a la infraestructura. Como defensa, intentamos etiquetar el tráfico spam para cachearlo sin afectar a los clientes reales, y además discutimos meter errores aleatorios en los precios para volver inútiles los datos. Al final terminamos trabajando con Cloudflare para bloquear rápido las solicitudes maliciosas, pero tomó tiempo y dinero. Sospechábamos que el atacante era un servicio subcontratado por un competidor, y fue frustrante que ni siquiera se acercaran a preguntar, aun cuando sí podíamos ofrecer una API formal. Antes parecía haber una mentalidad de “si tu sitio no aguanta el tráfico, es culpa tuya”, pero siento que hoy esa percepción cambió bastante.
  • Me pregunto si con ese método también se consumirían 7,000 puertos en mi propio servidor.
  • Pregunta si usar esa técnica no haría que en su propio servidor también se acumulen la misma cantidad de conexiones.
• Soy el autor principal de Anubis. Descubrí por experiencia que si configuras Cloudflare para devolver una respuesta HTTP 200, el bot deja de golpear una vez que recibe un 200.
  • Por cierto, parece que ahora mismo el sitio principal tiene algún problema.
  • También probé un método de cortar la conexión a la fuerza apenas se detecta en la capa de aplicación, y parece funcionar contra bots primitivos cuando la configuración del lado de Cloudflare se complica.
• Hace tiempo me pasó algo parecido en mi blog personal. Fue hace 7 u 8 años: de pronto el tráfico se disparó y pensé que algo se había vuelto viral, pero el patrón era demasiado mecánico y me pareció raro. Investigando, resultó que el bot/crawler de alguien estaba usando mi sitio como prueba para hacer scraping. Tras varios meses pidiéndoles educadamente que pararan y sin lograr nada, terminé redirigiendo ese bot a sitios porno aleatorios, y entonces el crawling se detuvo.
  • Este método es, en la práctica, de los mejores: redirígelos a lugares que no quieran ver en sus logs, o a sí mismos, o a su proveedor de servicios, o a contenido que no quieran.
• Otra forma de venganza bastante satisfactoria es devolver un 200 e incluir la cadena de prueba EICAR en el body para contaminar sus datos; ver explicación del archivo de prueba EICAR.
  • Como una especie de opuesto a un ataque SSRF, también sería divertido redirigir al bot a una API de metadatos de la nube para inducir llamadas a endpoints como <shutdown>. Incluso se podría incluir la cadena de prueba EICAR en la respuesta de redirección para activar también los sistemas automáticos de detección de seguridad.
• Si de plano no tienes por qué recibir tráfico legítimo desde AWS Singapore, otra opción es hacer blackhole a todo ese rango.
  • Se puede usar un WAF para descartar directamente esos paquetes; la función "block" de Cloudflare WAF sirve para esto.
  • Yo también hice algo así antes: el bot Byte Spider de Byte Dance raspó millones de imágenes, y al final hasta pedimos a Cloudinary que bloqueara ese user agent; al principio también bloqueamos por completo Singapore. Me da mucho coraje lo agresivas que son estas empresas de scraping para IA al operar sus bots. Haber usado un buen servicio como Cloudinary por lo menos nos ayudó a ahorrar costos, y hoy en día simplemente bloqueamos todos los bots de IA con Cloudflare.
  • Como referencia, los rangos IP por región de AWS se pueden consultar aquí.
• En 2018 pasé por algo similar, aunque en una escala mucho menor. Leía la lista oficial JSON de rangos IP de AWS y fabriqué una herramienta para bloquear esos rangos en Windows Firewall. La entrada de blog relacionada se puede consultar aquí, y el readme de la herramienta se puede ver aquí. Durante años funcionó bien como tarea programada en el servidor, aunque no estoy seguro de si todavía funciona hoy. Si a alguien le interesa, podría publicar el código o pasárselo a otra persona. Incluso implementarlo desde cero no debería ser tan difícil. Suerte.
• El regulador de telecomunicaciones de Singapur incluso prohíbe la posesión de pornografía, así que proponen responder a los bots maliciosos enviándoles softcore y al mismo tiempo reportarlos por correo al organismo y a AWS.
  • Cuando alguien causa daño de forma repetida en internet, usar las leyes de su país para responder suele ser lo más efectivo. De otras instituciones normalmente no se puede esperar gran cosa.
• Si le avisas a Cloudflare que ese tráfico es malicioso, pueden bloquearlo fuera de tu cuenta, de modo que no te cargue a ti en el conteo de tráfico.
• Tuve una experiencia parecida: pedían en masa un instalador de software de 80 MB. Redirigí las solicitudes ofensivas a un archivo llamado "please-stop.txt", y dentro del archivo expliqué el problema y pedí que se detuvieran; de hecho sí se detuvieron.