Cloudflare Radar 2025: ¿Qué país tiene el Internet más rápido? ¿Cuál es el tamaño de los ataques DDoS en Internet? ¿Cuando de Internet va con IPv6? ¿Y con Cifrado Post Cuántico?

Ya os he hablado muchas veces de Cloudflare Radar, un servicio de Open Data que permite a cualquiera tener una foto de lo que está sucediendo en Internet. Saber cuándo se están produciendo ataques, cómo están evolucionando las tecnologías, los nuevos protocolos o la adopción de estándares de ciberseguridad. 

Con el comienzo del año, se publicó el informe de "Cloudflare Radar 2025: Year in Review", donde hay algunos datos muy interesantes, vamos a verlos.

Figura 1: Cloudflare Radar 2025: ¿Qué país tiene el Internet más rápido? ¿Cuál es el tamaño de los ataques DDoS en Internet? ¿Cuando de Internet va con IPv6? ¿Y con Cifrado Post Cuántico?

El primero de los datos que llama la atención es sobre cómo se ha expandido Internet, cómo ha aumentado el tráfico durante el año 2025, y que como podéis ver es casi del veinte por ciento. Un total del 19% de crecimiento sobre la base que ya teníamos.

Figura 2: Internet Traffic Growth

Sobre esto hay un dato que a los que somos de España nos hizo especial ilusión, ya que tienen que ver con la Calidad de la Conexión a Internet, y nuestro país es el Número 1 en velocidad de descarga y en velocidad de tráfico de subida, gracias entre otras cosas al despliegue masivo de redes de fibra hecho por las empresas de telecomunicaciones.

Figura 3: España es el país con mayor velocidad de descarga

Se miran cuatro parámetros, y España es el primero en velocidad de bajada y subida de Internet, y está entre los 10 primeros en latencia, por lo que probablemente tiene ¿el mejor Internet del mundo? Tal vez me esté dejando por la emoción un poco, pero reconocedme que es espectacular.

Figura 4: España es el país con mayor velocidad de subida

Otro de los puntos que también es de interés tiene que ver con cómo estamos evolucionando los protocolos core de Internet, como es el IPv6, donde el IPv6 Council lleva años trabajando, y ya estamos casi con un 30% de adopción. Poco a poco.

Figura 5: Adopción de IPv6

Por supuesto, otro de los temas de importancia es el de la adopción de Post-Quantum Cryptography, donde como sabéis Cloudflare juega un rol muy relevante, como os conté en el artículo de: "Cómo ser Quantum Safe y desplegar Post-Quantum Cryptography (PQC) con Cloudflare" En el año 2025 hemos conseguido alcanzar el 52%, lo que es un "milestone" a celebrar. Parece imparable.

Figura 6: Más de la mita del tráfico TLS está usando PQC

Por supuesto, aprovecho para recomendarte que, si quieres aprender de este mundo, te compres el libro de "Quatum Security: Tecnología Cuántica & Ciberseguridad. Criptográfica Cuántica y Post-Cuántica" donde hablamos de todo este mundo de Quantum Security para que te lo sepas de memoria.

Figura 7: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica. 

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

Pero si hablamos de ciberseguridad en Internet, hay que hablar de cómo han evolucionado los ataques de Denegación de Servicio Distribuida (DDoS), donde cada vez hay más ataques y más grandes, por eso hay que tomar soluciones grandes a grandes problemas.

Figura 8: Evolución de los ataques Híper-Volumétricos de Denegación de Servicio

El informe trata de muchos otros temas, por eso os recomiendo que entréis a revisar vosotros el "Cloudflare Radar 2025: Year in Review" pero yo he extraído algunos que me han llamado la atención, sobre todo con el mundo de la IA. 

Figura 9: Servicios de GenAI más populares

Los servicios de GenAI más populares en el año 2025, donde ChatGPT de OpenAI es el Número 1 y Claude de Anthropic el segundo, con Perplexity y Google Gemini cerca. Esa popularidad ha hecho que OpenAI se haya llevado no solo los datos, sino también el modelo de negocio de Ads de la web.

Figura 10: Ratios de Crawler-to-Refer en los diferentes bots

