DNSSEC

DSNSEC, siglas en inglés de Domain Name System Security Extensions, es considerado un mecanismo eficaz para evitar el spoofing y manipulación de mensajes en el protocolo DNS, y por extensión, proporcionar una vía de protección contra ataques de caché poisoning y similares. DNSSEC se basa en una infraestructura de criptografía de clave pública PKI22 y en el uso de firmas digitales para establecer autenticidad de las fuentes y la validez de los mensajes. Aplicado a las queries DNS, asegura la integridad de los mensajes y la autenticidad de la fuente emisora.

DNSSEC, con el uso de una PKI y un conjunto especial de registros de recursos RRs, registros específicos de firma (RRSIGs) y registros de clave DNSKEY, permite a resolvers con capacidades DNSSEC comprobar lo siguiente:

  • Autenticidad de origen: Autenticar que los datos recibidos sólo pueden proceder de la zona solicitada
  • Integridad: Verificar la integridad de los datos, es decir, que los datos no han sido modificados en el transcurso de la transacción.
  • No existencia: Verificar, en el caso de una respuesta de dominio no existente (NXDOMAIN), que, efectivamente el registro no existe en la zona solicitada y no ha sido expresamente eliminado en la intercepción de la transacción.

En DNSSEC se valida la clave pública de una fuente con una cadena de verificaciones que empieza en un servidor de confianza (como un root server) y bajando por la jerarquía del espacio de nombres DNS verificando sucesivamente la firma de la clave pública de un nodo hijo por su nodo padre. La clave pública de servidores de confianza se denomina “trust anchor”.

Una vez realizada esta verificación de clave pública de la fuente, el siguiente paso en DNSSEC es autenticar la respuesta. En este caso, las respuestas incluyen no sólo los registros solicitados, sino además, la firma digital de un conjunto de registros encapsulada en un tipo de registro específico, denominado RRSIG. Entonces, el resolver, usando la clave pública verificada anteriormente, comprueba la validez de la firma y se asegura de que la respuesta es auténtica. En el caso de una respuesta negativa indicando la no existencia de un registro, se adjunta un registro específico denominado NSEC con su firma correspondiente, cuya verificación asegura la validez de la respuesta y que el registro no ha sido eliminado por una manipulación intermedia.

COMPONENTES Y OPERACIONES

Existen dos procesos principales:

  • Firmar y Servir
  • Verificar y Firmar

La   “separación de claves” es una buena práctica criptográfica, para limitar el alcance de un posible compromiso. De este modo, DNSSEC cuenta con dos pares de claves publica/privada. Un par denominado Key Signing Key (KSK) para el firmado de registros de clave DNSKEY y otro, denominado Zone Signing Key (ZSK) para el firmado de registros (RRsets) .

Registros DNSSEC:

  • DNSKEY (DNS Public Key): Clave pública  del DNS.
  • RRSIG (Resource Record Signature): Firma digital de un registro.
  • DS (Delegation Signer): Hash de una DNSKEY.
  • NSEC/NSEC3 (Next Secure): Se utiliza para la denegación de existencia.
  • NSEC3PARAM: Parámetros de configuración de NSEC3.

Ejemplo de Identificación de campos en registro DNSSEC

campos_dnssec

Operaciones DNSSEC

Firmado y Servicio de conjuntos de registros (RRsets)

  • Verificación de firma: Un resolver puede verificar las firmas digitales contenidas en los registros de firma RRSIG haciendo uso la clave pública aportada en los registros DNSKEY.

Proceso de resolución y verificación DNSSEC

Cuando es así requerido por un cliente, el servidor autoritativo añadirá datos adicionales DNSSEC a la respuesta. Estos datos proceden de la firma digital del registro solicitado (RRSIG). En el caso de que el recurso solicitado no exista, se responderá con un registro NSEC3 para autentificar la respuesta.

  • Verificación de una respuesta: El cliente lo primero que hará es verificar los datos recibidos del recurso solicitado .Para ello genera un hash del conjunto de registros de la respuesta (RRset) usando el algoritmo referenciado en la misma.
  • Cadena de confianza. Trust Anchor: Pero ¿qué garantiza que ambos, DNSKEY y el RRSIG no han sido modificados? Aquí, es donde entra en juego la verificación de la cadena de confianza desde el trust anchor que el cliente resolver tiene instalada y en el cual confía. Puede ser un trust anchor local para un dominio concreto (una isla de seguridad), o idealmente, la clave pública de un servidor root para un dominio globalmente seguro.

