¿Por qué es tan malo dejar un SSH con contraseña en Internet?

  

¿Por qué es esto tan malo?

Debido a que hay muchos bots que solo buscan en la web puertos abiertos e intentan iniciar sesión, una vez que el robot del escáner encuentra un puerto SSH abierto, se puede poner en cola para que otro bot (o botnet) intente usar la fuerza bruta de la contraseña. Uno de los riesgos aquí es que, eventualmente, pueden tener éxito en descifrar la contraseña y tomar el control del servidor.

  

Entiendo que la contraseña puede ser forzada con una fuerza bruta, pero ¿qué pasa si es muy   contraseña segura que tomaría eones a crackear?

Tener una contraseña larga es una técnica de mitigación, sin embargo, el consumo de recursos de un ataque de fuerza bruta (ancho de banda, espacio en disco utilizado para registros y CPU) también puede ser perjudicial.

Mitigación

Algunas técnicas para mitigar un ataque de fuerza bruta en SSH:

• Usa un puerto diferente, no tengas una falsa sensación de seguridad con esto, pero muchos bots sí buscan 22 exclusivamente. ( pregunta relacionada )
• Deshabilitar las contraseñas de SSH
• Requerir una clave privada para iniciar sesión
• Conexiones del acelerador
• Implemente un IPS ( Fail2ban y Snort vienen a la mente)
• Restrinja el inicio de sesión por dirección IP
• Restrinja los usuarios que pueden iniciar sesión (diferente que comprobar la dirección IP)

El riesgo principal es que la conexión inicial puede ser interceptada por un Man-In-The-Middle, por lo que un atacante puede recuperar la contraseña.

La primera vez que un usuario se conecta a un servidor SSH, se muestra algo similar a lo siguiente:

$ ssh scanme.nmap.org
The authenticity of host 'scanme.nmap.org (45.33.32.156)' can't be established.
ECDSA key fingerprint is SHA256:8iz5L6iZxKJ6YONmad4oMbC+m/+vI9vx5C5f+qTTGDc.
Are you sure you want to continue connecting (yes/no)?

Ahora, a menos que todos los usuarios vayan a verificar esa huella digital para asegurarse de que sea su servidor, existe el riesgo de que su conexión haya sido interceptada (por ejemplo, MITM en su red que intercepta directamente el tráfico, o algún tipo de secuestro DNS).

Esto se debe a que SSH es "Confianza en el primer uso". Si se conectó antes a ese host y la clave cambia repentinamente, se mostrará el siguiente mensaje, que advierte al usuario.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5c:9b:16:56:a6:cd:11:10:3a:cd:1b:a2:91:cd:e5:1c.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
RSA host key for ras.mydomain.com has changed and you have requested strict checking.
Host key verification failed.

La advertencia mitigará este ataque para los usuarios que ya se han conectado desde ese cliente en particular.

Otros riesgos, menos críticos, de tener SSH abierto en Internet es que hay muchos robots que encuentran e intentan iniciar sesión en dichos servidores. Si tiene una contraseña segura en todas las cuentas, entonces el riesgo de compromiso es muy bajo (me refiero a una que definitivamente no estará en una lista de palabras que el atacante pueda usar o crear). Se aplican las reglas habituales, por ejemplo, no se reutiliza la contraseña, la contraseña se almacena de forma segura, etc. El inconveniente es que los archivos de registro se acumularán rápidamente con todos los intentos de autenticación recibidos.

Con respecto a SSH en cualquier modo de autenticación, ya que este es otro servicio, existe la posibilidad de que se descubran vulnerabilidades que podrían ser explotadas automáticamente por tales bots. Sin embargo, el riesgo de esto no es mayor que el de un servidor web o una aplicación web de ser explotado. Al igual que cualquier servidor con servicios públicos, se recomienda una buena estrategia de administración de vulnerabilidades.

Consulte también esta respuesta , la parte relacionada con los mensajes de advertencia de SSH y el riesgo de continuar, incluso con el público autenticación de clave.

  

He escuchado varias veces varias veces para no dejar SSH con una contraseña abierta a través de Internet. ¿Por qué es esto tan malo?

     