Como vemos en la gráfica de Crawl-to-Refer, los bots se están llevando los datos, entrenando los modelos y luego están enviando muy poco tráfico a las webs. Por eso como parte de AI Security Suite de Cloudflare en el Bot Framework se lanzó el servicio de Pay-Per-Crawl, ya que una vez recogidos los datos está devolviendo muy poco tráfico a las webs que generan el contenido. Y también a la creación de Honeypots con AI Labirynth.

Figura 11: Google Bot es el Verified Bot que más consume

Si miramos los bots que más tráfico generan, GoogleBot es el número uno. Es decir, es el que más tráfico genera y además envía mucho menos tráfico que Google Search, así que el desequilibrio es grande. En Radar tienes todos los detalles de los Verified Bots.

Figura 12: Países que generan más tráfico de Bots

La última de las gráficas que he querido dedicar tiene que ver con los países que más tráfico de bots generan, que tiene mucho que ver con la carrera por la construcción de la Súper Inteligencia Artificial de la que os hablaba el verano pasado.  Si podéis, echarle un ojo al informe completo de "Cloudflare Radar 2025: Year in Review" que os va a gustar, y encontraréis datos interesantes que os permitirán ver cómo se mueve Internet.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

¿Cuál es la mejor solución AntiDDos para defenderse de los Ataques DDoS en Internet?

Si eres un profesional del mundo de la Ciberseguridad, ya sea en el Blue Team, en el Red Team o directamente el CISO de una compañía, seguro que ya sabes la respuesta a esta pregunta, y sabes que Cloudflare tiene la mejor solución AntiDDoS en Internet por algo que es intrínseco a la arquitectura de la plataforma de la compañía, pero para los que no sabéis por qué, dejadme que os lo explique en un artículo cortito que va a hacer que lo entendáis e una forma muy sencilla.

Figura 1: ¿Cuál es la mejor solución AntiDDos para

defenderse de los Ataques DDoS en Internet?

Esta pregunta que os hecho en el título la podías responder sin necesidad de que yo escribiera este artículo, ya que si vas a cualquier lugar de Internet lo vas a encontrar de una forma u otra. Podéis preguntarle a cualquier buscador de GenAI, y si no os contesta que es Cloudflare, entonces es que no funciona y tienes que cambiar de buscador.

Figura 2: La mejor solución AntiDDoS hoy en día según ChatGPT

Como os he dicho, esta información es fácil de conocer, y cualquier CISO de una organización que tiene claro que perder su puesto de trabajo por que la solución AntiDDoS que ha implantado no proteja suficientemente sus activos, probablemente tiene Cloudflare como protección. Las grandes empresas digitales en Internet que basan sus ingresos en modelos de suscripción SaaS, pero la mayoría de los e-commerce que vemos hoy en día. 

Intensidad de los Ataques DDoS

La primera de ellas es la virulencia e intensidad de los Ataques DDoS que tenemos hoy en día, donde en Cloudflare se han detectado ataques de hasta 29,4 y 29,7 Tbs, que seguro que es un tráfico mucho mayor que el que soporta la conexión a Internet de todos los servidores expuestos en la red. 

Figura 3: Los ataques DDosS más grandes mitigados por Cloudflare

Y estos dos últimos han sido en este mes de Octubre, e indica que esto no va a parar, sino que va a seguir creciendo en intensidad. Así que, si tienes un activo en Internet que es la fuente de tus ingresos, y no estás protegido contra estos ataques que se ejecutan a nivel mundial, la cosa pinta mal.

El Edge como Superficie de Exposición

El segundo punto importante de por qué las soluciones AntiDDoS de Cloudflare son capaces de mitigar estos ataques se basan en varios conceptos que tienen que ver con el diseño de la plataforma en el Edge de Cloudflare, que desde el inicio está pensada para dotar de Seguridad y Alto Rendimiento a todos los servicios de Internet. ¿Cómo? Pues sencillo, con una red global de nodos en el Edge que forman una única plataforma.

Figura 4: La plataforma y la red de Cloudfalre en el Edge

