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

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…

DNS Flag Day: el fin de los parches provisorios para EDNS

El próximo 1° de febrero de 2019, los cuatro principales proveedores de software para DNS recursivos -Bind, Unbound, PowerDNS y Knot- realizarán un lanzamiento conjunto de nuevas versiones de sus sistemas con una característica en común: el fin de parches provisorios históricos que perdonaban ciertas conductas desviadas del estándar en los servidores DNS autoritativos.

Estas conductas incorrectas según el estándar EDNS ("Extensiones al DNS", disponibles desde 1999 en los RFC2671, actualizado por RFC6891) incluyen la falta de respuesta, encendido de bits incorrectos, demoras en respuesta, etc.; y se suman a ciertos dispositivos en el camino (firewalls, IDS, middleboxes, etc.) que descartan algunos paquetes DNS porque no calzan con la implementacion de DNS que conocen.

Estos problemas fuerzan actualmente a los DNS "resolvers" a implementar una serie de trucos para poder lidiar con muchos casos de borde. Estos trucos ocasionaban un aumento de complejidad en el código …