Se sabía que podría pasar y pasó, pero era previsible. Por eso GitHub sobrevivió al ataque DDoS más grande de la historia. Un ataque de denegación de servicio distribuido que alcanzó un pico de 1,35 terabits por segundo enviados a través de 126,9 millones de paquetes por segundo. Pese a ello, solo cayó diez minutos.
La buena noticia es que resolver una situación similar es posible, como demostró la plataforma; la mala es que estos ataques pueden repetirse a mayor escala si no se hace nada. La responsabilidad, en parte, es de muchos.
Grandes ataques DDoS anteriores como el sufrido por la compañía Dyn en 2016, el mayor registrado hasta entonces, que causó problemas en servicios como Twitter, Reddit y precisamente GitHub, entre otros, pueden quedar casi en anécdota en comparación con los que aprovechan el enorme poder de amplificación usado por el que conocimos ayer. Las cifras que se han proporcionado espantan.
El 27 de febrero, hace solamente tres días, los investigadores de seguridad de Cloudflare describieron un abuso de los servidores Memcached para amplificar ataques DDoS por un factor sin precedentes de 51.200. Se trata de máquinas con un sistema de caché distribuido que usan sitios como Reddit, YouTube, Twitter, Facebook o Wikipedia.
El abuso es posible debido a la implementación no segura del soporte para el protocolo UPD y la exposición a conexiones externas del puerto del mencionado protocolo, el 11211, en la configuración por defecto. Como en otros métodos de amplificación, los atacantes envían una pequeña solicitud desde una dirección IP falsa para obtener a cambio una respuesta mucho mayor.
En este caso, envían una petición al puerto 11211 utilizando una IP falsa que coincide con la IP de la víctima. Con solamente unos pocos bytes remitidos al servidor vulnerable, según los investigadores, reciben una respuesta miles de veces más grande. "Lanzar tal ataque es fácil", aseguran.
El conjunto de estos servidores no es vulnerable, pero muchos sí lo son. Aunque en Cloudflare solo vieron 5.729 direcciones IP únicas de máquinas Memcached cuando publicaron estos informes, aseguraban que Shodan informaba de 88.000 servidores abiertos. Otras fuentes elevan la cifra hasta los 100.000. Están distribuidos por todo el mundo, pero donde tienen una mayor concentración es en América del Norte y en Europa. Además, según Cloudfare, "la mayoría de los servidores vulnerables se encuentran en los principales proveedores de alojamiento".
Una día después de este anuncio, también hecho por otras firmas de seguridad como Arbor Networks, Qihoo 360 o Akamai, se produjo el ataque contra GitHub. Lo sorprendente es que a pesar de la magnitud, pocos se dieron cuenta de lo que estaba sucediendo. GitHub.com no estuvo disponible entre las 17:21 a 17:26 UTC y se registraron problemas intermitentes entre las 17:26 a 17:30 UTC. Ya está.
Después, todo volvió a la normalidad. Lo lograron gracias a la ayuda de su servicio de mitigación de ataques DDoS, precisamente la compañía Akamai, una de las que investigó sobre este tipo de abusos. Conocían perfectamente el problema.
"Dada la ampliación del ancho de banda de tránsito entrante a más de 100 Gbps en una de nuestras instalaciones, se tomó la decisión de trasladar el tráfico a Akamai, que podría ayudar a proporcionar una capacidad de red de borde adicional", explican desde GitHub.
Fue entonces cuando los especialistas de Akamai tomaron el control, explican, "filtrando todo el tráfico procedente del puerto UDP 11211, el puerto predeterminado utilizado por Memcached". Tras ocho minutos, los atacantes cedieron y el ataque cesó. "Modelamos nuestra capacidad basada en cinco veces el ataque más grande que internet haya visto jamás", dijo a Wired el vicepresidente de Seguridad Web de Akamai, Josh Shaul. Estaban preparados y ganaron.
Como decíamos al inicio, la buena noticia es que es posible detener estos grandes ataques. Si se está suficientemente preparado, claro. La mala es que pueden repetirse siendo todavía más grandes. Y no lo decimos nosotros, lo dicen los responsables de mitigar lo sufrido por GitHub. "Es muy probable que este ataque récord no sea el más grande en mucho tiempo", aseguraban ayer tras presentar los detalles de su actuación sobre el gran ataque DDoS.
Memcached puede tener oyentes UDP y TCP y no requiere autenticación. Como el UDP es fácilmente falsificable, hace que este servicio sea vulnerable a ser utilizado como reflector. Peor aún, Memcached puede tener un factor de amplificación de más de 50.000, lo que significa que una solicitud de 203 bytes resulta en una respuesta de 100 megabytes.
Además, según explican, muchas otras organizaciones vienen experimentado ataques similares desde el pasado lunes. Esto les hace pronosticar ataques potencialmente mayores en un futuro cercano.
Debido a su capacidad para crear ataques tan masivos, es probable que los atacantes adopten rápidamente la amplificación de Memcached como herramienta favorita. Además, como las listas de reflectores utilizables son compiladas por los atacantes, el impacto de este método de ataque tiene el potencial de crecer significativamente.
Que no sea así pasa por tomar precauciones a distintos niveles. La más inmediata, explican, es que "los proveedores pueden clasificar el tráfico del puerto de origen 11211 y evitar que el tráfico entre y salga de sus redes". Aunque tomar estas medidas dicen que llevará tiempo. Otra buena precaución a tomar puede ser deshabilitar el soporte UDP si no se usa, como sugieren desde Cloudflare. Esconder los servidores tras un cortafuegos también sería una buena y obvia idea.
Las soluciones al abuso de los servidores Memcached pasan también por responder desde ellos con un tamaño de paquete más pequeño que la solicitud como medida preventiva si no se puede dejar de usar UDP, arreglar los protocolos vulnerables y la posibilidad de suplantar las IP. Soluciones, como vemos, las hay. Falta que se implementen.