Como podéis ver en la imagen, en Julio de este año, la capacidad de tráfico en el Edge que soporta la red de Cloudflare es de 405 Tbps, gracias a tener una red distribuida por más de 330 ciudades en el mundo en más de 120 países, lo que hace que tenga 3 veces más capacidad en el Edge que la suma de todos los otros proveedores AntiDDos. Pero es que está conectado a más de 13.000 redes directamente para lograr la distribución de tráfico más rápida en el Edge posible. Y es que la plataforma de Cloudflare tiene el Doble de Puntos de Presencia en Edge en el mundo a la suma de todos los demás proveedores. Vamos, Cloudflare es el "Big Gorilla" en el Edge.

Figura 5: Un Edge que se gestiona a escala global

Pero la magia final es que es una única plataforma mundial, que cuando detecta un ataque de DDoS, este es distribuido tanto en origen como de manera coordinada, para evitar que se pueda tumbar un PoP, haciendo que todos los nodos colaboren en las distribución del ataque. ¿Cómo? Pues gracias primero a la gestión de manera global del tráfico, y en segundo lugar, gracias al diseño de la red AnyCast de Cloudflare.

Una red Anycast para distribuir la superficie en el Edge

Cuando un servicio está publicado en Cloudflare, su dirección IP está distribuida de forma Anycast, o lo que es lo mismo, está en todos los nodos del Edge. Cuando un cliente se quiere conectar a esa dirección IP, la dirección está publicada en el nodo más cercano a la persona. Es decir, que las 12.000 redes a las que está conectado alguno de los PoP de Cloudflare, cada cliente tiene a unos 20 ms la dirección IP que busca, porque está en el nodo más cercano a él, igual que está en el resto de los PoPs. 

Figura 6: Diferencia entre Anycast & Unicast

¿Y qué efecto tiene en la protección AntiDDoS? Pues sencillo, supongamos una botnet que controla millones de dispositivos en Internet, y son utilizados para hacer un Ataque de DDoS contra una dirección IP de Internet. Este tráfico de ataque tendrá muchos orígenes distintos, y vendrá desde muchas redes distintas, así que si la dirección IP es una dirección IP Anycast en la plataforma Edge de Cloudflare, cada parte del tráfico de ataque se gestiona en un nodo diferente. Divide y Vencerás en la protección por diseño.

Figura 7: El ataque es distribuido en origen, y distribuido en destino

Después, si se diera el caso de que hay mayor impacto en un nodo en concreto del PoP, la gestión global de la red permite que parte de este tráfico sea redirigido a PoPs más cercanos sin pararse a limpiarlo, con lo que se el análisis del tráfico y su limpieza se comparte entre nodos más descargados. Y mientras tanto, el tráfico legítimo que ha sido limpiado es enviado correctamente al servicio que sigue funcionando.

Figura 8: La mejor solución AntiDDoS según Gemini, y las razones de por qué

Estas características únicas de la plataforma de Cloudflare le permiten a cualquier sitio de Internet protegido por los servicios AntiDDoS tener una superficie mundial de defensa. Y la magia se produce ya cuando, desde una de las herramientas de seguridad de la plataforma, ya sea WAF, DLP,  Cloud Access Security Broker, Bot Control, AI Audit, e-mail Filtering, Content Filtering, etcétera, da igual la que sea, la configuras, la aplicas, y en segundos está distribuida en todos los PoP del mundo. Único. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Exprimir el Secure Edge: Webinars de Cloudflare en Directo durante Septiembre

El calendario de actividades de divulgación tecnológica es alto en Cloudflare, y una de estas actividades son los Webinars en directo. Cada mes puedes participar en nuevos seminarios que además incluyen las novedades de todo lo que se va publicando en el modelo de Innovación Continua que defiende y practica la compañía.

Figura 1: Exprimir el Secure Edge - Webinars de Cloudflare

en Directo durante Septiembre

Hoy os traigo la lista de los que están planificados para este mes de Septiembre, para que si tienes tiempo, puedas participar en alguno de ellos que si te interesa el mundo de las tecnologías de seguridad en el Edge y los sistemas de Zero Trust en arquitecturas de Secure Access Service Edge (SASE), seguro que lo vas a disfrutar.

