Seguridad en SSH: Guía de Hardening y Realismo Técnico 2020

Seguridad en SSH: Configuraciones de Hardening para una Infraestructura de Paz

[ log ] Actualización Legacy: Realismo Técnico en el Acceso Remoto

Trabajar con servidores mediante conexiones SSH es el pan de cada día en las Operaciones IT. No importa si es un laboratorio o un entorno empresarial; la terminal es una herramienta de servicio, y protegerla es nuestra Responsabilidad Radical. Para evitar que un acceso no deseado se convierta en un incendio a las 3:00 AM, debemos aplicar medidas de Seguridad en SSH y Hardening estrictas.

Calidad de Contraseña: La Primera Capa de Resiliencia

El uso de contraseñas débiles es la puerta principal al caos accidental. Entendemos que la estabilidad es una disciplina, y esa disciplina comienza con políticas de identidad robustas a nivel de Sistema Operativo (PAM).

Es más común de lo que piensas, incluso ‘1234’ es de las contraseñas más usadas en el mundo hasta la actualidad. Te recomendamos How to enforce password complexity on Linux

Evitar la reutilización de contraseña

Entre las recomendaciones está evitar el uso de contraseñas anteriores. Puedes consultar el siguiente artículo para encontrar más detalles sobre lo que implica la configuración Linux: Prevent From Using Or Reuse Same Old Passwords

Longitud y Complejidad con pam_cracklib

En Sys Adventures, rechazamos el elitismo técnico, pero somos inflexibles con la seguridad. Configurar una longitud mínima no es burocracia, es defensa. Para lograrlo editamos los archivos de autenticación para forzar un estándar mínimo de 12 caracteres y complejidad diversa:

En sistemas basados en Debian/Ubuntu

vi /etc/pam.d/common-password

En sistemas basados en RHEL/CentOS

vi /etc/pam.d/system-auth

Buscamos la siguiente línea

password requisite pam_cracklib.so

Y agregamos la siguiente línea para indicar que el mínimo requerido es de 12

minlength=12

Quedando de la siguiente forma

password requisite pam_cracklib.so try_first_pass retry=3 minlength=12 lcredit=1

De forma predeterminada, en la mayoría de los sistemas operativos sólo cuentan con el requerimiento de incluir una letra minúscula. Podemos manipular las cuatro variables de validación según creamos conveniente

1. Letras mayúsculas: ucredit
2. Letras minúsculas: lcredit
3. Números: dcredit
4. Símbolos: ocredit

Agregamos los parámetros de validación, para este ejemplo obligaremos a incluir al menos una letra mayúscula, dos minúsculas, un dígito y un símbolo

ucredit=-1 lcredit=-2 dcredit=-1 ocredit=-1

Quedando de la siguiente forma

password requisite pam_cracklib.so try_first_pass retry=3 minlength=12 ucredit=-1 lcredit=-2 dcredit=-1 ocredit=-1

Expiración de contraseñas

De forma predeterminada, las contraseñas nunca expiran, aun así, podemos definir cada cuanto tiempo se tiene que cambiar la contraseña, así como el periodo de notificación antes de que esto suceda. Editamos el archivo de configuración

vi /etc/login.defs

Buscamos las siguientes líneas y editamos los valores a conveniencia

PASS_MAX_DAYS 150
PASS_MIN_DAYS 0
PASS_WARN_AGE 7

Con esto las contraseñas deben cambiar cada seis meses, y enviar un mensaje de advertencia siete días antes de caducidad de la contraseña.

Parametrizar configuraciones de SSH (sshd_config)

Una vez asegurado el sistema operativo, debemos aplicar Realismo Técnico al daemon de SSH. Aquí es donde definimos quién tiene el control.

1. Limitación Radical del Root

En su archivo de configuración podemos limitar la forma de acceso para el usuario root. Cuando hacemos esto es recomendable manejar usuarios sin privilegios para que puedan hacer el salto hacia el usuario root, o en su defecto, utilizar usuarios con permisos de sudo

Editamos el archivo de configuración

vi /etc/ssh/sshd_config

Buscamos la siguiente línea PermitRootLogin y la establecemos en no

PermitRootLogin no

Guardamos los cambios en el archivo y reiniciamos el servicio de SSH

service sshd restart

2. Cambiar el puerto predeterminado

El servicio de SSH utiliza el puerto predeterminado 22, sin embargo, en la configuración este puerto se puede personalizar, hay que tomar en cuenta que cada vez que queramos conectarnos al servicio se deberá especificar el número de puerto en el cliente, además de prever posibles implicaciones de seguridad a nivel configuración de red en el Switch.

Editamos el archivo de configuración

vi /etc/ssh/sshd_config

