Durante el día de ayer, 1 de marzo de 2018, se produjo lo que hasta ahora ha sido el mayor ataque de denegación de servicio ditribuido (DDoS) de la historia. En este caso no fue la web de Trump o de la BBC como ha ocurrido en otras veces con algunas de esas declaraciones del Presidente de los Estados Unidos que se convierten en un flame. En este caso el ataque ha sido dirigido hacia GitHub.
Vamos por partes para los que no tengáis ni idea de quién son lo señores estos de GitHub y para los que no sepáis qué es una denegación de servicio distribuida y luego seguimos con la noticia.
GitHub
GitHub es un repositorio de código abierto para desarrolladores. Si eres desarrollador (antes se llamaba ‘programador’, pero somos muy 2.0) y quieres que el código que programas quede disponible al mundo para que pueda ser reutilizado y otros desarrolladores no tengan que programar lo mismo, o si tienes algún proyecto basado en software libre o simplemente por si quieres que la comunidad te ayude a revisar tu código, puedes darte de alta en GitHub. En este sitio se reúnen muchísimos proyectos de software libre que puedes bajar de forma gratuita y revisar, modificar o ejecutar. Y por supuesto es uno de los servicios de Internet que más tráfico tiene, millones de visitas cada día para subir nuevo código, actualizar código ya existente, hacer un backup de un proyecto aunque no sea público o descargar algún desarrollo. Y todo esto de forma gratuita. ¿A que el software libre es la bomba? Ya hablaremos otro día con más calma de qué es el software libre y por qué tengo el pingüino de Linux (Tux) tatuado en la espalda… literalmente.
¿Qué es una denegación de servicio?
Como su propio nombre indica, una denegación de servicio consiste en realizar muchísimas peticiones a un servidor de manera que alcancemos el número máximo de conexiones que permite ese servidor o consumamos todo el ancho de banda de su conexión a Internet, con lo que los usuarios reales no podrán conectar con el servidor. Es decir, como cuando has dejado la clave de tu Wifi por defecto (a pesar de que ya hemos comentado en alguna ocasión lo peligroso que es eso) y tienes a medio barrio conectado a tu Wifi, por lo que todo va muy muy lento. Se utiliza sobre todo a modo de protesta cuando algún servicio cambia su política o alguien hace algunas declaraciones escabrosas (lo que comentábamos antes de Trump).
Hay dos tipos de ataques de denegación de servicio: el DoS (Denial of Service) que es cuando un atacante tiene más ancho de banda que tú y simplemente se dedica a hacer muchas peticiones desde su ordenador hasta que el tuyo deja de responder porque no tiene más recursos o porque está consumiendo todo el ancho de banda. Y el DDoS (Distributed Denial of Service), que es cuando un atacante controla un montón de ordenadores o dispositivos conectados a Internet que hacen todos juntos una petición hacia tu servidor, por lo que no importa el ancho de banda que tengas ya que entre todos los ordenadores que te atacan logran tener más que tú. Este es el ataque más común hoy en día debido a la cantidad de ordenadores que hay conectados a Internet con algún tipo de malware o troyano instalado sin que su propietario lo sepa simplemente esperando órdenes del atacante. Os va a quedar muy claro con estas dos imágenes que utilizo en los cursos cuando hablo de esto. La primera imagen es un DoS y la segunda es un DDoS:
Y ahora que ya tenemos claros los conceptos, volvamos a hablar de la noticia.
DDoS a GitHub
GitHub sufrió ayer este tipo de ataques con un ancho de banda total de ¡¡¡¡1.35 Tbps (terabits por segundo)!!! ¿Y esta cifra qué significa? Para que os hagáis una idea, en mi casa tengo una conexión de 50 Mbps de Vodafone… 1.35 Tbps es igual a más o menos 1.415.577 Mbps, es decir, como si un atacante pudiera sincronizar 28.311 conexiones como la mía de casa para atacar todas juntas al mismo servicio. Brutal.
Pero este ataque no se realizó utilizando conexiones domésticas, sino que el malote consiguió sincronizar 100.000 servidores memcache conectados a Internet para reenviar a GitHub datos que ya tenían en caché, es decir, que ya habían sido enviados a GitHub y estaban ‘cacheados’ en memoria por si hubiera que volver a enviarlos, así se ahorra todo el trabajo de volver a cargarlos en memoria, por lo que el malote lo que hizo fue decirle a estos servidores que volvieran a enviar a GitHub todo ese código que ya enviaron en su momento. ¿Os imagináis la barbaridad de datos que son esos 1.35 Tbps?.
Lo sorprendente de la historia no es que sea el mayor de los ataques que hemos visto hasta ahora (que también), sino que GitHub ¡¡¡CONSIGUIÓ DETENERLO!!!. En menos de 10 minutos consiguieron descartar el tráfico bueno del tráfico malo y rechazar todo el tráfico proveniente de esos 100.000 servidores memcache a través de los cortafuegos y de desviar tráfico a servicios que filtran tráfico como Akamai (un servicio que sirve precisamente para eso, es capaz de distinguir el tráfico de usuarios reales del tráfico de atacantes y redirigir a los servidores reales de la empresa sólo el tráfico bueno).
El problema de este tipo de ataques es que no podemos hacer mucho para impedirlos. En el caso de GitHub consiguieron detenerlo porque estaban preparados para este tipo de ataques, seguramente por la experiencia (y por un buen análisis de riesgos), por lo que ya contaban con los cortafuegos adecuados y el contrato con la empresa de filtrado de tráfico, pero ¿qué pasaría si alguien decidiera atacar nuestra empresa o página web? pues seguramente no podríamos hacer mucho para evitarlo. Es más, con el dinero que lleváis en la cartera en este momento (yo ya estoy a final de mes (sí, ya sé que es día 2)) pero con 20 o 30€ sería posible contratar en la Darkweb (de la que ya hemos hablado) una red de máquinas infectadas que atacara durante 24 horas cualquier empresa que conozcamos. ¿Os imagináis si vuestra competencia decide atacaros justo cuando vais a presentar un nuevo producto? ¡el impacto podría hacer que fallara toda la campaña de presentación del producto! Por lo que debemos estar preparados e invertir en una buena infraestructura de servidores, cortafuegos y demás cuando de la disponibilidad de estos depende nuestro negocio.
Informe de GitHub: https://githubengineering.com/ddos-incident-report/