En cuanto ponemos un servicio SSH accesible desde cualquier parte de Internet, los ataques de fuerza bruta y demás se suceden casi al instante (es una licencia, evidentemente, hay un tiempo de «descubrimiento»). Nos llegan desde todo el globo terráqueo por lo que, hablando de protección y suponiendo que nunca accederá un usuario desde determinados continentes o países, aplicar la Geolocalización IP para deshabilitar conexiones se convierte en una opción muy interesante. Aún reconociendo la importancia de realizar buenos filtros y de implementar mecanismos de autenticación multifactor, en esta entrada nos vamos a centrar solo en las opciones de SSH básicas para su protección. He tomado como base, la clase que impartía en Administración de Servicios de Internet dedicada a SSH y su fortalecimiento.
Las opciones con las que vamos a intentar mejorar y adaptar la configuración de nuestro servicio a nuestra política de seguridad y a nuestras necesidades, las encontraremos en el fichero /etc/ssh/sshd_config.
Empecemos….
En mi opinión, una política buena de administración de la cuenta de ‘root’ es que a ella no se puede acceder nada mas que con los comandos sudo o su, es decir, no podemos establecer una sesión de trabajo directamente con root. Inhabilitar el acceso directo en SSH consiste simplemente en que la directiva PermitRootLogin tenga el valor NO. Además, nuestra política debe establecer qué usuarios tienen permiso para establecer sesiones de trabajo. Esta política, la implementamos con las siguientes directivas y debemos tener en cuenta que el orden en el que están escritas, es el orden en el que son procesadas (ver referencia 1):
- DenyUsers: Denegamos usuarios concretos
- AllowUsers. Le podemos indicar tanto los usuarios (separados por un espacio en blanco) que pueden establecer sesión como desde qué equipos lo deben hacer (con el formato usuario@equipo)
- DenyGroups. Lo dice el nombre: para denegar grupos.
- AllowGroups Indicamos los grupos de usuarios separados por comas.
Una vez decidido quién puede acceder, tenemos que determinar en qué condiciones. Así, con la directiva MaxAuthTries podemos establecer el número máximo de intentos de autenticación fallidos. Por defecto, este valor es 6.
Con las siguientes directivas, podemos elegir el mecanismo de autenticación:
- PasswordAuthentication: Por defecto yes, es decir, usamos contraseña para autenticar.
- PubkeyAuthentication: autenticación mediante clave pública. Funciona solo con la versión 2 del protocolo (protocol 2, mucho más seguro que la primera versión, ya comprometido)
Si decidimos usar los mecanismos PAM (UserPam yes) para la autenticación, pasamos a tener muchas más opciones, además de ser obligatorio (su uso) si tenemos los usuarios centralizados en un servidor al que accederemos, por ejemplo, mediante LDAP. Así podemos, además de establecer de dónde y cómo accedemos a la información de autorización y autenticación del usuario (pam_unix o pam_ldap), indicar:
- Condiciones de acceso con pam_access establecidas en el fichero /etc/security/access.conf
- Admitir o denegar los usuarios listados en un fichero determinado con pam_listfile Por ejemplo:
auth required pam_listfile.so item=user sense=deny file=/etc/sshd/sshd.deny onerr=succeed
auth required pam_listfile.so item=user sense=allow file=/etc/sshd/sshd.allow onerr=fail
- No permitir el acceso, salvo a root, cuando exista el fichero /etc/nologin, por ejemplo en el apagado del servidor, con pam_nologin
- Si usamos autenticación mediante contraseña, chequear la seguridad de esta con pam_pwcheck o pam_cracklib
- Limitar el uso de ciertos recursos (se establece en el fichero /etc/security/limits.conf) con pam_limits
- Desde dónde podrá acceder root con pam_securetty con seguridad (es decir, desde los dispositivos listados en /etc/securetty)
- Introducir retrasos cuando la autenticación es incorrecta con pam_faildelay
- Cambiar el grupo asignado a un usuario en función de cuándo, cómo y dónde se conecte con pam_group. El comportamiento está indicado en el fichero /etc/security/group.conf
- …
Para mejorar la seguridad de un servicio SSH en Internet, otro mecanismo muy útil es el de Port Knocking que habilite el puerto del servicio SSH exclusivamente cuando lo vayamos a utilizar. Es un sistema ingenioso y que, como he comentado en clase de Administración e Instalación de Serviciosde Internet y Administración de Sistemas Operativos en Red, podemos usar para fortalecer diversos servicios, pero principalmente, SSH. Explicaré, en otra ocasión, un guión sencillo que usa iptables para desarrollar esta funcionalidad, evitando la instalación de un software específico (¡¡¡que también lo hay!!!)
Por otra parte, sobre el puerto escuchado, tenemos la opción de indicar un puerto diferente del 22 para dificultar escaneos simples y automatizados: Port number. Hablando de automatización, con MaxAuthTries (esta directiva la hemos mencionado antes) podemos también evitar que un posible atacante esté probando nuestras credenciales indefinidamente. En los servicios que administro, los configuro con MaxAuthTries 3, el mismo número de intentos que con los PINs de las tarjetas de crédito 😉 Otra directiva interesante es LoginGraceTime con la que podemos establecer el máximo tiempo de espera a la autenticación del usuario; cuanto más bajo, mejor. En mi opinión, no más de 60 segundos.
Por último, es posible que queramos utilizar el entorno gráfico en nuestras sesiones de trabajo remotas. Para ello, debemos activar X11Forwarding que permitirá el reenvío del protocolo X11 a través de SSH. Para hacer uso de las X a través de SSH debemos:
- X11Forwarding yes, en el servidor y ForwardX11 yes en el cliente
- En el cliente, ejecutamos:
xhost +servidor ssh -X usuario@servidor
- En el servidor (en la sessión SSH), exportamos el display
export DISPLAY=dirección_cliente:0.0 Y ejecutamos aplicación gráfica deseada...
¡¡¡Espero que os sea útil!!!
Referencias
- man 5 sshd_config