Buscamos la siguiente línea Port y cambiamos el 22 por el número de puerto que queramos usar, digamos el puerto 9122

Port 9122

Guardamos los cambios en el archivo y reiniciamos el servicio de SSH

# service sshd restart

3. Forzar ‘Protocol 2’

Si bien por default la mayoría de los clientes actuales se conectan mediante la versión 2 de SSH, la versión 1 continúa activa y sigue siendo una puerta de entrada. Podemos editar el archivo de configuración para forzar todas las conexiones en su versión 2, lo cual implica dejar de usar clientes antiguos.

Editamos el archivo de configuración

vi /etc/ssh/sshd_config

Buscamos la siguiente línea Protocol y quitamos el comentario de la línea #

Protocol 2

Guardamos los cambios en el archivo y reiniciamos el servicio de SSH

service sshd restart

4. Limitar acceso por usuario

Otra configuración interesante es dar acceso solamente a ciertos usuarios del sistema para tener un control estricto de quien puede conectarse.

Editamos el archivo de configuración

vi /etc/ssh/sshd_config

Al final del archivo agregamos la siguiente línea

AllowUsers sysadmin, sysadventures

Con esta línea indicamos que el acceso sólo se permite para los usuarios sysadmin y sysadventures

Guardamos los cambios en el archivo y reiniciamos el servicio de SSH

service sshd restart

5. Autenticación mediante Llaves: Soberanía del Operador

Aunque las contraseñas pueden parametrizarse, la autenticación por llaves RSA/Ed25519 es el estándar de oro para una arquitectura proactiva. Las llaves permiten eliminar el factor del error humano en la elección de contraseñas.

Para aplicar esta configuración hay que completar ciertos pasos que, a grandes rasgos son:

Generar las llaves (Pública y Privada) en el servidor

ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa): Enter (Esta línea nos permite nombrar el fichero final)
Enter passphrase (empty for no passphrase): Enter (Dejar en blanco si no se usa una contraseña de paso)
Enter same passphrase again: Enter (Se confirma la contraseña)
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
16:8e:e8:f2:1d:c9:b9:cf:43:9a:b3:3c:c1:1f:95:93 user@localhost

Ingresar a la carpeta de ssh del usuario

cd ~/.ssh/

Dentro de esa carpeta deben existir dos archivos: id_rsa y id_rsa.pub. Al querer establecer una conexión mediante SSH, el cliente solicitara el archivo .pub

Siempre resguarde la llave privada (id_rsa) fuera del servidor y documente quién tiene acceso a la llave pública en su repositorio de infraestructura.

Ahora debemos crear el archivo authorized_keys y dentro del mismo copiar el contenido del archivo id_rsa.pub

Llegado a este punto ya tenemos activada la autenticación mediante llaves. Este proceso es por usuario, hay que tenerlo muy en cuenta si se quiere estandarizar el uso de llaves. Te recomendamos Aprende a configurar las llaves SSH en un servidor Linux

5.1 Desactivar el uso de contraseñas

Con la configuración anterior ya activamos la autentificación mediante llaves y la autentificación mediante contraseña sigue activa (Trabajando al mismo tiempo). En caso de que quieras completar el estándar de llaves, puedes desactivar el inicio mediante contraseña.

Editamos el archivo de configuración

vi /etc/ssh/sshd_config

Buscamos la siguiente línea AuthorizedKeysFile y quitamos el comentario de la línea #

AuthorizedKeysFile .ssh/authorized_keys

Guardamos los cambios en el archivo y reiniciamos el servicio de SSH

service sshd restart

6. Limitar tiempo de conexión

Podemos definir un límite de tiempo de uso para SSH en cada conexión, muchas veces esta configuración no es realmente necesaria, pero podría evitar algunos huevos de seguridad relacionadas con el usuario (Muchos suelen dejar sus computadoras desbloqueadas y con conexiones abiertas de forma indefinida).

Editamos el archivo de configuración

vi /etc/ssh/sshd_config

Buscamos las siguientes líneas

• ClientAliveInterval: Esta variable indica al servidor cada cuanto tiempo debe de enviar un mensaje KeepAlive.
• ClientAliveCountMax: Esta variable indica cuántos mensajes deben de ser enviados antes de cerrar la sesión

Podemos setear los números de ambos según creamos conveniente.

Guardamos los cambios en el archivo y reiniciamos el servicio de SSH

service sshd restart

Conclusión: Del Caos al Control

Aplicar estas configuraciones de Seguridad en SSH no solo protege sus datos; protege la paz mental de quien mantiene el sistema. Un servidor correctamente «hardened» es un servidor que permite al equipo innovar sin miedo a intrusiones triviales.