Todos los Webinars en Septiembre

09: From Robotics to Remote Access: Implementing Zero Trust in an Era of Evolving Threats

"Retailers are juggling managing vast amounts of customer data, payment information, and supply chain networks across multiple locations and platforms, traditional perimeter-based security models are proving inadequate against sophisticated cyber threats.Join us for our webinar featuring Ocado Group's Technical Architect as he shares their real-world Zero Trust Network Access (ZTNA) deployment journey. 

Figura 2: From Robotics to Remote Access: Implementing

Zero Trust in an Era of Evolving Threats

From securing robotic warehouse systems and customer fulfilment platforms to protecting proprietary technology solutions and sophisticated automation, discover how Ocado Group implemented Zero Trust principles across their entire technology ecosystem."

10: 3 phases, 10 steps: Implementing a SASE architecture

"Cloudflare experts will walk you through a proven 10-step roadmap to successfully implement SASE across your organization. Drawing from real-world customer examples, we’ll explore how leading enterprises are scoping their Zero Trust projects, overcoming common roadblocks, and unlocking measurable improvements in agility and security."

Figura 3:  3 phases, 10 steps: Implementing a SASE architecture

10: Securing and scaling your cloud environment to support AI transformation

"Even the most innovative and well-built AI application won’t succeed if it lacks the right underlying cloud infrastructure. The right foundation enables strong data security, efficient connectivity between AI components, and cost-effective scale. The wrong one turns those same benefits into obstacles. This is doubly true for agentic AI, whose complexity introduces a whole new realm of security and scalability issues.

Figura 4: Securing and scaling your cloud environment to support AI transformation

How should organizations adapt their cloud environments to support AI scale and security — whether they have already made cloud investments, or are turning to the cloud for the first time? Forrester guest speaker Lee Sustar has extensive experience advising enterprises on exactly that question. Join our webinar to learn about: Common trends and challenges in how organizations make AI-focused cloud investments Lee’s advice for organizations tackling these challenges Cloudflare’s perspective on how a commodity cloud vs a connectivity cloud delivers competitive advantage with AI scaling."

17: Modernizing Security: Real World Stories of Zero Trust in Action

"Employees, applications, and infrastructure exist everywhere today – across regions, cloud environments, and hybrid work settings. To manage this sprawling attack surface, many organizations are modernizing security with Zero Trust best practices to reduce risk, simplify their architectures, and enable business agility.

Figura 5: Modernizing Security: Real World Stories of Zero Trust in Action

In this webinar series, Cloudflare spotlights customers making progress on that journey. Register now to join a conversation exploring successful real-world deployments, including:Priority use cases to get started and scale with Zero TrustCommon challenges and best practices to overcome themArchitectural strategies and technical capabilities, including roadmap previews."

18: Temporada alta de fin de año 2025: Maximiza ingresos y minimiza riesgos.

"¿Está tu infraestructura digital lista para afrontar la temporada alta de ventas de fin de año 2025 y el aumento de ciber-amenazas?Únete a nuestros expertos de Cloudflare para conocer cómo fortalecer la resiliencia digital de tu negocio durante la época más exigente del comercio minorista.Compartiremos estrategias prácticas para retailers que se están preparando para los picos de tráfico del Buen Fin, Black Friday, Cyber Monday y la temporada navideña, en un contexto donde las amenazas evolucionan constantemente: desde ransomware que impacta operaciones e inventarios, hasta ataques dirigidos a APIs o páginas de pago.En esta sesión de alto impacto te mostraremos cómo proteger tus ingresos, reducir riesgos y asegurar una experiencia de compra fluida durante tus días más críticos.

Figura 6: Temporada alta de fin de año 2025: Maximiza ingresos y minimiza riesgos

Aprenderás cómo:Escalar sin fricción durante aumentos repentinos de visitas, donde cada segundo cuenta para convertirDefenderte de bots avanzados, ransomware y ataques DDoS que apuntan a los días de mayores ventasEvitar fraude digital, robo de datos de pago y abuso de APIs en plataformas de checkout, inventario y logísticaImplementar estrategias tecnológicas que prioricen al comprador real y aseguren la información del cliente."

