Cómo reforzar OpenSSH en Ubuntu 18.04

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

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 (el sshcomando ). Puede obtener más información sobre el modelo cliente-servidor SSH en SSH Essentials: Working with SSH Servers, Clients, and Keys (Fundamentos de SSH: trabajar con servidores, clientes y claves SSH ). Proteger adecuadamente su servidor OpenSSH es muy importante, ya que actúa como la puerta de entrada o 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 18.04 configurado siguiendo la configuración inicial del servidor con Ubuntu 18.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.

Muchas de las configuraciones de protección de OpenSSH se implementan mediante el archivo de configuración de servidor OpenSSH estándar, que se encuentra en /etc/ssh/sshd_config. Antes de continuar con este tutorial, se recomienda realizar una copia de seguridad de su archivo de configuración existente, de modo que pueda restaurarlo en el improbable caso de que algo salga mal.

Realice una copia de seguridad del archivo utilizando 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 el archivo de configuración, puede revisar las opciones que están configuradas actualmente. 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 su 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 incluye muchas opciones y configuraciones predeterminadas. Según la configuración de su servidor actual, 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 hacer que se reconozca la opción comentada, deberá quitar el comentario de las mismas eliminando el carácter numeral.

En primer lugar, deshabilite el inicio de sesión a través de SSH como usuario root configurando la siguiente opción:

configuración sshd

PermitRootLogin no

Esto es muy beneficioso, ya que evitará que un posible atacante inicie sesión directamente como root. También fomenta buenas prácticas de seguridad operativa, como operar como un usuario sin privilegios y sudoaumentar los 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 lo siguiente:

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. Se recomienda desactivarlo si no es necesario en el servidor:

configuración sshd

X11Forwarding no

El servidor OpenSSH permite que los clientes que se conectan pasen variables de entorno personalizadas, es decir, que establezcan $PATHo configuren parámetros de terminal. Sin embargo, al igual que el reenvío X11, no se usan comúnmente, por lo que se pueden deshabilitar en la mayoría de los casos:

configuración sshd

PermitUserEnvironment no

Si decide configurar esta opción, también debe asegurarse de comentar cualquier referencia AcceptEnvagregando un símbolo ( #) al comienzo de la línea.

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.

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

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 sshdpara aplicar la nueva configuración:

sudo service sshd reload

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 generará 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 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 su editor de texto favorito:

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

Paso 3: Restringir el shell de un usuario

En este paso, verás 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 nuevamente el archivo de configuración del servidor OpenSSH en su editor de texto favorito:

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 básico en el lugar 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 raíz 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 service sshd reload

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.

Una característica menos conocida del servidor OpenSSH es la capacidad de imponer restricciones por clave, es decir, restricciones que se aplican solo a claves públicas específicas presentes en el .ssh/authorized_keysarchivo. Esto es particularmente útil para controlar el acceso a sesiones de máquina a máquina, así como para brindar la capacidad a los usuarios que no utilizan sudo de controlar las restricciones para su propia cuenta de usuario.

También puede aplicar la mayoría de estas restricciones a nivel de sistema o de usuario, aunque sigue siendo ventajoso implementarlas también a nivel de clave, para proporcionar una defensa en profundidad y un mecanismo 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, lamentablemente no podrás usarlas.

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

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 obligar a los usuarios que se autentican con una clave específica a 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 de inmediato para todos los nuevos inicios de sesión, por lo que no es necesario volver a cargar OpenSSH manualmente.

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.

Esto reducirá 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.