En octubre de 2016 una botnet llamada Mirai tumbó a Dyn, un gran proveedor de DNS, y con él a Twitter, Netflix, Reddit y decenas de sitios más. El ataque alcanzó un pico de alrededor de 1,2 Tbps — el mayor registrado en su momento — y el arma era casi cómicamente mundana: cámaras IP, DVR y routers domésticos secuestrados que aún funcionaban con las contraseñas de fábrica. Mirai merece estudiarse no como historia, sino porque todo lo que ataca internet hoy está construido sobre sus ideas.
Cómo funcionaba Mirai
- Escaneaba internet continuamente en busca de dispositivos con puertos Telnet abiertos (23 y 2323).
- Probaba 61 pares de usuario/contraseña por defecto codificados — los logins de fábrica de cámaras y routers comunes.
- Los dispositivos comprometidos se enrolaban como bots mientras seguían funcionando con normalidad, así que sus dueños no notaban nada.
- Un servidor de mando y control (C2) daba las órdenes: IP objetivo, duración, tipo de ataque y parámetros de paquete.
Por qué importó la publicación del código fuente
En septiembre de 2016 el autor de Mirai publicó el código fuente abiertamente — una decisión que convirtió una botnet en toda una familia. Una vez abierto el código, cualquiera podía construir sobre él, y lo hicieron: Masuta, Satori, Reaper y muchos otros siguieron. Los descendientes modernos combinan el escáner de Mirai con exploits N-day, así que ya ni siquiera necesitan contraseñas por defecto — un dispositivo al que se le puso una contraseña fuerte pero nunca se parcheó sigue siendo reclutable.
Código abierto, problema permanente
Mirai dejó de ser un único evento el día en que su código se hizo público. Las técnicas son ahora conocimiento básico para los atacantes, y por eso el tráfico de la familia Mirai es un zumbido de fondo diario en internet, no un titular.
La amenaza hoy
- Se proyecta que la base instalada de dispositivos IoT supere los 30 mil millones, en su mayoría nunca parcheada de forma significativa.
- Los mecanismos de actualización de firmware en routers y cámaras de consumo siguen siendo en gran medida no funcionales.
- Los ataques de variantes de Mirai son un suceso diario, no un evento raro.
- Gran parte de su salida es tráfico de HTTP flood — exactamente el patrón de peticiones automatizadas que un desafío de proxy inverso y los límites de tasa están hechos para filtrar.
Defenderse del tráfico de clase Mirai
No puedes arreglar los dispositivos IoT del mundo, así que la defensa está en tu lado del cable. Para la parte de capa de aplicación de un ataque de la familia Mirai — las inundaciones HTTP — un proxy inverso que desafía a los clientes automatizados, limita la tasa por IP y ASN y oculta tu origen convierte la inundación en un flujo de peticiones fallidas. Akarguard hace esto en el edge; el componente volumétrico en bruto se absorbe aguas arriba en la red. Asume que los bots de la familia Mirai están sondeando tus servicios expuestos a internet ahora mismo — la única pregunta que importa es si tu stack filtra su tráfico o se cae bajo él.