Ir al contenido principal

Cómo aguantar ataques DoS sobre tu DNS usando DNSSEC

Durante el año 2014 estuvo de moda un ataque de denegación de servicio (DDoS) sobre servidores DNS autoritativos llamado "random subdomain attack", donde el atacante orquesta una gran cantidad de servidores DNS recursivos y envía solicitudes normales de resolución de una enorme cantidad de subdominios inexistentes del dominio víctima.

De esta manera, si lo que quiero es atacar el nombre de dominio "ejemplo.cl", envío una gran cantidad de solicitudes de resolución a cientos o miles de (open) resolvers DNS por los nombres "kePhu5ieHui5eaBa.ejemplo.cl", "ieGie4eoEeb9Iwae.ejemplo.cl", etc. Los resolvers, al no tener este nombre en sus cachés, envían la consulta a los autoritativos de "ejemplo.cl", el que al verse amplificado por la capacidad de estos resolvers y el número de ellos, se ve sobrecargado de consultas y tráfico.

En ese momento se tomaron diversos mecanismos para soportar este ataque, algunos fuera del DNS como inspectores de paquetes o firewalls que buscaban patrones y cortaban la comunicación en el camino, o bien dentro del DNS con la técnica "Response Rate Limiting" (RRL) que mantiene un conteo de solicitudes desde un resolver hacia un autoritativo, y pasado un límite deja de responder u obliga a pasar a TCP, reduciendo en la práctica el ataque sobre el autoritativo (aunque pasan el problema a los resolvers, que quedan con timeouts y/o exceso de recursos TCP).

Sin embargo, se puede aprovechar un efecto secundario de la firma DNSSEC de una zona para controlar este ataque.

Uno de los objetivos principales de DNSSEC es permitir la validación criptográfica de las respuestas, para que no quede duda que es genuina. Además de certificar las respuestas "existentes", DNSSEC permite verificar las respuestas "inexistentes", con el uso de los registros NSEC y NSEC3. De esta manera, siguiendo el ejemplo anterior, una consulta por el registro "kePhu5ieHui5eaBa.ejemplo.cl" da como respuesta "El nombre no existe, lo que puede verificar mirando el registro NSEC que le envío firmado acá, el cual dice que no hay nada dentro del intervalo a.ejemplo.cl y www.ejemplo.cl".

A mediados del año 2017 se estandarizó el uso de la técnica "Aggressive Use of DNSSEC-Validated Cache" (RFC8198), que permite que ahora un resolver que está validando con DNSSEC, pueda hacer caché de estas respuestas NSEC y/o NSEC3 para responder a un cliente inmediatamente que otro nombre que quepa en algunos de esos intervalos no existe, sin necesidad de ir a consultar a los autoritativos.

Entonces, si yo firmo mi zona con DNSSEC, mis autoritativos estarán más protegidos frente al ataque desde resolvers que estén validando e implementen RFC8198.

Actualmente tanto Bind (desde la versión 9.12), unbound (desde 1.7.0) y Knot resolver (desde 2.0.0) soportan el RFC8198 con registros NSEC; y se espera pronto el soporte con NSEC3. La gente de CZ.NIC, los creadores de Knot, han realizado un estudio que indica que la activación de esta tecnología significa una eliminación completa del tráfico para zonas con TTL grande, y una reducción del tráfico de entre 60 y 90% en el caso de zonas con TTL pequeño.


Comentarios

Entradas más populares de este blog

Hora de discontinuar SHA-1 en DNSSEC

Con la introducción de DNSSEC se hizo necesario el manejo de "criptografía asimétrica" en el DNS. Para ello se utilizan diversas tecnologías de seguridad como los clásicos algoritmos RSA y DSA, y otras nuevas que se incorporan a medida que van haciéndose prácticas -como las curvas elípticas el año 2012-, y por supuesto otras que deben irse dando de baja en la medida de que nuevas técnicas matemáticas y el avance de la capacidad de procesamiento hacen riesgoso su uso.


Routing seguro: instalación de FORT y FRR con RPKI

Una de las principales ventajas de las herramientas de Código Abierto es que permiten bajo licencias de uso acceder a su fuente y modificarla de acuerdo al objetivo de cada plataforma. Asimismo, millones de personas colaboran de manera productiva en la innovación y desarrollo de estas herramientas, lo que se traduce en su rápido avance y genera una constante retroalimentación dentro de la comunidad. Sin embargo, surgen diferentes inquietudes respecto al mundo de Código Abierto, una de ellas es: ¿Puede un proyecto mantener su desarrollo en los próximos 5 o 10 años? Un elemento tranquilizador es que hoy en día se observa que las grandes compañías cada vez se involucran más en las piezas de software construidos en Código Abierto; esta vinculación les permite escalar sus desarrollos tecnológicos a costos más bajos, pudiendo diseñar soluciones a la medida y adaptarlas a sus requerimientos. Estas compañías contribuyen con la comunidad aportando ideas y compartiendo parte de sus experienci…

¿Cómo probar conectividad IPv6 en Chile?

NIC Chile ha estado empujando la adopción de IPv6 en Chile como parte de nuestra misión de mejorar Internet en el país, comenzando con obtener nuestro prefijo de direcciones y conectividad nativa el año 2006. Dentro de las actividades en más de una década tenemos algunasconferencias y seminarios, participación en los World IPv6 Day y en un piloto con Google, liderar a través de NIC Chile Labs la iniciativa "IPv6 para Chile" del 2010, apoyado por InnovaChile de Corfo y la Subsecretaría de Telecomunicaciones junto a grandes proveedores de Internet del país; entre otras charlas y cursos.

Además nos hemos preocupado de entregar nuestros propios servicios en IPv6 nativo, permitiendo el registro de servidores "glue" para nuestros clientes en IPv6 desde el año 2007, activando los DNS para .CL desde el año 2010, dando servicios web, correo, whois desde el 2012, y por último el año 2015 activando nuestro servicio secundario de DNS para dominios .CL con IPv6, dando con este …