DNSSEC, securizando las comunicaciones en la web (I)

Introducción a DNS

El protocolo DNS fue definido originalmente en 1983 (RFC 882 y 883) y desde entonces no ha sufrido grandes cambios. Las nuevas funcionalidades han venidas asociadas a extensiones y nuevos tipos de registros. Dicho protocolo consiste básicamente en traducir un nombre de dominio como ser: www.segu-info.com.ar a una dirección IP. A su vez, esa IP permite al equipo buscar el sitio web.

Vulnerabilidades del protocolo DNS

La información transmitida en DNS puede ser "spoofed":

• Entre maestro y esclavo (AXFR).
• Entre maestro y sus clientes "resolver".

Actualmente el protocolo DNS no permite validar la información contenida en una respuesta:

• Vulnerable a las diferentes técnicas de poisoning.
• Datos envenenados siguen causando problemas por un tiempo (potencialmente grande, TTL).

Tampoco los secundarios tienen manera de autenticar al primario con el que están hablando.

¿Qué es DNSSEC?

DNSSEC (DNS Security Extensions) es un conjunto de extensiones al protocolo DNS que permiten validar criptográficamente que las respuestas que envían los servidores DNS sean reales, las que dicen ser. El mismo nace oficialmente en 2005 (ya que venía siendo tratado  en el IETF) con las especificaciones en los RFC 4033, 4034, 4035. DNSSEC no es un nuevo protocolo. Algunos de los cambios que implementa son:

• Cambios en el “wire protocol” (EDNS0)
• Extensión del tamaño máximo de una respuesta UDP de 512 a 4096 bytes
• Agregado de nuevos resource records
• RRSIG, DNSKEY, DS, NSEC
• Agregado de nuevos flags
• Checking Disabled (CD)
• Authenticated Data (AD)

Los nuevos RR que implementa son:

• RRSIG: Resource Record Signature
• DNSKEY: DNS Public Key
• S: Delegation Signer
• NSEC: Next Secure

Y los nuevos Flags que se añaden son:

• AD: que indica que la respuesta está autenticada.
• CD: indica que no se realiza chequeo (deshabilitado).

Un Resource Record en DNS es una tupla de cinco valores:

• Nombre
• Clase
• Tipo
• TTL
• Valor

Donde por ejemplo: www.empresa.com. 86400 IN A 200.40.100.141, tiene que:

• Nombre (www.empresa.com)
• Clase (IN)
• Tipo (A)
• TTL (86400 segundos)
• Valor (200.40.100.141)

Como contrapartida DNSSEC opera firmando RRSets (no RR individuales). Un RRSet es un conjunto de resource records que comparten igual:

• Clase
• Tipo
• Nombre

Ejemplos de RRSet con TTL omitido:

• www IN A 200.40.241.100
• www IN A 200.40.241.101

Alcance de DNSSEC

El alcance de las extensiones de seguridad a DNS pueden resumirse en tres servicios:

1. Distribución de llaves (key distribution): El servicio de distribución de llaves no sólo permite la recuperación de una llave pública de un nombre DNS para verificar la autenticidad de los datos de una zona DNS, sino que también proporciona un mecanismo mediante el cual cualquier llave asociada a un nombre DNS puede ser usada para otros propósitos. El servicio de distribución de llave pública soporta diferentes tipos de llaves y de algoritmos de encriptación.
2. Autenticación del origen de los datos (Data Origin Authentication): Este servicio es el punto crucial en el diseño de DNSSEC. Mitiga amenazas tales como envenenamiento de caché y compromiso de los datos de una zona en un servidor DNS. Los RRSets dentro de una zona son firmados criptográficamente, dando así un alto nivel de certeza de que los datos recibidos por resolvers y servidores pueden ser confiables. DNSSEC utiliza firmas digitales para firmar los RRSets dentro de DNS. Dicha firma digital contiene un valor hash cifrado del RRSet, el cual es una suma de control criptográfica de los datos contenidos en el mismo. Este hash es firmado (digitalmente encriptado) mediante una clave privada, generalmente perteneciente al dueño de la información, conocido como signer (o signing authority). El receptor del RRSet puede simplemente chequear la firma digital contra los datos en el RRSet, primero desencriptando la firma digital (RRSIG) utilizando la llave pública del signer para obtener el hash original de los datos, y luego computando su propio hash de los datos en el RRSet utilizando el mismo algoritmo de suma de control criptográfica De esta manera puede comparar los resultados del hash encontrado en la firma digital contra el hash recién computado. Si los dos valores hash coinciden, existe integridad en los datos y el origen de datos es auténtico.
   
3. Autenticación de transacciones y pedidos (DNS Transaction and Request Authentication): Permite autenticar pedidos y cabeceras de mensajes DNS. Esto garantiza que una respuesta sea verdaderamente en respuesta a una consulta realizada, y que dicha respuesta proviene efectivamente desde el servidor al cual estaba destinada la consulta. Proporcionar la seguridad para ambos se hace en un solo paso, parte de la información regresada desde un servidor seguro es una firma, dicha firma es producida por la concatenación de la consulta y su respectiva respuesta. Esto permite a un resolver seguro, realizar cualquier verificación concerniente a la transacción realizada. Esta autenticación también se utiliza en las actualizaciones dinámicas de DNS. Sin DNSSEC, las actualizaciones dinámicas no proveen ningún mecanismo que prohíba, a cualquier sistema que tenga acceso a un servidor autoritativo DNS, la actualización de información de su zona. Para proveer seguridad para estas modificaciones se incorpora DNSSEC para brindar una autentificación fuerte a sistemas habilitados a manipular dinámicamente información de zonas DNS en el servidor primario.

Protección proporcionada

DNSSEC nos protegerá de corrupción y del spoofing de datos:

• Proporciona un mecanismo para poder validar la autenticidad y la integridad de los datos contenidos en una zona DNS
• DNSKEY/RRSIG/NSEC
• Proporciona un mecanismo para delegar la confianza en ciertas claves públicas (cadena de confianza)
• DS
• Proporciona un mecanismo para autenticar las transferencias de zona entre primarios y secundarios
• TSIG

Continua leyendo la 2da parte

Mauro D. Gioino de la Redacción de Segu-Info

Suscríbete a nuestro Boletín