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

• Inhabilitar inicio de sesión de raíz : la mayoría de los ataques automatizados se concentrarán en la cuenta de raíz, por lo que no es bueno comenzar el inicio de sesión desde esa cuenta.

• Solo permitir ciertos grupos / usuarios : limita qué usuarios y grupos pueden SSH al sistema.

• Límite por IP o rango de IP : una de las formas más efectivas de proteger su sistema contra ataques SSH.

• Utilice la autenticación basada en clave - como lo describe Olivier

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

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

• En / etc / ssh / ssh_config (o ~ / .ssh / config) establezca StrictHostKeyChecking en yes o ask . Esto proporciona cierta protección contra los ataques de intermediarios al verificar que el servidor al que se está conectando sea el que usted espera.
• Si puede agregar registros a su zona DNS, publique un registro SSHFP y establezca VerifyHostKeyDNS en yes o ask . El cliente obtendrá el SSHFP de DNS y verificará la huella digital. (Tenga en cuenta que aún es vulnerable si su atacante controla el DNS).
• Forzar versión de protocolo 2. Es decir. establezca 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 claves 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 los keyloggers & shoulder surfers).
• Asegúrese de que UseBlacklistedKeys sea no (este es el valor predeterminado). Esto evita que use las claves 'en la lista negra' generadas durante los débiles paquetes de debs openssl de Debian. Compruebe 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 sea yes (el valor predeterminado). Esto hace que el cliente verifique la dirección IP del host contra conocido_hosts para agregar protección contra la falsificación de DNS.
• Establezca HashKnownHosts en yes . Esto evita la pérdida de información de su archivo conocido_hosts.

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 de fuerza bruta.
• Ataques de hombro: personas que se esconden detrás de usted mientras escribe su contraseña.
• Registradores de claves.

Otra cosa, si solo unas pocas personas pueden hacer SSH, bashc le envía un aviso cada vez que alguien inicia sesión en SSH

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

No debe permitir el inicio de sesión de forma remota. Utilice su o sudo una vez que haya iniciado sesión.

Puede ser una buena idea evitar que las personas hagan un túnel ssh a través de su servidor de puerta de enlace a servidores internos. Esto puede evitar que sus servidores internos queden expuestos a Internet.

Deberías usar la versión 2 de SSH.

Se me ocurre que ninguna de las otras respuestas habla de un punto muy importante para asegurar SSH: educar a sus usuarios . Hagas lo que hagas, si los usuarios no aprenden a reaccionar con sensatez cuando sucede algo sospechoso, 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 verificar la huella digital de la clave con una fuente confiable, y si SSH advierte sobre una clave que ha cambiado, no deben omitir la advertencia).

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

Hay una nueva opción en el servidor para requerir 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 al cliente para falsificar esto.

Como todos dicen: deshabilite siempre el inicio de sesión de root, 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.

Atrás cuando ssh-keygen se configuró de manera predeterminada para generar claves RSA de 1024 bits. Usé 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.