El incidente en que mi gato me alertó de un ataque DDoS
(dannyguo.com)- En una época en la que no había una rotación formal de guardia, a las 3 de la mañana mi gato despertó a una persona dormida, lo que permitió revisar de inmediato una alerta de AWS CloudWatch y la caída del sitio web
- Después de una alerta de unhealthy targets del balanceador de carga, el sitio dejó de abrir, y estaban entrando grandes volúmenes de solicitudes desde muchas IP conectadas con varios países
- Como el producto solo se ofrecía a usuarios de Estados Unidos, el tráfico internacional era anómalo y, por el contexto, se trataba de un ataque DDoS
- Bloquear una por una las IP desde el servidor podía ser ineficiente, pero con una regla de bloqueo por país ya configurada en AWS WAF se bloquearon cientos de miles de solicitudes durante aproximadamente una hora
- Cerca del inicio del ataque, al buzón de soporte llegó un correo de amenaza que afirmaba haber detenido el sitio con una vulnerabilidad de Apache y exigía 5,000 dólares en Bitcoin; la empresa no respondió
La falla que salió a la luz a las 3 de la mañana
- En ese momento, la startup no tenía una rotación formal de guardia, y operaba con un esquema en el que el equipo vigilaba en conjunto las alertas urgentes
- Cerca de las 3 de la mañana, el gato me despertó al acicalarme el cabello, y al mirar el teléfono vi que unos minutos antes había llegado una alerta de AWS CloudWatch
- La causa de la alerta eran unhealthy targets del balanceador de carga, y el sitio web efectivamente no cargaba
- En el panel de monitoreo se veía un gran volumen de solicitudes provenientes de muchas direcciones IP vinculadas con varios países
- Como el producto solo se ofrecía a usuarios de Estados Unidos, ese tráfico internacional era distinto a lo habitual y, por el contexto, se concluyó que era un ataque DDoS
La avalancha de solicitudes que se frenó con AWS WAF
- La primera respuesta que vino a la mente fue bloquear direcciones IP a nivel de servidor, pero si el atacante podía usar más IP de origen, eso podía ser engorroso y de efectividad limitada
- Aprovechando que ya estaba configurado AWS Web Application Firewall, se añadió como respuesta inmediata a la caída una regla para bloquear solicitudes de otros países
- Tras aplicar la regla, durante aproximadamente una hora se bloquearon cientos de miles de solicitudes, y el sitio web volvió a funcionar
- Al detenerse también la avalancha de solicitudes, la falla inmediata quedó resuelta
El correo de amenaza que llegó justo después del ataque
- Esa mañana se revisó un correo que había entrado al buzón de soporte cerca del momento en que comenzó el ataque
- El remitente afirmaba haber encontrado una vulnerabilidad del sitio web y haber hecho fallar Apache, pero la empresa no usaba Apache
- Decía haber detenido todo el tráfico del sitio web y que podía mantenerlo así durante meses, y exigía 5,000 dólares en Bitcoin a cambio de entregar un “solution file”
- La empresa no respondió
- Como el teléfono estaba en modo No molestar durante la noche, no es correcto decir que la vibración o el sonido de la alerta de AWS despertaron primero al gato
- La persona cree que el gato somehow percibió que era algo que no podía esperar hasta la mañana, y considera que fue una forma de despertar mucho menos desagradable que una alarma de PagerDuty
1 comentarios
Comentarios de Hacker News
Como siempre, es fácil pasar por alto la amenaza interna. ¿Un correo de extorsión con gramática sospechosa? ¿Un rescate pedido en Bitcoin? ¿Nunca se les ocurrió que quizá el gato estaba detrás del ataque?
En Kansas no hay muchos terremotos, pero todavía recuerdo el primero y único que sentí.
Estaba profundamente dormido cuando mi gato siamés me despertó dándome golpecitos en la cara con la pata, y se sentó al pie de la cama gruñendo de una forma inusualmente agresiva.
En menos de 30 segundos empezó el temblor. No sé cómo lo supo, pero fue bastante asombroso. Se fue en 2020 y todavía lo extraño.
En el reciente terremoto de NYC también hubo videos de perros aullando antes de que la gente sintiera las vibraciones, y parece ser un fenómeno bastante común.
Cuando viví el terremoto de magnitud 7.4 en Taipei hace unas semanas, lo único que pensaba era que tenía que volver con mi perro, como le había prometido. Antes de irme, mi perro estaba inquieto; no sé si percibió que me iba o el terremoto hacia el que yo me dirigía.
En la roca hay dos tipos de ondas: ondas P y ondas S. Las ondas P son ondas de presión, por eso son más rápidas, y las ondas S se mueven de lado a lado y son un poco más lentas. Es muy probable que el gato se haya despertado por el siseo de las ondas P, que llegan un poco antes del terremoto que sienten las personas.
Que existen dos tipos de ondas y que las ondas P llegan primero se puede comprobar en https://manoa.hawaii.edu/exploringourfluidearth/physical/oce....
Puede que el teléfono estuviera en silencio, pero que la pantalla siguiera parpadeando. El mío se comporta así en ese modo.
En mi primer trabajo había una persona que se daba cuenta de las fallas en el dashboard de monitoreo antes de que explotaran. Ni él podía explicar o entender qué estaba viendo, ni los demás podían imitarlo, pero cuando decía que algo andaba raro, por lo general llegaba una alerta poco después.
Una vez leí sobre un supervisor de obra que se ganó el respeto de los trabajadores porque encontraba tuberías bajo tierra o dentro de las paredes con una habilidad anormal. Al principio empezó a creer que era un poder psíquico, pero después concluyó que había aprendido de forma inconsciente patrones típicos y algunas pistas poco intuitivas que aparecían de vez en cuando. Por ejemplo, ver un ducto de ventilación en la pared de un edificio y darse cuenta de que probablemente había una tubería de desagüe en el subsuelo.
Llegué a detectar con bastante precisión el punto de “este juego está por crashear, debería guardar”. Guardaba, reiniciaba 10 segundos después y efectivamente crasheaba; todavía no sé cómo lo sabía.
5,000 dólares suena a una suma bastante de príncipe. En 2016, en nuestra empresa también recibimos una exigencia así.
Sufrimos un DDoS y decidimos ignorarlo, aunque por si acaso investigamos un poco sobre BTC. Después gastamos mucho más de 5,000 dólares aplicando un montón de defensas contra DDoS, pero no pagarle al extorsionador vale la pena.
No respondimos a ninguno de los correos. Los atacantes también eran bastante tontos: solo atacaron el servidor web, que estaba en un lugar con buena conectividad.
El servicio que realmente generaba dinero estaba en el Caribe, con apenas un T1 de 1.5 Mbps y un respaldo satelital de 0.5 Mbps. Podrían haberlo saturado mucho más fácil y durante más tiempo, y eso habría implicado alrededor de 1 millón de dólares por hora en pérdida de ingresos.
Pagarle 5 mil dólares a un atacante puede parecer más barato que montar defensas, pero si tienes defensas, es más probable que recibas menos ataques en el futuro. Y, como dijiste, no darle dinero a criminales tiene valor en sí mismo.
Sobre la parte de “no respondí, pero mirando atrás habría sido divertido burlarme un poco”, la falta de respuesta es la única respuesta válida.
Si te burlas, podrías llamar más la atención y convertirte en objetivo de otros ataques. ¿Qué ganas con eso?
Aun así, imaginarlo era divertido, sobre todo después de ver este video enlazado en el artículo: https://www.youtube.com/watch?v=dWzz3NeDz3E.
Hace tiempo, alguien de mi familia se dio cuenta de que el lavavajillas perdía agua gracias a una alerta del gato.
La conclusión fue que el gato estaba intentando salvarnos, o intentando matarnos; una de dos.
Una persona que dormía al aire libre se despierta por el graznido de un cuervo, justo cuando un gran felino, probablemente un tigre, se estaba acercando sigilosamente.
Un personaje cree que el cuervo intentaba advertirle a la persona; otro cree que el ave le estaba avisando al tigre sobre la persona dormida para comerse las sobras después de la comida.
“Gramática horrible”, muy de la época anterior a ChatGPT
Hablando un poco más en serio, ¿algún día habrá una forma de detener para siempre los ataques DDoS? Todas las amenazas son malas, pero DDoS me parece el tipo de ataque más tonto. No requiere ninguna habilidad ni conocimiento especial: basta con ejecutar un script o pagarle a alguien que directamente lo ejecute por ti como servicio.
Las direcciones IP y, en IPv6, las subredes, son recursos limitados para los usuarios comunes; lo mismo pasa con el ancho de banda. La mayoría de los ataques de amplificación requieren suplantación de IP, algo que en conexiones normales muchas veces no es posible.
Si es un ataque basado en capacidad, gana quien tenga más ancho de banda. El atacante puede usar amplificación en ese caso. Si es un ataque basado en carga o de capa de aplicación, se puede resolver bloqueando las IP del atacante a nivel de firewall. En este caso ya había WAF/Cloudfront, así que no era un ataque puramente volumétrico, sino más cercano a uno de capa de aplicación.
Encontrar las IP atacantes que hay que bloquear es un problema de atribuir correctamente el costo por IP de origen y también atribuir correctamente, por IP de origen, el beneficio que representa la actividad de usuarios legítimos; luego bloquear las IP o rangos cuyo costo supere ampliamente el beneficio.
No es tan fácil como suena. El costo aparece de muchas formas: conexiones abiertas que ocupan memoria, handshakes TLS, solicitudes que al servidor web le resulta caro parsear, solicitudes que disparan consultas costosas a la base de datos, ancho de banda de entrada/salida, etc. Por eso la mayoría pone Cloudflare o, como aquí, Cloudfront al frente, y usa reglas manuales para sortearlo, como en este caso.
Sería genial que hubiera una forma de hacer que la capa de protocolo fuera resistente a DDoS, pero no sé muy bien si eso es posible.
Y también están los DDoS basados en capacidad. Esos se pueden bloquear si tienes más ancho de banda que todos los demás, pero es bastante difícil, y además te conviertes en un atacante potencial.
La innovación aquí es propagar filtros de tráfico mediante BGP. El enrutamiento nulo sería el producto mínimo viable: esta IP está siendo atacada, así que descarten el tráfico hacia ella lo antes posible. También he visto sistemas más precisos, como descartar UDP, descartar paquetes fragmentados o descartar paquetes entrantes y salientes de ciertos puertos UDP/TCP.
La mayoría de estos sistemas están diseñados para que las rutas especiales no se propaguen directamente más allá del par, aunque en algunos casos podría ser deseable que sí se propaguen.
Si la mayoría de tus clientes están en México y Canadá te lanza un DDoS que satura el enlace entre Canadá y tú, quizá no sea un gran problema. Siempre y cuando los routers de consumo del lado de México no intenten “ayudar” con ese cuello de botella de Canadá.
Pensé que habían conectado el comedero del gato a las alertas
De todos modos, qué lindo. ¿Cómo se llamaba el gato?
Se llamaba Bamboo. Lamentablemente murió de cáncer. Le puse así porque una de las primeras cosas que hizo después de adoptarlo fue intentar comerse mi maceta de bambú.
El comedero inalámbrico del gato dependía de Internet y, cuando no salió la comida, el gato fue a quejarse con el administrador.
Me recordó este libro: Dogs that Know When their Owners are Coming Home https://www.sheldrake.org/books-by-rupert-sheldrake/dogs-tha...
Bloquear DDoS con token bucket es tan fácil que, normalmente, la única vez que mi gato tiene que despertarme es cuando atacan mi Discord.
Parece más bien una forma de descartar, en el firewall o en el ingreso, los paquetes que generan carga excesiva antes de que lleguen al servidor de la aplicación.
Si un ataque tiene suficiente volumen de solicitudes de conexión o una cantidad suficientemente grande de direcciones IP únicas, igual puede sobrecargar el servicio.
El token bucket suele ser parte de una estrategia de resiliencia general, no una solución mágica que resuelva todos los problemas de denegación de servicio.