🔝 ⭕️ 🍼 Conectividad SSH más segura con DNSSEC 💹 👁️ ⛔️

Todos los que usan SSH saben que la primera vez que se conectan al servidor, aparece un mensaje que confirma la huella digital de la clave. Además, la clave se almacena en el lado del cliente y este mensaje no se vuelve a mostrar hasta que se cambie la clave guardada. Pero, ¿cuál es el significado práctico de este procedimiento?

En la vida real, casi nadie verifica la huella digital de la clave SSH del servidor sin pensar realmente en la posibilidad de ataques MiTM. Con el advenimiento del registro DNS SSHFP, la huella digital de la clave del servidor puede almacenarse en DNS y autenticarse usando DNSSEC. En este caso, ni siquiera necesita confirmar la clave en la primera conexión. Este artículo le mostrará cómo configurar un registro SSHFP para su servidor SSH.

Servidor de prueba

Primero, necesitamos un servidor. En el panel RuVDS, los detalles para el acceso SSH se encuentran inmediatamente en la tarjeta del servidor. Guardamos la dirección IP y la contraseña para la conexión.

También puede configurar el firewall directamente desde el panel de control para permitir el acceso SSH solo para su IP.

Para configurar SSHFP, un dominio debe ser dirigido a la dirección IP del servidor; configuraremos registros DNS para este dominio.

Cómo funcionan las claves en SSH

En los ejemplos, consideraremos solo el paquete OpenSSH, ya que esta es la opción más popular.

Al instalar un nuevo servidor, se generan claves SSH aleatorias, por lo general esto ocurre inmediatamente al instalar el paquete OpenSSH o durante el primer arranque si se utilizan imágenes de sistema listas para usar.

Los archivos clave se encuentran aquí:

$ ls -la /etc/ssh/ssh_host_*_key*

/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub

En esta lista hay varias claves de diferentes tipos a la vez: dsa, rsa, ecdsa, ed25519. Esto se hace por compatibilidad con diferentes clientes SSH. En la etapa de conexión, el cliente y el servidor acuerdan qué algoritmo clave se utilizará. El cliente puede pedirle al servidor que use un algoritmo diferente si el propuesto no es compatible. El servidor envía la parte pública de su clave al cliente y se le solicita al usuario que verifique su huella digital manualmente.

El servidor envía la huella digital de la clave pública al cliente en el momento de la conexión.

Si esta es la primera conexión, se mostrará un mensaje al cliente con la solicitud de verificar manualmente la huella digital:

The authenticity of host 'example.com (123.45.67.89)' can't be established.
ECDSA key fingerprint is SHA256:7Q4nIqjuo/lSXWFkt9RaJYVHrT6LUAc6KWrdQ4/DDeA.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

En esta etapa, todos usualmente hacemos clic en Sí sin dudarlo y la huella digital de la clave se guarda en un archivo ~/.ssh/known_hosts. Ahora, si cambia la clave en el servidor, se mostrará un mensaje al cliente sobre un posible ataque MiTM. Se supone que, por primera vez, el cliente realizó una comprobación de clave por su cuenta y se aseguró de su autenticidad.

Este enfoque es bastante arriesgado, porque si el atacante logra aprovechar el momento de la primera conexión, podrá deslizar su clave e interceptar la conexión. En el caso de c HTTPS, tenemos un tercero que confirma la clave del servidor con un certificado. Si se usara el mismo enfoque que en SSH en la web, los mensajes de verificación clave nos atormentarían constantemente y los ataques MiTM estarían en todas partes, porque nadie verificaría las claves, pero simplemente siempre estaría de acuerdo.

Almacenamos una impresión clave en DNS. ¿Qué son las entradas SSHFP?

¿Cómo descubrir que la clave SSH propuesta por el servidor es realmente real y que este no es un ataque MiTM? De hecho, para ingresar al servidor y verificar la clave, primero debe ingresar la contraseña. Pero entonces el atacante podrá piratear instantáneamente el servidor y reemplazar todos los datos en él, tanto que no notaremos la captura. Por lo tanto, necesitamos una forma de verificar la autenticidad de la clave ANTES de la conexión real.

Durante mucho tiempo, la única forma de verificar la clave SSH del servidor antes de conectarse fue usar un canal diferente, por ejemplo, pedirle al administrador del servidor que proporcione la huella digital de la clave del servidor. Esto es inconveniente, por lo que es más fácil ignorar el problema y estar siempre de acuerdo sin dudarlo.

SSHFP permite la autenticación de clave del servidor antes de conectarse a través de DNS

SSHFP- tipo de registros DNS para almacenar claves SSH. La huella digital de la clave SSH se coloca en el servidor DNS como un registro TXT y se firma con la clave DNSSEC. Es decir, cuando se conecta al servidor por primera vez utilizando el nombre de host, el cliente podrá saber de antemano la huella digital de la clave del servidor a través de DNS, y si coincide con el servidor propuesto, luego conéctese sin previo aviso .

