Guía de refuerzo de la seguridad de OpenSSH para Linux

SSH es uno de los protocolos más utilizados para la administración de sistemas en plataformas Linux. Está disponible para muchos sistemas operativos basados en Unix, Linux y MacOS. Se basa en el modelo cliente-servidor, en el que una máquina ejecuta el componente servidor y la otra utiliza una herramienta cliente para acceder a él.

¿Cómo funciona SSH?

El cliente (ssh) inicia la conexión enviando una solicitud al servidor. El servidor escucha las peticiones entrantes mediante el demonio del servidor (sshd). Utiliza su clave pública para autenticarse ante el cliente que intenta conectarse a él:

De esta forma, el cliente se asegura de que se está conectando al servidor SSH correcto. Una vez hecho esto, el cliente puede acceder al servidor. Si estás en un cliente Windows, tendrás que utilizar herramientas como Putty para conectarte al servidor. Tanto el cliente como el servidor pueden estar instalados en el mismo sistema, esto significa que puedes utilizar la herramienta cliente para acceder a otras máquinas o que tu sistema puede ser el propio servidor al que pueden acceder otras personas. En tal caso, el archivo de configuración se coloca en el mismo directorio, pero con un nombre ligeramente distinto. La ubicación del directorio es ‘/etc/ssh’ y el nombre del archivo de configuración del cliente ssh es ‘ssh_config’ y el del archivo de configuración del servidor es ‘sshd_config’:

En caso de que tengas ambos archivos en tu sistema, debes elegir sabiamente qué archivo necesitas configurar. En la mayoría de los casos, es el servidor el que necesitamos configurar por seguridad, ya que abre la puerta a posibles accesos en el sistema.

Primero empezamos comprobando el estado del demonio SSH o sshd en nuestro servidor. De esta forma podemos ver si se está ejecutando y si está habilitado para iniciarse automáticamente al arrancar. El siguiente comando comprobará el estado de sshd:

$ systemctl status ssh.service

O utiliza el siguiente

$ systemctl status sshd.service

En la captura de pantalla podemos ver que el servicio está activo y habilitado. Ha estado funcionando durante las últimas 6 horas. Cuando amplíes la vista del terminal pulsando la flecha derecha, verás que está escuchando en el puerto 22 por defecto.

A veces realizamos cambios en el archivo de configuración SSH del sistema remoto mientras estamos conectados a él utilizando el propio SSH. En tal caso, debemos utilizar el comando recargar en lugar de reiniciar. De esta forma es menos probable que nos desconectemos.

Configurar SSH siguiendo las mejores prácticas

Creo que ha llegado el momento de empezar con la configuración del servidor SSH. Antes de ensuciarnos las manos con el archivo de configuración SSH, deberíamos hacer una copia de seguridad del archivo con la configuración por defecto:

$ sudo cp /etc/ssh/sshd_config ~/sshd_config.bkp

Después de realizar la copia de seguridad nos aseguramos de que si metemos la pata con el archivo principal y rompemos nuestro SSH, podemos utilizar el archivo de copia de seguridad para volver a la normalidad.

1. Cambiar el puerto por defecto

El demonio sshd escucha por defecto en el puerto 22 del servidor. Se recomienda cambiar este valor a algún otro número de forma que se reduzca el alcance de los ataques automatizados mediante scripts. Este enfoque se denomina seguridad a través de la oscuridad. Para ello, abre el siguiente archivo y busca la línea que contiene el texto ‘#Puerto 22’.

$ sudo nano /etc/ssh/sshd_config

Descomenta la línea ‘#Puerto 22′ y cambia ’22’ por algún otro número de puerto, que no esté en uso en tu sistema. Nosotros tenemos que cambiarlo por ‘222’ y reiniciar el servicio. Ahora utiliza el comando ssh con la opción ‘p’ para especificar el nuevo puerto:

$ ssh usuario@sistema_ip -p 222

2. Deshabilitar el inicio de sesión como usuario Root

Root es el usuario por excelencia en cualquier sistema Linux, con acceso a todos los recursos del sistema. En caso de que no necesites un acceso root estricto, debes deshabilitar el inicio de sesión como usuario root en tu servidor. Para ello abre el mismo archivo anterior:

$ sudo nano /etc/ssh/sshd_config

y establece el parámetro «PermitRootLogin» en «no». Esto garantizará que el servidor esté protegido de los ataques aleatorios dirigidos a la cuenta root. La opción por defecto es «prohibir-contraseña», que permite el inicio de sesión basado en la autenticación de clave pública, pero deniega los inicios de sesión basados en contraseña.

3. Configurar la versión del protocolo

La versión de protocolo más antigua de SSH es la 1 y es menos segura que la SSH2. Además, tienen implementaciones de red diferentes y no son compatibles entre sí. Para comprobar qué versión de protocolo está activa en tu servidor, abre de nuevo el archivo sshd_config y busca la línea «Protocolo»:

$ cat /etc/ssh/sshd_config | grep ‘Protocolo’

En caso de que obtengas una salida vacía, es probable que el OpenSSH esté utilizando la versión 2, como ocurría en nuestro caso. Otra forma es utilizar la utilidad de comandos netcat:

$ nc localhost 22

Ejemplo de salida:

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4

De la salida podemos ver que SSH2 está activo en nuestro sistema.

Para comprobar qué versión de protocolo está ejecutando un servidor remoto, intenta conectarte a él utilizando un cliente ssh con la opción -Q (consulta):

$ ssh -Q protocolo-version usuario@nombre_servidor

La imagen anterior muestra una versión 2 de SSH al acceder a un servidor ssh de Ubuntu desde un Kali Linux.

4. Complejidad de la contraseña

Las contraseñas débiles siempre son vulnerables a ser explotadas, por lo que las contraseñas vacías tienen más probabilidades de ser explotadas. Por tanto, la opción PermitEmptyPasswords debe establecerse como «no» en el archivo sshd_config. Del mismo modo, el número de intentos de inicio de sesión con una contraseña incorrecta debe limitarse para reducir las posibilidades de ataque por fuerza bruta. Esto se puede conseguir estableciendo la opción «MaxAuthTries» en un valor menor, como 3.

En la imagen anterior podemos ver que cuando establecemos el valor «MaxAuthTries» en 3, se nos deniega el acceso SSH después de tres contraseñas erróneas. Otro aspecto de seguridad importante es utilizar la autenticación de clave pública para el inicio de sesión. Los modelos de autenticación basados en claves son menos vulnerables a los ataques de fuerza bruta. Del mismo modo, podemos utilizar el módulo de autenticación PAM para fortificar aún más el servidor SSH.

Conclusión

En esta guía, hemos intentado cubrir los puntos más importantes para asegurar un servidor SSH y resumirlos en cuatro puntos principales. Aunque esta guía no es completa, incluso puedes encontrar más áreas para reforzar aún más tu servidor SSH. Por ejemplo, puedes probar a añadir un mensaje de banner para alertar a los usuarios sobre el uso de tu sistema a través de SSH. También puedes denegar el inicio de sesión con contraseña y utilizar la autenticación basada en claves para el inicio de sesión sin contraseña. Otra cosa interesante es que puedes limitar el número de usuarios SSH y su tiempo de conexión.