¿Qué tipo de vulnerabilidades de seguridad expone el proporcionar DNSSEC?

Estaba planeando firmar mi zona DNS con DNSSEC. Mi zona, el registrador y mi servidor DNS (BIND9) son compatibles con DNSSEC. El único que no admite DNSSEC es mi proveedor secundario de servidores de nombres (es decir, buddyns.com ).

En su sitio web , afirman esto con respecto a DNSSEC:

BuddyNS no es compatible con DNSSEC porque se expone a algunas vulnerabilidades no adecuadas para un servicio DNS de alto volumen.

Bueno, pensé que el uso de DNSSEC es actualmente de alguna manera cuestionable ya que la mayoría de los resolutores no verifican si los registros están firmados correctamente. Lo que no sabía era que, según su declaración, parece que proporcionar expondría vulnerabilidades de seguridad de algún tipo.

¿Cuáles son esas "vulnerabilidades"?

DNSSEC tiene algunos riesgos, pero no están directamente relacionados con la reflexión o la amplificación. La expansión del tamaño del mensaje EDNS0 es una pista falsa en este caso. Dejame explicar.

Cualquier intercambio de paquetes que no dependa de una prueba de identidad previa está sujeto a abuso por parte de los atacantes DDoS que pueden usar ese intercambio de paquetes no autenticado como reflector, y quizás también como amplificador. Por ejemplo, se puede abusar de ICMP (el protocolo detrás de "ping") de esta manera. Al igual que el paquete TCP SYN, que solicita hasta 40 paquetes SYN-ACK incluso si el SYN fue falsificado para provenir de alguna víctima que no quiere esos paquetes SYN-ACK. Y, por supuesto, todos los servicios UDP son vulnerables a este ataque, incluidos NTP, SSDP, uPNP y, como se señala en otras respuestas aquí, también incluyen DNS.

La mayoría de los dispositivos de detección de intrusiones, prevención de intrusiones y balanceador de carga son cuellos de botella, incapaces de mantenerse al día con el tráfico de "velocidad de línea". Además, muchos enrutadores no pueden funcionar a velocidad de línea y algunos conmutadores. Estos cuellos de botella, al ser la cosa más pequeña "en el camino", y más pequeños que los enlaces en sí, son el objetivo real de los ataques DDoS basados ​​en la congestión. Si puede mantener el firewall de alguien ocupado con el tráfico de ataque, entonces el buen tráfico no pasará, incluso si los enlaces no están llenos. Y lo que ralentiza un cortafuegos no es el número total de bits por segundo (que puede aumentarse usando mensajes más grandes, y EDNS0 y DNSSEC lo harán), sino el número total de paquetes por segundo.

Hay mucha leyenda urbana sobre cómo DNSSEC empeora DDoS debido al mayor tamaño de mensaje de DNSSEC, y aunque esto tiene un sentido intuitivo y "suena bien", es simplemente falso. Pero si hubiera una pizca de verdad en esta leyenda, la respuesta real aún estaría en otra parte: [porque DNSSEC siempre usa EDNS0, pero EDNS0 se puede usar sin DNSSEC], y muchas respuestas normales que no son DNSSEC son tan grandes como un DNSSEC la respuesta sería Considere los registros TXT utilizados para representar políticas SPF o claves DKIM. O simplemente cualquier conjunto grande de direcciones o registros MX. En resumen, ningún ataque requiere DNSSEC y, por lo tanto, cualquier enfoque en DNSSEC como riesgo DDoS es energía mal utilizada.

¡DNSSEC tiene riesgos! Es difícil de usar y más difícil de usar correctamente. A menudo requiere un nuevo flujo de trabajo para cambios de datos de zona, gestión de registradores, instalación de nuevas instancias de servidor. Todo eso tiene que ser probado y documentado, y cada vez que algo se rompe relacionado con DNS, la tecnología DNSSEC debe investigarse como una posible causa. Y el resultado final si hace todo bien será que, como firmante de zona, su propio contenido y sistemas en línea serán más frágiles para sus clientes. Como operador de servidor remoto, el resultado será que el contenido y los sistemas de todos los demás serán más frágiles para usted. A menudo se considera que estos riesgos superan los beneficios, ya que el único beneficio es proteger los datos DNS de la modificación o sustitución en vuelo. Ese ataque es tan raro que no vale la pena todo este esfuerzo. Todos esperamos que DNSSEC se vuelva omnipresente algún día, debido a las nuevas aplicaciones que habilitará. Pero la verdad es que hoy, DNSSEC es todo costo, sin beneficios y con altos riesgos.

Entonces, si no desea usar DNSSEC, esa es su prerrogativa, pero no permita que nadie lo confunda con el problema de DNSSEC como su función como amplificador DDoS. DNSSEC no tiene la función necesaria como amplificador DDoS; Hay otras formas mejores y más baratas de utilizar DNS como amplificador DDoS. Si no desea utilizar DNSSEC, hágalo porque aún no ha bebido el Kool Aid y quiere ser el último en mover (más tarde) no el primero (ahora).

