¿Qué tan seguro es permitir el acceso SSH basado en clave dentro de LAN?

2

Así que esta es mi configuración:

  • Tenemos algunas máquinas en una LAN, utilizadas para computación, a las que mis colegas y yo accedemos desde el exterior con SSH.
  • Todas nuestras cuentas en las máquinas de LAN se administran y comparten a través de LDAP (reside en la LAN, pero solo es accesible con SSL).
  • El acceso desde el exterior está restringido a través de una de las máquinas (SSH en un puerto diferente al 22 y ejecuta Fail2Ban). La autenticación de contraseña está deshabilitada y todos los usuarios utilizan claves cifradas con frase de contraseña al iniciar sesión desde fuera de la LAN. El inicio de sesión de raíz también está deshabilitado en toda la red.

Sin embargo, como es común cambiar de máquina a máquina, muchos usuarios utilizan el inicio de sesión sin contraseña dentro de la LAN. Esto significa que si un atacante obtiene acceso a ese host externo, tiene el mismo nivel de acceso en toda la LAN que el usuario que estaba comprometido.

¿Cómo puedo mitigar este riesgo? ¿Cuáles son algunas buenas prácticas a seguir? ¿Hay otros problemas evidentes con mi configuración?

    
pregunta nikitautiu 21.11.2018 - 17:20
fuente

2 respuestas

2

Puede utilizar host de SSH Jump ( ssh -J ) para conectarse a la máquina interna a través de la máquina externa. Esta configuración significa que los materiales clave residen en su estación de trabajo en lugar de en la puerta de enlace. Cuando utiliza la configuración de host de salto, su estación de trabajo local negocia directamente la conexión SSH a las máquinas internas, por lo que un atacante que pulsó el host de salto no puede interceptar la conexión a su máquina interna.

Si desea iniciar la conexión después de estar conectado a la puerta de enlace, puede utilizar reenvío de agente ( ssh -A ). Tenga en cuenta que esto es menos seguro que la configuración del host de salto, ya que un atacante que pulsó la puerta de enlace puede utilizar el socket del agente reenviado para crear nuevas conexiones a la máquina interna. Para protegerse contra esto, puede configurar su agente ssh local para que muestre el cuadro de diálogo de confirmación antes de que el agente necesite firmar una nueva conexión. También tenga en cuenta que, bajo esta configuración, la puerta de enlace puede interceptar las comunicaciones, ya que la sesión será descifrada por la puerta de enlace antes de reenviarla a la máquina interna. En general, se prefiere el host de salto, pero hay situaciones en las que el reenvío del agente tiene sentido, por ejemplo, si necesita transferir archivos directamente entre el host de salto y la máquina interna, en lugar de tener que enrutar a través de su estación de trabajo local.

    
respondido por el Lie Ryan 22.11.2018 - 13:04
fuente
0

La respuesta de Lie ya cubre la mayoría de los aspectos.

Aquí hay algunos aspectos adicionales con respecto a la seguridad de los pares de claves del cliente:

  • Debe establecer una administración de claves autorizada que elimine automáticamente las claves públicas de los usuarios inactivos / eliminados
  • Se recomienda encarecidamente aplicar una política para la rotación de la clave del cliente.
  • No puede aplicar efectivamente una protección de clave privada sólida a menos que inscriba tokens de hardware criptográfico para los usuarios, pero estos son lentos.

Por lo tanto, recomiendo usar certificados de cliente temporales de OpenSSH que emita después de la autenticación multifactor y que sean válidos solo por un par de horas.

    
respondido por el Michael Ströder 22.11.2018 - 16:46
fuente

Lea otras preguntas en las etiquetas