Optar por la comprobación estricta de DNSSEC: ¿Proporciona DNSSEC una forma para que una zona solicite una validación estricta de la firma?

6

¿Hay una forma para que un dominio good.com le prometa que firmará todos sus registros DNS, y que cualquier registro sin firma para cualquier host *.good.com debe ser rechazado? En otras palabras, ¿hay una manera para que una zona proporcione una declaración firmada que indique que está protegida por DNSSEC y sugiere que los clientes de DNSSEC pueden usar la comprobación estricta de firmas para los registros DNS en esa zona?

Esto sería análogo a un registro HSTS (donde un sitio solo participa en HTTPS y sugiere que los navegadores rechacen cualquier intento de conexión a través de HTTP inseguro), o una política de SPF que opte por un control estricto (indicando que los correos electrónicos que no No cumpla con la política de SPF).

Fondo (como yo lo entiendo). En principio, DNSSEC brinda protección contra ataques de intermediarios: el cliente puede verificar si la respuesta de DNS tiene una firma válida e ignorar todas las respuestas sin firmar y las respuestas con firmas no válidas. Desafortunadamente, en la práctica, este tiene un costo de compatibilidad inaceptable . Si trata todas las respuestas no firmadas como no válidas, entonces "interrumpe Internet": algunos sitios dejan de funcionar, ya sea porque el dominio no está firmando todos los registros de forma sistemática, o (me han dicho) porque las firmas de vez en cuando se eliminan mediante middleboxes. / p>

Como resultado, por razones prácticas de implementación, muchos clientes con capacidad DNSSEC en realidad no están validando : mire la firma, pero si falta la firma, todavía aceptan la respuesta DNSSEC. (Incluso la resolución de DNS pública de Google lo hará en algunos casos .)

Esto abre un desagradable ataque de hombre en el medio: el hombre en el medio simplemente elimina todas las firmas DNSSEC, y luego modifica los registros como quiera. Si el cliente acepta respuestas de DNS sin firmar, este ataque de hombre en el medio niega el valor de DNSSEC. Por supuesto, el otro lado de esta situación infeliz es que si el cliente rechaza todas las respuestas de DNS no firmadas, entonces podría estar seguro contra ataques de intermediarios, pero muchos sitios heredados dejarán de funcionar, lo que causará un costo de compatibilidad inaceptable. Al menos, este es mi entendimiento.

Podría imaginar que una mejor solución podría ser posible si los clientes conscientes de DNSSEC tuvieran una manera de indicar qué zonas deberían usar la validación estricta de firmas. En particular, si google.com o good.com tenía una forma de declarar "Garantizo que todos mis registros DNS se firmarán, y quiero que trate cualquier registro no firmado como no válido", entonces un cliente que coopera podría aplicar una validación estricta a Los registros DNS para *.good.com , mientras que no se validan para otras zonas. Esto podría permitir una buena compatibilidad con los dominios heredados al tiempo que permite la comprobación estricta de las zonas que desean optar a ella, en otras palabras, proporciona una protección parcial contra los ataques de intermediarios sin "romper Internet".

¿Existe tal mecanismo?

    
pregunta D.W. 14.04.2016 - 00:54
fuente

2 respuestas

2

Hay tres indicadores en un paquete DNSSec que son responsables de comunicar los requisitos de validación de un dominio.

El bit de OD

El bit de OD lo establece el resolvedor para indicar que requiere que los registros de recursos de autenticación se incluyan en la respuesta.

Si un resolutor tiene en cuenta la seguridad, DEBE establecer el bit de OD. Si un Servidor de nombres recibe un mensaje sin el bit de OD, DEBE eliminar los registros de recursos de autenticación. A menos que haya una solicitud específica para un registro de autenticación.

El bit del CD

Este bit permite que los servidores de nombres intermedios deshabiliten la validación de firmas. Esto básicamente dice 'no te molestes en validar las cosas, lo haré yo mismo, solo envíame los registros en bruto'

El bit AD

Esta es la parte que realmente responde a tu pregunta.

  

El lado del servidor de nombres DEBE establecer el bit AD si y solo si      el lado del resolutor considera todos los conjuntos de RR en la sección de Respuesta y cualquier      RRs de respuesta negativa relevantes en la sección de Autoridad a ser      auténtica.

El bit AD dice, estos registros son auténticos y están firmados.

Realización de consultas seguras

Si www.example.com tiene las claves correctas y los registros de recursos configurados. Todavía debe responder a los clientes que no entienden DNSSec. DNSSec está diseñado para ser compatible con versiones anteriores, debe responder a las solicitudes que no entienden DNSSec. Esto crea la vulnerabilidad que resaltas.

Sin embargo, el proceso existe, utilizando los indicadores anteriores para garantizar que solo se reciban los registros auténticos, pero esto requiere que la resolución esté configurada para hacerlo. Bind proporciona este mecanismo en la DNSSec-validation bandera (que está habilitada por defecto)

  

Habilitar la validación de DNSSec en nombre. Nota DNSSec-habilitar también debe configurarse en sí para que sea efectivo. El valor predeterminado es sí.

Entonces, si crea su propio DNS Resolver y lo configura para que solo acepte respuestas validadas, no podrá resolver dominios que no tengan una cadena de confianza completa asociada a ellos. Aunque los dominios que no tienen registros DNSSec funcionarán como antes.