30: How Cloudflare can coexist alongside Zscaler to fast-track your remote access project

"Are you worried about doubling down with the wrong security vendor? Maybe you are using one vendor (like Zscaler) for web inspections, but the thought of a full-scale SASE rollout seems overwhelming, complex, and disruptive. The good news is you can start modernizing remote access immediately, without those concerns.Join this webinar to discover how Cloudflare can strengthen and simplify security, while coexisting seamlessly alongside your web proxy from vendors like Zscaler.

Figura 7:  How Cloudflare can coexist alongside Zscaler

to fast-track your remote access project

In particular, our experts will show how to take advantage of clientless deployments of ZTNA, DNS filtering, and email security to improve your posture — all without installing additional software on devices.With demos, architectural walkthroughs, and real-world customer examples, you will learn:Use cases that deliver quick time-to-value with minimal disruptionStep-by-step technical guidance to run Cloudflare in parallel with Zscaler Recommendations on when a best-of-breed approach makes sense."

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Serverless & Bullet-Proof Web Sites (1 de 2)

En este artículo me gustaría contaros una pequeña PoC que hicimos en el equipo de Ideas Locas que teníamos guardada para algún evento de Web3, pero que como tengo ganas de contárosla, he decidido hacerlo desde hoy. No es un estudio completo, ni mucho menos, porque el escenario es enorme, pero se basa en un idea muy sencilla, que es hacer Serverless & Bullet-Proof WebSites, capaces de soportar el intento de bloqueo o censura de cualquier entidad.

Figura 1: Serverless & Bullet-Proof Web Sites (1 de 2)

Esto no es algo nuevo, y la Serverless Web lleva tiempo estudiándose, y trabajándose con diferentes arquitecturas, todas ellas totalmente distribuidas.

Dust-RSS

Uno de esos ejemplos fue un proyecto personal del equipo de Ideas Locas, en aquel entonces en Informática 64, en aquel entonces del año 2010, y que presentamos en la RootedCON de 2011 y se llamó Dust-RSS.

Figura 2: Dust-RSS en su presentación en RootedCON 2011

La idea era muy sencilla, evitar la censura de los servidores RSS de los blogs para permitir que cualquiera que tuviera algo que comunicar lo pudiera hacer siempre, y para eso diseñamos una arquitectura muy sencilla, basado en claves PGP y una red P2P para hacer la distribución. Esto hacía que no hubiera un único punto de fallo en el servidor web, ni en el DNS, y que con tener la clave pública PGP del publicador se pudiera buscar por redes P2P las publicaciones. 

Figura 3: Demo de Dust RSS funcionando

De esta forma, el publicador lo único que debía conservar era su clave PGP privada para poder poner en la red P2P una nueva publicación. La arquitectura funcionaba, pero se quedó en una PoC que presentamos en DefCON 2012, y que se quedó como un bonito experimento.

OSIRIS SPS

Uno de las arquitecturas que buscaba solucionar estos problemas de censura de servidores Web se trataba de OSIRIS SPS (Serverless Portal System) y su Gateway ISIS, para poder publicar servidores Web que no dependieran de un único punto de fallo. Para ello, la solución era similar a tener a páginas web cacheadas y compartidas por una red P2P.

Figura 4: Foro de Anime publicado en Osiris SPS visible vía Isis Gateway

Las páginas web de los portales que se ven a través de esas URLs realmente no están en ningún servidor web concreto, sino distribuidos por toda la red P2P de Osiris SPS, lo que impediría un bloqueo o censura del sistema. Es perfecto para crear foros y portales de denuncia social que no puedan ser quitados de Internet si no quieren sus usuarios.

DeepWeb: TOR, I2P, FeeNet, Hyperboria, CJDNS

Todas estas soluciones no accesibles a través de los navegadores de "superficie", son consideradas redes de la DeepWeb, no solo porque no son accesibles con las herramientas más comunes de Internet, sino porque además cuentan con herramientas y protecciones contra el control, ya sea cifrados especiales o como hemos visto, para evitar el bloqueo de sus contenidos, como en el caso de OSIRIS SPS o el sistema DUST RSS que utiliza mecanismos P2P para ello.  q

