Cómo endurecer OpenSSH en Ubuntu 18.04

El autor seleccionó la Electronic Frontier Foundation Inc para recibir una donación como parte del programa Write for DOnations.

Introducción

Los servidores Linux suelen administrarse remotamente usando SSH mediante la conexión con un servidor OpenSSH, que es el software de servidor SSH predeterminado usado en Ubuntu, Debian, CentOS, y la mayoría de los otros sistemas basados en Linux/BSD.

El servidor OpenSSH es la parte de servidor de SSH, también conocida como daemon SSH o sshd. Puede conectar con un servidor OpenSSH usando el cliente OpenSSH: el comando ssh. Puede obtener más información sobre el modelo cliente-servidor SSH en Puntos esenciales de SSH: Trabajar con servidores, clientes y claves SSH. Proteger de forma adecuada su servidor OpenSSH es muy importante, ya que actúa como la puerta principal o de entrada a su servidor.

En este tutorial, endurecerá su servidor OpenSSH usando diferentes opciones de configuración para garantizar que el acceso remoto a su servidor sea tan seguro como sea posible.

Requisitos previos

Para completar este tutorial, necesitará lo siguiente:

• Un servidor de Ubuntu 18.04 configurado conforme a la Configuración inicial de servidores con Ubuntu 18.04, con un usuario sudo no root.

Una vez que tenga todo esto listo, para comenzar inicie sesión en su servidor como usuario no root.

Paso 1: Endurecimiento general

En este primer paso, implementará algunas configuraciones iniciales de endurecimiento para mejorar la seguridad general de su servidor SSH.

La configuración de endurecimiento exacta más adecuada para su propio servidor depende en gran medida de su propio modelo de amenazas y nivel de riesgo. Sin embargo, la configuración que usará en este paso es una configuración segura general que será adecuada para la mayoría de los servidores.

Muchas de las configuraciones de endurecimiento para OpenSSH las implementará usando el archivo de configuración estándar del servidor OpenSSH, que está ubicado en /etc/ssh/sshd_config. Antes de continuar con este tutorial, recomendamos que haga una copia de seguridad de su archivo de configuración existente, para que pueda restaurarlo en el improbable caso de que algo salga mal.

Realice una copia de seguridad del archivo usando el siguiente comando:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Esto guardará una copia de seguridad del archivo en /etc/ssh/sshd_config.bak.

Antes de editar su archivo de configuración, puede revisar las opciones que están establecidas actualmente. Para hacer esto, ejecute el siguiente comando:

sudo sshd -T

Esto ejecutará el servidor OpenSSH en modo de prueba ampliado, lo que validará el archivo de configuración completo e imprimirá los valores de configuración efectivos.

Ahora puede abrir el archivo de configuración usando su editor de texto favorito para comenzar a implementar las medidas de endurecimiento iniciales:

sudo nano /etc/ssh/sshd_config