La razón por la que los servidores de nombres de Google se comportan como lo hacen, es que los han configurado para ignorar el bit AD si el dominio es popular. Entonces, si stackexchange tuvo un problema con su certificado, Google todavía se resolvería con sus servidores de nombres. Esto parece ser una decisión para evitar que StackExchange deje de usar Internet para una gran parte de las personas que utilizan el DNS de Google.

editado para responder a la pregunta real!

Si ha configurado su resolutor seguro, y alguien en la parte superior puede secuestrar sus consultas, podría eliminar el bit de OD, lo que obligaría a los servidores anteriores a eliminar todos los registros de autenticación. Cuando su resolutor seguro reciba ese registro, simplemente supondría que el dominio que estaba buscando no tenía ninguna autenticación configurada.

Para realizar este ataque, ni siquiera es necesario que se inserte por completo en el medio, la capacidad de ajustar el paquete DNS saliente sería suficiente.

Esto fue considerado como parte del diseño original de DNSSec. De acuerdo con RFC3833 - Análisis de amenazas del sistema de nombres de dominio

  

Si bien ciertamente sería posible firmar mensajes DNS usando un      mecanismo de seguridad de canal como TSIG o IPsec, o incluso para cifrar      utilizando IPsec, esto no sería una muy buena solución para      ataques de intercepción
  [...]
  Para servidores de nombres muy utilizados (tales      como los servidores de la zona raíz), este costo sería casi seguro      ser prohibitivamente alto Aún más importante, sin embargo, es que la      El modelo de confianza subyacente en tal diseño sería incorrecto, ya que en el mejor      solo proporcionaría un control de integridad salto a salto en los mensajes DNS      y no proporcionaría ningún tipo de verificación de integridad de extremo a extremo

DNSSec está diseñado para proteger contra una serie de ataques específicos, como el envenenamiento de caché. Los ataques de Man in the middle simplemente se descartaron por la razón anterior.

    
respondido por el Michael B 14.04.2016 - 01:17
fuente
0

La respuesta corta es: cuando usa DNSSEC en una zona, todos los registros deben estar firmados. Por lo tanto, no hay necesidad de un mecanismo para transmitir explícitamente esta declaración, ya que es la política predeterminada y única de las zonas firmadas por DNSSEC.

No hay excepciones con eso. Existe un mecanismo de exclusión de NSEC3 , pero está más orientado a delegar solo zonas como TLD, con el fin de reducir el tamaño firmando solo para las zonas secundarias que están habilitadas para DNSSEC.

Entonces, si la zona está habilitada para DNSSEC y la resolución está validando, debe tratar todos los registros no firmados como un error de validación y devolver SERVFAIL .

Para obtener más información, consulte "4.3. Determinación del estado de seguridad de los datos" en RFC4035 y anote este último párrafo en sección 5:

  

Un resolutor DEBE esperar información de autenticación de firmada      zonas Un resolutor DEBE creer que una zona está firmada si el      El resolutor ha sido configurado con información de clave pública para el      zona, o si el padre de la zona está firmado y la delegación de la      el padre contiene un DS RRset.

En resumen, la presencia de una clave en la zona y la validación de toda la cadena de confianza desde la raíz hasta esta clave en la zona debe tener como consecuencia que todos los registros en la zona tengan un registro de RRSIG para validar su autenticidad.

En ese caso, obtener una respuesta sin los registros RRSIG también puede mostrar un ataque continuo, por lo que se debe tratar como un error de validación, por lo tanto, SERVFAIL .

Ahora, como se citó a sí mismo, varios resolutores eligen para anular el comportamiento estándar predeterminado y dejar pasar algunos registros DNSSEC no válidos o faltantes. Es una decisión de política local, hasta cada resolutor, pero está claramente fuera de la norma.

A medida que se vincula, Google lo hace para casos como "dominio muy popular", muchos ISP lo hacen de vez en cuando, por ejemplo, Comcast, ya que tienen la culpa cuando los nombres de dominio no están configurados correctamente (vea este ejemplo: < a href="https://www.darkreading.com/risk/dnssec-error-caused-nasa-website-to-be-blocked/d/d-id/1136990"> enlace y puede encontrar una lista curada de problemas relacionados en enlace ). Y ahora hay incluso un RFC específicamente para este problema: RFC7646: Definición y uso de anclajes de confianza negativa de DNSSEC

  

Este documento define Negativo      Trust Anchors (NTA), que se pueden usar para mitigar la validación de DNSSEC      fallas al deshabilitar la validación de DNSSEC en dominios específicos.

y:

  

En el caso de una falla de validación debido a una mala configuración de un Top-      Dominio de nivel (TLD) o nombre de dominio popular (como los 100 principales      sitio web), el contenido o los servicios en el TLD o dominio afectado podrían ser      inaccesible para un gran número de usuarios. En tales casos, puede ser      apropiado para usar un NTA tan pronto como la mala configuración sea      confirmado. Un ejemplo de una lista de sitios web "top N" es Alexa.      "Los 500 mejores sitios en la Web" [Alexa] o una lista de los más      Se accedió a los nombres en el caché del resolvedor.

También puede interesarle este borrador: enlace que tiene que tener en cuenta las dificultades para validar a los resolutores, tanto debido a errores de configuración como a entornos hostiles.

    
respondido por el Patrick Mevzek 03.04.2018 - 18:14
fuente

Lea otras preguntas en las etiquetas