Figura 5: Libro de Deep Web: TOR, FeeNEt & I2P.  Privacidad y Anonimato 
de Daniel Echevarry a.k.a. "adastra" en 0xWord.

Por supuesto, muchas de las funciones de seguridad que se buscan en estas redes, están en las más conocidas de la DeepWeb como son  TOR, FreeNET e I2P, donde el cifrado de las comunicaciones es una de las claves en todas ellas.

Figura 6: Arquitectura de conexión CJDNS para la red Hyperboria

Pero la búsqueda de arquitecturas distribuidas y seguras ea algo que se ha estudiado mucho, como el caso de CJDNS y su red Hyperboria con conexiones cifradas y certificadas sobre IPv6, GNUNet, Lantern, YaCy para conseguir que no puedan ser accesibles los contenidos por nadie.

Malware en BlockChain

Por supuesto, pensar en arquitecturas Serverless y Distribuidas, es hablar del core de las cadenas de bloques de BlockChain, y utilizar las capacidades que tiene para poder almacenar datos de forma permanente y protegida con la distribución por diseño que tiene esta tecnología.

Figura 7: PoC de C&C con OP_Code en cadena de BitCoin

propuesta por Yaiza Rubio y Felix Brezo en EuskalHack 2017

En la EuskalHack del 2017, Felix Brezo y Yaiza Rubio hacían una demostración de cómo se podrían almacenar comandos de un C&C de una Botnet de malware en el campo OP_CODE la cadena de bloques de BitCoin.

Figura 8: Libro de "Bitcoin: La tecnología Blockchain y su investigación"
de Yaiza Rubio y Félix Brezo en 0xWord

Esto, al precio que está hoy el BitCoin parece un poco caro, pero esta idea de usar la cadena de OP_CODE para hacer servicios no es nueva, y algunos proyectos lo han utilizado en el pasado, aunque co la proliferación de cadenas de bloques a precios mucho más más económicos, hace que ya no sea necesario centrarse en ese campo.

Figura 9: Análisis del malware de Etherhiding

Y como muestra de esto lo hemos tenido con el caso del malware de Etherhiding, donde el binario del malware se han escondido dentro de la cadena de Binance Smart Chain, y ha utilizado SmartContracts para actualizarse.

Redes Sociales Descentralizadas

Por supuesto, la explosión de las cadenas de Blockchain, y otras arquitecturas distribuidas, hayan ido apareciendo en todos los verticales tecnológicos nuevos servicios que pretenden ser más resistentes contra los ataques a servicios descentralizados, como son las Redes Sociales.

Figura 10: Yo tengo mi curenta en Mastodon

Ahí, propuestas como Mastodom, Diaspora, Matrix, Block Square, que son sólo una pequeña muestra, han ido apareciendo por todos los rincones de Internet, y se han convertido en parte de la transformación y disrupción que se está viviendo en este mundo de las redes sociales.

Figura 11: Red social Diaspora 

Pero la descentralización de todos los servicios digitales que se están construyendo hoy en día. Algunos que se han hecho piezas fundamentales en las arquitecturas Web3, como el almacenamiento IPFS (Inter Planetary File System) del que ya hablamos.

Y esto nos lleva a nuestra PoC, que es cómo aplicar todas las arquitecturas al servicio fundamental de la web, y que como veremos es rápido y sencillo, pero será en la segunda parte de este artículo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo funcionan los ataques de DDoS usando "Amplificación DNS" con consultas tipo Root sobre UDP y cómo fortificar el servicio

El uso del protocolo UDP (User Datagram Protocol) para el envío de consultas DNS posibilita el utilizar este servicio para realizar ataques distribuidos de denegación de servicio (DDoS) hacia otros servidores en Internet. Uno de los ataques principales, basado en DNS, es el ataque de Amplificación de DNS o DNS Amplification utilizando consultas de tipo root falsificando la dirección IP de origen, es decir, haciendo un IP Spoofing en el paquete de DNS Request.  

Figura 1: Cómo funcionan los ataques de DDoS usando "Amplificación DNS" con consultas tipo Root sobre UDP y cómo fortificar el servicio

