it-swarm-es.com

¿Qué métodos están disponibles para asegurar SSH?

¿Qué métodos están disponibles para asegurar SSH?

44
Olivier Lalonde
  • Desactivar inicio de sesión raíz - La mayoría de los ataques automáticos se concentrarán en la cuenta raíz, por lo que no permitir los inicios de sesión desde esa cuenta es un buen lugar para comenzar.

  • Solo permitir ciertos grupos/usuarios - Limite qué usuarios y grupos pueden SSH al sistema.

  • Límite por IP o Rango de IP - Una de las formas más efectivas de asegurar su sistema contra ataques SSH.

  • Usar autenticación basada en clave - Según lo descrito por Olivier

  • Use fail2ban - fail2ban monitoreará los intentos de inicio de sesión SSH y después de un número determinado de intentos fallidos, bloqueará la dirección IP de los atacantes para un período de tiempo establecido Este puede ser un método muy efectivo para ralentizar a los atacantes.

34
Mark Davidson

Las otras respuestas se centran en asegurar el servidor , lo cual es importante, pero el lado del cliente también merece cierta protección:

  • En/etc/ssh/ssh_config (o ~/.ssh/config) establezca StrictHostKeyChecking en yes o ask. Esto proporciona cierta protección contra ataques de hombre en el medio al verificar que el servidor al que se está conectando es el que espera.
  • Si puede agregar registros a su zona DNS, publique un registro SSHFP y configure VerifyHostKeyDNS en yes o ask. El cliente buscará el SSHFP desde DNS y verificará la huella digital. (Tenga en cuenta que aún es vulnerable si su atacante controla el DNS).
  • Protocolo de fuerza versión 2. I.e. conjunto Protocol 2 en/etc/ssh/ssh_config: el valor predeterminado es 2,1 que permite volver a v1 si v2 no está disponible.
  • Prefiera las claves a las contraseñas para iniciar sesión. Use una contraseña segura en sus claves ssh. Utilice teclas de longitud adecuada (número de bits).
    • Si tiene usuarios que proporcionan claves ssh, audite la seguridad de la contraseña ejecutando john en las claves.
  • Use un token de hardware para desbloquear la clave en lugar de escribir la contraseña (para evitar keyloggers y surfistas de hombro).
  • Asegúrese de que UseBlacklistedKeys es no (este es el valor predeterminado). Esto evita que use claves 'en la lista negra' generadas durante paquetes débiles de opensian de Debian. Verifique las claves de host y usuario con ssh-vulnkeys. En los sistemas derivados de Debian (por ejemplo, ubuntu) puede instalar los paquetes openssh-blacklist y openssh-blacklist-extra.
  • Asegúrese de que CheckHostIP es yes (el valor predeterminado). Esto hace que el cliente verifique la IP del Host contra conocido_hosts para agregar protección contra la falsificación de DNS.
  • Establezca HashKnownHosts en yes. Esto evita que se filtre información de su archivo known_hosts.
18
bstpierre

Deshabilitar inicios de sesión basados ​​en contraseña

Reemplazar la autenticación basada en contraseña por autenticación basada en clave evitará:

  • Intentos de descifrado de contraseñas por fuerza bruta.
  • Ataques de hombro: personas que se escabullen mientras escribes tu contraseña.
  • Registradores de teclas.
11
Olivier Lalonde

Otra cosa, si solo se permiten pocas personas en SSH, haga que Bashrc le envíe un aviso cada vez que alguien inicie sesión en SSH

7
Aviah Laor

Para empezar, no debe permitir las contraseñas y solo permitir la autenticación con claves RSA. Esto hace que los ataques de fuerza bruta sean inviables. Sin embargo, la gente will todavía lo intentará, por lo que querrá limitar los intentos de inicio de sesión y tal vez cambiar el puerto para ahorrar ancho de banda. Este enfoque se basa en confiar en sus usuarios para cifrar y proteger sus claves privadas.

No debe permitir el inicio de sesión raíz de forma remota. Use su o Sudo una vez que haya iniciado sesión.

Puede ser una buena idea evitar que las personas tunelen ssh a través de su servidor de puerta de enlace a servidores internos. Esto puede evitar que sus servidores internos estén expuestos a Internet.

Debe usar la versión 2 de SSH.

6
Magnus

Se me ocurre que ninguna de las otras respuestas habla sobre un punto muy importante para asegurar SSH: eduque a sus usuarios. Hagas lo que hagas, si los usuarios no aprenden a reaccionar con sensatez cuando sucede algo sospechoso, entonces estás condenado. Como mínimo, los usuarios deben conocer el negocio de manejo de claves del servidor (cuando se conectan por primera vez a un servidor determinado, deben deben verificar la huella digital de la clave con una fuente confiable; y si SSH advierte sobre una clave que ha cambiado, ellos no deben omitir la advertencia).

La tecnología solo puede llevarte tan lejos; Mientras un humano esté involucrado en el proceso, la cantidad de conocimiento de seguridad de ese usuario es un límite difícil en el nivel de seguridad que puede esperar lograr.

6
Thomas Pornin

Hay una nueva opción en el servidor que requiere frases de contraseña en las claves del cliente. Creo que esta es una muy buena idea. Sin embargo, aún no conoce la complejidad de la frase de contraseña y los usuarios podrían volver a compilar el cliente para falsificar esto.

3
nowen

Como todos dicen: siempre deshabilite el inicio de sesión raíz, cambie el número de puerto predeterminado (aunque esto puede dificultar el uso de algunos clientes sftp) y solo acepte la autenticación basada en clave.

Además, si cambia cualquier tamaño de clave en sshd_config o especifica un tamaño de bit de clave cuando ejecuta ssh-keygen, debe revisar los tamaños de clave que especifique de vez en cuando.

En el pasado, cuando ssh-keygen no generaba claves RSA de 1024 bits, solía usar la opción -b para generar claves de 1536 bits. Con el tiempo, el valor predeterminado cambió para generar claves de 2048 bits y seguía generando claves de 1536 bits.

2
ewalshe