Guía de endurecimiento 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, donde 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 petición al servidor. El servidor escucha las peticiones entrantes utilizando el demonio del servidor (sshd). Utiliza su clave pública para autenticarse ante el cliente que intenta conectarse a él:

De esta manera, 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á en un cliente Windows, tendrá que utilizar herramientas como Putty para conectarse al servidor. Tanto el cliente como el servidor pueden estar instalados en el mismo sistema, esto significa que puedes usar la herramienta del cliente para acceder a otras máquinas o tu sistema puede ser el propio servidor al que pueden acceder otros. En este caso, el archivo de configuración se coloca en el mismo directorio pero con un nombre ligeramente diferente. 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.

Empezamos por comprobar el estado del demonio SSH o sshd en nuestro servidor. De esta manera podemos ver si se está ejecutando y está habilitado para iniciarse automáticamente en el arranque. El siguiente comando comprobará el estado de sshd:

$ systemctl status ssh.service

O utilice 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. Al ampliar la vista del terminal pulsando la flecha de la derecha, observamos que está escuchando en el puerto 22 por defecto.

A veces hacemos cambios en el archivo de configuración SSH del sistema remoto mientras estamos conectados a él usando el propio SSH. En tal caso debemos usar el comando reload en lugar del restart. De esta manera es menos probable que nos desconectemos.

Configurando SSH usando las Mejores Prácticas

Creo que ahora es el momento de empezar con la configuración del servidor SSH. Antes de ensuciarnos las manos con el archivo de configuración de 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 nos equivocamos con el archivo principal y rompemos nuestro SSH, podemos utilizar el archivo de copia de seguridad para volver a la normalidad.

1. Cambio del puerto por defecto

El demonio sshd por defecto escucha 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 llama seguridad a través de la oscuridad. Para ello, abra el archivo de abajo y busque la línea que contiene el texto ‘#Port 22’.Advertisement

$ sudo nano /etc/ssh/sshd_config

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

$ ssh [email protected]_ip -p 222

Root es el usuario por excelencia en cualquier sistema Linux con acceso a todos los recursos de su sistema. En caso de que no requiera un acceso root estricto, debe deshabilitar la facilidad de inicio de sesión como root en su servidor. Para ello abra el mismo archivo anterior:

$ sudo nano /etc/ssh/sshd_config

y establece el parámetro ‘PermitRootLogin’ a ‘no’. Esto asegurará que el servidor esté protegido de los ataques aleatorios dirigidos a la cuenta raíz. La opción por defecto es ‘prohibit-password’, que permite el inicio de sesión basado en la autenticación de clave pública, pero niega los inicios de sesión basados en la contraseña.

3. Ajuste de la versión del protocolo

La versión de protocolo más antigua de SSH es la 1 y es menos segura en comparación con SSH2 y tienen diferentes implementaciones de red y tampoco son compatibles entre sí. Para comprobar qué versión de protocolo está activa en su servidor, abra de nuevo el archivo sshd_config y busque la línea ‘Protocolo’:

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

En caso de tener una salida vacía, es probable que el OpenSSH esté usando la versión 2, como ocurrió 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 protocolos está ejecutando un servidor remoto, intente conectarse a él utilizando un cliente ssh con la opción -Q (query):

$ ssh -Q protocolo-versión [email protected]Nombre de la empresa

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

4. Complejidad de la contraseña

Las contraseñas débiles son siempre vulnerables a ser explotadas, por lo que las contraseñas vacías son más susceptibles de ser explotadas. Por lo tanto, la opción PermitEmptyPasswords debería estar establecida en ‘no’ en el archivo sshd_config. Del mismo modo, el número de intentos de inicio de sesión con una contraseña incorrecta debería limitarse para reducir las posibilidades de un ataque de fuerza bruta. Esto puede lograrse con la opción ‘MaxAuthTries’ establecida en algún valor menor como 3.

De la imagen anterior podemos ver que cuando establecemos el valor ‘MaxAuthTries’ a 3, se nos niega SSH después de tres contraseñas incorrectas. Otro aspecto importante de la seguridad 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 tratado de cubrir los puntos más importantes para asegurar un servidor SSH y resumirlos en cuatro puntos principales. Aunque esta guía no es completa, puedes encontrar más áreas para fortalecer aún más tu servidor SSH. Por ejemplo, puedes intentar añadir un mensaje de banner para alertar a los usuarios sobre el uso de tu sistema a través de SSH. También puede negar el inicio de sesión con una 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.