▷¿Cuáles son los posibles problemas de seguridad con un demonio SSH? ✔️ Foro Ayuda 【 2024 】

Buscamos en el mundo online para de esta forma mostrarte la respuesta para tu duda, en caso de preguntas déjanos tu duda y contestaremos con gusto, porque estamos para servirte.

Solución:

La mayor preocupación serían las personas que inician sesión como administrador de la computadora a través de SSH. Esto se puede hacer mediante la fuerza bruta si tiene una contraseña fácil de adivinar.

Hay varias medidas de seguridad que puede tomar, a continuación se muestran algunas de las que siempre tomo al configurar un servidor SSH y algunas más.

Utilice una contraseña segura, que consta de al menos (digamos) 10 letras mayúsculas y minúsculas, números y otros caracteres.
Encarcelar a los usuarios a su directorio personal. Los usuarios encarcelados no podrán acceder / editar archivos que estén fuera de su directorio de inicio. Entonces su usuario no podrá acceder / editar key archivos del sistema. Se pueden encontrar muchos tutoriales en línea sobre cómo encarcelar a un usuario. La mayoría de ellos usa JailKit. Puede encontrar un ejemplo de un tutorial de este tipo aquí. Alternativamente, también puede utilizar el nativo del servidor OpenSSH ChrootDirectory directiva. Puede encontrar un ejemplo de un tutorial sobre esto aquí.
Instale Fail2Ban. Fail2Ban es un programa que comprueba los registros de autenticación en busca de entradas incorrectas. Cuando se alcanza un cierto límite, agrega un bloque de firewall para esa determinada IP durante un período de tiempo preestablecido. También hay varios tutoriales en línea que se encuentran en línea sobre cómo configurar Fail2Ban con SSH, un ejemplo sería este. La página de inicio de Fail2Ban también contiene algunos CÓMO agradables y completos.
Deshabilite el inicio de sesión de root a través de SSH. Este es el usuario que tiene acceso a prácticamente todos los archivos de su sistema, por lo que se recomienda deshabilitar su inicio de sesión de shell. En las últimas versiones de Ubuntu, el usuario root se deshabilita automáticamente, pero no está de más deshabilitar su acceso SSH de todos modos. Esto se hace editando el archivo /etc/ssh/sshd_config.^✝ Busque la siguiente línea y asegúrese de que no haya un # delante de ella.
```
#PermitRootLogin no
```
Utilice un puerto no estándar (por ejemplo, no el 22). Esto se hace a través del reenvío de puertos en su enrutador (por ejemplo, 16121 -> 22 en lugar de 22 -> 22) o haciendo que el demonio SSH escuche en un puerto diferente. Esto hará que su servicio SSH sea menos fácilmente detectable por usuarios malintencionados. Esto se hace editando el archivo /etc/ssh/sshd_config.^✝ Busque la siguiente línea y cambie 22 al puerto que desee. No olvide reenviar el puerto correcto en su enrutador después.
```
Port 22
```
No utilice contraseñas para iniciar sesión. Además de las contraseñas, SSH también permite iniciar sesión mediante el uso de keys. Esto significa un key se almacena en su computadora en la que accede al SSH de la máquina SSH. Cuando se intenta una conexión, el cliente SSH utiliza el key para iniciar sesión en el servidor en lugar de a través de la autenticación de contraseña. Autenticación keys criptográficamente son mucho más fuertes que las contraseñas y, por lo tanto, no son tan fáciles de descifrar. También hay varios tutoriales en línea que se encuentran en línea sobre cómo configurar la autenticación basada en claves con SSH, un ejemplo sería este. (Si utiliza SSH desde Windows con PuTTY, consulte este enlace para ver un procedimiento de PuTTY). key-basada en la autenticación, puede deshabilitar la autenticación de contraseña editando el archivo /etc/ssh/sshd_config.^✝ Busque la siguiente línea y asegúrese de que no haya un # delante de ella.
```
#PasswordAuthentication no
```
Opcionalmente, como @ Linker3000 mencionó en su comentario, puede configurar un túnel VPN a la PC a la que desea acceder a través de SSH y luego no permitir el acceso a la red no local en el servidor SSH. De esa manera, ningún dispositivo externo sin una conexión VPN podrá acceder a su servidor SSH. Esto se puede hacer negando TODOS los hosts y luego permitiendo que solo las IP de la red local inicien sesión. Esto se hace editando /etc/hosts.deny y agregue lo siguiente:
```
sshd: ALL
```
y para /etc/hosts.allow agregue lo siguiente:
```
sshd: 192.168.1.*
```
donde la IP coincide con la de su red local. * es un comodín, por lo que todas las direcciones IP que comienzan con 192.168.1. será aceptado. Si esto no funciona, su distribución podría usar ssh en lugar de sshd. En ese caso, deberías intentar ssh: 192.168.1.* y ssh: ALL en lugar de.
Solo puede permitir hosts específicos, haga lo mismo con el /etc/hosts.allow y /etc/hosts.deny como se describe en 6, pero en /etc/hosts.allow agregue la siguiente línea y cada host para permitir separados por espacios:
```
sshd: IP OF HOST TO ALLOW 1 IP OF HOST TO ALLOW 2 IP OF HOST TO ALLOW 3 ETC.
```
Permita que solo usuarios específicos accedan a su servidor SSH. Esto se hace editando el archivo /etc/ssh/sshd_config.^✝ Busque la siguiente línea y asegúrese de que no haya un # delante de ella. Si no existe, créelo. Por ejemplo, si desea permitir solo a john, tom y mary, agregue / edite esta línea:
```
AllowUsers john tom mary
```
También puede denegar a usuarios específicos, por ejemplo, si desea denegar el acceso a john, tom y mary, agregue / edite esta línea:
```
DenyUsers john tom mary
```
Solo permita el protocolo SSH2 para conexiones entrantes. Hay dos versiones del protocolo SSH. SSH1 está sujeto a problemas de seguridad, por lo que se recomienda usar SSH 2. Esto se puede forzar editando el archivo. /etc/ssh/sshd_config.^✝ Busque la siguiente línea y asegúrese de que no haya un # delante de ella. Si no existe, créelo.
```
Protocol 2,1
```
elimine el, 1 para que la línea sea
```
Protocol 2
```
No permita que los usuarios inicien sesión que no tengan una contraseña establecida. Esto se puede forzar editando el archivo /etc/ssh/sshd_config.^✝ Busque la siguiente línea y asegúrese de que no haya un # delante de ella. Si no existe, créelo.
```
PermitEmptyPasswords no
```
Y aunque es simple y tal vez no sea necesario decirlo, pero ha demostrado ser crucial en varios casos, mantenga su software actualizado. Actualice regularmente sus paquetes / software instalados.

