- Oct

2019

Publicado por: Juan Vázquez

Guardianes de Internet

El sistema de nombres de dominio (Domain Name System) es un sistema de nomenclatura descentralizado para dispositivos conectados a Internet o una red privada. Su función principal es traducir las direcciones IP a nombres fáciles de identificar y recordar para las personas.

Este sistema asegura la disponibilidad de los sitios webs o los correos electrónicos entre otros sistemas, mediante el mapeo de nombres de dominio con direcciones IP. Por lo tanto, el sistema DNS es una parte muy importante de Internet y su disponibilidad es crucial para el funcionamiento de Internet tal y como se conoce actualmente.

Sin embargo, el diseño de este protocolo no tuvo en cuenta la seguridad. Debido a esto, se hace necesaria la utilización de un protocolo seguro como es DNSSEC (Domain Name System Security Extensions).

Hoy, la seguridad de Internet depende de siete llaves físicas custodiadas por 14 personas que se reúnen periódicamente. Están vigiladas por medidas de seguridad para que nadie ponga en peligro el sistema. ¿Quiénes son estas 14 personas? ¿Son siempre las mismas? ¿Qué ocurriría si alguien consiguiera estas llaves?

En este artículo te contaremos todo lo que siempre quisiste saber y nunca te atreviste a preguntar sobre DNSSEC, tratando los aspectos más importantes relativos a su funcionamiento técnico y arquitectura, incluyendo información sobre el grado de implementación en la actualidad de este protocolo a nivel mundial.

¿Cómo funciona DNS?

Actualmente hay cerca de 300 millones de dominios registrados. El sistema DNS es jerárquico y se pueden distinguir tres niveles de dominio dentro de dicha jerarquía. Suponiendo que tenemos el dominio www.jtsec.es podemos distinguir las siguientes partes:

Dominios de 3º nivel. También conocidos como subdominios, consisten en una porción del nombre de dominio que aparece antes del segundo nivel del nombre de dominio. El más conocido es “www” pero también puede ser otros como el dominio “blogs”.
Dominios de 2º nivel. Es la parte o nivel que diferencia al dominio del resto, en nuestro caso concreto sería “jtsec”.
Dominio de nivel superior. Este nivel es el mayor nivel dentro de la jerarquía de organización del a web. Normalmente suelen ser .com o .net pero hay algunos códigos reservados para regiones específicas como .es .uk, .au, etc.

Se procederá a describir el funcionamiento del sistema mediante el siguiente ejemplo:

Un usuario introduce un dominio de una web, por ejemplo www.jtsec.es en su navegador habitual. El navegador lo que hace en primer lugar es enviar un mensaje a la red preguntando la dirección IP relacionada con el nombre introducido por el usuario.
El ordenador del usuario realiza la consulta a una máquina proporcionada por proveedor de servicio de Internet (ISP). Esta máquina tiene dos opciones: o dispone de la “respuesta” almacenada en su memoria o necesita realizar la consulta de forma recursiva a otros servidores del ISP.
Si ninguno de estos servidores dispone de la dirección IP almacenada, realizarán la consulta a otros servidores raíz.
Estos servidores raíz redireccionarán la consulta a los servidores de dominio de nivel superior en función de la consulta (en nuestro caso, el servidor encargado del dominio .es).
Cada servidor de dominio de nivel superior tiene su propio conjunto de servidores autorizados a los que preguntar sobre el dominio de segundo nivel.
Una vez que el servidor raíz conozca la dirección del servidor que dispone de la información consultada, informa al servidor recursivo del ISP. Es ahora cuando este servidor contacta con el servidor de dominio con la información deseada y obtiene la dirección IP del dominio consultado.
El siguiente paso consiste en almacenar esta información (dominio y dirección IP) en la memoria caché de los servidores recursivos del ISP con el objetivo de mejorar el tiempo de respuesta para la próxima vez que un usuario busque dicho dominio.
Finalmente, el servidor recursivo devuelve la información al ordenador del usuario, que a su vez proporciona al navegador web la información necesaria para que este sepa la dirección IP a la que debe de realizar la conexión. Posteriormente, el usuario podrá ver la información contenida en dicho dominio.

Este es el proceso que se debe de seguir para obtener la dirección IP asociada a un nombre de dominio. Esto ocurre generalmente en apenas décimas de segundo y es transparente para el usuario final.

Funcionamiento de DNSSEC

A raíz de la necesidad de incluir medidas de seguridad en DNS debido a las vulnerabilidades detectadas en el mismo, surge la tecnología de Extensiones de seguridad del DNS, DNSSEC para proteger este aspecto de la infraestructura de Internet.

DNSSEC es una tecnología que se ha desarrollado, entre otras cosas, para brindar protección contra este tipo de ataques mediante la firma digital de los datos a fin de tener la seguridad de que son válidos. Sin embargo, para eliminar esta vulnerabilidad de Internet, esta tecnología se debe implementar en cada uno de los pasos del proceso de búsqueda, desde la zona raíz hasta el nombre de dominio final. La firma de la raíz (implementar DNSSEC en la zona raíz) es un paso necesario de este proceso general. Es importante destacar que no cifra los datos. Tan solo certifica la validez de la dirección del sitio que se visita.

Este protocolo proporciona mecanismos de verificación de:

Integridad de la respuesta para demostrar que no ha sido alterada desde el origen.
Autenticidad de la respuesta para demostrar que procede del servidor legítimo.
Autenticidad de respuestas negativas para demostrar los recursos inexistentes en la zona.

Otra característica de este protocolo seguro consiste en implementar firma digital mediante un esquema de clave pública en todos los niveles de la jerarquía DNS. Esta seguridad se basa en el mantenimiento de una cadena de confianza desde la zona raíz (root) que se denomina raíz de confianza. Además, se firman los recursos de la zona y se incorporan estas firmas como un registro más de la respuesta DNS.

Arquitectura DNSSEC

En el siguiente esquema se puede observar la arquitectura básica del protocolo DNSSEC:

En el esquema anterior se pueden diferenciar los siguientes elementos:

RRSet(). Es como se denomina a un conjunto de recursos de un tipo concreto que tiene una zona específica. Siguiendo la definición de recursos que se realiza en el protocolo DNS se pueden destacar los siguientes recursos:

Registro A es el registro de dirección
Registro MX es el registor de intercambio de correo
Registro NS es el registro de servidor de nombres

DNSKEY(). Es la clave pública que le tiene que proporcionar el servidor a los resolvers que le pregunten sobre algún recurso en particular. Aquí se firma con la clave KSK por lo tanto, la clave KSK que se transmite iría autofirmada junto con la clave ZSK pública firmada con la propia clave KSK. Un atacante podría suplantar la identidad y darnos sus propias claves autofirmadas. Para ello lo que utilizamos es el DS como cadena de confianza. Este registro es un hash de KSK pública.
DS.Es un recurso calculado por la zona hija y que se transmite al DNS de la zona padre que contendrá los DS de las zonas hija que contenga. De este modo se transmite y se perpetua la cadena de confianza entre los servidores. Hay que tener en cuenta, que la cadena de confianza se va propagando de la zona hija a la zona padre. De este modo, cuando llega una petición al nodo padre, lo que se necesita mandar es el recurso asociado con el servidor de la zona hija y su DS como prueba de que está en la cadena de confianza.
KSK. Clave de firma de clave, una clave de autenticación que corresponde a una clave privada utilizada para firmar una o más claves de autenticación para una zona determinada. La validación de DNSSEC no distingue entre claves de firma de clave y otras claves de autenticación de DNSSEC, y es posible utilizar una única clave como clave de firma de clave y como clave de firma de zona, aunque no sea recomendable. Esta clave es generada por hardware (módulo HSM). Este módulo es al que acceden los guardianes con sus correspondientes smartcards en la ceremonia de generación de claves, del nodo raíz.
ZSK. Clave de firma de zona, una clave de autenticación que corresponde a una clave privada utilizada para firmar una zona. Normalmente, una clave de firma de zona formará parte del mismo conjunto de claves de firma de DNSKEY que la clave de firma de clave cuya clave privada correspondiente firma este conjunto de claves de firma de DNSKEY, pero la clave de firma de zona se utiliza con un propósito ligeramente diferente y puede diferir de la clave de firma de clave en otros aspectos, como la duración de la validez. Esta clave suele ser generada por software a partir de la clave KSK.

Funcionamiento del Protocolo

Antes de comenzar a desarrollar el funcionamiento del protocolo DNSSEC hay que tener en cuenta los siguientes puntos:

Cuando se hace referencia al nodo raíz de DNS no hay que pensar en un único servidor respondiendo a las peticiones de los usuarios de todo el mundo. Este servidor raíz está replicado por todo el mundo (cientos de servidores), para evitar cualquier tipo de latencia en la respuesta. La responsabilidad de operar y gestionar estos nodos se reparte entre las siguientes organizaciones/autoridades:

Hay que tener en cuenta que cada hostname está replicado en varias localizaciones del mundo y, por tanto, cada una de las organizaciones/autoridades incluidas en la tabla mencionada deben de hacerse cargo del mantenimiento de dichos servidores. En España, hay unos 13 servidores raíz (distribuidos entre Madrid y Barcelona). Además, IANA proporciona la siguiente distribución global de servidores raíz (el número de cada indicador del mapa dice el número de servidores raíz que hay en una determinada zona:<\p>

Siguiendo la jerarquía del protocolo DNS, el resto de dominios son hijos del nodo raíz. Así, por ejemplo, el dominio .com es un nodo hijo del nodo raíz y es responsabilidad de la organización VeriSign. IANA proporciona la lista de los dominios de los cuales se hace responsable junto con los datos de contacto de la organización/persona física propietaria del dominio.
Cuando se hable del nodo/servidor resolver hay que tener en cuenta que se trata del servidor DNS que proporciona el ISP para que los usuarios que han contratado dicho ISP tengan un servidor DNS al que hacer las peticiones. Aquellas peticiones que no tenga en la memoria caché dicho nodo resolver tendrá que consultarlas con el nodo DNS que corresponda, siguiendo la jerarquía del protocolo DNS.

A continuación, se explicará un ejemplo con el objetivo de entender los cambios que introduce el protocolo DNSSEC con respecto al protocolo DNS. Hay que tener en cuenta que este protocolo está diseñado para coexistir con DNS. Para ello, el flag “DO – DNSSEC OK” es el medio con el que un servidor es informado por un servidor recursivo de que este último tiene capacidades de DNSSEC. A partir de este momento el servidor DNS autoritativo le proporcionará al servidor el recurso que le haya solicitado junto con la información necesaria para validarlo.

En el ejemplo, el resolver solicita el recurso www.example.com al servidor raíz (pasos (1) y (2)). Este servidor proporciona el registro NS junto con la firma de este registro con la clave privada de ZSK, el registro de confianza DS junto con su firma a partir de la clave privada de la clave de la zona ZSK y las DNSKeys junto con su firma realizada con la clave KSK pública al servidor resolver (respuesta en los pasos (1) y (2)). Hay que recordar que, el registro DS es un hash de la clave pública KSK y la firma de este registro se hace con la clave privada de la clave de la zona ZSK, por lo que el resolver deberá de calcular dicho hash para verificar que la cadena sigue siendo de confianza. El objetivo del envío de esta información es el de proporcionar la información solicitada (en este caso sería el registro NS, ya que el servidor autoritativo no dispone de la información que busca el nodo resolver y por lo tanto le tiene que indicar cual es el siguiente “salto”), las claves con la que firma la información y el registro DS para demostrar que es un nodo “fiable”.

El servidor resolver realizará la verificación (sección 4.3 Validación) para comprobar que el servidor raíz es de confianza y a continuación procederá a realizar la consulta al servidor DNS autoritativo .com (pasos (3) y (4)) el cual le responde con el registro NS (de example.com), el registro de confianza DS y las claves DNSKeys junto con sus respectivas firmas para continuar comprobado la fiabilidad del servidor autoritativo en cuestión.

Finalmente, el resolver obtiene la información que necesitaba en un principio y procede a contactar con el servidor que contiene el recurso www.example.com. Este servidor le proporciona el recurso (aquello por lo que pregunta, en este caso, la dirección IP del dominio www.example.com), las claves DNSKey y sus respectivas firmas al servidor resolver (pasos (5) y (6)).

Verificación

La verificación es otro de los procedimientos importantes de DNSSEC. Es necesario que cada servidor procese la información que haya recibido de un determinado servidor DNS autoritativo y verifique la integridad de la información recibida. Para ello, es necesario verificar los siguientes puntos:

Anclaje de confianza (con la zona padre). Se verificará la autenticidad de la clave KSK para confirmar que procede del servidor autoritativo de la zona.
Clave de firma de zona (ZSK). Se verificará la autenticidad de la ZSK para confirmar que pertenece al servidor autoritativo de la zona y, además, se verificará la integridad de los recursos servidos para confirmar la garantía de la cadena de confianza.
Recurso DNS solicitado. Se verificará la autenticidad del recurso mediante la verificación de la firma del servidor autoritativo y además se verificará la integridad del recurso para comprobar que no haya sido alterado desde el origen.

A continuación, se explicará un ejemplo sobre el procedimiento de validación en DNSSEC. Para empezar, en el nodo raíz el procedimiento aparece en la siguiente ilustración:

El nodo resolver debe de validar los siguientes recursos procedentes del nodo raíz:

DNSKey “.” (KSK). La clave pública de la clave KSK debe de ser validada con el objetivo de confirmar la identidad del servidor raíz. Este es un caso especial ya que es el nodo más alto dentro de la jerarquía. Por ello, este nodo dispone de la clave previamente publicada por el nodo raíz en el propio equipo, es decir, la parte pública de la clave KSK se encuentra en el nodo resolver, con el objetivo de disponer de información para comparar cuando le llegen los distintos recursos procedentes del nodo raíz. Esta clave es “actualizada” por las organizaciones que son responsables de los nodos raiz, las cuales proceden a su actualización una vez que se complete la ceremonia de generación de claves correspondiente. En definitiva, si los dos recursos (la clave recibida y la clave pública KSK que tenía previamente en el propio equipo) coinciden se puede determinar que se ha validado la confianza en el anclaje (KSK).
DNSKEY “.” (ZSK). El siguiente paso consiste en validar la clave pública de la clave de la zona ZSK. Para ello se necesita la clave pública previamente adquirida y la firma de la propia clave ZSK para, aplicar el algoritmo de validación (el cual puede variar pero normalmente se utiliza RSA con SHA 256, si bien se está empezando a reemplazar por algoritmos de curva elíptica) y comparar con la clave ZSK proporcionada por el servidor raíz. Si el procedimiento es éxitoso se puede determinar que la clave ZSK procede del servidor raíz.
DS “.com”. Este es el recurso relacionado con la cadena de confianza y por lo tanto el nodo resolver debe de validarlo. Para ello se utiliza la clave pública de la zona (que acaba de ser validada) y la firma del recurso DS. Una vez más, si el algoritmo de validación proporciona el mismo valor que el recurso en cuestión, la validación se considera éxitosa.
NS “.com”. Este es el recurso solicitado en este ejemplo. El proceso de validación es igual que el proceso descrito anteriormente.

El siguiente nodo .com proporcionará al nodo resolver los siguientes recursos que deberá de validar:

DNSKey “.com” (KSK). La clave pública de la clave KSK debe de ser validada con el objetivo de confirmar la identidad del servidor .com.En este caso, disponemos de un hash de la clave pública que nos ha servido el nodo de la zona padre y que calcula el nodo resolver. A continuación, se utiliza esta información para validad la cadena de confianza con el nodo padre. Por lo tanto, si los dos recursos coinciden se puede determinar que se ha validado la confianza en el anclaje (KSK).
DNSKEY “.com” (ZSK). El siguiente paso consiste en validar la clave pública de la clave de zona ZSK. Para ello se necesita la clave pública del nodo .com y la firma de la clave ZSK para posteriormente, aplicar el algoritmo de validación (el cual puede variar pero normalmente se utiliza RSA con SHA 256) y comparar con la clave ZSK. Si el procedimiento es éxitoso se puede concluir con la confianza de las claves de firma de la zona “.com”.
DS “example.com”. Este es el recurso relacionado con la cadena de confianza y por lo tanto el nodo resolver debe de validarlo. Para ello se utiliza la clave pública de la zona (que acaba de ser validada) y la firma del recurso DS. Una vez más, si el algoritmo de validación proporciona el mismo valor que el recurso en cuestión, la validación se considera éxitosa.
NS “example.com”. Este es el recurso solicitado en este ejemplo. El proceso de validación es igual que el proceso descrito anteriormente.

Finalmente, el nodo resolver será “dirigido” al último paso antes de obtener el recurso final deseado. El procedimiento queda reflejado a través de la validación, por parte del nodo resolver de los siguinetes pasos:

DNSKey “example.com” (KSK). La clave pública de la clave KSK debe de ser validada con el objetivo de confirmar la identidad del servidor example.com.En este caso, disponemos de un hash de la clave pública que nos ha servidor el nodo de la zona padre y que calcula el nodo resolver. A continuación, se utiliza esta información para validar la cadena de confianza con el nodo padre. Por lo tanto, si los dos recursos coinciden se puede determinar que se ha validado la confianza en el anclaje (KSK).
DNSKEY “example.com” (ZSK). El siguiente paso consiste en validar la clave pública de la clave de zona ZSK. Para ello se necesita la clave pública del nodo example.com (recién validada en el paso anterior) y la firma de la clave ZSK para posteriormente, aplicar el algoritmo de validación (el cual puede variar pero normalmente se utiliza RSA con SHA 256) y comparar con la clave ZSK. Si el procedimiento es éxitoso se puede concluir con la confianza de las claves de firma de la zona “.com”.
A “www.example.com”. Este es el recurso solicitado en este ejemplo. El proceso de validación es igual que el proceso descrito anteriormente.

Tal y como se puede observar, el uso de DNSSEC aumenta en gran medida el procesamiento con respecto al que hace un servidor DNS convencional. Debido a esto se intenta reducir el impacto mediante el uso de claves ZKS más cortas que las KSK a cambio de renovarlas cada tres meses.

Proceso de Rollover de las claves

Por regla general, el proceso de generación de nuevas claves (ya sean las claves KSK o ZSK), generalmente se realiza un despliegue previo de las claves con el objetivo de evitar que un servidor tenga que firmar dos veces todos los datos de la zona. Para ello se siguen los siguientes pasos:

Fase inicial: el funcionamiento es el correcto y esperado, disponemos de una clave KSK y otra ZSK.
Nueva clave: se introduce una nueva clave dentro del conjunto de claves que dispone el servidor. En este momento todavía no se han generado firmas con esta clave todavía. Hay que esperar a que se propague la información de esta nueva clave a los servidores autoritativos más el tiempo TTL que dure la caché con la información de la clave antigua.
Nuevas firmas: una vez que las memorias caché se eliminen y se precise firmar de nuevo la información, los servidores autoritativos comenzarán a incluir la nueva clave generada.
Fase de borrado: una vez que el proceso anterior haya finalizado se borrarán las claves antiguas para que no se vuelva a firmar información con ellas. Hay que tener en cuenta que el proceso de implantación y dispersión de las claves es similar tanto para la clave KSK y la ZSK. La diferencia principal es la frecuencia en la que se realiza el proceso. Se recomienda que KSK se renueve una vez al año y ZSK cada 3 meses, no obstante, la generación de nuevas claves KSK suele ser más dilatada en el tiempo (cada 7 años).

Negociación explícita de la existencia

Esta es una de las características nuevas del uso de DNSSEC. El protocolo DNS no está preparado para dar una respuesta del tipo: “la petición DNS solicitada no existe”. Debido a esto, a DNSSEC se le plantea la problemática de validar este tipo de situaciones mediante la infraestructura de claves que tiene. Por lo tanto, DNSSEC corrige esto añadiendo los tipos de registro NSEC y NSEC3. Ambos permiten una autenticación de la negación de existencia.

El funcionamiento de NSEC consiste en devolver el siguiente registro seguro. Por ejemplo, si un servidor contiene varios recursos y se le pide un recurso que no existe, el registro NSEC guardará el último registro y por lo tanto la petición contendrá información para poder ser firmada. El servidor resolver que reciba esta información deducirá que la respuesta no existe porque el campo NSEC está relleno.

Un problema asociado que surge del uso de este campo de DNSSEC es que un servidor infectado podría hacer un “inventario” de toda la información que contiene un servidor autoritativo utilizando la información que aparece en este campo. La solución ha sido utilizar un nuevo campo llamado NSEC3 el cual envía el hash de los recursos incluidos en este registro. De este modo, un servidor malicioso no recibiría información adicional de una respuesta “vacía”. Esto plantea otro problema: adivinar el hash mediante técnicas de fuerza bruta no es complicado y, por lo tanto, el uso del campo NSEC3 no es seguro totalmente tampoco.

No hay que olvidar, que el protocolo DNS, en términos generales, no es un protocolo que contenga información privada y confidencial, pero si es cierto que hay cierta preocupación con la posibilidad de que un atacante pueda recopilar más información de la necesaria y pueda realizar un ataque mayor a una organización determinada utilizando esta información.

Problema de la última milla

Existe un problema relacionado con la implantación de servidores proxy transparentes para DNS por parte de los ISPs. Estos servidores proxy están configurados para interceptar el tráfico DNS y redirigirlo al servidor autoritativo correspondiente. Esto supone un fallo de seguridad debido a que es una prueba de que, dentro de la red del ISP se puede redireccionar el tráfico DNS sin implementar DNSSEC y que hasta que no llegue al nodo resolver no se podrá tener la confianza de estar utilizando DNSSEC. La propuesta realizada sería utilizar, además, confidencialidad durante el proceso de petición/respuesta del protocolo DNS. Las soluciones actuales se basan en encapsular el paquete DNS dentro del protocolo HTTPS y TLS:

DoH (DNS over HTTPS)
DoT (DNS over TLS)

Por lo tanto, con el objetivo de proporcionar confidencialidad, autenticidad y privacidad, se recomienda el uso de la combinación DNSSEC y DoH/DoT.

Guardianes de Internet

Teniendo en cuenta la importancia de este sistema, se hace necesario medidas exigentes de seguridad para proteger el funcionamiento de DNS y, en definitiva, de Internet. Para ello la máxima responsable de este sistema, ICAAN (Internet Corporation for Asigned Namens and Numbers, la cual es una asociación sin ánimo de lucro fundada en 1998 cuyo objetivo es asegurar que Internet sea segura, estable e interoperativa) creó en 2010 un nuevo sistema de seguridad.

La medida de seguridad consiste en el uso de 14 llaves secretas que protegen el sistema. Estas 14 llaves están en manos de 14 personas en el mundo y se trata de evitar que en un mismo país haya demasiados guardianes. Dos veces al año vuelan desde su país de residencia a Estados Unidos para participar en una curiosa ceremonia que se celebra de manera alterna en dos sedes. Siete lo hacen en Los Ángeles, en invierno y verano y siete en Virginia en otoño y primavera (las dos sedes están separadas por 4250 km con el objetivo de garantizar que, si sufre un ataque o un desastre, como un terremoto, las otras sigan funcionando).

Estas 14 personas son lo que se conoce como "guardianes" aunque su nombre oficial es Trusted Community Representatives (TCR). Hay dos tipos de TCR con distintas funciones

Crypto Officer.Son los encargados de asistir a cada ceremonia para poder acceder a las smartcards que encienden el módulo HSM para generar las nuevas claves de zona (claves ZSK). En total hay 14 personas designadas con este rol (7 en cada una de las sedes mencionadas) y deben de asistir como mínimo 3 personas para poder habilitar el módulo criptográfico. Generalmente, se suele consultar a los 7 que deban asistir a una ceremonia para conocer su disponibilidad durante un periodo de 4 días por si hay algún imprevisto en el día prefijado de la ceremonia y hay que aplazarlo al día siguiente.
Recovery Key Share HolderEs responsable de proteger una parte de una clave utilizada para cifrar las copias de seguridad de los contenidos del módulo HSM. Cada una de las personas que tengan este rol son responsables de mantener una smartcard (con su correspondiente bolsa a prueba de manipulaciones) en una caja de seguridad de un banco, el cual sea accesible por ellos. Hay 7 personas con este rol designado y en principio, no deben de asistir a las ceremonias ya que su finalidad es poder acceder a la información de la clave privada que contiene el módulo HSM en un momento dado. No obstante, deben de ser capaces de asistir a una ceremonia en relativamente poco tiempo y además, deben de proporcionar pruebas de que contienen intactas sus Smartcards de forma anual (parece ser que, con una foto demostrando que la bolsa anti tamper sigue intacta, es suficiente).

La ceremonia, cuya duración es de unas dos horas y media, tiene la finalidad de generar nuevas claves de zona a partir de una llave maestra tiene máximas medidas de seguridad y transparencia, ya que es retransmitida por streaming. En dicha ceremonia participan testigos, personal de seguridad, informáticos y al menos tres de los siete Crypto Officers.

Cada uno de los guardianes debe de ir pasando una serie de controles. Identificarse con su pasaporte, escáneres de retina y sensores biométricos de la palma de la mano. En total son siete niveles de seguridad hasta llegar a la habitación donde se encuentra el dispositivo que generará la nueva clave raíz. Esta clave solo puede activarse con la participación simultánea al menos 3 guardianes. Los niveles de seguridad se pueden categorizar en los siguientes:

Tiers 1-2.El acceso físico es registrado y solo se considera como personal autorizado a aquel personal que tiene el permiso de acceder al edificio sin escolta. A partir de este nivel de seguridad el acceso ya es con escolta.
Tiers 3-5.El acceso físico a la siguiente instalación es registrado y grabado en vídeo. El acceso aquí ya es mediante un doble factor de autenticación (escáner de retina y sensores biométricos de la palma de la mano). Aquel personal que no tenga escolta no puede acceder a este nivel.
Tiers 6-7.El acceso aquí es al HSM y al lugar donde se encuentran las tarjetas. Estos componentes se encuentran en cajas fuertes cerradas, con bolsas anti-tampering y cajas seguras. El acceso a la taquilla que guarda las tarjetas se debe de hacer mediante una llave que ha sido proporcionada antes a los guardianes.

Si algo falla o alguien se salta el guion, todo se paraliza. En casos extremos se autodestruyen las tarjetas inteligentes que se utilizan para acceder a un dispositivo HSM que contiene una parte una clave maestra KSK (Key Sign Key).

En ambas sedes se custodia un HSM que genera la clave KSK y que almacena la parte privada de la misma. Cada tres meses se utiliza la clave maestra almacenada (KSK privada) en un HSM para firmar las claves de zona que se van a utilizar en el siguiente trimestre. El objetivo es evitar darles tiempo a los piratas informáticos a desvelarlas mediante ataques de fuerza bruta, en los que van probando miles de millones de combinaciones. El motivo de esta problemática está relacionado con que las claves ZSK generalmente son más cortas para facilitar a nivel de CPU el procesamiento de las peticiones DNSSEC. Así que cada tres meses se cambian estas claves para evitar que, por fuerza bruta, un atacante pueda sacar a partir de la firma, la clave privada.

Como ya se ha mencionado, es necesario que cada uno de los guardianes pasen los niveles de seguridad mencionados hasta llegar a una especie de jaula en la que se guarda un dispositivo conocido como Módulo de Seguridad de Hardware (HSM). Este dispositivo carece de conexión a Internet y solo se puede utilizar una vez que los guardianes hayan introducido sus correspondientes smartcards. Para controlar este dispositivo se utiliza un ordenador portátil sin conexión a Internet, sin disco duro ni batería para poder realizar la comunicación con el módulo HSM a través de un cable Ethernet. El Sistema Operativo de este equipo se arranca mediante DVD y la memoria para registrar los logs generados durante el proceso consiste en una memoria USB. Además, cuando se realiza la generación de nuevas claves KSK (la cual, a día de hoy, solo se ha producido una vez desde 2010) se realiza en nuevos módulos HSM y se pasa a eliminar de forma segura (mediante zeorization) la información incluida en los módulos antiguos e incluso se destruyen los dispositivos reemplazados en la misma ceremonia mediante una máquina específica.

Este dispositivo, además, resiste cualquier tipo de manipulación y en caso de intrusión, borra automáticamente las claves que almacena. Estadísticamente, según la ICAAN “la posibilidad de una conspiración que pueda comprometer las claves es de una entre un millón, asumiendo un índice de deshonestidad del 5 por ciento entre los individuos que participan en la ceremonia”.

A modo de resumen se pueden tener en cuenta los siguientes puntos importantes de la ceremonia:

Con las Smart Cards de los Crypto Officers (nombre oficial de los guardianes) se puede acceder al HSM.
El HSM tiene la clave privada de la KSK.
La frecuencia de generación de nuevas claves ZSK se hace de forma trimestral, la generación de la clave KSK solo se ha hecho una vez desde 2010 hasta hoy.
Con esta clave se firman las ZSK nuevas para que se comience a utilizar en el siguiente trimestre.
Después se hace un backup de la información que se ha generado y se desactiva el HSM y se guarda de nuevo.

Finalmente se envían las claves (pública y privada en el caso de la clave ZSK) al ICANN y a VeriSign. Pueden mandarse (de hecho, lo hacen así en varias reuniones) por correo firmado o mediante una web segura. En el caso de las claves KSK, hay algunas diferencias debido a su importancia, las cuales se tratarán en la sección 4.5.

Caja fuerte

Hay dos cajas fuertes en las habitaciones de cada una de las sedes. Una (en la imagen) contiene cajas de seguridad parecidas a las que se pueden encontrar en un banco. En estos depósitos se hallan las tarjetas inteligentes con las que los guardianes obtienen el permiso para activar el módulo de hardware HSM que se utilizará para firmar las nuevas claves ZSK de zona. La otra contiene el módulo en sí. Hay dos dispositivos en cada sede, por si el otro se avería.

Nuevas firmas generadas

Las nuevas claves (con sus correspondiente parte pública y privada de la clave ZSK) generadas serán transmitidas por un operario de la ICAAN a través de una conexión segura a VeriSign, una compañía estadounidense que gestiona infraestructuras de red.

Los guardianes deben de introducir sus claves con el objetivo de que se verifique que no haya existido ningún tipo de manipulación en la clave maestra y entonces, comienza el proceso de generación de las firmas de las claves de zona ZSK a partir de la clave privada de la clave maestra (KSK). Para ello, el HSM (el cual, si sufre una caída o es golpeado demasiado fuerte, se autodestruirá) comienza con la generación de las nuevas claves de zona ZSK a partir de la parte privada de la clave KSK.

Una vez que se hayan generado las firmas, se procede a realizar una copia de las firmas generadas para proceder a enviarlas a VeriSign y a la ICANN. Este envío de información se realizará a través de un correo firmado o mediante el uso de una web segura. Es necesario tener en cuenta que estas firmas comenzarán a tener validez a partir de la ceremonia que se realiza en el siguiente trimestre.

Importancia del proceso

Estas medidas de seguridad son necesarias ya que si, el sistema se viese comprometido, Internet podría dejar de ser “fiable” como lo conocemos. Un posible atacante podría realizar un Phishing a nivel mundial ya que podría engañar a cualquier usuario y proporcionar direcciones IP distintas para obtener información confidencial de cada uno de los usuarios que utilizan Internet. Los guardianes podrían reiniciar el sistema completamente en el caso de que se vea comprometida la integridad del sistema DNSSEC para solucionar cualquier tipo de ataque de las dimensiones que se están tratando. Hay que ser conscientes de lo susceptible a un ataque Man In The Middle que es el protocolo DNS ya que un atacante puede analizar el tráfico DNS y suplantarlo sin que un usuario pueda verificar la procedencia de las respuestas recibidas. Si un atacante intercepta las comunicaciones de un DNS recursivo, puede redireccionarlas a sí mismo o a otro servidor infectado para realizar un ataque de phishing.

Primera rotación de claves realizada

El 15 de octubre de 2018, la ICANN procedió a realizar el primer cambio de la clave criptográfica KSK que ayuda a proteger el Sistema de Nombres de Dominio (DNS) el cual, se ha completado con una interrupción mínima de la Internet global tal y como la conocemos. Ha sido la primera vez que se ha cambiado la clave desde que se puso en uso por primera vez en 2010.

Tras evaluar los datos disponibles, no parece que haya un número significativo de usuarios finales de Internet que se hayan visto afectados negativamente por el cambio de clave.

Existieron algunos problemas durante la ceremonia pero que no supusieron fallos importantes en el sistema global y que, por lo tanto, no influyeron en el funcionamiento normal de Internet (definido por la comunidad de ICANN). En ese contexto, la transferencia de la nueva clave de firma de claves, conocida como KSK 2017, ha sido un éxito.

En este punto, la ICANN procederá al siguiente paso en el proceso de transferencia: la revocación de la antigua KSK, conocida como KSK 2010, durante la próxima ceremonia que se celebre en el primer trimestre de 2019.

Otro punto importante a tener en cuenta es el modo en el que se transfiere de una sede a otra la parte privada de la clave KSK. Después de la generación de la clave privada y de la finalización de la ceremonia,s e exporta la clave encriptada con lo que se conoce como SMK (Storage Master Key, de acuerdo con las espécificaciones técnicas del AEP Keyper HSM, el cual, es el modelo de HSM utilizado en las ceremonias) en una smartcard y se introduce en una bolsa anti-tamper y se transporta a la otra sede por un transportista. Después, en la otra sede se procede a introducir en la caja fuerte correspondiente la smartcard, comprobando previamente que la bolsa no ha sido manipulada en el proceso de transporte. Una vez se guarda la smartcard que contiene la clave privada, se procede a cerrar la caja fuerte y en la siguiente ceremonia se importa dicha clave en el HSM correspondiente, el cual deberá de tener la misma SMK que el dispositivo HSM que exportó la clave y se continúa con el procedimiento de generación de las nuevas claves ZSK. Esta clave SMK está relacionada con la clave de acceso a los HSM. Como ya se ha comentado anteriormente, para acceder al dispositivo HSM, es necesaria la colaboración de al menos 3 de los guardianes. Esto es posible gracias a la característica M of N la cual permite realizar una división de la clave de autenticación del HSM (con la restricción de necesitar al menos 3 de esas “divisiones”).

A pesar de que pueda parecer que el transporte de la clave KSK sea poco seguro y suponga una amenaza al sistema implementado, hay que tener en cuenta que el despliegue de las nuevas claves ZSK que se firmen con esta nueva clave KSK generada, no se realiza hasta que se celebre la próxima ceremonia. Por este motivo, en caso de que la clave KSK transportada sufra algún tipo de manipulación, no se vería afectada la seguridad de DNSSEC ya que se podría generar una nueva clave KSK y por lo tanto, volver a repetir la ceremonia.

Por último, hay que señalar que este proceso de guardado de la smartcard en la caja fuerte se graba y se registra en el log correspondiente (Script_MediaDeposit_Annotated), de modo que también queda evidencia de que el proceso se ha realizado según lo previsto.

Este tipo de medidas de seguridad tan estrictas provocan reacciones en la comunidad de todo tipo, pero el objetivo principal de la ICANN es demostrar transparencia para que los usuarios puedan confiar en la estabilidad y seguridad del servicio DNS tal y como lo conocemos a toda costa. Esto hace que surgan comentarios divertidos como el siguiente de la cuenta @SwiftOnSecurity:

“Fun fact: During key rotation ceremonies, ICANN has a locksmith ready to drill the locks of the safes holding DNSSEC private keys, if for some reason they won’t open”

No obstante, los usuarios de internet podemos confiar en que no se realiza ninguna manipulación durante el proceso y que se emplean todas las medidas de seguridad necesarias para lograr evitar cualquier tipo de ataque a escala mundial.

Representación en España

La Entidad Pública Empresarial Red.es, adscrita al Ministerio de Industria, Turismo y Comercio a través de la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información, tiene legalmente encomendadas una serie de funciones con el objeto de contribuir al desarrollo de las telecomunicaciones y la sociedad de la información en España.

Red.es entre otras funciones tiene asignada la gestión del registro de nombres de dominio de Internet bajo el código de país correspondiente a España ".es", que incluye todas la funciones relacionadas con la tramitación de solicitudes y asignación de dominios de acuerdo con la normativa correspondiente, así como la realización de las funciones técnicas necesarias para garantizar el correcto funcionamiento del sistema de dominios en España y en la red global de Internet, participando en los organismos internacionales que coordinan de la gestión del sistema de nombres de dominio.

ESNIC (Network Information Center) es un departamento de la entidad pública empresarial Red.es, autoridad competente para la gestión del Registro de nombres de dominio de Internet bajo el código de país “.es”. Se encarga de la tramitación de nuevos dominios y su asignación entre otros.

No existe una relación directa entre Red.es e ICANN. Son dos entidades independientes que se encargan de mantener los dominios en distintos niveles de la jerarquía de DNS. Red.es se encarga de gestionar los dominios a nivel de España e ICANN se encarga de gestionar el nodo raíz de DNS. La ICANN dispone de un departamento que se encarga de supervisar la asignación global de direcciones IP, sistemas autónomos, servidores raíz de nombres de dominio DNS y otros recursos relativos a los protocolos de Internet. Este departamento es lo que conocemos como IANA.

Para tener una idea del rango de operación de cada uno de estos organismos se debe de tener en cuenta en primer lugar de la existencia de dos grandes divisiones de los dominios de primer nivel (TLD). Por un lado, están los dominios gTLD, que son los dominios de primer nivel genéricos (Generic Top Level Domain), entre los cuales figuran los .com, .info, .org o .net. En este tipo se incluyen los dominios patrocinados (sTLD sponsored Top Level Domain), que impulsan colectivos determinados (.cat, .museum, .aero).

Los dominios gTLD deben tener un mínimo de tres caracteres y no están asociados a países. Su gestión corre a cargo de organismos internacionales como la ICANN.

El segundo gran grupo de dominios son los ccTLD (country code Top Level Domain) o dominios de primer nivel de código de país. Entre ellos figuran los .es, .ar, .fr, .mx, etc. Su característica principal es que solo cuentan con dos caracteres y son gestionados por organismos de cada país.

Todos los tipos de dominios que existen en el mundo quedan registrados en el IANA y el dominio .es, es gestionado por la entidad pública Red.es.

También es necesario tener en cuenta que ambos tipos de dominios, cuelgan del nodo raíz, debido a que todos ellos son dominios de primer nivel. Esta dependencia queda reflejada de forma gráfica en la siguiente imagen:

Ataques recientes mediante el protocolo DNS

Todas las medidas de seguridad utilizadas por la ICANN demuestran la preocupación existente para proteger el sistema DNS mediante la utilización de DNSSEC. Esta preocupación no es infundada ni mucho menos exagerada. En esta sección se incluirá información sobre uno de los ataques recientes (Enero de 2019) de secuestro DNS y su impacto.

El gobierno de Estados Unidos, junto con varias empresas de seguridad líderes en el sector, advirtió recientemente sobre una serie de ataques muy complejos y generalizados que permitieron a presuntos hackers iraníes desviar grandes volúmenes de contraseñas de correo electrónico y otros datos confidenciales de múltiples gobiernos y empresas privadas. Esta campaña de cyber espionaje ha sido denominada por Cisco Talos como DNSpionage.

Talos informó en su investigación que los autores del espionaje DNS pudieron robar cuentas de correo electrónico y otras credenciales de acceso a varias entidades gubernamentales y del sector privado en el Líbano y los Emiratos Árabes Unidos mediante el secuestro de los servidores DNS, de modo que todo el tráfico email y de las redes VPN fue redirigido a una dirección de Internet controlada por los atacantes.

Talos informó que estos secuestros de DNS también allanaron el camino para que los atacantes obtuvieran certificados de encriptación SSL para los dominios objetivo (por ejemplo, webmail.finance.gov.gov.lb), lo que les permitió descifrar las credenciales de correo electrónico y VPN interceptadas y verlas en texto plano.

Entre otros muchos dominios, se conoce que se secuestraron dominios relacionados con embajadas, ministerio de finanzas, servicio de policía de Abu Dhabi, servicio de inteligencia de Jordania, etc. El secuestro se basó en cambiar la dirección IP a la que apuntaban los dominios hacia los servidores que controlaban los propios atacantes.

Mediante el análisis del ataque se pudo comprobar que la IP a la que se redireccionaban estos dominios se encontraba en Alemania. Pero el problema no finalizó aquí ya que se consultó los dominios que apuntaban a dicha dirección IP y se descubrieron varios que pertenecían a Suecia. Estos dominios suecos eran propiedad de Netnod Internet Echange, un importante proveedor mundial de DNS con sede en Suecia y operador de uno de los 13 servidores raíz (recordemos, el más alto en la jerarquía DNS).

El CEO de Netnod, Lars Michael Jogbäck, confirmó que partes de la infraestructura DNS de Netnod fueron secuestradas a finales de diciembre de 2018 y principios de enero de 2019, después de que los atacantes obtuvieran acceso a cuentas en el registrador de nombres de dominio de Netnod. También confirmo que “Netnod no era el objetivo final del ataque. Se considera que el objetivo ha sido el robo de los datos de acceso a los servicios de Internet en países fuera de Suecia".

La entidad PCH (Packet Clearing House), la cual gestiona una cantidad significante de la infraestructura mundial de DNS (con más de 500 TLD, varios de ellos repartidos en países de Medio Este) también fue víctima de los atacantes.

El director ejecutivo de la entidad dijo que los hackers falsificaron credenciales que el registrador de PCH usó para enviar mensajes de señalización conocidos como Protocolo de Aprovisionamiento Extensible (EPP). EPP es una interfaz poco conocida que sirve como una especie de back-end para el sistema DNS global, permitiendo a los registradores de dominios notificar a los registros regionales (como Verisign) sobre cambios en los registros de dominios, incluyendo nuevos registros de dominios, modificaciones y transferencias.

Jogbäck reconocío que la infraestructura de Netnod sufrió tres ataques separados de los atacantes de DNSpionaje. Los dos primeros ocurrieron en una ventana de dos semanas entre el 14 de diciembre de 2018 y el 2 de enero de 2019, y fueron dirigidos a servidores de la empresa que no estaban protegidos por DNSSEC.

Sin embargo, el tercer ataque entre el 29 de diciembre y el 2 de enero fue dirigido a la infraestructura de Netnod que estaba protegida por DNSSEC y que servía a su propia red interna de correo electrónico. Sin embargo, como los atacantes ya tenían acceso a los sistemas de su registrador, pudieron desactivar brevemente esa protección, o al menos durante el tiempo suficiente para obtener certificados SSL para dos de los servidores de correo electrónico de Netnod.

Una vez que los atacantes tenían esos certificados, volvieron a habilitar DNSSEC para los servidores objetivo de la compañía mientras aparentemente se preparaban para lanzar la segunda etapa del ataque, desviando el tráfico que transcurre a través de sus servidores de correo a las máquinas controladas por los atacantes. Pero Jogbäck mencionó que por la razón que sea, los atacantes no usaron su acceso no autorizado a su registrador para desactivar la DNSSEC antes de intentar desviar el tráfico de Internet.

Este fue el despiste que hizo posible detectar a los atacantes y detener el avance de su misión de espionaje.

Por otra parte, PCH no sufrió tanto los efectos del ataque ya que su infraestructura está basada completamente en DNSSEC. No obstante, hubo una incidencia con dos empleados que no estaban utilizando el servicio, pero más allá de esto no hubo mayores problemas.

Como PCH había protegido sus dominios con DNSSEC, el efecto del secuestro contra su infraestructura de correo fue que durante aproximadamente una hora en la que nadie, salvo los dos empleados mencionados, recibió ningún correo electrónico, ya que no se podía “verificar” la firma de los atacantes.

Esta situación ha servido a ambas compañías como experiencia para mejorar su infraestructura DNSSEC y han aumentado sus esfuerzos y recursos relacionados con dicha infraestructura. Muchas de estas mejoras están relacionadas con las recomendaciones que hizo John Crain jefe de seguridad, estabilidad y resiliencia de ICANN a raíz de estos ataques:

Usar DNSSEC (tanto para firmar zonas como para validar respuestas).
Usar funciones de registro como Registry Lock que ayuda a proteger los registros de nombres de dominio para que no sean modificados sin una autorización previa del registrador.
Utilizar listas de control de acceso para aplicaciones, tráfico de Internet y monitorización.
Utilizar doble factor de autenticación y exigir que sea utilizada por todos los usuarios y subcontratistas pertinentes.
En los casos en que se utilicen contraseñas, escoger contraseñas únicas y considerar la posibilidad de utilizar administradores de contraseñas.
Revisar cuentas con registradores y otros proveedores.
Supervisar los certificados mediante la supervisión, por ejemplo, de los registros de transparencia de certificados, cuyos componentes aumentan el modelo de la cadena de confianza al proporcionar soporte para la supervisión y el escrutinio público de todo el sistema de certificados SSL.

Además, la ICANN también propone la siguiente lista de medidas a tener en cuenta para los responsables de gestionar servidores DNS de dominios importantes:

Asegurarse que todos los parches de seguridad del sistema hayan sido revisados y aplicados.
Revisar los archivos de registro para comprobar si hay acceso no autorizado a los sistemas, especialmente el acceso de administrador.
Revisar los controles internos sobre el acceso de usuarios con permisos de administrador.
Verificar la integridad de cada registro DNS y el historial de cambios de esos registros.
Disponer de una complejidad de contraseñas suficiente, haciendo hincapié en su longitud.
Asegurarse que las contraseñas no se compartan con otros usuarios.
Asegurarse de que las contraseñas nunca se almacenan o transmitan en texto plano.
Disponer de una política de cambio periódico de contraseña.
Aplicar una política de bloqueo de contraseñas a partir de varios intentos fallidos.
Asegurarse que los registros DNS de zona estén firmados por DNSSEC y que los nodos resolvers implementan la validación de DNSSEC.
Seguir con las recomendaciones que realizó la ICANN a raíz de los ataques que se han mencionado en esta sección.

No obstante, gran parte del problema que sufrieron ambas entidades está relacionado con el escaso uso de DNSSEC a nivel global en la actualidad.

Uso de DNSSEC en la actualidad

Desafortunadamente, el uso de DNSSEC no se está extendiendo a la velocidad deseada y actualmente el número de zonas firmadas es inferior al 1% tal y como se puede observar en la siguiente gráfica:

Un elemento fundamental para que un dominio se pueda utilizar DNSSEC es que los dominios que se encuentran por encima en la jerarquía lo estén. En este caso, cabe indicar que, a nivel operacional, el estado de implantación de DNSSEC es bastante bueno, tal y como se puede observar en la siguiente imagen:

Teniendo esto en cuenta, sería posible en España, por ejemplo, utilizar DNSSEC por cualquier dominio ya que el dominio .es y el dominio raíz lo están implantando y se puede aumentar, por tanto, la cadena de confianza.

Este último punto es básico y a su vez muy importante ya que, el primer paso para implementar DNSSEC a nivel mundial es que se pueda confiar en todos los nodos raíz que haya desplegados en el mundo. Actualmente el porcentaje de implantación es de un 91%.

Desgraciadamente, el estado de implantación de España es bajo, tal y como se puede observar en la siguiente gráfica:

Bibliografía

A continuación se hace un listado de aquellos enlaces de interés relacionados con los guardianes de internet y DNSSEC para acceder a información de mayor profundidad: