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

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

Hay varias medidas de seguridad que puede tomar, a continuación se encuentran algunas de las que siempre tomo cuando configuro un servidor SSH y algunas adicionales.

1. Use una contraseña segura, que consista de al menos (digamos) 10 letras mayúsculas y minúsculas, números y otros caracteres.

2. Encarcele a los usuarios en su directorio de inicio. Los usuarios encarcelados no podrán acceder/editar archivos que estén fuera de su directorio de inicio. Por lo tanto, su usuario no podrá acceder/editar archivos clave del sistema. Se pueden encontrar muchos tutoriales en línea sobre cómo encarcelar a un usuario. La mayoría de ellos usan JailKit. Puede encontrar un ejemplo de un tutorial de este tipo aquí. Alternativamente, también puede usar el ChrootDirectory nativo del servidor OpenSSH directiva. Puede encontrar un ejemplo de un tutorial sobre esto aquí.

3. Instale Fail2Ban. Fail2Ban es un programa que verifica los registros de autenticación en busca de entradas incorrectas. Cuando se alcanza un cierto límite, agrega un bloque de firewall para esa IP determinada durante un período de tiempo preestablecido. También hay varios tutoriales 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 completos y agradables.

4. Deshabilite el inicio de sesión raíz a través de SSH. Este es el usuario que tiene acceso a casi 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 raíz 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 # delante de ella.

   #PermitRootLogin no
   

5. Use un puerto no estándar (por ejemplo, no 22) Esto se hace mediante el 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 detectable para usuarios maliciosos. 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
   

6. 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 claves privadas. Esto significa que se almacena una clave en su computadora en la que accede al SSH de la máquina SSH. Cuando se intenta una conexión, el cliente SSH usa la clave para iniciar sesión en el servidor en lugar de mediante la autenticación de contraseña. Las claves de autenticación son mucho más fuertes criptográficamente 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 obtener instrucciones sobre PuTTY). Una vez que haya configurado la autenticación basada en claves, puede desactivar la autenticación con contraseña editando el archivo /etc/ssh/sshd_config . Busque la siguiente línea y asegúrese de que no haya # delante de ella.

   #PasswordAuthentication no
   

7. 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 prohibir el acceso a la red no local en el servidor SSH. De esa forma, ningún dispositivo externo sin conexión VPN podrá acceder a su servidor SSH. Esto se puede hacer denegando TODOS los hosts y luego permitiendo que solo las direcciones IP de la red local inicien sesión. Esto se hace editando /etc/hosts.deny y agrega lo siguiente:

   sshd: ALL
   

   y hasta /etc/hosts.allow agrega 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 probar ssh: 192.168.1.* y ssh: ALL en su lugar.

8. 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.}
   

9. 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 # delante de ella. Si no existe, créalo. Por ejemplo, si desea permitir solo a john, tom y mary, agregue/edite esta línea:

   AllowUsers john tom mary
   

   También puede denegar el acceso 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
   

10. Solo permita el protocolo SSH2 para las 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 # delante de ella. Si no existe, créalo.

    Protocol 2,1
    

    elimine el ,1 para que la línea sea

    Protocol 2
    

11. No permita que los usuarios inicien sesión sin 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 # delante de ella. Si no existe, créalo.

    PermitEmptyPasswords no
    

12. Y aunque es simple y tal vez no hace falta decirlo, pero resultó ser crucial en múltiples casos, mantenga su software actualizado. Actualice regularmente sus paquetes/software instalados.

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

sudo /etc/init.d/ssh restart

o

sudo /etc/init.d/sshd restart

según la distribución de Linux que esté utilizando.

Algunos consejos:

1. Utilice la autenticación basada en claves, que es MUCHO más segura que las contraseñas
2. Solo SSH 2
3. Deshabilitar los inicios de sesión raíz
4. Para los paranoicos, cambie el puerto del puerto estándar 22
5. Para mayor comodidad, use una herramienta para asignar su IP a un nombre de DNS, como Dyndns o similares. Puedes pasar mucho tiempo con la misma IP, pero esa vez que viajas y la necesitas, te darás cuenta de que te dieron una nueva.
6. 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 al prohibir los inicios de sesión con contraseña (coloque 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 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 espiadas son los problemas, y permitir la autenticación de contraseñas 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íe completamente (pero si confía en una máquina, también podría instalar una clave privada en ella, 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 de intermediario si se está ejecutando en la máquina cliente; 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 insertando 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 fisgón 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 compatibilidad con 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.