Récord en ataques DDoS
Recientemente se produjo un ataque DDoS de 1,3 TBps sin precedentes contra Github y, hace solo unos días los atacantes ya han batido ese récord con otro ataque de amplificación UDP Memcrashed, contra una compañía cuyo nombre no ha sido revelado.
También se sabe que los atacantes que están detrás de estos ataques DDoS están extorsionando a sus víctimas.
Acontecimientos recientes: GitHub ¿cómo se ha manejado el tráfico?
El pasado día 2 de marzo GitHub sobrevivió al mayor ataque DDoS hasta la fecha con un tráfico de aproximadamente 1,3 Tbps (Terabytes por segundo). El mayor ataque registrado anteriormente fue en 2016 cuando la botnet Mirai lanzó un DDos de 1,2 Tbps contra DYN DNS, tumbando su red, y gran parte de Internet junto a ella.
A continuación, Tanner Harrison, del equipo de soporte técnico de WatchGuard, ofrece más detalles sobre la causa de este ataque DDoS, además de aportar consejos sobre cómo se pueden evitar y soluciones para mitigarlos.
¿Cuál ha sido la causa de estos últimos ataques? ¿Ha sido este otro ataque de una botnet?
Un día antes del ataque, Akamai (el servicio de Inteligencia DDoS y Mitigación Cloud) descubrió un nuevo vector de ataque de reflexión DDoS que utiliza una nueva herramienta de red llamada memcached. Los ataques de reflexión utilizan tráfico UDP falso desde un servidor que aloja el servicio explotado para forzar el envío de datos a una víctima desprevenida. Los ataques de amplificación llevan el ataque de reflexión un paso más allá. El atacante activa un servicio UDP para enviar una gran cantidad de datos a la víctima, con solo un pequeño paquete enviado por el atacante. Este ataque de reflexión específico utiliza memcached para amplificar tamaños de paquetes, con el fin de inundar el sitio de destino con datos. El ataque es como otros ataques conocidos de reflexión y amplificación DDoS, como DNS, TFTP, LDAP, SNMP, BitTorrent, entre otros. La diferencia clave es la potencia de amplificación que ofrece memcached.
Imagen cortesía de Akamai.com
En un ataque típico de amplificación DNS, se verían factores de amplificación de alrededor de 100, mientras que con el de reflexión desde un servidor memcache se vería un factor de más de 50.000. Según la publicación del blog de Akamai sobre el ataque recientemente descubierto, es difícil determinar el factor de amplificación exacto:
“Cuando un sistema recibe una solicitud de obtención de memcached elabora una respuesta al recopilar los valores solicitados de la memoria, enviándolos por cable en un flujo ininterrumpido. Esta respuesta se manda al destino en múltiples paquetes UDP, cada uno de 1.400 bytes. Es difícil determinar el factor de amplificación exacto de memcached, pero los ataques generaron casi 1 Gbps por reflector. Otras organizaciones han informado de ataques de más de 500 Gbps utilizando la reflexión de memcacheed”.
¿Cómo se puede evitar esto?
La mejor forma de prevenir este tipo de ataque es asegurarse de que los reflectores potenciales (DNS, MemCache, TFTP, etc.), no estén expuestos a internet. De forma imperiosa, se anima a todos los administradores del sistema a deshabilitar el protocolo de memcache en cualquier servidor expuesto a Internet, o al menos bloquear el puerto UDP 11211.
Este ataque contra GitHub demuestra que tenemos que estar preparados para más ataques multi-gigabytes, tal como hemos visto con el protocolo de memcache y la botnet Mirai. Los administradores de TI deben planificar en consecuencia para mitigar estos riesgos.
Prevención y mitigación de DDoS:
- Utilizar firewalls on-premise o filtros de contenido
- Equipamiento especializado / balanceadores de carga
- Mitigación ISP
- Mitigación de terceros
También se recomienda bloquear el puerto 11211 para evitar que sus servidores se conviertan en un reflector.
Se puede implementar una solución de balanceo de carga para las conexiones ISP para que el tráfico fluya en un escenario de doble vuelta o de desbordamiento. Por lo general, se debería utilizar algún tipo de equipo para manejar la carga en el Boarder de la red. Hay que tener en cuenta que estos dispositivos no pueden manejar ataques de gran volumen (ataques con una gran cantidad de tráfico, como estos ataques de amplificación). Se producirá un cuello de botella en la red.
Los pasos 3 y 4, por lo general, se combinan. Para ataques a gran escala dependerá de la coordinación del ISP y un servicio de mitigación cloud de un tercero. Como Corey Nachreiner, CTO de WatchGuard, declara en su publicación en el blog Secpliticy: “Las soluciones DDoS híbridas o cloud manejan gran parte del ataque en sentido ascendente, distribuyen parte de la carga a través de una gran red distribuida y bloquean gran parte del tráfico incluso antes de que alcance sus puertas”.
Estas soluciones DDoS en la nube o híbridas tienen la infraestructura, el ancho de banda y los recursos disponibles para mitigar estos ataques.