^✝ = después de haber editado el archivo de configuración SSH, no olvide reiniciar el demonio para aplicar los cambios. Reinicie el demonio ejecutando:

sudo /etc/init.d/ssh restart

sudo /etc/init.d/sshd restart

dependiendo de la distribución de Linux que esté utilizando.

Algunos consejos:

Utilice la autenticación basada en claves, que es MUCHO más segura que las contraseñas
Solo SSH 2
Deshabilitar inicios de sesión de root
Para los paranoicos, cambie el puerto del puerto estándar 22
Para mayor comodidad, use una herramienta para asignar su IP a un nombre DNS, como Dyndns o similar. Puede pasar mucho tiempo con la misma IP, pero una vez que viaje y la necesite, encontrará que se le ha emitido una nueva.
Por supuesto, solo permita el puerto necesario para SSH (puerto 22, o uno no estándar si lo desea) a través de su firewall.

El principal riesgo es olvidar que está ejecutando un servidor ssh y poner una contraseña débil en una cuenta. Hay atacantes que prueban sistemáticamente nombres de cuentas comunes (como webmaster y bob) y contraseñas débiles. Puede eliminar este riesgo prohibiendo los inicios de sesión con contraseña (poner PasswordAuthentication no en sshd_config, y también poner UsePAM No o deshabilite la autenticación de contraseña en la configuración de PAM para ssh). Una medida intermedia es restringir los inicios de sesión ssh a una lista blanca de usuarios con AllowUsers o AllowGroups en sshd_config.

Tenga en cuenta que permitir los inicios de sesión con contraseña no es en sí mismo un problema de seguridad. Las contraseñas débiles y las contraseñas fisgoneadas son los problemas, y permitir la autenticación de contraseña en el servidor ssh es un habilitador. Para protegerse contra el espionaje de contraseñas, nunca escriba su contraseña en una máquina en la que no confía completamente (pero si confía en una máquina, también podría instalar una key en él, y luego no necesita autenticación de contraseña).

El requisito mínimo para usar un cliente ssh en una máquina es que confíe en que no habrá un secuestro activo de la comunicación ssh (es posible un ataque man-in-the-middle si se está ejecutando en la máquina cliente, cree está escribiendo comandos en un cliente ssh prístino, pero el cliente de hecho está transmitiendo sus datos de autenticación fielmente, pero también inserta un caballo de Troya en la comunicación después). Este es un requisito más débil que confiar en que no habrá un rastreador de contraseñas (generalmente se realiza a través de un registrador de teclas, pero existen otros métodos menos automatizados, como la navegación por el hombro). Si tiene la confianza mínima pero aún le teme a los fisgones, puede usar contraseñas de un solo uso (OpenSSH las admite a través de su soporte PAM).

Por supuesto, como cualquier otro programa que interactúa con máquinas fuera de su control (no solo servidores de red sino también clientes), debe mantenerse al día con las actualizaciones de seguridad.

Comentarios y valoraciones del post

Recuerda algo, que tienes concesión de valorar esta noticia si diste con la solución.

¡Haz clic para puntuar esta entrada!

(Votos: 0 Promedio: 0)

¿Cuáles son los posibles problemas de seguridad con un demonio SSH?

Solución:

Comentarios y valoraciones del post

Utiliza Nuestro Buscador

Preguntas Relacionadas: