Cómo reforzar OpenSSH en Ubuntu 20.04

Jamie Scaife escribió una versión anterior de este tutorial .

Introducción

Los servidores Linux a menudo se administran de forma remota mediante SSH conectándose a un servidor OpenSSH , que es el software de servidor SSH predeterminado utilizado en Ubuntu, Debian, CentOS, FreeBSD y la mayoría de los demás sistemas basados ​​en Linux/BSD.

El servidor OpenSSH es el lado servidor de SSH, también conocido como demonio SSH o sshd. Puede conectarse a un servidor OpenSSH mediante el cliente OpenSSH, específicamente ejecutando el sshcomando . Puede obtener más información sobre el modelo cliente-servidor SSH en SSH Essentials: Working with SSH Servers, Clients, and Keys . Proteger adecuadamente su servidor OpenSSH es muy importante, ya que actúa como la puerta de entrada o punto de entrada a su servidor.

En este tutorial, fortalecerá su servidor OpenSSH mediante el uso de diferentes opciones de configuración para garantizar que el acceso remoto a su servidor sea lo más seguro posible.

Prerrequisitos

Para completar este tutorial, necesitarás:

• Un servidor Ubuntu 20.04 configurado siguiendo la configuración inicial del servidor con Ubuntu 20.04 , incluido un usuario sudo que no sea root.

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

Paso 1: endurecimiento general

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

La configuración de protección exacta más adecuada para su servidor depende en gran medida de su propio modelo de amenaza y umbral de riesgo . Sin embargo, la configuración que utilizará en este paso es una configuración segura general que se adaptará a la mayoría de los servidores.

Editará el archivo de configuración principal de OpenSSH /etc/ssh/sshd_configpara configurar la mayoría de las opciones de protección en este tutorial. Antes de continuar, es una buena idea crear una copia de seguridad de su archivo de configuración existente para que pueda restaurarlo en el improbable caso de que algo salga mal.

Cree una copia de seguridad del archivo utilizando el siguiente cpcomando:

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.

A continuación, revise las opciones de configuración predeterminadas actuales de OpenSSH que corresponden a la configuración en /etc/ssh/sshd_config. Para ello, ejecute el siguiente comando:

sudo sshd -T

Esto ejecutará el servidor OpenSSH en modo de prueba extendido, 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 nanosu editor de texto favorito para comenzar a implementar las medidas de fortalecimiento iniciales:

sudo nano /etc/ssh/sshd_config

Nota: El archivo de configuración del servidor OpenSSH que se instala con Ubuntu 20.04 incluye muchas opciones y configuraciones predeterminadas. Según la configuración de su servidor existente, es posible que ya se hayan configurado algunas de las opciones de protección recomendadas.

