¿Qué tan malo es tener múltiples dispositivos con las mismas claves de servidor SSH?

21

Estoy trabajando en un dispositivo integrado que ejecuta FreeBSD y SSH.

Como sabes, a sshd le gusta generar aleatoriamente un conjunto de claves de servidor cuando se inicia por primera vez. El problema es que enviaremos el producto con un sistema de archivos de tarjeta SD de solo lectura (no negociable).

Mis dos opciones como las veo son:

  • Envíe las mismas claves de servidor sshd en todos los dispositivos
  • Montar un sistema de archivos de memoria y generar las claves del servidor en cada arranque (lento ...)

¿Es un problema de seguridad importante enviar las mismas claves de servidor en todos los dispositivos? Estos artículos no estarán directamente en internet. Ocasionalmente habrá múltiples dispositivos propiedad de la misma persona y en la misma red.

La mayoría de las veces el dispositivo no estará conectado a internet.

Iniciar sesión con SSH no es parte de la operación normal. Es principalmente para la conveniencia de los programadores y técnicos. Los clientes no iniciarán sesión en el dispositivo con SSH.

¿Cuáles son las ramificaciones de usar las mismas claves de servidor en múltiples dispositivos de hardware?

PD: ¿alguien podría crear una etiqueta de internet de las cosas?

EDITAR : estoy hablando de instalar las mismas claves privadas de host en todos los servidores (dispositivos). En lo que respecta a las claves públicas / privadas del usuario, actualmente no hay planes para usar el inicio de sesión basado en claves: sería un inicio de sesión con contraseña. Nuevamente, la misma contraseña en todos los servidores (dispositivos).

Sé que esta es probablemente una mala idea. Sin embargo, me gustaría saber por qué precisamente es una mala idea para poder entender las compensaciones.

NXT
fuente
Si se refiere a las claves de host, los usuarios con más de uno de sus dispositivos pueden recibir advertencias dependiendo de la configuración de su cliente ssh. las mayores preocupaciones estarían relacionadas con las claves de autenticación ssh reales. Esperemos que no esté instalando ninguna clave privada y que sus claves públicas estén restringidas a redes de origen específicas y que sus claves privadas propiedad de sus técnicos tengan una contraseña fuerte y que esas claves nunca se registren en un repositorio por error. Las IoT están recibiendo un nombre realmente malo debido a esas cosas. No decir que lo harías, solo decir que es un gran problema.
Aaron
Estoy hablando de instalar la misma clave privada de host en todos los servidores, si eso es lo que quiere decir.
NXT
2
Usar el mismo nombre de usuario / contraseña en todos los dispositivos es una muy mala idea. Es mucho más fácil aplicar la fuerza bruta que la clave privada utilizada para la autenticación de clave pública. Incluso si se supone que estos dispositivos no están conectados directamente a Internet, alguien lo hará de todos modos. Y si "no está conectado directamente" significa NAT, están lo suficientemente conectados ...
Tero Kilkanen
77
Compartir la clave SSH significa que alguien que puede acceder a la clave privada en un dispositivo puede hacerse pasar por todos estos dispositivos.
user253751
3
Si bien esta es una pregunta interesante, no veo nada al respecto que se relacione con la administración del sistema y, por lo tanto, esté fuera de tema para Server Fault. Está preguntando sobre el diseño de una interfaz de depuración / diagnóstico para un dispositivo integrado que está enviando, y no una interfaz que sea relevante para los administradores de sistemas. Esta pregunta podría migrarse a Seguridad de la información .
200_success

Respuestas:

27

En lugar de almacenar datos específicos del host, como las claves de host ssh en la tarjeta SD u otros medios de solo lectura, puede almacenarlos en NVRAM, que es para lo que sirve en un sistema integrado. Deberá realizar algunos scripts personalizados para almacenar y recuperar las claves en el momento del arranque, pero los scripts serán exactamente los mismos para cada dispositivo.

Michael Hampton
fuente
12

El impacto de enviar el mismo par de claves con todos sus dispositivos está directamente relacionado con la seguridad de los clientes que se conectan a ellos, ya que significa que no hay forma (desde un cliente SSH) de identificar de manera única el dispositivo al que se puede conectar. En caso de que su par de claves se filtre, podría usarse para ataques MITM.

Por otro lado, la regeneración de las claves en cada arranque también activará una alerta en los clientes.

Como referencia, de man ssh(1):

sshmantiene y verifica automáticamente una base de datos que contiene identificación para todos los hosts con los que alguna vez se ha utilizado. Las claves de host se almacenan en ~/.ssh/known_hostsel directorio de inicio del usuario. Además, el archivo /etc/ssh/ssh_known_hostsse verifica automáticamente en busca de hosts conocidos. Cualquier nuevo host se agrega automáticamente al archivo del usuario. Si la identificación de un host cambia alguna vez, sshadvierte sobre esto y deshabilita la autenticación de contraseña para evitar la suplantación de servidores o ataques de intermediarios, que de otro modo podrían usarse para eludir el cifrado. La StrictHostKeyCheckingopción se puede usar para controlar los inicios de sesión en máquinas cuya clave de host no se conoce o ha cambiado.

Dawud
fuente
2
No entiendo por qué no pueden generar una sola vez (en cada dispositivo, en el primer arranque) y luego nunca volver a generar (a menos que se eliminen).
djsmiley2k - CoW
Perfectamente factible. Pero el OP dice que quiere: 'Montar un sistema de archivos de memoria y generar las claves del servidor en cada arranque'. Entonces mi respuesta asume eso.
dawud
Ah, sí, me perdí eso cuando lo leí la primera vez.
djsmiley2k - CoW
5

