Estamos encantados de anunciar Advanced DNS Protection, un sólido mecanismo de defensa diseñado para proteger contra los ataques DDoS más sofisticados al DNS. Este sistema está diseñado para proporcionar una seguridad de primer nivel, y garantiza que tu infraestructura digital siga siendo resistente frente a la evolución de las amenazas.
Nuestros sistemas actuales han detectado y mitigado con éxito los ataques DDoS "más sencillos" contra el DNS, pero han tenido problemas con los más complejos. El sistema Advanced DNS Protection es capaz de subsanar esta carencia con el uso de nuevas técnicas que mostraremos en esta entrada del blog.
Advanced DNS Protection está actualmente en fase beta y está disponible para todos los clientes de Magic Transit sin coste adicional. Sigue leyendo para saber más sobre los ataques DDoS al DNS, cómo funciona el nuevo sistema y las próximas funciones.
Si te interesa, regístrate para saber más sobre cómo podemos ayudarte a garantizar la protección, la disponibilidad y la eficacia de tus servidores DNS.
Un tercio de todos los ataques DDoS tiene como objetivo los servidores DNS
Los ataques de denegación de servicio distribuido (DDoS) son un tipo de ciberataque cuyo objetivo es interrumpir y desactivar sitios web y otros servicios en línea. Cuando los ataques DDoS logran su objetivo de desconectar sitios web, pueden conllevar importantes pérdidas de ingresos y daños a la reputación.
Distribución de los tipos de ataques DDoS en 2023
Una forma habitual de interrumpir y desconectar un sitio web es inundar sus servidores con más tráfico del que pueden admitir. Esto se conoce como un ataque de inundación HTTP. Es un tipo de ataque DDoS que se dirige directamente al sitio web con una avalancha de solicitudes HTTP. Según nuestro último informe de tendencias DDoS, en 2023 nuestros sistemas mitigaron automáticamente 5,2 millones de ataques DDoS HTTP, lo que representa el 37 % de todos los ataques DDoS.
Esquema de un ataque de inundación HTTP
Sin embargo, hay otra forma de interrumpir sitios web, a través de un ataque indirecto. En lugar de inundar los servidores del sitio web, el ciberdelincuente inunda los servidores DNS. Si el servidor DNS se ve desbordado con más consultas de las que puede procesar, falla la traducción del nombre de host a dirección IP y el sitio web experimenta una interrupción infligida indirectamente porque el servidor DNS no puede responder a las consultas legítimas.
Un ejemplo notable es el ataque dirigido contra Dyn, un proveedor de DNS, en octubre de 2016. Fue un ataque DDoS devastador lanzado por la botnet Mirai. Causó interrupciones en sitios importantes como Airbnb, Netflix y Amazon, y Dyn tardó un día entero en restablecer los servicios. Eso es mucho tiempo para interrupciones de servicio que pueden tener un impacto significativo en la reputación y los ingresos.
Más de siete años después, los ataques Mirai y los ataques DNS siguen siendo increíblemente comunes. En 2023, los ataques al DNS fueron el segundo tipo de ataque más común, en concreto, representaron el 33 % de todos los ataques DDoS (4,6 millones de ataques). Los ataques lanzados por variantes de la botnet Mirai fueron el quinto tipo más frecuente de ataque DDoS a a la capa de red, de hecho, representaron el 3 % de todos los ataques DDoS a la capa de red.
Esquema de un ataque de inundación de consultas DNS
¿Qué son los ataques DDoS sofisticados al DNS?
La mitigación de ataques DDoS contra el DNS puede ser más fácil cuando existe un patrón recurrente en cada consulta, lo que se denomina "huella digital del ataque". Los sistemas de mitigación basados en huellas digitales pueden identificar esos patrones y luego implementar una regla de mitigación que filtre perfectamente los ataques de tráfico sin afectar al tráfico legítimo.
Por ejemplo, tomemos un escenario en el que un atacante envía una avalancha de consultas DNS a su objetivo. En este ejemplo, el atacante solo usó la dirección IP de origen aleatoria. Todos los demás campos de consulta se mantuvieron constantes. El sistema de mitigación detectó el patrón (el puerto de origen es 1024 y el dominio consultado es "example.com") y generará una regla de mitigación efímera para filtrar esas consultas.
Diagrama simplificado del concepto de huella digital de ataque
Sin embargo, hay ataques DDoS al DNS que son mucho más sofisticados y aleatorios, y carecen de un patrón de ataque aparente. Sin un patrón coherente que bloquear, resulta prácticamente imposible mitigar el ataque mediante un sistema de mitigación basado en huellas digitales. Además, aunque se detecte un patrón en un ataque sumamente aleatorio, probablemente el patrón sería tan genérico que mitigaría por error el tráfico legítimo del usuario y/o no detectaría todo el ataque.
En este ejemplo, el atacante también envió consultas al dominio consultado aleatorio en su ataque de inundación de consultas DNS. Simultáneamente, un cliente (o servidor) legítimo también está consultando "example.com". Se le asignó un número de puerto aleatorio que resultó ser 1024. El sistema de mitigación detectó un patrón (el puerto de origen es 1024 y el dominio consultado es "example.com") que solo detectó la parte del ataque que coincidía con la huella digital. El sistema de mitigación no detectó la parte del ataque que consultaba otros nombres de host. Por último, el sistema de mitigación detectó por error tráfico legítimo que parecía similar al tráfico de ataque.
Diagrama simplificado de un ataque aleatorio de inundación DNS
Este es solo un ejemplo muy sencillo de cómo la huella digital puede fallar a la hora de detener ataques DDoS aleatorios. Este reto se amplifica cuando los atacantes "blanquean" su tráfico de ataque a través de solucionadores DNS públicos de buena reputación (un solucionador DNS, también conocido como servidor DNS recursivo, es un tipo de servidor DNS que se encarga de rastrear la dirección IP de un sitio web desde varios otros servidores DNS). Esto se conoce como ataque de blanqueo de DNS.
Diagrama del proceso de resolución DNS
Durante un ataque de blanqueo de DNS, el atacante consulta subdominios de un dominio real gestionado por el servidor DNS autoritativo de la víctima. El prefijo que define el subdominio es aleatorio y nunca se utiliza más de una vez. Debido al componente de aleatoriedad, los servidores DNS recursivos nunca tendrán una respuesta en caché y tendrán que reenviar la consulta al servidor DNS autoritativo de la víctima. Entonces, el servidor DNS autoritativo recibe tal avalancha de consultas que no puede atender consultas legítimas, e incluso se bloquea por completo.
Esquema de un ataque de blanqueo de DNS
La complejidad de los ataques DDoS sofisticados al DNS reside en su naturaleza paradójica. Aunque son relativamente fáciles de detectar, mitigarlos eficazmente es bastante más difícil. Esta dificultad se deriva del hecho de que el servidor DNS autoritativo no puede limitarse a bloquear las consultas del servidor DNS recursivo, ya que estos servidores también realizan consultas legítimas. Además, el servidor DNS autoritativo no puede filtrar las consultas dirigidas al dominio objetivo porque se trata de un dominio auténtico que debe permanecer accesible.
Mitigación de ataques DDoS sofisticados al DNS con el sistema Advanced DNS Protection
El aumento de este tipo de ataques DDoS al DNS nos motivó a desarrollar una nueva solución, una que protegiera mejor a nuestros clientes y subsanara la carencia de los enfoques de huella digital más tradicionales. Esta solución es el sistema Advanced DNS Protection. Similar al sistema de protección TCP avanzada, es un sistema definido por software que nosotros desarrollamos, y funciona en nuestra plataforma de mitigación con estado, flowtrackd (flow tracking daemon).
Advanced DNS Protection complementa nuestro conjunto actual de sistemas de protección contra DDoS. Siguiendo el mismo enfoque que nuestros otros sistemas de defensa DDoS, el sistema Advanced DNS Protection también es un sistema distribuido, y una instancia del mismo se ejecuta en cada servidor de Cloudflare de todo el mundo. Una vez iniciado el sistema, cada instancia puede detectar y mitigar los ataques de forma autónoma, sin necesidad de ninguna regulación centralizada. La detección y la mitigación es instantánea (cero segundos). Cada instancia también se comunica con otras instancias en otros servidores de un centro de datos. Se comunican y comparten información sobre amenazas para ofrecer una mitigación integral dentro de cada centro de datos.
Capturas de pantalla del panel de control de Cloudflare que muestran un ataque DDoS al DNS que fue mitigado por el sistema Advanced DNS Protection
Juntos, nuestros sistemas basados en huellas digitales (los conjuntos de reglas gestionadas de protección contra DDoS) y nuestros sistemas de mitigación con estado proporcionan una sólida estrategia de defensa multicapa para protegerte contra los ataques DDoS al DNS más sofisticados y aleatorios. El sistema también es personalizable, lo que permite a los clientes de Cloudflare adaptarlo a sus necesidades. Revisa nuestra documentación para obtener más información sobre las opciones de configuración.
Esquema de los sistemas de protección contra DDoS de Cloudflare
También hemos añadido nuevos puntos de datos centrados en el DNS para ayudar a los clientes a comprender mejor sus patrones de tráfico y ataques al DNS. Estos nuevos puntos de datos están disponibles en una nueva pestaña "Protección DNS" (DNS Protection) dentro del panel de análisis de red de Cloudflare. La nueva pestaña proporciona información sobre qué consultas de DNS se aprueban y se descartan, así como las características de esas consultas, incluido el nombre de dominio consultado y el tipo de registro. También puedes obtener los análisis con la API GraphQL de Cloudflare y exportar los registros a tus propios paneles de control mediante Logpush.
Consultas DNS: cómo discernir lo bueno de lo malo
Para protegernos de los ataques DDoS sofisticados y sumamente aleatorios al DNS, necesitábamos decidir mejor qué consultas DNS tienen más probabilidades de ser legítimas para nuestros clientes. Sin embargo, no es fácil deducir lo que es legítimo de lo que podría formar parte de un ataque solo sobre la base del nombre de la consulta. No podemos confiar únicamente en los mecanismos de detección basados en huellas digitales, ya que a veces se producen consultas aparentemente aleatorias, como abc123.example.com, que pueden ser legítima. Lo contrario también es cierto. Una consulta para mailserver.example.com puede parecer legítima, pero puede acabar no siendo un subdominio real para un cliente.
Para colmo, nuestro servicio de mitigación basado en el enrutamiento de paquetes de capa 3, Magic Transit, utiliza el retorno de servidor directo (DSR), lo que significa que no podemos ver las respuestas del servidor DNS de origen para saber qué consultas son legítimas en última instancia.
Esquema de Magic Transit con el retorno de servidor directo (DSR)
Decidimos que la mejor forma de combatir estos ataques era crear un modelo de datos de las consultas DNS previstas de cada cliente, basándonos en un registro histórico que desarrollamos. Este modelo nos permite decidir con mayor confianza qué consultas son probablemente legítimas, y descartar las que pensemos que no lo son, protegiendo así los servidores DNS de nuestros clientes.
Esta es la base de Advanced DNS Protection. Inspecciona todas las consultas DNS enviadas a nuestros clientes de Magic Transit, y las aprueba o descarta en función del modelo de datos y de la configuración individual de cada cliente.
Para ello, cada servidor de nuestra red global envía continuamente determinados datos relacionados con el DNS, como el tipo de consulta (por ejemplo, el registro A) y los dominios consultados (pero no el origen de la consulta), a nuestro centro de datos central, donde calculamos de forma periódica los perfiles de tráfico de consultas DNS de cada cliente. Esos perfiles se distribuyen por nuestra red mundial, donde se consultan para ayudarnos a decidir con más confianza y precisión qué consultas son buenas y cuáles son malas. Descartamos las consultas malas y autorizamos las buenas, teniendo en cuenta la tolerancia del cliente a las consultas DNS inesperadas en función de sus configuraciones.
Cómo resolvimos los desafíos técnicos que surgieron al diseñar el sistema Advanced DNS Protection
Durante el desarrollo de este sistema, nos enfrentamos a varios desafíos técnicos específicos:
Tratamiento de datos
Procesamos decenas de millones de consultas DNS al día en nuestra red global para nuestros clientes de Magic Transit, sin contar el conjunto de otros productos DNS de Cloudflare, y utilizamos los datos relacionados con DNS mencionados anteriormente para crear perfiles de tráfico de consultas personalizados. El análisis de este tipo de datos requiere un tratamiento preciso de nuestras canalizaciones de datos. Para la creación de estos perfiles de tráfico, utilizamos tecnologías de muestreo en escritura y de tasa de bits adaptable para escribir y leer los datos necesarios, respectivamente. De esta forma, nos aseguramos de que capturamos los datos con gran precisión al tiempo que protegemos nuestra infraestructura de datos, y descartamos la información que pudiera afectar la privacidad de los usuarios finales.
Representación compacta de los datos de la consulta
Algunos de nuestros clientes realizan decenas de millones de consultas DNS al día. El almacenamiento de esta cantidad de datos sería prohibitivamente cara, así como su distribución en un formato sin comprimir. Para resolver este desafío, decidimos utilizar un filtro Bloom de recuento para el perfil de tráfico de cada cliente. Se trata de una estructura de datos probabilística que nos permite almacenar y distribuir de forma concisa el perfil DNS de cada cliente, y luego consultarlo eficazmente en el tiempo de procesamiento del paquete.
Distribución de datos
De vez en cuando, necesitamos volver a calcular y redistribuir el perfil de tráfico DNS de cada cliente entre nuestro centro de datos y cada uno de nuestros servidores. Utilizamos nuestro propio servicio de almacenamiento R2 para simplificar enormemente esta tarea. Con las sugerencias regionales y el dominio personalizado activados, habilitamos el almacenamiento en caché y utilizamos solo un grupo de buckets R2. Cada vez que necesitamos actualizar la vista global de los modelos de datos de clientes en todos nuestros servidores perimetrales, el 98 % de los bits transferidos se sirven desde la caché.
Tolerancia incorporada
Cuando se implementan nuevos nombres de dominio, nuestros modelos de datos no los conocerán de inmediato, porque nunca antes se han visto consultas con esos nombres. Esta y otras razones de posibles falsos positivos nos obligan a incorporar cierta tolerancia al sistema para permitir consultas potencialmente legítimas. Lo hacemos aprovechando los algoritmos del bucket de token. Los clientes pueden configurar el tamaño de los buckets de token cambiando los niveles de sensibilidad del sistema Advanced DNS Protection. Cuanto menor sea la sensibilidad, mayor será el bucket de token, y viceversa. Un bucket de token más grande proporciona más tolerancia a las consultas DNS inesperadas y a las consultas DNS esperadas que se desvían del perfil. Un nivel de sensibilidad alto se traduce en un bucket de token más pequeño y un enfoque más estricto.
Cómo aprovechar la red global definida por software de Cloudflare
Al fin y al cabo, estos son los tipos de desafíos que Cloudflare resuelve de forma excelente. Nuestros clientes confían en nosotros para gestionar su tráfico y garantizar la protección, la disponibilidad y la eficacia de sus propiedades de Internet. Nos tomamos esa confianza muy en serio.
El sistema Advanced DNS Protection aprovecha nuestra infraestructura global y nuestras capacidades de procesamiento de datos junto con algoritmos y estructuras de datos inteligentes para proteger a nuestros clientes.
Si aún no eres cliente de Cloudflare y deseas proteger tu servidor DNS ponte en contacto con nosotros. Los clientes de Cloudflare pueden activar los nuevos sistemas poniéndose en contacto con su equipo de cuentas o con el equipo de soporte de Cloudflare.