GitHub

Parece que nadie se dio cuenta. Ayer miércoles, GitHub, la web de alojamiento de proyectos y aplicaciones, fue víctima del peor ataque DDoS jamás registrado en la historia. Sorprendentemente, la plataforma fue capaz de mitigarlo en cuestión de minutos.

El pasado 28 de febrero, GitHub fue impactado con una cantidad monumental de tráfico: 1,35 Tbps (terabits por segundo) enviados a través de 126.9 millones de paquetes por segundo. El ataque DDoS provocó que el sitio web estuviera inaccesible de las 17:21 a las 17:26 UTC y de forma intermitente de las 17:26 a las 17:30 UTC, informó este 1 de marzo en su sitio web.

GitHub

Aunque algunos usuarios lo notaron, la página fue mejorando progresivamente hasta volver a la normalidad en cuestión de minutos. GitHub también aclaró que no fue comprometida la confidencialidad o integridad de la información que estuvo en riesgo.

Anteriormente, el ataque DDoS más grande registrado fue el sufrido por la empresa Dyn en 2016. El viernes 21 de octubre de ese año, un tráfico de 1,2 Tbps provocó la caída de numerosos sitios como Twitter, Reddit, Spotify y Paypal, entre otros. Aquel incidente fue causado por una botnet gigante que usó Mirai para aprovecharse de una vulnerabilidad existente en millones de accesorios, dispositivos y electrodomésticos que se conectan a la red o **Internet de las Cosas**.

El Internet de las Cosas fue usado para el último gran ataque DDoS y no podemos hacer nada para impedirlo

Sin embargo, este DDoS no utilizó ninguna botnet como en el caso de Dyn. A diferencia de un ataque de estas características, este tipo de ataques amplificados no requieren infectar ningún dispositivo con un malware. En cambio, se aprovecha de los servidores memcached, los cuales almacenan caché de todo tipo de datos para optimizar la velocidad de redes y sitios web.

Si bien estos sistemas de almacenamiento en caché de bases de datos funcionan para acelerar redes y sitios web, no están destinados a ser expuestos en internet público; es decir, cualquiera puede consultarlos, y ellos también responderán a cualquiera. Por eso, al encontrarlos, un pirata informático puede imitar la IP de la víctima y usarlos para enviar hasta 50 veces la cantidad de datos solicitados por la víctima.

De acuerdo con *WIRED*, hay alrededor de 100.000 servidores memcached, en su mayoría de empresas y otras instituciones, que actualmente están expuestos en línea al no tener protección de autenticación. Eso significa que un atacante puede acceder a ellos y enviarles un paquete de comando especial al que responderá el servidor con una respuesta mucho mayor.

GitHub: "No contaban con mi astucia"

¿Cómo es que GitHub pudo identificar y controlar el ataque DDoS en menos de 10 minutos? Dado que usan el servicio de mitigación de ataques DDoS Akamai Prolexic, pudieron tomar control de inmediato. En 8 minutos, *los hackers* se rindieron y finalizaron el ciberataque.

El sistema de Akamai presume estar diseñado para soportar ataques cinco veces mayores*. Por tal razón, la empresa de mitigación de ataques DDoS estaba confiada en que podría soportar los 1,3 Tbps. Sin embargo, nunca habían recibido recibido 1,5 Tbps de un solo golpe, admitió Josh Shaul, vicepresidente de seguridad web de Akamai a WIRED* horas después de que finalizara el ataque de GitHub:

> Modelamos nuestra capacidad basándonos en cinco veces el ataque más grande que internet jamás haya visto. Así que habría estado seguro de poder manejar 1,3 Tbps, pero al mismo tiempo nunca tuvimos un terabit y medio entrando de una sola vez. Una cosa es tener la confianza. Otra cosa es ver que realmente se desarrolle como tú esperarías.

Además de la infraestructura de defensa DDoS general de Prolexic, Akamai también implementó recientemente mitigaciones específicas para los ataques DDoS proveniente de los servidores memcached. Al final, GitHub salió bien librado porque estaba preparado, y nadie contaba con su astucia.

No obstante, este ataque DDoS sin precedentes pone de relieve los riesgos que implican los servidores memcached expuestos. Solo queda esperar que los dueños de este tipo de servidores expuestos tomen conciencia e implementen medidas para prevenir este tipo de ataques cada vez más frecuentes.