Parece que en la primera opción, las claves SSH estarían disponibles en la tarjeta SD. Por lo tanto, cualquier usuario podría tomar la tarjeta y leerla. Entonces, básicamente, sus claves privadas se han convertido (en su mayoría) en públicas.

Esto permitirá ataques de hombre en el medio, como los siguientes:

  1. Un usuario configura un servidor SSH con las claves privadas obtenidas de su dispositivo y le da esa dirección IP a su técnico.
  2. Su técnico ingresa la contraseña de root a través de la conexión SSH.
  3. El usuario ahora conoce la contraseña de root que es válida para todos sus dispositivos.

Sin embargo, no debe usar contraseñas raíz en primer lugar, use las claves ssh para la autenticación. Entonces, el impacto de las claves del servidor compartido es bastante pequeño si solo inicia sesión desde una LAN.

SSH también proporciona confidencialidad, por lo que un atacante debe poder configurar un servidor falso para beneficiarse de las claves; oler pasivamente el tráfico no permitirá descifrarlo.

jpa
fuente
Es curioso cómo nuestras ideas preconcebidas pueden cegarnos (a mí). La tarjeta SD está dentro de la unidad detrás de un panel y debajo de una placa de circuito, por lo que nunca se me ocurrió que alguien la sacaría. Sin embargo, tiene razón, es absolutamente accesible para cualquier persona con un destornillador. Gracias por el recordatorio de considerar la seguridad física del sistema.
NXT
WRT # 2, la contraseña de root no debe enviarse a través de la conexión SSH. Debe ingresarse en el cliente del terminal y utilizarse para la mitad local de un protocolo de autenticación que demuestre la posesión del secreto sin transmitir el secreto ("prueba de conocimiento"). Incluso los sistemas de hace décadas sabían enviar un hash de la contraseña y no la contraseña en sí. Incluya un nonce en el protocolo de desafío / respuesta, y el atacante no conoce la contraseña original ni ningún token que pueda usarse en su lugar.
Ben Voigt
1
@BenVoigt Creo que la mayoría de los sistemas Unix transmiten la contraseña al servidor. El archivo shadow solo almacena un hash, pero no desea confiar en un hash generado por el cliente, porque de lo contrario cualquiera podría iniciar sesión con un hash robado, sin revertirlo. Por lo tanto, el servidor debe conocer la contraseña real para ejecutar bcrypt o similar en ella.
jpa
2

¡Leí esto con horror! Yo, que he hecho varias máquinas en el mismo clúster con la misma clave de host ssh, nunca me atrevería a hacer esto. Bajo ninguna circunstancia permita que máquinas con diferentes conjuntos de administradores compartan claves de host ssh. De esa manera se encuentra la locura y el horror cuando gritas cuando te publican por tu falta de seguridad.

He aquí, te digo la verdad, el que compromete un dispositivo los compromete a todos. Una vez que obtenga uno, espere que las personas malas salten de uno a otro a voluntad y la seguridad retroceda como si fuera papel delgado.

joshudson
fuente
1
¿Podría explicar cómo un atacante usaría una clave privada de servidor robada para comprometer otros dispositivos?
jpa
@jpa: para claves de host, al interceptar y robar contraseñas, etc. Además, esta configuración parece proponer hacer lo mismo con las claves de usuario.
joshudson
1

Como usted menciona que el acceso al SSH no es utilizado por el usuario / cliente final, es posible que desee desactivar el acceso SSH de manera predeterminada y solo habilitarlo temporalmente cuando el dispositivo se pone en modo "depuración".

Luego puede enviar todos los dispositivos con la misma clave, suponiendo que haya protegido el modo de "depuración" para que alguien que intente piratear el dispositivo no pueda activarlo de forma remota.

O tiene una nueva clave generada cuando el dispositivo entra en modo de "depuración", por lo que no tiene que perder el tiempo de arranque generando las claves cada vez que se enciende el dispositivo.

Edders
fuente
Me gusta esta idea.
NXT
1

Aquí hay un escenario de ataque de muestra basado en las restricciones que tiene:

Si sus dispositivos son, digamos un Raspberry Pi por ejemplo. Si subo y saco la tarjeta SD de una, puedo pegar la tarjeta SD en mi propia computadora, encontrar la clave sshd y copiarla a donde quiera. Tal vez tomo mi propia frambuesa pi y una tarjeta ethernet USB. Ahora puedo pegar eso entre un dispositivo objetivo y donde sea que vayan y monitorear las conexiones ssh. Cuando veo que el dispositivo de destino está intentando establecer una conexión ssh, hago esto:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

¿Oh, qué es eso? ¿Tu contraseña es "Me gustan los gatos"? Chico, este es un correo electrónico interesante que enviaste a tu esposa. Apuesto a que sería aún más interesante si ella leyera este correo electrónico que le envió a la esposa de su vecino de al lado.

Las posibilidades son infinitas . Y el objetivo nunca lo sabría, porque la clave sshd es idéntica a la que se encuentra en el servidor real. Dependiendo de la seguridad física de las instalaciones que reciben su dispositivo, esto podría ser increíblemente trivial. No hagas esto.

En cambio, haz lo que ya propones pero arréglalo . Antes de escribir su imagen, ejecute algo como esto:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

Y ahora cada servidor tiene una nueva clave. Porque realmente, realmente no quiere ser la distribución de copias de una clave. Quiero decir, sinceramente, es al menos tan malo como tomar una foto de las llaves de su casa y subirlas a Internet con la dirección de su casa.

Wayne Werner
fuente
1
Si alguien tiene acceso físico a su hardware y no puede cifrar los datos en reposo, entonces todas las apuestas están desactivadas.
user9517 es compatible con GoFundMonica el