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

Me gustaría poder SSH a mi PC de oficina Ubuntu 10.04 desde el exterior. Por lo tanto, estoy pensando en iniciar un demonio SSH en la PC. ¿Cuáles son los problemas de seguridad, posibles problemas técnicos, ajustes de configuración específicos, etc. que debo tener en cuenta?

En caso de que sea importante: esto es esencialmente para mi propio uso, no creo que haya otras personas usándolo; Es una PC Ubuntu 10.04 en un entorno mayoritariamente Windows 7 / Vista / XP.

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

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

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

2. Usuarios de la cárcel a 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 . Un ejemplo de este tutorial se puede encontrar aquí . Alternativamente, también puede usar la ChrootDirectorydirectiva nativa del servidor OpenSSH . Un ejemplo de un tutorial sobre esto se puede encontrar aquí .

3. Instalar 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 bloqueo de firewall para esa determinada IP durante un período de tiempo predeterminado. 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ÓMOs agradables y completos.

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 en su sistema, por lo tanto, se recomienda deshabilitar su inicio de sesión de shell. En las últimas versiones de Ubuntu, el usuario root se deshabilita automáticamente, pero de todos modos no está de más deshabilitar su acceso SSH. Esto se hace editando el archivo /etc/ssh/sshd_config. ^✝ Busque la siguiente línea y asegúrese de que no haya ningún # delante.

   #PermitRootLogin no
   

5. Use un puerto no estándar (por ejemplo, no 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 para usuarios malintencionados. Esto se hace editando el archivo /etc/ssh/sshd_config. ^✝ Busque la siguiente línea y cambie 22 a cualquier puerto que desee. No olvide reenviar el puerto correcto en su enrutador después.

   Port 22
   

6. No use 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 a la 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 un tutorial de PuTTY). Después de configurar la autenticación basada en claves, puede desactivar 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 ningún # delante.

   #PasswordAuthentication no
   

7. Opcionalmente, como @ Linker3000 mencionó en su comentario, puede configurar un túnel VPN para 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 puede hacerse negando TODOS los hosts y luego permitiendo que solo las IP de la red local inicien sesión. Esto se hace editando /etc/hosts.denyy agregando lo siguiente:

   sshd: ALL
   

   y para /etc/hosts.allowagregar lo siguiente:

   sshd: 192.168.1.*
   

   donde la IP coincide con la de su red local. *es un comodín, por 192.168.1.lo que se aceptarán todas las direcciones IP que comiencen por . Si esto no funciona, su distribución podría usar en sshlugar de sshd. En ese caso, deberías probar ssh: 192.168.1.*y en su ssh: ALLlugar.

8. Solo puede permitir hosts específicos, haga lo mismo con /etc/hosts.allowy /etc/hosts.denycomo se describe en 6, pero /etc/hosts.allowagregue 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 ningún # delante. Si no existe, créelo. Por ejemplo, si solo desea permitir a John, Tom y Mary, agregue / edite esta línea:

   AllowUsers john tom mary
   

   También puede denegar 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 ningún # delante. Si no existe, créelo.

    Protocol 2,1
    

    quite el 1 para que la línea sea

    Protocol 2
    

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

    PermitEmptyPasswords no
    

12. Y aunque es simple y tal vez no sea necesario decirlo, pero demostró 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 olvides reiniciar el demonio para aplicar los cambios. Reinicia el demonio ejecutando:

sudo /etc/init.d/ssh restart

o

sudo /etc/init.d/sshd restart

dependiendo de qué distribución de Linux esté usando.

Algunos consejos:

1. Use la autenticación basada en claves, que es MUCHO más segura que las contraseñas
2. SSH 2 solamente
3. Deshabilitar inicios de sesión de 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 DNS, como Dyndns o su tipo. Puede pasar mucho tiempo con la misma IP, pero esa vez que viaje y la necesite, verá que le emitieron una nueva.
6. Por supuesto, solo permita el puerto necesario para SSH (puerto 22, o 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 intentan sistemáticamente nombres de cuenta comunes (como webmastery bob) y contraseñas débiles. Puede eliminar este riesgo mediante la prohibición de los inicios de sesión de contraseña (poner PasswordAuthentication noen sshd_config, y, o bien también poner UsePAM Noo autenticación de contraseña desactivar 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 AllowUserso AllowGroupsdentro sshd_config.

Tenga en cuenta que permitir el inicio de sesión con contraseña no es en sí un problema de seguridad. Las contraseñas débiles y las contraseñas indagadas son los problemas, y permitir la autenticación de contraseñas en el servidor ssh es un habilitador. Para protegerse contra la indagación 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 clave privada en ella, y luego no necesitará la autenticación de contraseña).

El requisito mínimo para usar un cliente ssh en una máquina es que confía en que no habrá un secuestro activo de la comunicación ssh (un ataque de hombre en el medio es posible si se está ejecutando en la máquina cliente - usted piensa 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 está insertando un troyano en la comunicación después). Este es un requisito más débil que confiar en que no habrá un entrometido de contraseña (generalmente realizado a través de un keylogger, pero hay otros métodos menos automatizados como la navegación de hombro). Si tiene la mínima confianza pero aún teme a los intrusos, 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.

Tres cosas me vinieron a la mente:

1. Si abre el puerto predeterminado 22, muy pronto se detectará y su PC se verá afectada por ataques de fuerza bruta. Le sugiero que configure sshd para escuchar algún otro puerto o hacer mapeo de puertos en su firewall. Si bien esto no es una bala mágica, seguramente le ahorrará al menos los mismos ciclos de CPU.

   Puerto 12345

2. Deshabilita explícitamente la autenticación de contraseña y usa solo claves. Cualquier clave será mejor que la contraseña más compleja que pueda recordar.

   Contraseña Autenticación no

3. Aunque Ubuntu tiene el usuario root deshabilitado por defecto, deshabilita explícitamente el inicio de sesión root

   PermitRootIniciar sesión no