¿Cómo prepararse para el cambio de la llave principal para firma de DNSSEC (Root Key Sign Key KSK) el 11 de octubre de 2018?
¿Cómo prepararse para el cambio de la llave principal para firma de DNSSEC (Root Key Sign Key KSK) el 11 de octubre de 2018?
¿Tus sistemas están preparados para que el servicio de DNS
siga funcionando en tus redes?
Mañana, jueves 11 de octubre de 2018, a las 16:00 UTC, la
ICANN cambiará la clave criptográfica que se encuentra en el centro del sistema
de seguridad DNS, lo que llamamos DNSSEC. La clave actual está en uso desde el
15 de julio de 2010. Este es un reemplazo que se ha planificado durante mucho
tiempo.
Si todo sale bien, nadie lo notará y todos sus sistemas
funcionarán normalmente. Sin embargo, si sus resolutores de DNS no están listos
para usar la nueva clave, es posible que sus usuarios no puedan acceder a
muchos sitios web, enviar correos electrónicos, usar redes sociales o
participar en otras actividades de Internet. Esto está dirigido particularmente
a los proveedores de servicio de Internet, proveedores de telecomunicaciones y
organizaciones que tienen un servidor de nombres local, que tienen servicios de
resolución de nombres que implementan DNSSEC como parte de la cadena de
confianza para la resolución de nombres a través de toda la red de internet. No
es algo que el usuario común o una empresa en general deba hacer.
Este cambio de la clave de seguridad central para DNS se
conoce como "Rollover de la llave principal para firma (KSK)". Ha
estado en discusión y planificación desde 2013. El ICANN (Internet Corporation
for Assigned Names and Numbers), la corporación de Internet para asignación de
nombres y números, ha publicado distintos artículos e información al respecto
desde entonces y pueden encontrarse en:
Este cambio estaba previsto para realizarse hace un año, en
2017, sin embargo se decidió dar más tiempo a las organizaciones para que actualizaran
sus KSK. Para octubre del año pasado estos son los números de organizaciones que
ya tenían implementada la nueva llave KSK-2017:
Duane Wessels, DNS OARC 27
Es decir, hace un año, arriba del 90% de las organizaciones que
reportaron su estado ya estaban utilizando la llave de 2017. Se esperaría que
en un año, la mayoría del 10% de organizaciones restantes ya hubiera
actualizado sus llaves (https://blog.apnic.net/2017/10/03/not-rolling-ksk/
).
Para entender qué significa este cambio es importante
entender qué es el DNS. Si ya saben qué es esto pueden saltar a la siguiente
sección del artículo sobre qué hacer para actualizar sus servidores de DNS.
DNS significa Domain Name Service, se refiere a un servicio
que se dedica a convertir las direcciones de nombres de dominio –que son
fáciles de recordar, como asociaciondeinternet.mx– a las direcciones IP que
les corresponden. Las direcciones IP son la forma de identificar de manera
única a los equipos que se conectan al Internet, de forma similar a los números
telefónicos. Así computarizamos un directorio o agenda telefónica para no tener
que memorizar los números telefónicos de todas las personas con las que nos
comunicamos. Los servidores DNS sirven para convertir las direcciones de nombre
de dominio en una dirección IP.
Cuando el servicio local de nombres (este puede ser el
router local en su casa u oficina) no conoce una dirección, pregunta al servidor
al cual está conectado; en este caso puede ser el del proveedor de servicios de
internet. Si éste tampoco conoce la dirección, pregunta a sus vecinos buscando
aquellos que tienen autoridad para resolver cada una de las porciones de una
dirección, por ejemplo .mx, .com, etcétera. Estos a su vez preguntan a sus vecinos
hasta encontrar a alguien que responda con una respuesta autoritativa. En un inicio
en el diseño de internet, cualquier proveedor con un resolutor de nombres podía
contestar estas respuestas, lo cual podía propiciar que hubiera un servicio que
diera respuestas falsas a la solicitudes de resolución de nombres, suplantando
así a algún sitio sin que los clientes pudieran percibir la diferencia.
Apnic.net
Por esto se creó el DNSSEC (DNS Security Extensions) de
forma que se agregaron extensiones de seguridad basados en firmas digitales para conocer
la identidad de los resolutores de nombres que están dentro de la cadena de
confianza para resolver direcciones. Para implementar estas extensiones se ocupan
llaves que cada uno de los resolutores obtiene de una autoridad superior; a su
vez, ICANN es la autoridad que emite la llave raíz. Con una cadena obtenida de esta
llave raíz de firma (KSK) es que se puede validar si la llave de cada uno de
los resolutores es válida.
Estas llaves son actualizadas cada determinado tiempo para incrementar
su seguridad y prevenir malos usos, de esta forma es que ahora se está actualizando
la llave maestra emitida en 2010 (KSK-2010).
¿Qué ha pasado hasta
ahora?
La ICANN comenzó el proceso de transferencia el año pasado.
Las nuevas claves se han creado y replicado en todos los HSM (Módulos de
seguridad de hardware) en las dos instalaciones que opera la ICANN.
Antes de comenzar el proceso de renovación se realizaron
las pruebas de las implementaciones del RFC5011, documento que describe el
proceso de la actualización de las llaves, y la mayoría de las implementaciones
reportaron el éxito.
La nueva clave se publicó el 11 de julio de 2017, por lo que
el conjunto DNSKEY ahora contiene dos KSK. En ese punto, la nueva clave / KSK- 017
ha entrado en el estado Publicado y convive con la llave anterior KSK-2010.
El cambio estaba programado para el 11 de octubre de 2017, sin embargo se tomó
la decisión de postergar este cambio un año para dar más tiempo a los
interesados. Cualquier resolución de validación que haya estado funcionando
durante al menos 30 días durante la ventana del 11 de julio al 11 de octubre de
2017 debería ya haber colocado la nueva llave en estado "Activo"
antes del 11 de octubre.
¿Qué se puede esperar
el 11 de octubre de 2018 cuando se realice el cambio?
En la mayoría de los casos el cambio será transparente y no
habrá ninguna afectación. Como ya se comentó, el reporte de hace un año indica
que arriba del 90% ya lo había implementado; para finales de septiembre de 2018
(https://blog.apnic.net/2018/09/28/measuring-the-ksk-roll/
) se calcula que arriba del 99.93% ya lo ha implementado.
Es importante mencionar que lo más común es contar con dos
servidores de resolución de nombres, por lo que sería necesario que ninguno de los dos estuviera actualizado para tener una afectación.
Aquellos servidores que no lo hayan implementado podrían
experimentar los siguientes síntomas durante las primeras 48 horas después del
cambio:
-
Lentitud en las resoluciones, reflejada en
general en una lentitud en la navegación, recepción/envío de correos o ejecución
de transacciones
-
Notificaciones de páginas no encontradas
-
Errores en el envío /recepción de mensajes
-
Mensajes truncos y transacciones incompletas
La afectación a usuarios finales se calcula en un porcentaje debajo del 0.01% a nivel mundial y sabemos que los principales proveedores de telecomunicaciones en México y los mayores prestadores de servicios de comercio electrónico, banca y otros servicios en línea en México ya han tomado las previsiones necesarias.
Pero ¿cómo saber si mis
sistemas están listos?
Es importante reiterar que este cambio ya fue retrasado un
año; durante este tiempo la mayoría de los programas de resolución de DNS han
estado anunciando y trabajando con la nueva llave desde entonces. Si su
servidor de DNS está al día con las actualizaciones más recientes, todo debe
estar listo.
1. Pruebe si está haciendo validación de DNSSEC
Antes de hacer algo más, primero debe verificar si está
realizando la validación de DNSSEC en su red. Como se indica en el documento de
orientación de la ICANN, hay que abrir una línea de comandos / terminal /
shell y escribir:
dig @ <IP de su resolución de DNS> dnssec-failed.org a
+ dnssec
Por ejemplo, al usar el servidor DNS público de Google, el comando
sería:
dig @
8.8.8.8 dnssec-failed.org a + dnssec
Si la respuesta incluye este texto:
;;
->>HEADER<<- opcode: QUERY, status: SERVFAIL
entonces se está llevando a cabo la validación de DNSSEC y por
lo tanto su servidor de DNS debe asegurarse de implementar el cambio de KSK.
En cambio, si la respuesta incluye:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
No se está realizando la validación de DNSSEC. Por lo tanto
puede omitir el resto de este artículo, y no tener que preocuparse por el Root
KSK Rollover el 11 de octubre. Sin embargo, sería recomendable leer sobre
DNSSEC y comprender por qué implementarlo para sus validaciones y elevar el
nivel de seguridad y confianza de su porción de la red. (No es necesario
hacerlo antes del 11 de octubre de 2018).
Si está haciendo la validación de DNSSEC hay que considerar
dos puntos:
Desafortunadamente, si no es un administrador de sus
resolutores de DNS, existen mecanismos limitados para verificar si tiene la
nueva clave. Hay un par de posibilidades (consulte # 2 y # 3a), pero de lo
contrario, deberá ponerse en contacto con los administradores de DNS / equipo
de TI y dirigirlos a esta publicación y los otros recursos mencionados.
En algunos casos, la clave raíz DNS / DNSSEC también se
conoce como “ancla de confianza” (root anchor).
2. Pruebe la prueba
KSK de Sentinel
Para un pequeño porcentaje de los servidores involucrados,
es posible que pueda usar la "prueba de Sentinel" que se basa en un
borrador del protocolo de Internet que está en desarrollo. Puede hacerlo en
cualquiera de estos sitios:
En este momento, muy pocos de los servicios de DNS
implementan esta prueba. Esperemos que para el próximo Root KSK Rollover,
dentro de unos años, esto se haya implementado más ampliamente para que los
usuarios regulares puedan ver si están protegidos.
Sin embargo, para la mayoría de nosotros, hay que utilizar otros
métodos:
3a. Compruebe si sus
resolutores de DNS tienen instalado el nuevo Root KSK, a través de distintas
herramientas
Hay varias pruebas que puede realizar en su sistema. La
ICANN ha publicado una lista en la siguiente liga:
Ese documento lista los pasos a seguir para los siguiente
solucionadores de DNS:
·
BIND
·
Unbound
·
PowerDNS
Recursor
·
Knot
Resolver
·
Windows
Server 2012RS and 2016
·
Akamai
DNSi Cacheserve
·
Infoblox NIOS
Para los usuarios de BIND, ISC2 también proporciona un
documento especializado: Root KSK
Rollover in BIND.
3b. Compruebe si sus resolutores
de DNS tienen instalado el nuevo Root KSK, a través de archivos específicos
Si tiene acceso de línea de comando a sus servidores DNS,
puede buscar en archivos específicos para ver si la nueva clave está instalada.
La clave actual ("KSK 2010") tiene una ID de 19036. La nueva clave
tiene una ID de 20326. Estas claves se pueden encontrar en estas ubicaciones en
Red Hat Linux:
·
bind
– see /etc/named.root.key
·
unbound
/ libunbound – see /var/lib/unbound/root.key
·
dnsmasq
– see /usr/share/dnsmasq/trust-anchors.conf
·
knot-resolver – see /etc/knot-resolver/root.keys
Busque allí un registro con un ID de 20326. Si es así, está
todo listo. Si no es así, hay que instalar la nueva clave.
Nota: estas ubicaciones son para Red Hat Linux, CentOS y
Fedora. Otras distribuciones de Linux pueden usar ubicaciones de archivos
ligeramente diferentes; el punto es que debería haber un archivo en algún lugar
de su sistema con estas claves.
Para distinguir la llave anterior de la
nueva de firma de zona se ve así:
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
Y la nueva llave de firma de zona se verá
así:
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOL
AJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3Eg
VLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWe
L3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555Kr
UB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
4. Tener un plan de
respaldo en caso de que haya problemas.
Sería bueno tener un plan de respaldo en caso de que el 11 de octubre haya
problemas de DNS inesperados en su red y los usuarios no
puedan resolver direcciones a través de DNS. Una sugerencia es cambiar
temporalmente sus sistemas para utilizar alguno de los varios servidores DNS
"públicos" que son operados por diferentes compañías. Por ejemplo:
Proveedor
|
IPv4
|
IPv6
|
Cloudflare
|
1.1.1.1
|
2606: 4700: 4700 :: 1111
|
Google
|
8.8.8.8
|
2001: 4860: 4860 :: 8888
|
Quad9
|
9.9.9.9
|
2620: fe :: fe
|
Verisign
|
64.6.64.6
|
2620: 74: 1b :: 1: 1
|
Puede cambiar a uno de estos resolutores mientras resuelve
los problemas con sus propios sistemas. Una vez que haya configurado
correctamente sus sistemas, puede volver a cambiar para que la validación de
DNSSEC se realice lo más cerca posible de sus usuarios (minimizando así las
áreas potenciales de la red donde un atacante podría inyectar tráfico DNS
malicioso).
5. Planee estar
disponible el 11 de octubre de 2018 a las 16:00 UTC
Finalmente, si es un administrador de un servidor de DNS o
de infraestructura de TI, no programe un día libre el 11 de octubre, será un
día para monitorear y estar atento de cualquier anomalía en los servicios de
DNS. Este Root KSK Rollover se ha estado planeando desde hace muchos
años. Debe ser un tema nada fuera de lo común, en el sentido de que será
"sólo un día más en Internet". Probablemente encontrará actualizaciones de estado utilizando el hashtag #KeyRoll en Twitter y otras
redes sociales.
El resultado final de todo esto será la demostración de que
podemos cambiar de manera segura la clave criptográfica raíz del DNS, lo que
nos permite continuar mejorando el nivel de seguridad y confianza que podemos
tener en esta parte vital del núcleo público de la Internet.
Este artículo es una adaptación de:
https://www.internetsociety.org/blog/2018/10/are-you-ready-how-to-prepare-for-the-dnssec-root-ksk-rollover-on-october-11-2018/
Comentarios
Publicar un comentario