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

Uso correcto del servicio DNS secundario gratuito

NIC Chile desde hace más de 20 años ha ofrecido el servicio de " Secundario DNS gratuito " para sus clientes. El objetivo siempre fue mejorar la robustez de .CL, ya que disponer de solo 1 NS es demasiado frágil, y este servicio siempre se ha mantenido con los niveles de infraestructura y tiempos de respuesta adecuados a su tiempo. El uso del servicio ha sido sostenido en el tiempo. Actualmente, más de 30 mil de nuestros clientes lo utilizan! Y con la adición de tecnologías como IPv6, se ha permitido que estos miles de dominios CL tengan presencia en la nueva red . Sin embargo, no todo es miel sobre hojuelas. Desde los inicios se ha detectado un problema técnico recurrente. El uso de este servicio, si bien es gratuito para clientes de NIC Chile, requiere una configuración técnica especial para que funcione correctamente. Y esta configuración debe ser realizada por quien administre el servicio DNS del dominio (por ejemplo la empresa de hospedaje (" host

Servicio AS112: atendiendo los reversos de direcciones IP privadas

El uso más común que se le da al servicio DNS es el de "transformar los nombres de dominio en direcciones IP", que permite por ejemplo a los humanos recordar fácilmente una dirección de un sitio web como "www.nic.cl", y dejar que sean las máquinas -mediante el DNS- que lo transformen a una dirección IPv6 como 2001:1398:5::6003, ó 200.7.7.3 en IPv4. Pero no es el único uso del DNS. También existe el llamado "servicio reverso", que como su nombre lo indica, hace lo contrario: transformar una IP en un nombre de máquina. Esto no es usado por los usuarios corrientes, sino por servicios por ejemplo de control de acceso, o registro de logs, etcétera; quienes parten de una dirección IPv6 como 2800:3f0:4003:c00::69 y obtienen como resultado www.google.com. Por otro lado, también existen direcciones IP especiales que se les llama "privadas", o "locales"; que tienen la particularidad que pueden ser usadas libremente por organizaciones en sus

dns-tools: herramienta para verificar zonas (ZONEMD) y firmar DNSSEC en forma distribuida

Actualmente existen diversas soluciones que permiten automatizar la firma DNSSEC de los dominios, integrados a los mismos servicios que normalmente proveen DNS. En el ámbito de código abierto, los más utilizados permiten activar DNSSEC con algunas instrucciones en la configuración, sin preocuparse de llaves ni firmas. Sin embargo, siempre es bueno tener herramientas que permitan hacer verificaciones o incluso firmas de una forma más de bajo nivel. Suelen ocurrir casos de uso donde alguien prefiere tener más control, o integrarse con sistemas internos no estándar. Les presentamos  dns-tools , una herramienta de línea de comandos (CLI), escrita en lenguaje Go, que permite firmar con DNSSEC una zona, crear registros de  integridad  de zona llamados ZONEMD, y a su vez validar estas firmas y registros. Esta herramienta fue creada por NICLabs , el laboratorio de NIC Chile. Es mantenida con código abierto en github , con licencia MIT. Una de las cosas más destacadas, y que lo hace una herrami