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.


¿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 …

El servicio más extraño de NIC Chile

Uno de los servicios más extraños que nos ha tocado entregar dentro de NIC Chile desde tiempos históricos, es el de "verificador de la Internet funcionando" ;)

Muchos administradores de red en sus organizaciones, cuando necesitan confirmar que su conexión a Internet está funcionando, hacen una prueba muy sencilla llamada "ping". Este test es básicamente enviar un paquete especial a un servidor determinado, que te responde con una copia del mismo paquete recibido. De hecho, el nombre original del servicio es "eco". Lo de ping es el nombre de una de sus primeras implementaciones, que hacía ese sonido por los parlantes del computador cada vez que tenía una respuesta, al estilo de los sonares de submarinos :) Se trata de  una herramienta sencilla y básica de cualquier administrador de red, que provee una primera prueba de que un sitio remoto es alcanzable.


¿Y hacia qué servidor puedo enviar mis ping? En teoría, ¡a cualquiera! El servicio "eco" es pr…