Configurar DNSSEC

Para usar SSHFP, necesita un nombre de dominio con DNSSEC configurado. Hay muchos servicios de DNS públicos que ofrecen un panel de control de DNS de inmediato con la función DNSSEC. El servicio de este tipo más popular es CloudFlare. Considere la configuración usando su ejemplo. Para los siguientes pasos, el dominio debe delegarse en el servidor Cloudflare NS.

▍Paso 1: generar una clave

Vaya al panel DNS -> Habilitar DNSSEC.

En este punto, se generarán claves para firmar su zona de dominio. Se le mostrarán las claves públicas. Deberán agregarse en el lado del registrador de dominios.

▍Paso 2: agregar claves públicas al registrador

A continuación, debe crear registros DS que contengan la clave pública del registrador de dominio.
Dependiendo de su registrador, la interfaz de adición de claves DNSSEC puede verse diferente. Es importante no confundir los valores, ya que pueden nombrarse de manera diferente y diferir de los nombres que se muestran en CloudFlare.

El siguiente ejemplo muestra cómo los valores mostrados en el panel CloudFlare se relacionan con los valores en el panel de control de dominio del registrador Uniregistry.

▍Paso 3: verifique los registros DS agregados

Después de agregar registros DS al costado del registrador, puede verificar que la configuración sea correcta. En el lado de CloudFlare, la firma de registros DNS se activará solo cuando se pase la verificación de la corrección de agregar registros DS en el lado del registrador.

Esperando la adición de registros DS

Después de un par de minutos u horas, si los registros se agregaron correctamente, verá dicho mensaje. Esto significa que las respuestas DNS ahora se firman usando DNSSEC.

▍Paso 4: verificar el funcionamiento de DNSSEC

Ahora puede probar el funcionamiento de DNSSEC en nuestro dominio utilizando servicios en línea como dnssec-analyzer.verisignlabs.com . Todas las marcas de verificación deben ser verdes.

Resultado de validación de DNSSEC

Agregar entradas SSHFP

Generaremos registros SSHFP en el servidor. En nuestro ejemplo, estamos administrando un servidor con la dirección myserver.com . Para este nombre de dominio, configuramos previamente DNSSEC.

En el servidor, ejecute el comando:

#   SSHFP   SSH-
sudo ssh-keygen -r myserver.com

myserver.com IN SSHFP 1 1 057ecce168ace29d5a0099e3b63df2850e4c8e20
myserver.com IN SSHFP 1 2 52cd6099a304b9b8f57f2cd914e96a1b7477eb2f88c98c602
myserver.com IN SSHFP 2 1 42d677482e4450ee515d3aac94d96302a99bd4ec
myserver.com IN SSHFP 2 2 edda5fa445dc0da570c772a6df0d4012037e1a102840d29c4
...

Se generarán huellas digitales para todas las claves de la carpeta / etc / ssh / . Puede generar selectivamente huellas digitales para claves específicas especificando la ruta del archivo.

Ahora todos estos registros deben agregarse en el panel DNS, en nuestro caso Cloudflare.

Agregar un registro SSHFP al panel Cloudflare

Por lo tanto, debe agregar todas las claves obtenidas en el paso anterior. Ahora puede verificar que se hayan agregado las claves:

dig SSHFP myserver.com

En la respuesta, debería ver todas las claves agregadas. Puede tomar tiempo firmar nuevas entradas, por lo que las claves en la respuesta pueden no aparecer de inmediato. Esto generalmente no toma más de 10-15 minutos.

Conectarse al servidor

Para que el cliente SSH verifique la validez de las claves a través de DNS, debe agregar habilitar esto en la configuración. La configuración del cliente se encuentra en la carpeta de inicio del usuario. Agregue una línea allí.

#  
vi ~/.ssh/config

VerifyHostKeyDNS yes

Ahora puedes conectarte al servidor. Para la pureza del experimento, puede eliminar la línea con la huella digital de ~ / .ssh / known_hosts . Para mayor claridad, puede agregar la opción -v

#   
ssh -v root@myserver.com


# DNS  ,  SSHFP 
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
.....
DNS lookup error: data does not exist

# DNS  ,   
#    DNSSEC
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS


# DNS  ,    DNSSEC
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_rsa_verify: signature correct

Si todo está configurado correctamente, la primera vez que se conecte al servidor, no se le pedirá que verifique manualmente la huella digital de la clave. Esto también requiere que el sistema de resolución de DNS admita la validación de DNSSEC.

Es importante recordar que SSHFP solo funcionará cuando esté conectado a un servidor por nombre de dominio y no funcionará cuando esté conectado por IP u otro dominio que no tenga registros SSHFP.

Conectividad SSH más segura con DNSSEC