Este tipo de ataques se conocen hace tiempo, y los hemos visto migrados a otras plataformas como LDAP, donde se pueden dar los Ataques DOS con CLDAP (Connectioless LDAP) Amplification, que funciona de forma muy similar. Esto hace que tanto los pentesters y auditores que buscan vulnerabilidades, como los administradores que buscan fortificar los servicios, deban tener en cuenta este tipo de ataques. En FOCA, una de las cosas que miramos es la seguridad de los servidores DNS, ya implementamos hace tiempo otras técnicas como DNS Cache Snooping son también muy útiles en ataques contra infraestructuras empresariales.

Figura 2: Pentesting con FOCA Silver Edition

La principal debilidad en el servicio DNS frente a este tipo de ataques de amplificación tiene su causa en el uso principal del protocolo UDP (User Datagram Protocol) para realizar las consultas DNS. UDP es un protocolo a nivel de transporte donde prima la velocidad de la transmisión y sobre el cual se envía y recibe la información sin que se haya establecido previamente una conexión y sin confirmación ni control de entrega/recepción. 

Figura 3: Ejemplo simple de ataque de DNS Amplification

Esto posibilita la suplantación de direcciones IP (IP spoofing) y la suplantación de mensajes de consulta/respuesta. Aunque DNS soporta el uso de TCP para el envío de mensajes, en las especificaciones de implementación se recomienda, por motivos de rendimiento, usar UDP en las consultas. Se sugiere limitar el uso de TCP para realizar transferencias de zona o para aquellas consultas que superan el tamaño máximo, establecido en 512 bytes en mensajes sobre UDP.

Búsqueda de servidores DNS vulnerables: Primera aproximación

Buscar un servidor de nombres vulnerable a ataques de amplificación de DNS es sencillo: sólo hay que comprobar si la cantidad de bytes de la respuesta del servidor de nombres es mayor al tamaño de la consulta y obligar a que el protocolo para el intercambio de datos sea UDP.

Figura 4: Petición de transferencia de zona utilizando DIG

Una primera aproximación sería utilizar servidores de nombres vulnerables a transferencia de zona para realizar Ataques de Amplificación de DNS que pudieran desembocar en un DDoS: el tamaño en bytes devuelto por el servidor de nombres al conceder la transferencia de zona (1994 bytes en este ejemplo) es superior al tamaño en bytes de la petición de transferencia de zona (112 bytes en este ejemplo).

Figura 5: Transferencia de zona concedida por el servidor DNS vulnerable

Como contrapartida, el protocolo que se utiliza durante la petición y envío de la transferencia de zona es TCP (Protocolo de Control de Transmisión), lo que dificulta en gran media spoofear la dirección IP de origen al ser un protocolo orientado a la conexión y con ello poder amplificar el tamaño de la respuesta del servidor de nombres sobre una víctima.

Figura 6: Protocolo TCP utilizado en el proceso de transferencia de zona

Además, el número de servidores de nombres vulnerables a transferencia de zona seguramente sea menor que el número de servidores vulnerables a la técnica que veremos en la segunda aproximación: consultas de tipo root sobre UDP y los registros de recursos NS (Name Server).

Búsqueda de servidores DNS vulnerables: Segunda aproximación

Parece evidente la necesidad de utilizar el protocolo UDP (no hay un establecimiento previo de la conexión) para poder spoofear las direcciones IP de origen de las peticiones DNS por la dirección de la víctima, y a la par, utilizar un servidor de nombres con capacidad de amplificar el tamaño de las respuestas frente al tamaño de las consultas DNS. Si se dan todas las condicionantes, entonces se podrían utilizar estos servidores para realizar ataques DDoS amplificando el ancho de banda del atacante para tumbar un servidor de red.

Figura 7: Ataques de redes IPv4&IPv6

La idea es sencilla: ¿cómo responderá un servidor DNS cuando se realice una consulta de la raíz (“.”) sobre los registros de recursos NS utilizando el protocolo UDP? Si el servidor de nombres no está bien configurado y es vulnerable a consultas de tipo root sobre los registros de recursos NS utilizando el protocolo UDP responderá con el FQDN (nombre de dominio totalmente cualificado) de los 13 servidores DNS de nombres globales.

Figura 8: Respuesta de un servidor DNS vulnerable a técnicas de amplificación

Se puede observar que el tamaño de la consulta de tipo root son 59 bytes frente al tamaño de la respuesta, 270 bytes, lo que demuestra que el servidor de nombres es vulnerable a técnicas de Amplificación de DNS y podría ser utilizado en un ataque coordinado de DDoS.

Figura 9: Características de la respuesta a la consulta de tipo root

Por el contrario, si el servidor DNS no es vulnerable a esta técnica, la respuesta que devolverá al intentar resolver la consulta “.” sobre los registros de recursos name servers será la siguiente:

Figura 10: Tiempo de espera agotado para la petición de resolución
de la consulta de tipo root sobre los registros NS

Cómo proteger el servidor de nombres

El problema de denegación de servicio (DoS) utilizando Amplificación DNS se debe a la enorme cantidad de servidores DNS presentes en Internet y configurados como Open Resolvers para ofrecer su servicio sin ningún tipo de restricción a cualquier solicitante de Internet. Por eso, es necesario que cada vez que se instale un servidor DNS expuesto a Internet, ya sea sobre plataformas GNU/Linux o Windows Server, deben ser fortificados.

 
Figura 11: Hardening GNU/Linux y Windows Server 2016

Si nuestra organización cuenta con servidores de nombres propios con información de las máquinas que tiene desplegadas en Internet, como primera aproximación basta deshabilitar las peticiones recursivas de los reenviadores a los 13 servidores globales que se encuentran en Internet.

Figura 12: Configuración en Windows Server para no utilizar reenviadores
ni los 13 servidores DNS globales de Internet.
(También hay que hacerlo con los ataques de CLDAP Amplification )

Si un cliente envía una consulta DNS a los servidores de la organización con un FQDN que no se encuentre en su base de datos, el servidor no utilizará los reenviadores para tratar de resolver la petición y la respuesta del servidor será “Se agotó el tiempo de espera de la solicitud a ns.lacomarca.local”. Esta es una comprobación que tanto los equipos Blue Team como Red Team de una empresa deben controlar, y en las distribuciones Kali vienen todas las herramientas necesarias para auditar los servidores DNS de la organización.

Figura 13: Pentesting con Kali Silver Edition

En el caso de que el servidor fuera bind9, dado que las resoluciones recursivas requieren el uso de las sugerencias de los servidores raíz, bastaría con añadir la primitiva “recursion no;” en el fichero “named.conf” e impedir las peticiones de transferencias para cada una de las zonas del fichero de nombres.

Figura 14: Limitación de recursión y zonas

Un administrador podría pensar en eliminar el contenido del fichero db.root en bind9 que contiene los registros de recursos A y AAAA de los servidores DNS raíz y eliminar la referencia a la zona “.” en el fichero global named.conf.

Figura 15: contenido del fichero db.root

Si la zona “.” no estuviera, BIND sigue funcionando al ser compilado con una lista de servidores raíz, por lo que como último recurso siempre dispondrá de una lista interna de servidores raíz, el único inconveniente es que la lista es fija, pero los servidores raíz no suelen cambiar. 

Figura 16: Referencia a la zona db.root que contiene los nombres
y direcciones IP de los 13 servidores de nombres globales

Esta comprobación vista hoy es algo que los pentesters, los clientes zombies de las botnets, y los administradores de open resolvers DNS deben buscar y cuidar.  Se deben administrar los servidores para que no sean utilizados en ataques de denegación de servicio. Entre las tareas que deben contemplarse, están las medidas anti-spoofing, filtrado de tráfico y, técnicas como Rate Response Limit y proporcionar una configuración correcta de consultas recursivas.

Saludos,  

Autor: Amador Aparicio (@amadapa), escritor de los libros “Raspberry Pi para Hackers & Makers: PoCs & Hacks Just for Fun!” y "Hacking Web Technologies 2ª Edición" , CSE (Chief Security Envoy) de ElevenPaths. 

Figura 17: Contactar con Amador Aparicio en MyPublicInbox