Sin duda es el servicio más utilizado para la administración de los sistemas operativos Linux. El año pasado en este artículo hablamos sobre algunos de los servicios que se encuentran expuestos a Internet en algunos países de América del Sur y observamos que para el servicio SSH la cantidad que se mostraba era de más de 20 millones de posibles hosts expuestos con este servicio.
Cabe destacar que en este artículo, la búsqueda se realizó al puerto 22 que es el puerto por defecto del servicio SSH (Dile NO a las configuraciones por defecto).
El servicio SSH es perfecto para mantener la confidencialidad e integridad de los datos que se puedan intercambiar entre sistemas. Además de esto, una de sus principales ventajas es la autenticación del servidor con el uso de clave pública.
Así que en esta oportunidad vamos a realizar algunas configuraciones para mejorar la seguridad de este servicio de administración remota tan utilizado.
La mayoría de los cambios se realizan en el archivo /etc/ssh/sshd_config
1. Autenticación SSH siempre basada en clave pública
El servidor OpenSSH admite varias autenticaciones. Nosotros recomendamos que se utilice la autenticación basada en clave pública. Para esto se debe crear el par de claves usando el siguiente comando ssh-keygen en su computadora de escritorio /portátil local.
Aquí te dejo un enlace de los amigos de Digital Ocean, que te muestra cómo crear el par de claves y agregarlas al servidor.
2. Cambio de puerto por defecto
La mayoría de los ataques a este servicio se producen por herramientas automáticas que buscan probar con usuarios y contraseñas comunes en el puerto 22.
Si cambias el puerto evitarás en su gran mayoría este tipo de ataques.
Port 300 3. Limite la vinculación IP
La directiva ListenAddress especifica en qué direcciones IP se abrirá el puerto para ofrecer el servicio. Si el sistema dispone de más de una dirección IP, ya sea IPv4 o IPv6, es conveniente limitar esta escucha únicamente a las necesarias. Por defecto viene en ALL, así que el servicio se abrirá en todas las interfaces disponibles del sistema.
ListenAddress 192.168.1.xx4. Deshabilitar el usuario ROOT para login
El usuario administrador del sistema no debería realizar la autenticación directamente contra el equipo. Es recomendable modificar este parámetro dejándolo en “no”
PermitRootLogin no 5. Limitar el acceso SSH de los usuarios del sistema
AllowUsers habilita qué usuarios tienen permitido el uso del servicio SSH. Puedes colocar varios usuarios. Por defecto, permite a todos los usuarios del sistema iniciar sesión por SSH pero es recomendable que limite el acceso solo a los que realmente necesitan utilizar este servicio.
AllowUsers user1 user2Al igual que con AllowUsers, AllowGroups permite especificar el grupo o los grupos de usuarios a los que se les permite hacer acceder mediante SSH al sistema.
6. Deshabilitar inicio de sesión basado en contraseña
Todos los inicios de sesión basados en contraseñas deben estar deshabilitados. Solo debe permitir inicios de sesión basados en claves públicas.
AuthenticationMethods publickey
PubkeyAuthentication yesEn algunas versiones viejas de SSHD sería así:
PubkeyAuthentication yes7. Deshabilitar contraseñas vacías
Debemos rechazar los inicios de sesión remoto, desde cuentas con contraseñas vacías.
PermitEmptyPasswords no8. Limitar intentos de autenticación fallida
Con el parámetro MaxAuthTries se especifica el máximo número de intentos de autenticación fallida por conexión. Recomendamos su configuración a un valor como 3.
MaxAuthTries 3 9. Ajuste de LoginGraceTime
Con esta directiva se especifica cuantos segundos se permite que un usuario permanezca con una conexión abierta sin haberse autenticado correctamente. Recomendamos que este valor sea por ejemplo 60.
LoginGraceTime 6010. Limitar conexiones simultaneas no autenticadas
Con esta directiva MaxStartups especificamos el número máximo permitido de conexiones simultaneas no autenticadas, todos los intentos de conexión siguientes serán denegados hasta que uno de los anteriores realice correctamente el proceso completo.
De esta forma podemos denegar posibles ataques de fuerza bruta. Por defecto viene en 10, recomendamos colocar un valor menor, por ejemplo “3”.
MaxStartups 311. Habilitar un banner de advertencia para los usuarios de SSH
Especifica el archivo que será mostrado antes de la autenticación de un usuario en el sistema.
Banner /etc/issue12. Configurar el intervalo de tiempo de espera de cierre de sesión inactiva
Se puede establecer un intervalo de tiempo de inactividad para las sesiones SSH. De esta forma, si un usuario deja la sesión desatendida, la misma se cierra automáticamente después de transcurrido el tiempo.
ClientAliveInterval 300
ClientAliveCountMax 013. Deshabilitar archivos .rhosts
SSH puede emular el comportamiento del comando RSH obsoleto, simplemente desactive el acceso inseguro a través de RSH.
IgnoreRhosts yes14. Deshabilitar la autenticación basada en el host
Es recomendable deshabilitar esta opción, ya que en principio definimos que la autenticación sería por clave pública.
HostbasedAuthentication no15. Deshabilitar X11forwarding
X11, es el servidor gráfico que usan casi todas las distribuciones Linux. Este servidor permite, entre otras cosas, forwarding a través de SSH. Esto significa que es posible ejecutar aplicaciones gráficas de una máquina remota exportando el display a nuestro escritorio. Es decir, la aplicación se ejecuta en el servidor remoto, pero la interfaz gráfica la visualizamos en nuestro escritorio local.
Así que si no necesitas utilizar este servidor gráfico es mejor no tenerlo habilitado.
X11forwarding no16. Chroot (Bloquear usuarios a sus directorios de inicio)
De forma predeterminada, los usuarios pueden navegar por los directorios del servidor, como /etc /, /bin, entre otros. Se puede proteger SSH, usando Chroot para bloquear a los usuarios en sus directorios personales.
Esta configuración se la mostraremos próximamente en un nuevo artículo.
17. Comprobación de configuración
Para comprobar el archivo de configuración y detectar cualquier error antes de reiniciar SSHD, ejecute:
sshd -tPara finalizar, es importante tener en cuenta que se puede limitar el acceso a este servicio solo a la LAN de la organización o a través de una VPN para casos que se requiera un acceso externo.
Artículo relacionados:
Hardening — Asegurando NGINX
Hardening — Mejorando configuraciones SSL/TLS
Asegurando las cabeceras de respuestas HTTP en servidores web IIS
Asegurando las cabeceras de respuestas HTTP en servidores web Apache y NGINX
