Cómo Hostinger lidia con ataques DDoS

Cómo reconocer un ataque de denegación de servicio distribuido (DDoS) 

Para evitar un ataque, necesitas saber lo que viene en tu camino. Cuando detectas un intento de interrumpir el funcionamiento regular de un servidor, servicio o red objetivo al sobrecargarlo con tráfico no deseado, te enfrentas a un ataque de denegación de servicio distribuido (DDoS).

Un ataque DDoS intenta denegar el acceso a un servidor objetivo generando una gran cantidad de tráfico de Internet malicioso que abruma los recursos disponibles del objetivo. Implementamos soluciones de filtrado de tráfico para prevenir este tipo de ataques y garantizar el máximo tiempo de actividad.

Estamos constantemente mejorando nuestros servicios y renovando nuestros sistemas para mantenernos a la vanguardia. Hoy detallaremos cómo combatimos los ataques DDoS y explicaremos la configuración de nuestro filtro de tráfico Wanguard y la infraestructura general.

¿Qué aspecto tiene un ataque?

Aquí hay un ejemplo de la vida real de un ataque DDoS. Imagina 400 Mbps de tráfico UDP dirigiéndose a un VPS con un ancho de banda disponible de 100 Mbps. 

Resultados del tiempo de carga del sitio web de Jekyll simple:
Antes del ataque: 0.08 segundos.
Durante un ataque: 23.35 segundos (primer intento), 30.86 segundos (segundo intento).

Los ataques DDoS a menudo son difíciles de mitigar porque generalmente involucran botnets completos o múltiples dirigidos a ti. Una botnet consta de muchos sistemas infectados, por lo que luchar contra ella por tu cuenta, la mayoría de las veces, resultará inútil.

Cómo lidiamos con los ataques DDoS

Tenemos dos soluciones de mitigación de DDoS para hacer frente a los ataques entrantes en nuestra infraestructura: agujero negro activado remotamente (RTBH) y filtrado de tráfico.

El filtrado RTBH ofrece una forma de eliminar el tráfico no deseado rápidamente antes de que ingrese a nuestra infraestructura. Si bien este método protege eficazmente nuestra infraestructura como proveedor de servicios, evita que todo el tráfico nos afecte, algo que no es algo que prefieran nuestros clientes. Eventualmente, sus sitios web y VPS se vuelven completamente inalcanzables. Como resultado, los atacantes logran sus objetivos.

El filtrado de tráfico es la protección DDoS de siguiente nivel para nuestros servicios. Solo detiene el tráfico malicioso en lugar de dejarlo todo. El tráfico malicioso se identifica examinando los paquetes que fluyen a través de nuestra infraestructura. Los siguientes elementos de tráfico se inspeccionan en busca de patrones específicos: 

• carga útil del paquete
• Puerto de origen
• IP de origen
• Puerto de destino
• país
• y más

Este proceso de filtrado se realiza en nuestra infraestructura antes de que el tráfico llegue a nuestros servicios, por lo que nuestros clientes no tienen de qué preocuparse.

Filtrado de tráfico

Configuración

Hemos implementado filtrado fuera de línea para nuestra configuración. Dado que rara vez experimentamos ataques DDoS potentes, el filtrado en línea sería ineficiente en cuanto a la practicidad y el costo reales; en su lugar, tenemos el método RTBH para combatirlos. 

Nuestra configuración involucra instancias de filtro conectadas a conmutadores de columna a través de los cuales fluye el tráfico desviado. Usamos sFlows, que se envían desde instancias de columna vertebral a la instancia de filtro, para investigar y desviar el tráfico si es necesario. El tráfico limpio se reenvía a los conmutadores hoja, mientras que el tráfico malicioso se descarta en la instancia del filtro. Es importante tener en mente que los procesos de filtrado y desvío de tráfico están completamente automatizados. 

Si algún host de destino experimenta un pico de tráfico por encima de nuestros umbrales establecidos, anunciamos esa dirección IP a las espinas dorsales mediante ExaBGP. Cuando el tráfico llega a una instancia de filtro, examinamos los paquetes entrantes para identificar el patrón de ataque. Una vez completado, se agregan nuevas reglas al firewall, lo que evita que el tráfico malicioso llegue a su destino.

Hardware

Los elementos principales de los que depende el servidor de filtrado son la CPU y la NIC. Después de algunas pruebas e investigaciones, decidimos optar por lo siguiente:

CPU: Intel(R) Xeon(R) Silver 4215R a 3,2 GHz.
NIC: Intel XL710 (40G).

Durante un ataque DDoS con ~1,5 Mpps y 8 Gbps de tráfico, el uso de la CPU se ve así:

Automatización

Sería difícil administrar manualmente múltiples instancias de filtro en todos los centros de datos. Como resultado, toda la solución está completamente automatizada, desde la detección de ataques hasta la configuración del umbral. Actualmente, usamos Chef y Ansible para nuestra infraestructura como código (IaC). Cambiar umbrales u otras configuraciones para todas las instancias a la vez es tan fácil como cambiar algunas líneas del código.

Configuración

Aquí hay un adelanto de nuestra configuración:

Nuestra instancia debe poder enrutar paquetes entre interfaces, por lo que el reenvío está activo tanto para IPv4 como para IPv6. Dado que no tenemos rutas a través de interfaces utilizadas para el desvío de tráfico, debemos desactivar el filtrado de rutas inversas o establecerlo en “modo loose”, como lo hemos hecho, para que los paquetes que llegan a través de esas interfaces no se pierdan.

Hemos aumentado la cantidad máxima de paquetes en un ciclo de sondeo de NAPI (net.core.netdev_budget) a 1000. Como preferimos el rendimiento a la latencia en este caso, hemos configurado nuestros búferes de anillo al máximo.

Hemos estado ejecutando esta solución durante seis meses y podemos ver que estos pequeños cambios son suficientes para manejar cualquier ataque de las escalas anticipadas. No profundizamos en el ajuste del sistema ya que los valores predeterminados son razonables y no causan ningún problema.

A continuación, tenemos acciones. Una acción se activa cuando se detecta o finaliza un ataque. Lo usamos para desviar el tráfico (anuncio de ruta a través de ExaBGP), informar a nuestro equipo de monitoreo sobre el ataque (un mensaje de Slack de la instancia) y más.

Los umbrales también se administran como código, lo que brinda numerosas opciones para detectar un ataque. Por ejemplo, si detectamos 100.000 paquetes UDP por segundo dirigidos a un solo objetivo, iniciamos el proceso de filtrado. También puede ser tráfico TCP, solicitudes HTTP/HTTPS, etc.

Los prefijos que deberían estar bajo protección también se agregan automáticamente desde las bolsas de datos de Chef.

Resultados

¿Cómo se ve el manejo de un ataque DDoS en Grafana? Veamos un ataque reciente con 8 Gbps y 1 Mpps de tráfico a continuación.

Aquí está el tráfico entrante a la instancia de filtro:

Y aquí está el tráfico saliente al dispositivo final:

Paquetes entrantes por segundo:

Paquetes salientes por segundo:

Como puedes ver, hay una breve ráfaga de tráfico que va desde la instancia de filtrado hasta el dispositivo final. Es la brecha causada por el proceso de identificación del patrón de ataque. Es una cantidad de tiempo corta, generalmente entre 1 y 10 segundos, pero es algo a tener en cuenta. Como se ve en el gráfico, una vez que se identifica el patrón de ataque, ¡estás a salvo!

¿Qué pasa con la velocidad de detección de ataques? Esta parte depende de sFlows y, como sabemos, no es tan rápida como la duplicación de puertos. Dicho esto, es fácil de configurar, flexible y cuesta menos. Una vez que comienza un ataque, el tiempo para desviar el tráfico a la instancia de filtro demora entre 20 y 50 segundos.

Así es como se ve todo el proceso desde la instancia de destino:

Tráfico

paquetes por segundo

Hay un pico breve y volvemos a la normalidad. Dependiendo del servicio que estés ejecutando, es posible que ni siquiera lo notes.

En Hostinger nos gusta saber qué está pasando en nuestra infraestructura, así que investiguemos un poco más este caso:

Fuente de ataque. Notamos un aumento en el tráfico IPv4 de algunos países, siendo India y Taiwán los que más contribuyeron. Existe una gran posibilidad de que esas direcciones IP hayan sido falsificadas, por lo que esta información puede ser inexacta. Tenemos la lista de direcciones de origen y ASN, pero no la publicaremos aquí por el mismo motivo (suplantación de identidad).

Protocolo de ataque. Este ataque se basó principalmente en UDP, ya que no vimos aumentos inusuales en el gráfico TCP.

Tipo de ataque. Generaba una gran cantidad de tráfico a puertos UDP aleatorios. Algunos de ellos se ven en el siguiente gráfico:

Resumen

RTBH, como protección DDoS, es eficaz, pero eventualmente provoca tiempo de inactividad. Después de implementar la solución de filtrado de tráfico en nuestra infraestructura, solo eliminamos el tráfico malicioso en lugar de todo. Hemos notado que el uso de RTBH ha disminuido entre un 90-95%, ¡lo que se traduce en un mejor tiempo de actividad para nuestros servicios y clientes!