En la respuesta en nodo padre adjunta:

  • DS conteniendo el hash de la clave pública que se quiere validar (el nodo hijo)
  • El registro de firma RRSIG correspondiente al DS
  • Clave pública DNSKEY (nodo padre) para verificar la firma

cadena_confianza

DIFICULTADES EN EL USO DE DNSSEC

DNSSEC tiene como contrapartida ciertos problemas y dificultades que se presentan en su utilización, entre los que se pueden destacar los siguientes:

  • Dificultad de implementación y mantenimiento. Respecto a DNS, resulta más complejo de implementar y requiere una cuidadosa atención en el mantenimiento de las zonas y las claves. Cualquier problema relacionado con el firmado o claves caducadas causará problemas en la resolución a clientes DNSSEC.
  • Tamaño de las respuestas. Una respuesta DNSSEC incrementa notoriamente su tamaño respecto a una respuesta DNS convencional, lo que conlleva un mayor uso de recursos de red y proporciona un vector explotable a ataques de amplificación DNS tal y como se explicó en el apartado de ataques de denegación de servicio ATAQUE DE AMPLIFICACIÓN DNS
  • Rendimiento y Resolución DNSSEC. El proceso de resolución y verificación de firmas supone un incremento de procesado por parte del resolver que puede impactar en el tiempo de respuesta y causar reintentos por parte de clientes, lo que acentuará la carga.
  • Renovación de claves. La correcta renovación de las claves supone una atención extra a la hora de administrar el servidor.
  • Sincronización. Puesto que para la verificación de firmas y vigencia de las claves se necesita comprobar los timestamps para determinar los periodos de validez, es necesaria una correcta sincronización de tiempo respecto a la referencia del firmante. Esto puede constituir un vector de ataque si se consigue cambiar la referencia de sincronización de tiempo de un servidor que puede provocar una denegación de servicio por problemas al verificar los tiempos de validez.

DESPLEGANDO DNSSEC

Cada organización es distinta y cada una debe estudiar y trazar un plan propio de despliegue. En principio, algunas recomendaciones básicas para llevar a cabo una implementación de DNSSEC serían:

  • Establecer una política de seguridad para DNSSEC
  • Determinar qué zonas necesitan ser firmadas. Generalmente la mayoría de organizaciones comienzan por firmar únicamente sus zonas públicas de internet
  • Decidir que servidores servirán zonas firmadas y actualizar y adaptar convenientemente el software.
  • Establecer procedimientos de generación de claves y renovación. Almacenamiento seguro y periodicidad de renovación
  • Escoger convenientemente los parámetros criptográficos. Algoritmos de cifrado, longitud de clave, tiempo de validez, etc.
  • Despliegue y test

Diseñar la implementación de DNSSEC siguiendo manuales de buenas prácticas, como el descrito por la ENISA23 en su publicación Good Practice Guide for deploying DNSSEC24

Empezar una prueba piloto con una réplica de una zona existente y firmarla. Si se crea un subdominio de la misma, configurar el trust anchor y probar la validación.

Vocabulario y Abreviaturas

PKI. Public Key Infraestrcture: Es un conjunto de componentes para establecer comunicaciones cifradas basadas en criptografía asimétrica de clave pública. Muy utilizado para autenticación, cifrado , firmado digital y otros usos donde se establecen relaciones de confianza en certificados digitales.

KSK (Key Signing Keys) se corresponde a clave de firma de clave (una clave de términos larga)

ZSK (Zone Signing Keys) se corresponde a clave de firma de zona (una clave de términos corta)

Trust anchor: o clave de confianza. Un ancla de confianza (trust anchor) es una entidad autorizada representada por una clave pública y datos asociados. La clave pública se utiliza para verificar las firmas digitales, y los datos asociados que se utilizan para restringir los tipos de información o actividades.

Fuentes:

  • Wikipedia
  • Inteco
Etiquetado con:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*