Al editar el archivo de configuración, es posible que algunas opciones estén comentadas de forma predeterminada mediante un solo carácter numeral ( #) al comienzo de la línea. Para editar estas opciones o habilitar la opción, deberá quitar el comentario eliminando el carácter numeral.

La primera opción de protección es deshabilitar el inicio de sesión a través de SSH como usuario root . Establezca la PermitRootLoginopción nodescomentando o editando la línea:

configuración sshd

PermitRootLogin no

Esta opción evitará que un posible atacante inicie sesión en su servidor directamente como root. También fomenta buenas prácticas de seguridad operativa de su parte, como operar como un usuario sin privilegios y utilizar sudola función de 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 en particular configurando la MaxAuthTriesopción:

configuración sshd

MaxAuthTries 3

Un valor estándar 3es aceptable para la mayoría de las configuraciones, pero es posible que desees establecerlo más alto o más bajo según tu propio umbral de riesgo.

Si es necesario, también puede establecer un período de gracia de inicio de sesión reducido, que es la cantidad de tiempo que tiene un usuario para completar la autenticación después de conectarse inicialmente a su servidor SSH:

configuración sshd

LoginGraceTime 20

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

Establecer este valor en un valor más bajo ayuda a prevenir ciertos ataques de denegación de servicio en los que se mantienen abiertas múltiples sesiones de autenticación durante un período de tiempo prolongado.

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

configuración sshd

PasswordAuthentication no

Como medida de protección adicional relacionada con las contraseñas, también puede desactivar la autenticación con contraseñas vacías. Esto evitará los inicios de sesión si la contraseña de un usuario está configurada con un valor en blanco o vacío:

configuración sshd

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 admite muchos otros métodos de autenticación, algunos de los cuales están habilitados de forma predeterminada. Si no son necesarios, puede deshabilitarlos para reducir aún más la superficie de ataque de su servidor SSH:

configuración sshd

ChallengeResponseAuthentication noKerberosAuthentication noGSSAPIAuthentication no

Si desea obtener más información sobre algunos de los métodos de autenticación adicionales disponibles dentro de SSH, puede revisar estos recursos:

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

El reenvío X11 permite visualizar aplicaciones gráficas remotas a través de una conexión SSH, pero esto rara vez se utiliza en la práctica. Deshabilítelo si no está ejecutando un entorno gráfico en su servidor:

configuración sshd

X11Forwarding no

El servidor OpenSSH permite que los clientes que se conectan pasen variables de entorno personalizadas. Por ejemplo, un cliente puede intentar configurar sus propios $PATHajustes de terminal. Sin embargo, al igual que el reenvío X11, no se utilizan comúnmente, por lo que puede desactivar la opción en la mayoría de los casos:

configuración sshd

PermitUserEnvironment no

Si decide restringir esta opción configurándola en no, entonces también debe asegurarse de comentar cualquier referencia en el archivo de configuración a AcceptEnvagregando un símbolo ( #) al comienzo de cualquier línea que especifique esa opción.

A continuación, puede desactivar varias opciones diversas relacionadas con la tunelización y el reenvío si no las va a utilizar en su servidor:

configuración sshd

AllowAgentForwarding noAllowTcpForwarding noPermitTunnel no

Por último, puedes desactivar el banner SSH detallado que está habilitado de forma predeterminada, ya que muestra información variada sobre tu sistema, como la versión del sistema operativo:

configuración sshd

DebianBanner no

Tenga en cuenta que es muy probable que esta opción no esté presente en el archivo de configuración, por lo que es posible que deba agregarla manualmente. Guarde y salga del archivo una vez que haya terminado. Si está utilizando la opción, nanopresione CTRL+Opara guardar el archivo y presione ENTERcuando se le solicite el nombre del archivo. Luego, presione CTRL+Xpara salir del editor.

Ahora valide la sintaxis de su nueva configuración ejecutándola sshden modo de prueba con el -tindicador:

sudo sshd -t

Si el archivo de configuración tiene una sintaxis válida, no habrá ningún resultado. En caso de que se produzca un error de sintaxis, se mostrará un resultado que describa el problema.

Una vez que esté satisfecho con su archivo de configuración, puede volver a cargarlo sshdusando systemdpara aplicar la nueva configuración:

sudo systemctl reload sshd.service

En este paso, completó un reforzamiento general del archivo de configuración del 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: Implementación de una lista de direcciones IP permitidas

Puede utilizar listas de direcciones IP permitidas para limitar los usuarios que están 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 podrá iniciar sesión en su servidor desde una pequeña cantidad de direcciones IP conocidas y confiables. Por ejemplo, su conexión a Internet doméstica, un dispositivo VPN corporativo o un servidor de seguridad estático o bastión en un centro de datos.

Al implementar una lista blanca de direcciones IP, puede garantizar que las personas solo puedan iniciar sesión desde una de las direcciones IP preaprobadas, lo que reduce en gran medida el riesgo de una violación en caso de que se filtren sus claves privadas o contraseñas.

Nota: Tenga cuidado al identificar las direcciones IP correctas para agregar a su lista blanca y asegúrese de que no sean direcciones reservadas o dinámicas que puedan cambiar periódicamente, como suele suceder, por ejemplo, con los proveedores de servicios de Internet para consumidores.

Puedes identificar la dirección IP con la que te estás conectando actualmente a tu servidor usando el wcomando:

w

Esto producirá un resultado 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 WHATyour_username     pts/0    203.0.113.1     12:24    1.00s  0.20s  0.00s w

Localice su cuenta de usuario en la lista y tome nota de la dirección IP de conexión. Aquí usamos la IP de ejemplo de203.0.113.1

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

sudo nano /etc/ssh/sshd_config

Puede implementar listas de direcciones IP permitidas utilizando la AllowUsersdirectiva de configuración, que restringe las autenticaciones de usuarios según el nombre de usuario y/o la dirección IP.

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

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

AllowUsers *@203.0.113.1

• Restrinja a todos los usuarios a un rango específico de direcciones IP mediante la notación de enrutamiento entre dominios sin clases (CIDR) :

AllowUsers *@203.0.113.0/24

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

AllowUsers *@203.0.113.*

• Restringir todos los usuarios a múltiples direcciones IP y rangos 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 nombrados de 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 continúa permitiendo que todos los demás usuarios inicien sesión sin restricciones:

Match User ashley  AllowUsers ashley@203.0.113.1

Advertencia: En un archivo de configuración de OpenSSH, todas las configuraciones que se encuentran dentro de un Matchbloque solo se aplicarán a las conexiones que coincidan con los criterios, independientemente de la sangría o los saltos de línea. Esto significa que debe tener cuidado y asegurarse de que las configuraciones que se pretenden aplicar de manera global no se coloquen accidentalmente dentro de un Matchbloque. Se recomienda colocar todos Matchlos bloques al final del archivo de configuración para ayudar a evitar esto.

Una vez que haya finalizado su configuración, agréguela al final del archivo de configuración del servidor OpenSSH:

configuración sshd

AllowUsers *@203.0.113.1

Guarde y cierre el archivo y luego proceda a probar la sintaxis de su configuración:

sudo sshd -t

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

sudo systemctl reload sshd.service

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 puede usar.

Paso 3: Restringir el shell de un usuario

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

Además de proporcionar acceso remoto al shell, 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 desee otorgar acceso completo al shell a los usuarios cuando solo necesitan poder realizar transferencias de archivos.

Existen múltiples configuraciones dentro del servidor OpenSSH que puedes usar para restringir el entorno de shell de usuarios específicos. Por ejemplo, en este tutorial, las usaremos para crear usuarios exclusivos de SFTP.

En primer lugar, puede utilizar el /usr/sbin/nologinshell para deshabilitar los inicios de sesión interactivos para ciertas cuentas de usuario, al tiempo que permite que funcionen sesiones no interactivas, como transferencias de archivos, tunelización, etc.

Para crear un nuevo usuario con el nologinshell, 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 luego intenta iniciar sesión de forma interactiva como uno de estos usuarios, la solicitud será rechazada:

sudo su alex

Esto generará algo similar al siguiente mensaje:

OutputThis account is currently not available.

A pesar del mensaje de rechazo en los inicios de sesión interactivos, aún se permitirán otras acciones como las transferencias de archivos.

A continuación, debe combinar el uso del nologinshell con algunas opciones de configuración adicionales para restringir aún más las cuentas de usuario relevantes.

Comience abriendo nanonuevamente el archivo de configuración del servidor OpenSSH en su editor preferido:

sudo nano /etc/ssh/sshd_config

Hay dos opciones de configuración que puedes implementar juntas para crear una cuenta de usuario solo para SFTP con restricciones estrictas: ForceCommand internal-sftpy ChrootDirectory.

La ForceCommandopción del servidor OpenSSH obliga al usuario a ejecutar un comando específico al iniciar sesión. Esto puede resultar útil para ciertas comunicaciones entre máquinas o para iniciar a la fuerza un programa en particular.

Sin embargo, en este caso, el internal-sftpcomando resulta especialmente útil. Se trata de una función especial del servidor OpenSSH que lanza un demonio SFTP local que no requiere archivos de sistema ni configuración de soporte.

Lo ideal sería combinar esto con la ChrootDirectoryopción que anulará o cambiará el directorio de inicio percibido por un usuario en particular, restringiéndolo esencialmente a un directorio específico en el sistema.

Para ello, agregue la siguiente sección de configuración al archivo de configuración del servidor OpenSSH:

configuración sshd

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

Advertencia: como se indicó en el paso 2, dentro de un archivo de configuración de OpenSSH, todas las configuraciones bajo un Matchbloque solo se aplicarán a las conexiones que coincidan con los criterios, independientemente de la sangría o los saltos de línea. Esto significa que debe tener cuidado y asegurarse de que las configuraciones destinadas a aplicarse globalmente no se coloquen accidentalmente dentro de un Matchbloque. Se recomienda colocar todos Matchlos bloques al final de su archivo de configuración para ayudar a evitar esto.

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

sudo sshd -t

Si no hay errores, puedes aplicar tu configuración:

sudo systemctl reload sshd.service

Esto ha creado una configuración robusta para el alexusuario, donde los inicios de sesión interactivos están deshabilitados y toda la actividad de SFTP está restringida al directorio de inicio del usuario. Desde la perspectiva del usuario, la raíz del sistema, es decir, /, es su directorio de inicio y no podrá recorrer el sistema de archivos para acceder a otras áreas.

Implementó el nologinshell para un usuario y luego creó una configuración para restringir el acceso SFTP a un directorio específico.

Paso 4: endurecimiento avanzado

En este paso final, implementará varias medidas de fortalecimiento adicionales para que el acceso a su servidor SSH sea lo más seguro posible.

El servidor OpenSSH puede imponer restricciones por clave. En concreto, las restricciones se pueden aplicar a cualquier clave pública que esté presente en el .ssh/authorized_keysarchivo. Esta capacidad es especialmente útil para controlar el acceso a sesiones de máquina a máquina, así como para proporcionar a los usuarios que no utilicen sudo la posibilidad de controlar las restricciones para su propia cuenta de usuario.

Si bien puede aplicar la mayoría de estas restricciones a nivel de sistema o de usuario mediante el /etc/ssh/sshd_configurationarchivo, puede ser ventajoso implementarlas también a nivel de clave, para brindar defensa en profundidad y una medida de seguridad adicional en caso de errores de configuración accidentales en todo el sistema.

Nota: solo puedes implementar estas configuraciones de seguridad adicionales si usas la autenticación de clave pública SSH. Si solo usas la autenticación con contraseña o tienes una configuración más compleja, como una autoridad de certificación SSH, estas opciones no estarán disponibles.

Comience abriendo su .ssh/authorized_keysarchivo en nanosu editor preferido:

nano ~/.ssh/authorized_keys

Nota: Dado que estas configuraciones se aplican por clave, deberá editar cada clave individual dentro de cada authorized_keysarchivo individual al que desee que se apliquen, para todos los usuarios de su sistema. Por lo general, solo necesitará editar una clave o archivo, pero vale la pena considerarlo si tiene un sistema complejo con múltiples usuarios.

Una vez que hayas abierto el authorized_keysarchivo, verás que cada línea contiene una clave pública SSH, que probablemente comience con algo como ssh-rsa AAAB.... Se pueden agregar opciones de configuración adicionales al comienzo de la línea, y estas solo se aplicarán a las autenticaciones exitosas con esa clave pública específica.

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

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

Puede aplicarlos para deshabilitar funciones SSH específicas para claves específicas. Por ejemplo, para deshabilitar el reenvío de agente y el reenvío X11 para una clave, debe utilizar la siguiente configuración:

~/.ssh/claves_autorizadas

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

De forma predeterminada, estas configuraciones funcionan utilizando una metodología de “permitir por defecto, bloquear por excepción”; sin embargo, también es posible utilizar “bloquear por defecto, permitir por excepción”, que generalmente es preferible para garantizar la seguridad.

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

Por ejemplo, para deshabilitar todas las funciones SSH para una clave particular, excepto el reenvío de pantalla X11, puede utilizar la siguiente configuración:

~/.ssh/claves_autorizadas

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

También puede considerar usar la commandopción , que es muy similar a la ForceCommandopción descrita en el Paso 3. Esto no proporciona un beneficio directo si ya está usando ForceCommand, pero es una buena defensa en profundidad tenerlo en su lugar, solo en el caso poco probable de que su archivo de configuración del servidor OpenSSH principal se sobrescriba, edite, etc.

Por ejemplo, para forzar a los usuarios a autenticarse usando una clave específica para ejecutar un comando específico al iniciar sesión, puede agregar la siguiente configuración:

~/.ssh/claves_autorizadas

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

Advertencia: La commandopción de configuración actúa únicamente como un método de defensa en profundidad y no debe utilizarse únicamente para restringir las actividades de un usuario de SSH, ya que existen formas potenciales de anularla o eludirla según el entorno. En su lugar, debe utilizar la configuración junto con los demás controles descritos en este artículo.

Por último, para aprovechar al máximo las restricciones por clave para el usuario exclusivo de SFTP que creó en el Paso 3, puede utilizar la siguiente configuración:

~/.ssh/claves_autorizadas

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

La restrictopción deshabilitará todo acceso interactivo y command="false"actuará como una segunda línea de defensa en caso de que la ForceCommandopción o nologinel shell fallen.

Guarde y cierre el archivo para aplicar la configuración. Esto tendrá efecto inmediatamente para todos los nuevos inicios de sesión, por lo que no es necesario volver a cargar OpenSSH manualmente. Asegúrese de probar los comandos que desea utilizar antes de desconectar su sesión SSH actual.

En este paso final, implementó algunas medidas de fortalecimiento avanzadas adicionales para el servidor OpenSSH mediante el uso de opciones personalizadas dentro de sus .ssh/authorized_keysarchivos.

Conclusión

En este artículo, revisó la configuración de su servidor OpenSSH e implementó varias medidas de fortalecimiento para ayudar a proteger su servidor.

Las opciones que configuró han reducido la superficie de ataque general de su servidor al deshabilitar funciones no utilizadas y bloquear el acceso de usuarios específicos.

Es posible que desee revisar las páginas del manual del servidor OpenSSH y su archivo de configuración asociado , para identificar posibles ajustes adicionales que desee realizar.