La guía definitiva para asegurar SSH

Introducción 

SSH (Secure Shell) es un protocolo de red que proporciona a los usuarios acceso seguro a un sistema remoto. Proporciona un fuerte canal de comunicaciones de datos cifrados entre dos computadoras a través de una red no segura. SSH es el método de conexión preferido para los administradores de sistemas Linux/UNIX para operaciones y mantenimiento. Aunque SSH proporciona mucha más seguridad que otros métodos de conectividad, si no se configura correctamente, puede ser vulnerable. Con este artículo, nuestro objetivo es proporcionar orientación para ayudarlo a proteger y fortalecer SSH.

Este tutorial explorará muchas opciones. No todas las opciones son factibles para todos los servidores. Solo tú conoces tu entorno, la base de usuarios y la importancia de los datos en el servidor. Depende de ti, las políticas de seguridad de tu empresa o alguna otra entidad dentro de tu organización decidir cuál es la configuración correcta para tu sistema.

Información importante sobre este tutorial

Los siguientes elementos se aplican a este tutorial a menos que se indique lo contrario:

  • Las ediciones de archivos se deben realizar en el archivo sshd_config, NO en el archivo ssh_config (observa la d después de ssh).
  • Cualquier cambio en la configuración de SSH requiere un reinicio del servicio para que tenga efecto.
  • La mayoría de las opciones que discutiremos ya estarán en el archivo sshd_config. Puede ser prudente verificar si la opción ya existe en el archivo de configuración. Si lo haces, puedes tener configuraciones conflictivas.
  • Hay muchas líneas comentadas en el archivo de configuración de SSH. Si una línea comienza con un símbolo de numeral (#), entonces es un comentario y no es leído por el demonio. Para que esa configuración tenga efecto, deberás eliminar ese símbolo de numeral.
  • Una línea comentada usualmente muestra el “valor predeterminado” para esa opción.

Utilizar solamente el protocolo SSHv2 

SSHv1 es una implementación insegura conocida del protocolo SSH. Para garantizar la integridad de tu sistema, debes configurar el demonio SSH para que acepte solo las conexiones SSHv2.

Para configurar el demonio SSH para que solo use el protocolo SSHv2, asegúrate de que la siguiente línea esté en el archivo sshd_config y no esté comentada.

NOTA: las versiones de Red Hat y CentOS después de 7.4 utilizan SSHv2 de forma predeterminada. Todavía me gusta poner esta línea en el archivo de configuración.

Apagar o retrasar la compresión

SSH puede usar gzip para comprimir datos. Si existen vulnerabilidades en el software de compresión, podría resultar en un compromiso del sistema.

Se han tenido muchas discusiones sobre si la compresión es realmente necesaria o no en conexiones rápidas. En general, se cree que la compresión en realidad ralentiza el proceso a menos que se use en una conexión lenta (módem, RDSI, etc.). Si tienes que usar la compresión, usa la función de retraso para asegurarse de que el usuario se autentique primero antes de que comience la compresión.

Para desactivar el comentario de compresión, edita o agrega la siguiente línea a sshd_config:

Para retrasar la compresión hasta después de autenticar a un usuario agrega:

Sin compresión es mi configuración preferida.

Limitar los intentos máximos de autenticación

Limitar el máximo de veces que alguien puede fallar en la autenticación es una buena manera de mitigar los ataques de fuerza bruta. La configuración de MaxAuthTries a un número bajo forzará la desconexión de la sesión después de X número de intentos fallidos.

Para limitar los intentos de autenticación máximos, elimina el comentario, edita o agrega la siguiente línea a sshd_config:

Puedes establecer este número tan bajo como desees, pero en mi opinión, 3 es un buen equilibrio entre seguridad y comodidad.

Denegar inicios de sesión de root

Si permites inicios de sesión de root, no puedes vincular directamente una acción a un usuario. Forzar a los usuarios a iniciar sesión con una cuenta específica del usuario asegura la responsabilidad. Además, asegura aún más la cuenta de root de otros tipos de ataques.

Para evitar que los usuarios inicien sesión como root, descomenta, cambia o agrega la siguiente línea en sshd-config:

Esta configuración es muy recomendable.

Mostrar la fecha y hora del último inicio de sesión

Este suele ser el predeterminado en la mayoría de los sistemas modernos, pero aun así es importante verificarlo. La impresión de la fecha y hora del último inicio de sesión permite al usuario reconocer el uso no autorizado de la cuenta. Esto conducirá a la notificación de cualquier acceso no reconocido para futuras investigaciones.

Para asegurarse de que tu sistema muestre la fecha y hora del ultimo de inicio de sesión, descomenta, edita o agrega la siguiente línea a sshd_config:

Esta es un punto fácil para la seguridad.

Terminar sesiones inactivas de SSH

Dejar una sesión de SSH abierta indefinidamente es una mala idea porque un usuario puede dejar su estación de trabajo sin supervisión. Esto puede dar a un usuario no autorizado la oportunidad de ejecutar comandos desde esa estación de trabajo desatendida. Es una buena práctica terminar las sesiones inactivas de SSH dentro de un corto período de tiempo para cerrar esa ventana de oportunidad.

Para asegurarse de que una sesión de SSH se termine, has un comentario, debes descomentar o agregar la siguiente línea en sshd-config:

La opción ClientAliveCountMax trabaja estrechamente con ClientAliveInterval. Por ejemplo, si deseas que una sesión inactiva se cierre después de 15 minutos, debes configurar las dos opciones así:

Extracto de la página del manual sobre ClientAliveCountMax:

Establece la cantidad de mensajes de client alive (ver más abajo) que pueden enviarse sin que ssh reciba ningún mensaje del cliente. Si se alcanza este umbral mientras se envían los mensajes de client alive, sshd desconectará al cliente y terminará la sesión.

Extracto de la página del manual sobre ClientAliveInterval:

Establece un intervalo de tiempo de espera en segundos, después de lo cual, si no se han recibido datos del cliente, sshd enviará un mensaje a través del canal cifrado para solicitar una respuesta del cliente. El valor predeterminado es 0, lo que indica que estos mensajes no se enviarán al cliente.

Usuarios específicos de la lista blanca

Puedes hacer una lista (permitirdos) a usuarios específicos que están autorizados para conectarse al demonio SSH. Solo los usuarios en esta lista podrán acceder, todos los demás serán denegados. Esto tiene beneficios obvios.

Para permitir solo los usuarios “pfloyd”, “rwaters” y “dgilmour” quita el comentario, edita o agrega la siguiente línea a ssd_config:

También puedes negar a los usuarios utilizando las declaraciones de DenyUsers de esta manera:

Esto no siempre es factible, pero si tu entorno puede soportar esta configuración, definitivamente aumentará tu seguridad.

Prohibir las contraseñas vacías

Asegúrate de que cualquier conexión SSH requerirá una cadena de contraseña no vacía. Esto no afecta a la autenticación de clave SSH.

Para garantizar que los inicios de sesión de SSH requieran una contraseña, debes descomentar, editar o agregar la siguiente línea en sshd_config:

Esta opción es otro cambio fácil que se recomienda para todos los casos excepto para casos muy específicos.

Aplicar reglas de complejidad de contraseñas

Si estás utilizando la autenticación de contraseña, sería conveniente aplicar reglas de complejidad de contraseña. Tu organización puede establecer estas reglas, o simplemente puede seguir las mejores prácticas. Algunas reglas posibles son:

  • Forzar la longitud de la contraseña a ser mayor que X
  • La contraseña debe contener al menos X número de letras minúsculas
  • La contraseña debe contener al menos X número de letras mayúsculas
  • La contraseña debe contener al menos X número de dígitos
  • La contraseña debe contener al menos X número de caracteres especiales
  • La contraseña no debe contener el nombre de usuario (o viceversa)

No permitir el acceso a través de rhosts

El archivo de rhosts es una manera de controlar la confianza entre sistemas. Si un sistema “confía” en otro sistema, permitirá inicios de sesión sin contraseña. Esta es una antigua configuración anticuada y debe ser denegada explícitamente en la configuración SSH

Para asegurarse de que SSH no permita los inicios de sesión de rhosts se debe descomentar, editar o agregar la siguiente línea en sshd_config:

El archivo rhosts ya no se usa más. Se recomienda que esta opción se establezca en la mayoría de las configuraciones SSH.

No permitir el acceso a través de KnownHosts

El archivo known_hosts se utiliza para autenticar servidores. Cuando un usuario inicia una conexión SSH, compara la huella digital del servidor con la almacenada en este archivo para asegurarse de que se está conectando al sistema correcto.

Esto se basa en la configuración de las posiciones anteriores y garantiza que las conexiones remotas requieren una contraseña.

Para indicar a sshd que ignore al usuario known_hosts durante la eliminación de la autenticación, edita o agregua la siguiente línea en sshd_config:

Este ajuste debe configurarse en la mayoría de los entornos.

Deshabilitar la autenticación basada en host

Esto es similar a la autenticación de rhosts o hosts.equiv. En mi experiencia, rara vez se utiliza y se debe establecer en no.

Para desactivar la autenticación basada en host, quita el comentario, edita o agrega lo siguiente a sshd_config:

Se establece en no de forma predeterminada, pero para completarlo, lo agregaría a la configuración.

Deshabilitar X11Forwarding

La configuración X11Forwarding permite ejecutar un programa de forma remota a través de una sesión SSH y tener la interfaz gráfica mostrada en el cliente. Si no hay una necesidad categórica para X11Forwarding, debe estar deshabilitado.

Para deshabilitar X11Forwarding, descomenta, edita o agrega la siguiente línea a sshd_config:

La opción X11Forwarding rara vez es necesaria, lo recomiendo para la mayoría de los sistemas.

Utilizar un puerto no estándar

De forma predeterminada, SSH escucha en el puerto TCP 22. Esto es conocido por todos y, a menudo, es examinado por hackers y script kiddies que realizan pruebas para determinar si SSH se está ejecutando en un sistema. Otros puertos predecibles en los que las personas ejecutan SSH son 2222 y 2121. También puede ser conveniente evitarlos. Elije cualquier puerto alto que no sea un puerto usado o registrado. Para este ejemplo, utilizaremos 9222.

Para configurar el demonio SSH para que escuche en un puerto no estándar tienes que descomentar, editar o agregar lo siguiente en sshd_config:

Normalmente no cambio los puertos predeterminados para los sistemas detrás de un firewall. Si tu sistema está abierto a Internet u otras redes no confiables, esta es una buena práctica estándar.

NOTA: No olvides cambiar las reglas del firewall para permitir conexiones entrantes en el nuevo puerto.

Establecer un enlace IP a una dirección IP específica

De forma predeterminada, SSH escuchará en todas las direcciones IP (0.0.0.0) configuradas en la máquina. Debes vincular explícitamente SSH a una dirección IP específica, preferiblemente una dirección de administración en una VLAN aislada.

Para configurar el enlace de IP, descomenta, edita o agrega la siguiente línea en sshd_config:

Esto normalmente va de la mano con el enlace de puerto.

Proteger las claves de host SSH

Proteger las claves privadas

Debes proteger la clave de host privado del acceso autorizado. Si la clave privada está comprometida, el host podría ser suplantado. Todos los archivos de clave privada deben ser accesibles solo por la cuenta root (0600).

Para enumerar los permisos de las claves privadas en el directorio /etc/ssh/ usa el comando ls.

Para cambiar los permisos usa el comando chmod:

Es posible que tus sistemas almacenen las claves en un directorio diferente. Puedes determinar dónde se almacenan al verificar el archivo sshd_config. Aquí hay un comando conveniente – grep, para el archivo de la directiva HostKey.

El comando anterior debe enumerar las claves del host y la ruta establecida en su configuración.

Proteger las claves de host público

Aunque no es tan importante como las claves privadas, también debes proteger las claves públicas. Si se modifican, el servicio SSH puede verse comprometido o crear una denegación de servicio. Todos estos deben configurarse como de escritura solo por la cuenta root (0644).

Para listar los permisos de las claves públicas en el directorio /etc/ssh/ usa el comando ls.

Para cambiar los permisos usa el comando chmod:

Las claves públicas a menudo se almacenan con las claves privadas, consulta la sección anterior para obtener información sobre cómo encontrar el directorio.

Comprobar los archivos de configuración específicos del usuario

Sin querer, los usuarios pueden dejar su directorio de inicio o sus archivos abiertos al mundo donde se pueden modificar (¿chmod 777 es mucho?) En este caso, otros usuarios tienen acceso para modificar configuraciones específicas del usuario y pueden iniciar sesión en el servidor como otro usuario. Para detener esto, podemos usar StrictModes para verificar las configuraciones del directorio de inicio.

Para asegurarse de que sshd realice una comprobación de modo estricto de los archivos de inicio, es necesario descomentar, editar o agregar la siguiente línea:

Se recomienda esto, especialmente para sistemas con una gran cantidad de usuarios.

Prevenir la escalada de privilegios

Usando la separación de privilegios de SSH se creará un proceso secundario sin privilegios para aceptar conexiones entrantes. Después de la autenticación del usuario, SSH crea otro proceso con los permisos del usuario autenticado.

El valor predeterminado es sí en todos los sistemas que conozco, pero pensé que valía la pena discutirlo. Puedes configurarlo manualmente al descomentar, editar o agregarla siguiente línea a sshd_config:

El uso de sandbox añade restricciones adicionales.

Usar autenticación de clave pública

Esto puede no ser factible en todos los sistemas. Pero el uso de la autenticación de clave SSH puede proporcionar múltiples beneficios. La autenticación de claves es mucho más fuerte que cualquier contraseña que un humano pueda recordar fácilmente. También proporciona autenticación sin contraseña para una mayor comodidad.

Para permitir que la autenticación de clave pública descomenta, edita o cambia la siguiente línea en sshd_config:

Este valor predeterminado es sí en la mayoría de los sistemas.

Para aprender cómo configurar la autenticación de clave SSH, puedes leer este post:  “Cómo configurar la autenticación de claves SSH“.

Deshabilitar los métodos de autenticación no utilizados

Los administradores de Linux saben que es una buena práctica detener y eliminar cualquier servicio que no estés usando. De manera similar, debes deshabilitar cualquier método de autenticación que no estés usando en SSH.

Aquí te mostramos cómo deshabilitar todos los métodos de autenticación. Ten cuidado de no deshabilitarlos a todos.

Deshabilitar la autenticación GSSAPI

Las configuraciones avanzadas y los métodos de autenticación adicionales están disponibles a través de Generic Security Service Application Program Interface (GSSAPI). Si no estás usando esto, debería estar deshabilitado.

Para deshabilitar GSSAPI, descomenta, edita o agrega la siguiente línea a sshd_config:

Deshabilitar la autenticación Kerberos

Nuevamente, si no lo estás usando, desactívalo.

Para deshabilitar la autenticación Kerberos, elimina el comentario, edita o agrega la siguiente línea a sshd_config:

Deshabilitar la autenticación de contraseña

Puedes desactivar la autenticación de contraseña si has configurado y probado un método de autenticación mejor.

Para deshabilitar la autenticación de contraseña, elimina el comentario o cambia la siguiente línea en sshd_config:

Deshabilitar la autenticación de clave pública

Si estás utilizando otro método de autenticación, puedes deshabilitar la autenticación de clave pública. Dejar la autenticación de clave pública configurada en sí es un riesgo menor que otros métodos.

Para deshabilitar la autenticación de clave pública debes descomentar, cambiar o agregar la siguiente línea en sshd_config:

Utilizar cifrados compatibles con FIPS 140-2

Utiliza la compatibilidad con FIP 140-2 para evitar algoritmos de cifrado débiles.

Para asegurarse de que SSH esté utilizando el cifrado aprobado por FIPS 140-2, descomenta, edita o agrega la siguiente línea a sshd_config:

Esto limita los cifrados que se pueden utilizar para SSH. Asegúrate de probar la compatibilidad con cualquier cliente antiguo, scripts o aplicaciones que puedan usar SSH.

Utilizar FIPS 140-2 compatibles con MACs

Utiliza la conformidad FIP 140-2 para evitar los hashes criptográficos débiles.

Para asegurarse de que SSH use el Messages Authentication Code (MACs) aprobado por FIPS 140-2, corrige o agrega la siguiente línea a sshd_config:

Asegúrate de probar la compatibilidad con cualquier cliente antiguo, scripts o aplicaciones que puedan usar SSH.

Filtrar las conexiones SSH entrantes en el Firewall del host

Filtrar las conexiones SSH entrantes es una buena manera de asegurar SSH. Aunque no siempre es factible. Puedes permitir que solo direcciones IP específicas o subredes se conecten a tu sistema. No podemos cubrir todos los firewalls, pero aquí hay ejemplos que usan iptables, firewalld y Uncomplicated Firewall (UFW) .

Filtrar conexiones SSH con iptables

Para permitir que solo una dirección IP específica se conecte a SSH mediante iptables:

Para permitir que una subred se conecte a SSH mediante iptables:

NOTA: Cambia la dirección IP y el número de puerto para que coincida con tu configuración.

Para obtener más información sobre iptables, lee este post “Cómo configurar IPTables”.

Filtrar conexiones SSH con Firewalld

Para permitir que una dirección IP específica se conecte a SSH mediante Firewalld:

Para permitir que una subred se conecte a SSH mediante Firwalld:

NOTA: Cambia la dirección IP y el número de puerto para que coincida con tu configuración.

Filtrar conexiones SSH con UFW

Para permitir que una dirección IP específica se conecte a SSH:

Para permitir que una subred se conecte a SSH:

NOTA: Cambia la dirección IP y el número de puerto para que coincida con tu configuración.

Configuración de un banner de conexión

En mi experiencia, esto hace más daño que bien. Puede disuadir a algunos scripts kiddies, pero la mayoría de los crackers experimentados tomarán un banner bien hecho como un desafío. Si decides agregar un banner, me gustaría pensar en lo anterior cuando establezcas el tono del mensaje.

Para establecer un banner, descomenta, edita o agrega la siguiente línea:

Luego edita el archivo /etc/issue con la verborrea que deseas que se muestre cuando alguien se conecte a SSH en tu sistema.

Programas opcionales

Hay una gran cantidad de programas que se pueden instalar para ayudar a frustrar los ataques. El más conocido es fail2ban, que analiza los registros en busca de comportamientos maliciosos como demasiadas fallas de contraseña. Luego realiza una acción como actualizar las reglas del firewall para bloquear la dirección IP ofensiva.

La configuración completa de fail2ban no se cubre en este artículo.

Conclusión

Cubrimos muchas opciones para ayudar a proteger tu demonio SSH en este tutorial. Como dije en la introducción, la posibilidad de cada configuración depende de ti. Solo tú puedes analizar la conveniencia frente a la seguridad de cada uno. Saber qué opciones están disponibles es siempre un buen comienzo y creo que cubrimos la mayoría de ellas.

Si utilizas todos los ajustes de esta página, tu configuración superará los estándares de configuración que sugieren las organizaciones de seguridad informática.