La semana pasada, como sabemos, tuvo lugar el ataque DDoS más grande que se recuerda. Este ataque afectó directamente a GitHub, un popular servicio para alojar desarrollos de software. En total el ataque fue de 1,3 Tbps. Superó al mayor ataque de este tipo hasta la fecha, contra DynDNS. Hoy nos hacemos eco de los aspectos técnicos de cómo resolvieron este problema.
Ataque DDoS contra GitHub
En un artículo anterior hablamos de los servidores Memcached y de cómo pueden utilizarse para realizar ataques DDoS. Vimos que esos errores que facilitan los ataques son muy frecuentes, por lo que podemos encontrarnos con casos similares. En el caso de GitHub, como podemos esperar, afectó a muchos usuarios. Algunos de ellos recurrieron a las redes sociales para informarse y poner su problema. Otros optaron por acudir a la página de estado de la web. Sin embargo la propia página de estado también se vio afectada.
Pero, por suerte, los sistemas de defensa de DDoS no tardaron en saltar. Hubo un primer ataque el pasado 28 de febrero. Sin embargo le siguió uno aún más fuerte solo un día después, el 1 de marzo. Los servidores volvieron a la normalidad solo 15 minutos después. Fue a través de los datos BGP como confirmaron que GitHub se encontraba ante un ataque DDoS. BGP es un protocolo por el cual se intercambia información entre sistemas autónomos (AS). Debemos recordar que BGP es un protocolo de enrutamiento dinámico de pasarela exterior, es decir, entre AS. Podéis visitar nuestro tutorial sobre qué es el ataque HTTP Request Smuggling.
Cómo resolvió GitHub el problema
En cuestión de minutos, fue introducido en el BGP para alcanzar al menos a cinco prefijos de GitHub. Según informan en ThousandEyes, todos sus monitores BGP vieron cambios de ruta. GitHub desvió sus rutas BGP a nuevas interconexiones desde sus principales ISP. Esto fue a través de Prolexic, una subsidiaria de Akamai y cuya función es la de intentar mitigar los problemas de ataques DDoS.
Gracias a este cambio en la ruta de BGP pudieron forzar todo el tráfico destinado a GitHub a través de los centros de depuración de Prolexic. De esta manera consiguieron absorber el ataque DDoS y mitigar el problema. Todo este proceso duró apenas 15 minutos.
Por tanto, GitHub fue bastante rápido y eficiente para resolver el que se considera como el mayor ataque DDoS de la historia. Rápidamente se activaron los mecanismos defensivos. Hay que añadir que, aunque el problema quedó resuelto en 15 minutos como hemos mencionado, todo el tráfico destinado a GitHub continuó pasando a través de los centros de depuración de Prolexic durante unas 6 horas.
En las siguientes imágenes podemos ver el momento en el que Prolexic se introdujo en la ruta AS y cómo se eliminó. También cómo se restauraron los servidores de GitHub. Una variedad son los ataques RDDoS.
Momento en el que introducen nuevas conexiones con Prolexic para mitigar el problema
El objetivo de un ataque DDoS es desbordar los recursos de una página. Con esto bloquean temporalmente el servicio. Atascan, literalmente, la capacidad para responder ante los usuarios. Es una técnica que lamentablemente está creciendo en los últimos tiempos. Es un problema al que tienen que hacer frente muchas empresas y sitios en Internet.