Se debe evitar que los servidores de contenido DNS, a veces llamados "servidores de autoridad", sean abusados ​​como amplificadores reflectores de DNS, porque DNS usa UDP y porque UDP es abusable por paquetes de fuente falsificada. La forma de proteger su servidor de contenido DNS contra este tipo de abuso no es bloquear UDP, ni forzar TCP (usando el truco TC = 1), ni bloquear CUALQUIER consulta, ni optar por no recibir DNSSEC. Ninguna de esas cosas te ayudará. Necesita limitar la tasa de respuesta de DNS(DNS RRL), una tecnología completamente gratuita que ahora está presente en varios servidores de nombres de código abierto, incluidos BIND, Knot y NSD. No puede solucionar el problema de reflexión de DNS con su firewall, porque solo un middlebox con contenido como el servidor DNS en sí (con RRL agregado) sabe lo suficiente sobre la solicitud para poder adivinar con precisión qué es un ataque y qué no. Quiero enfatizar, nuevamente: DNS RRL es gratuito, y todos los servidores de autoridad deberían ejecutarlo.

Para terminar, quiero exponer mis prejuicios. Escribí la mayor parte de BIND8, inventé EDNS0 y co-inventé DNS RRL. He estado trabajando en DNS desde 1988 con 20 y tantos años, y ahora tengo 50 y tantos gruñones, con cada vez menos paciencia para encontrar soluciones a medias a problemas incomprendidos. Por favor acepte mis disculpas si este mensaje suena demasiado como "¡Hola chicos, salgan de mi césped!"

Sé de dos vulnerabilidades específicas. Existe la reflexión / amplificación mencionada por Håkan. Y existe la posibilidad de enumerar zonas.

Reflexión / amplificación

Reflexión significa ataques en los que las solicitudes con una IP de origen falsificada se envían a un servidor DNS. El host que está siendo engañado es la principal víctima del ataque. El servidor DNS enviará sin saberlo la respuesta a un host que nunca la solicitó.

La amplificación se refiere a cualquier ataque de reflexión en el que la respuesta reflejada consta de más bytes o más paquetes que la solicitud original. Antes de la amplificación DNSSEC + EDNS0 de esta manera, solo se enviarían hasta 512 bytes. Con DNSSEC + EDNS0 es posible que se envíen 4096 bytes, que generalmente abarca 3-4 paquetes.

Hay posibles mitigaciones para estos ataques, pero no conozco ningún servidor DNS que los implemente.

Cuando la IP del cliente no ha sido confirmada, el servidor DNS puede enviar una respuesta truncada para obligar al cliente a cambiar a TCP. La respuesta truncada puede ser tan corta como la solicitud (o más corta si el cliente usa EDNS0 y la respuesta no), lo que elimina la amplificación.

Cualquier IP de cliente que complete un protocolo de enlace TCP y envíe una solicitud de DNS en la conexión se puede incluir temporalmente en la lista blanca. Una vez en la lista blanca, esa IP puede enviar consultas UDP y recibir respuestas UDP de hasta 512 bytes (4096 bytes si se usa EDNS0). Si una respuesta UDP desencadena un mensaje de error ICMP, la IP se elimina de la lista blanca nuevamente.

El método también se puede revertir usando una lista negra, lo que significa que las direcciones IP de los clientes pueden realizar consultas a través de UDP de forma predeterminada, pero cualquier mensaje de error ICMP hace que la IP se ponga en una lista negra que necesita una consulta TCP para salir de la lista negra.

Un mapa de bits que cubra todas las direcciones IPv4 relevantes podría almacenarse en 444 MB de memoria. Las direcciones IPv6 tendrían que almacenarse de alguna otra manera.

Enumeración de zona

Si la enumeración de zonas es una vulnerabilidad en primer lugar es objeto de debate. Pero si no desea que todos los nombres en su zona sean de conocimiento público, probablemente lo consideraría una vulnerabilidad. La enumeración de zonas se puede mitigar principalmente mediante el uso de registros NSEC3.

El problema que aún persiste incluso cuando se usa NSEC3 es que un atacante puede encontrar el hash de cada etiqueta simplemente consultando nombres aleatorios. Una vez que el atacante tiene todos los hashes, se puede realizar un ataque de fuerza bruta fuera de línea en esos hashes.

Una defensa adecuada contra la enumeración de zonas requeriría que un atacante realice una consulta al servidor autorizado para cada suposición. Sin embargo, no existe tal defensa en DNSSEC.

Lo que viene a la mente no es en realidad DNSSEC específico, sino más bien acerca de la extensión EDNS0, en la que se basa DNSSEC.

EDNS0 permite cargas útiles UDP más grandes y las cargas útiles UDP más grandes pueden permitir peores ataques de reflexión / amplificación de tráfico.

No sé cuál es el porcentaje de validadores de resolución, pero parece que el software de servidor de nombres popular se envía con la validación activada de forma predeterminada y uno encontrará fácilmente algunos proveedores de servicios notables que están abiertos a hacer la validación, como Comcast y los resolvers públicos de Google.

En base a esto, creo que el porcentaje de validadores de resolución probablemente esté en una forma significativamente mejor que el porcentaje de zonas firmadas.