Así se ha producido el mayor ataque DDoS de la historia

Todo sucedió muy rápido. El pasado 28 de febrero por la tarde, los servidores de GitHub, la plataforma web de proyectos colaborativos, dejaron de funcionar por completo entre las 17h21 y las 17h26, y lo hicieron de forma intermitente hasta las 17h31 cuando se restableció la normalidad. ¿Qué había sucedido exactamente? No era un problema técnico ni una saturación puntual de la red; GitHub había sufrido el mayor ataque por denegación de servicio (DDoS) de la historia, y los expertos han mostrado su preocupación al entender que puede volver a repetirse en cualquier otro servicio.

Más información

El Gobierno confirma un ciberataque masivo a empresas españolas

Petya, un virus más peligroso y sofisticado que WannaCry

Un ciberataque paraliza 16 hospitales de Reino Unido y les exige dinero

La plataforma estaba bien pertrechada y los sistemas de seguridad respondieron al mismo de forma ejemplar y con un impacto mínimo dadas las dimensiones del ataque: apenas diez minutos de desconexión, pese a tratarse de un bombardeo absolutamente indiscriminado mediante el cual se volcaron 126,9 millones de paquetes que alcanzaron la cifra récord de 1,35 terabits por segundo. Los ataque DDoS consisten en un acceso masivo y coordinado a una web o servicio que termina por no poder atender la súbita demanda y cae; este tipo de ataques son muy comunes y recordaremos el gran impacto que vivieron servicios como Twitter o Spotify en otro gran ataque que tuvo lugar en 2016 (este diario lo padeció igualmente en 2017).

¿Cómo se lleva a cabo un ataque DDoS? Por regla general, estos ataques suelen tener su origen en botnets -redes de ordenadores zombies (o infectados por malware) controlados en remoto, pero en esta ocasión, los atacantes utilizaron servidores Memcached de diversas entidades que, como explica a EL PAÍS Fernando Suárez, vicepresidente del Colegio de Profesionales en Ingeniería Informática, “no estaban convenientemente protegidos, permitiendo peticiones de cualquier origen”. El problema de este tipo de ataques es que no hay una infección como tal, sino que se basan en una vulnerabilidad del sistema, de la que todavía no hay una concienciación real: “La falta de concienciación y sensibilidad en la protección de los sistemas ya no solo es un problema para la compañía que carece de la misma, sino que puede suponer el origen de un ataque hacia otras instituciones”, explica.

Diez minutos no fueron prácticamente nada y de hecho, la mayoría de los usuarios del servicio no fueron conscientes del mismo (ni desde luego, de su magnitud). Sin embargo, los sistemas de seguridad de GitHub detectaron el ataque desde el primer momento: “Entre las 17h21 y las 17h26 identificamos y mitigamos un ataque significante DDoS”, explican en su blog. La respuesta no se hizo esperar y al ver que el tráfico generado por el ataque se disparó hasta en cincuenta veces el habitual, desde GitHub se tomó la decisión de volcar parte del mismo a servidores externos ubicados en Akamai, que aliviaron el atasco al tiempo que filtraban las fuentes maliciosas. Por poner un ejemplo gráfico, sería como abrir todas las hojas de las puertas de un estadio a la conclusión de un partido.

A las 17h31 cesó el ataque y la situación volvió a la normalidad, pero lo desmedido del mismo dejó hondamente preocupados a los expertos. ¿Puede volver a repetirse un ataque de estas características o incluso mayor? Suárez sostiene que sí: “Puede repetirse”, explica; “GitHub estaba preparado para este tipo de ataques, pero la mayoría de las entidades no lo están”. Este es el dato más preocupante, ya que un ataque por denegación de servicio no resulta excesivamente complejo ni caro para la entidad que desee derribar momentáneamente un servicio.

Sin embargo, la buena noticia la encontramos en la rápida reacción de los sistemas de seguridad de GitHub, que han demostrado sofisticarse a medida que aumentan los ataques. “Un ataque DDoS tarda como media una hora en ser detectado, lo que implica la presencia humana en la supervisión”, explica a Wired Alex Henthorne-Iwane, de la firma de seguridad ThousandEyes. “Cuando ves que la reacción y solución tienen lugar en menos de 20 minutos, quiere decir que ha sido gestionada mediante software, y esa es una gran noticia”.