Entiendo que la contraseña puede ser forzada con una fuerza bruta, pero ¿qué sucede si se trata de una contraseña muy segura que tomaría eones para descifrar?

El gran beneficio de deshabilitar los inicios de sesión con contraseña de SSH es en realidad para evitar que las cuentas predeterminadas con contraseñas débiles o los usuarios que eligen contraseñas débiles sean forzadas por la fuerza bruta. En este momento, es posible que solo tenga unas pocas cuentas sin contraseñas débiles, pero es posible que se instale algo en el futuro, en caso de que no sea así. Cuantos más sistemas o complejidad tenga a lo largo del tiempo, mayor será el riesgo.

Caso anecdótico: un conocido mío perdió su servidor y todo lo que había en él porque le dio a un amigo una cuenta con la contraseña de changeme que no se cambió. Tampoco se crearon copias de seguridad remotas, por lo que perdió todo.

Las claves SSH son mucho más seguras por defecto. A menos que la generación de claves esté rota , el nivel más bajo de compromiso requiere obtener la clave de los usuarios. Mientras que con las contraseñas, el nivel es simplemente adivinar cuando alguien expone una contraseña débil. Se trata de asegurarse de que se protejan contra futuros fracasos humanos.

Otra cosa a considerar es la posibilidad de vulnerabilidades (aunque conocidas desde hace algún tiempo o día cero) en el propio demonio sshd, que podría ser explotado por un atacante. Para mitigar esto, es mejor abrir sshd solo para los usuarios que trabajan con IP conocidas en las que confía, o mediante una VPN, si es posible.

Hay varias razones diferentes por las que es más seguro usar la autenticación de clave pública en lugar de la autenticación de contraseña:

• La clave secreta nunca abandona la máquina cliente, por lo que es más difícil interceptar la clave secreta que la contraseña. Esto es importante en caso de que un atacante realice un ataque mitm contra su primera conexión donde no se conoce la clave del host. También es importante en caso de que el atacante haya puesto en peligro el servidor.
• El uso de la autenticación de clave pública lo protege contra ataques mitm completos. Si un atacante realiza un ataque mitm contra su primera conexión, es posible que no verifique la clave del host. Sin embargo, si usa la autenticación de clave pública para autenticarse, entonces la autenticación está vinculada al ID de sesión ssh, lo que evita que el atacante utilice la misma autenticación para pasar la conexión al servidor legítimo. Esto reduce el ataque de un ataque mitm completo a solo interceptar la conexión, que a menudo será más fácil para el usuario darse cuenta. (Por ejemplo, cuando el usuario busca un archivo que se sabe que está en el servidor real, pero que el atacante no conoce, el usuario notará que algo no está bien).

Dado que recomiendo no usar la autenticación de contraseña, también le aconsejaré que no la deje activada en su servidor ssh por los siguientes motivos:

• Los atacantes intentarán ataques de fuerza bruta con contraseña. Si tiene algún usuario en el sistema con una contraseña débil, existe la posibilidad de que tal ataque tenga éxito.
• Incluso si todos los usuarios del sistema tienen contraseñas seguras, los atacantes seguirán intentando forzar las contraseñas. Esto consumirá recursos en el servidor. Ocasionalmente, he visto que los ataques de fuerza bruta son tan agresivos que los inicios de sesión legítimos fallan debido a la sobrecarga del servidor.
• Si te acostumbras a los servidores ssh que nunca aceptan contraseñas, es más probable que te des cuenta en caso de que algún atacante intente tirarte un mitm-attack y te presente una solicitud de contraseña.

Como lo entiendo, una clave no es tan diferente de una contraseña; es mucho, mucho más largo y por lo tanto más difícil de romper. Además, necesitas una contraseña en la parte superior.

Pero también me gustaría decir que tiene sentido permitir que solo ciertas direcciones IP se conecten incluso a su puerto SSH. Disminuye los archivos de registro y, en general, es una buena práctica permitir solo el acceso (no el inicio de sesión) a un servicio si es necesario. Así, por ejemplo, a un rango de direcciones IP de VPN de su compañía. Pero nunca confíe en eso.

Algunas veces se sugiere mover el puerto SSH, pero veo poco beneficio en eso.

También (fuera de tema): nunca permita el inicio de sesión de SSH para la raíz.