Cuando edite su archivo de configuración, algunas opciones pueden omitirse por defecto usando un carácter almohadilla único (#) al inicio de la línea. Para editar estas opciones, o que la opción omitida sea reconocida, deberá dejar de omitirlas eliminando la almohadilla.

Primero, deshabilite el inicio de sesión a través de SSH como el usuario root estableciendo la siguiente opción:

PermitRootLogin no

Esto es sumamente beneficioso, ya que evitará que un atacante potencial inicie sesión directamente como root. También alienta las buenas prácticas de seguridad operativas, como operar como usuario sin privilegios y usar sudo para escalar privilegios solo cuando sea absolutamente necesario.

A continuación, puede limitar el número máximo de intentos de autenticación para una sesión de inicio de sesión concreta configurando lo siguiente:

MaxAuthTries 3

Un valor estándar de 3 es aceptable para la mayoría de configuraciones, pero es posible que desee establecer esto más alto o más bajo dependiendo de su propio umbral de riesgo.

Si es necesario, puede también establecer un periodo de gracia de inicio de sesión reducido, que es la cantidad de tiempo que un usuario tiene para completar la autenticación tras conectar inicialmente con su servidor SSH:

LoginGraceTime 20

El archivo de configuración especifica este valor en segundos.

Establecer esto a un valor inferior ayuda a evitar ciertos ataques de denegación de servicio, en los que múltiples sesiones de autenticación se mantienen abiertas durante un periodo de tiempo prolongado.

Si ha configurado claves SSH para la autenticación, en vez de usar contraseñas, deshabilite la autenticación por contraseña SSH para evitar que las contraseñas de usuario filtradas permitan a un atacante iniciar sesión:

PasswordAuthentication no

Como otra medida de endurecimiento relacionada con las contraseñas, es posible que también desee deshabilitar la autenticación con contraseñas vacías. Esto evitará los inicios de sesión si una contraseña de usuario se establece como un valor en blanco o vacío:

PermitEmptyPasswords no

En la mayoría de los casos de uso, SSH se configurará con autenticación de clave pública como el único método de autenticación en uso. Sin embargo, el servidor OpenSSH también es compatible con muchos otros métodos de autenticación, algunos de los cuales están habilitados por defecto. Si estos no son necesarios, puede deshabilitarlos para reducir aún más la superficie de ataque de su servidor SSH:

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Si desea obtener más información sobre otros métodos de autenticación disponibles en SSH, es posible que desee revisar estos recursos:

• Autenticación desafío-respuesta
• Autenticación de Kerberos
• Autenticación GSSAPI

El reenvío X11 permite mostrar aplicaciones gráficas remotas sobre una conexión SSH, pero esto apenas se usa en la práctica. Se recomienda deshabilitarlo si no es necesario en su servidor:

X11Forwarding no

El servidor OpenSSH permite conectar clientes para pasar variables de entorno personalizadas, es decir, configurar un $PATH o configurar ajustes de terminal. Sin embargo, al igual que el reenvío X11, estos no se usan normalmente, así que pueden deshabilitarse en la mayoría de los casos:

PermitUserEnvironment no

Si decide configurar esta opción, debería asegurarse de omitir cualquier referencia a AcceptEnv añadiendo una almohadilla (#) al principio de la línea.

A continuación, puede deshabilitar varias opciones diversas relacionadas con la canalización y reenvío si no las va a usar en su servidor:

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

Finalmente, puede deshabilitar el banner textual SSH que está habilitado por defecto, ya que muestra diferentes informaciones sobre su sistema, como la versión del sistema operativo:

DebianBanner no

Tenga en cuenta que esta opción probablemente no esté ya presente en el archivo de configuración, de forma que es posible que la tenga que añadir manualmente. Guarde y salga del archivo una vez que termine.

Ahora, valide la sintaxis de su nueva configuración ejecutando sshd en modo de prueba:

sudo sshd -t

Si su archivo de configuración tiene una sintaxis válida, no habrá resultados. En el caso de que se produzca un error de sintaxis, verá un resultado describiendo el problema.

Una vez satisfecho con su archivo de configuración, puede recargar sshd para aplicar los nuevos ajustes:

sudo service sshd reload

En este paso, ha completado cierto endurecimiento general del archivo de configuración de su servidor OpenSSH. A continuación, implementará una lista de direcciones IP permitidas para restringir aún más quién puede iniciar sesión en su servidor.

Paso 2: Implementar una lista de direcciones IP permitidas

Puede usar listas de direcciones IP permitidas para limitar los usuarios autorizados a iniciar sesión en su servidor según la dirección IP. En este paso, configurará una lista de direcciones IP permitidas para su servidor OpenSSH.

En muchos casos, solo iniciará sesión en su servidor desde un número pequeño de direcciones IP conocidas de confianza. Por ejemplo, la conexión a Internet de su casa, una aplicación VPN corporativa, un jump box estático o un bastion host en un centro de datos.

Al implementar una lista de direcciones IP permitidas, puede garantizar que las personas solo podrán iniciar sesión desde una de las direcciones IP preaprobadas, reduciendo enormemente el riesgo de sufrir un problema de seguridad en caso de que sus claves o contraseñas privadas se filtren.

Puede identificar la dirección IP con la que está conectando actualmente a su servidor usando el comando w:

w

Con esto, se mostrará algo similar a lo siguiente:

Output
 14:11:48 up 2 days, 12:25,  1 user,  load average: 0.00, 0.00, 0.00
         USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
your_username     pts/0    203.0.113.1     12:24    1.00s  0.20s  0.00s w

Busque su cuenta de usuario en la lista y anote la dirección IP de conexión. Aquí usamos la IP de ejemplo 203.0.113.1

Para comenzar a implementar su lista de direcciones IP permitidas, abra el archivo de configuración del servidor OpenSSH en su editor de texto favorito:

sudo nano /etc/ssh/sshd_config

Puede implementar listas de direcciones IP permitidas usando la directiva de configuración AllowUsers, que restringe las autenticaciones de usuarios según el nombre de usuario o la dirección IP.

La configuración y requisitos de su sistema determinará qué configuración específica es la más apropiada. Los siguientes ejemplos ayudarán a identificar la más adecuada:

• Restringir a todos los usuarios a una dirección IP específica:

AllowUsers *@203.0.113.1

• Restringir a todos los usuarios a un rango específico de direcciones IP usando la notación Classless Inter-Domain Routing (CIDR):

AllowUsers *@203.0.113.0/24

• Restringir a todos los usuarios a un rango específico de direcciones IP (usando comodines):

AllowUsers *@203.0.113.*

• Restringir a todos los usuarios a múltiples direcciones y rangos de IP específicos:

AllowUsers *@203.0.113.1 *@203.0.113.2 *@192.0.2.0/24 *@172.16.*.1

• No permitir a todos los usuarios excepto a los usuarios indicados desde direcciones IP específicas:

AllowUsers sammy@203.0.113.1 alex@203.0.113.2<^>

• Restringir a un usuario específico a una dirección IP específica, mientras se permite que todos los otros usuarios inicien sesión sin restricciones:

Match User ashley
  AllowUsers ashley@203.0.113.1

Una vez que haya terminado su configuración, añádala a la parte inferior de su archivo de configuración del servidor OpenSSH:

AllowUsers *@203.0.113.1

Guarde y cierre el archivo, y continúe a probar su sintaxis de configuración:

sudo sshd -t

Si no se reportan errores, puede volver a cargar el servidor OpenSSH para aplicar su configuración:

sudo service sshd reload

En este paso, implementó una lista de direcciones IP permitidas en su servidor OpenSSH. A continuación, restringirá el shell de un usuario para limitar los comandos que se les permite usar.

Paso 3: Restringir el shell de un usuario

En este paso, verá las diferentes opciones para restringir el shell de un usuario SSH.

Además de proporcionar acceso shell remoto, SSH también es ideal para transferir archivos y otros datos, por ejemplo, a través de SFTP. Sin embargo, es posible que no siempre quiera conceder acceso completo al shell a los usuarios cuando solo necesiten poder realizar transferencias de archivos.

Existen múltiples configuraciones en el servidor OpenSSH que puede usar para restringir el entorno shell de los usuarios particulares. Por ejemplo, en este tutorial las usaremos para crear usuarios solo SFTP.

Primero, puede usar el shell /usr/sbin/nologin para deshabilitar los inicios de sesión interactivos para ciertas cuentas de usuario, permitiendo al mismo tiempo que las sesiones no interactivas sigan funcionando, como transferencias de archivos, canalización, etc.

Para crear un nuevo usuario con el shell nologin, utilice el siguiente comando:

sudo adduser --shell /usr/sbin/nologin alex

Alternativamente, puede cambiar el shell de un usuario existente para que sea nologin:

sudo usermod --shell /usr/sbin/nologin sammy

Si intenta iniciar sesión de forma interactiva como uno de estos usuarios, la solicitud se rechazará:

sudo su alex

Esto mostrará un resultado similar al siguiente mensaje:

Output
This account is currently not available.

A pesar del mensaje de rechazo sobre los inicios de sesión interactivos, se seguirán permitiendo otras acciones como las transferencias de archivos.

A continuación, debería combinar su uso de la shell nologin con algunas opciones de configuración adicionales para restringir aún más las cuentas de usuario relevantes.

Comience abriendo el archivo de configuración del servidor OpenSSH en su editor de texto favorito de nuevo:

sudo nano /etc/ssh/sshd_config

Hay dos opciones de configuración que puede implementar juntas para crear una cuenta de usuario solo SFTP altamente restringida: ForceCommand internal-sftp y ChrootDirectory.

La opción ForceCommand en el servidor OpenSSH fuerza a un usuario a ejecutar un comando específico tras iniciar sesión. Esto puede ser útil para ciertas comunicaciones equipo a equipo o para iniciar de forma forzosa un programa concreto.

Sin embargo, en este caso, el comando internal-sftp es particularmente útil. Esta es una función especial del servidor OpenSSH que inicia un daemon SFTP básico que no necesita ningún archivo de sistema o configuración de soporte.

Esto debería combinarse idealmente con la opción ChrootDirectory, que anulará/cambiará el directorio raíz percibido para un usuario concreto, restringiéndolos esencialmente a un directorio específico en el sistema.

Añada la siguiente sección de configuración a su archivo de configuración del servidor OpenSSH para esto:

Match User alex
  ForceCommand internal-sftp
  ChrootDirectory /home/alex/

Guarde y cierre su archivo de configuración, y luego pruebe su configuración de nuevo:

sudo sshd -t

Si no hay errores, puede aplicar su configuración:

sudo service sshd reload

Esto ha creado una configuración robusta para el usuario alex, donde los inicios de sesión interactivos se deshabilitan, y toda la actividad SFTP se restringe al directorio de inicio del usuario. Desde la perspectiva del usuario, la raíz del sistema, es decir, /, es el directorio de inicio y no podrá atravesar el sistema de archivos a otras áreas.

Ha implementado el shell nologin para un usuario y luego ha creado una configuración para restringir el acceso SFTP a un directorio específico.

Paso 4: Endurecimiento avanzado

En este paso final, implementará varias medias de endurecimiento adicionales para hacer que el acceso a su servidor SSH sea tan seguro como se posible.

Una función menos conocida del servidor OpenSSH es la capacidad para imponer restricciones según la clave, es decir, restricciones que se aplican solo a claves públicas específicas presentes en el archivo .ssh/authorized_keys. Esto es particularmente útil para controlar el acceso para las sesiones equipo a equipo, y para proporcionar la capacidad a los usuarios no sudo de controlar las restricciones para su propia cuenta de usuario.

Puede aplicar la mayoría de estas restricciones a nivel de usuario o sistema también, sin embargo, es ventajoso implementarlas a nivel de clave también, para proporcionar defensa en profundidad y un mecanismo de seguridad adicional en caso de errores de configuración accidentales en todo el sistema.

Comience abriendo su archivo .ssh/autorized_keys en su editor de texto favorito:

nano ~/.ssh/authorized_keys

Una vez que haya abierto su archivo authorized_keys, verá que cada línea contiene una clave pública SSH, que probablemente comenzará con algo como ssh-rsa AAAB.... Pueden añadirse opciones de configuración adicionales al principio de la línea, y estas solo se aplicarán para las autenticaciones correctas contra esa clave pública específica.

Las siguientes opciones de restricción están disponibles:

• no-agent-forwarding: Desactivar el reenvío de agente SSH.
• no-port-forwarding: Deshabilitar el reenvío de puerto SSH.
• no-pty: Deshabilitar la capacidad de asignar un tty (es decir, inicial un shell).
• no-user-rc: Evitar la ejecución del archivo ~/.ssh/rc.
• no-X11-forwarding: Deshabilitar el reenvío de pantalla X11.

Puede aplicar estas configuraciones para deshabilitar funciones SSH específicas para claves específicas. Por ejemplo, para deshabilitar el reenvío de agente y el reenvío de X11 para una clave, usaría la siguiente configuración:

no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...

Por defecto, estas configuraciones funcionan usando una metodología “permitir por defecto, bloque por excepción”; sin embargo, también es posible usar “bloque por defecto, permitir por excepción” lo cual es generalmente preferible para garantizar la seguridad.

Puede hacer esto usando la opción restrict, que implícitamente denegará todas las funciones SSH para la clave específica, requiriendo que se vuelvan a habilitar explícitamente solo cuando sea absolutamente necesario. Puede volver a habilitar las funciones usando las mismas opciones de configuración descritas anteriormente en este tutorial, pero sin el prefijo no-.

Por ejemplo, para deshabilitar todas las funciones SSH para una clave concreta, aparte del reenvío de pantalla X11, puede usar la siguiente configuración:

restrict,X11-forwarding ssh-rsa AAAB...

Es posible que desee considerar usar la opción command, que es muy similar a la opción ForceCommand descrita en el Paso 3. Esto no le ofrece un beneficio directo si ya está usando ForceCommand, pero es una nueva defensa en profundidad que implementar, en el improbable evento de que se sobrescriba, edite, etc., el archivo de configuración de su servidor Open SSH principal.

Por ejemplo, para forzar que los usuarios autentiquen contra una clave específica para ejecutar un comando específico tras el inicio de sesión, puede añadir la siguiente configuración:

command="top" ssh-rsa AAAB...

Finalmente, para usar mejor las restricciones por clave para el usuario solo SFTP que creó en el Paso 3, puede usar la siguiente configuración:

restrict,command="false" ssh-rsa AAAB...

La opción restrict deshabilitará todo el acceso interactivo, y la opción command="false" actúa como una segunda línea de defensa en el caso de que fallaran la opción ForceCommand o el shell nologin.

Guarde y cierre el archivo para aplicar la configuración. Esto tendrá efecto de inmediato para todos los nuevos inicios de sesión, de forma que no es necesario que vuelva a cargar OpenSSH manualmente.

En este paso final, implementó algunas medidas de endurecimiento avanzadas adicionales para el servidor OpenSSH usando las opciones personalizadas en sus archivos .ssh/authorized_keys.

Conclusión

En este artículo, ha revisado la configuración de su servidor OpenSSH y ha implementado varias medidas de endurecimiento para ayudar a proteger su servidor.

Esto reducirá la superficie general de ataque de su servidor deshabilitando las funciones no utilizadas y bloqueando el acceso por parte de usuarios específicos.

Es posible que desee revisar las páginas del manual para el servidor OpenSSH y su archivo de configuración asociado para identificar cualquier ajuste potencial adicional que desee realizar.