Las mejores formas de proteger su servidor SSH

 

Asegure la conexión SSH de su sistema Linux para proteger su sistema y sus datos. Tanto los administradores de sistemas como los usuarios domésticos necesitan reforzar y proteger las computadoras con acceso a Internet, pero SSH puede ser complicado. Aquí hay diez sencillos beneficios rápidos para ayudar a proteger su servidor SSH.

Conceptos básicos de seguridad SSH

SSH son las siglas de Secure Shell. El nombre "SSH" se usa indistintamente para significar el protocolo SSH en sí mismo o las herramientas de software que permiten a los administradores y usuarios del sistema realizar conexiones seguras a computadoras remotas usando ese protocolo.

El protocolo SSH es un protocolo encriptado diseñado para brindar una conexión segura a través de una red insegura, como Internet. SSH en Linux se basa en una versión portátil del proyecto OpenSSH. Se implementa en un modelo cliente-servidor clásico, con un servidor SSH que acepta conexiones de clientes SSH. El cliente se utiliza para conectarse al servidor y mostrar la sesión al usuario remoto. El servidor acepta la conexión y ejecuta la sesión.

En su configuración predeterminada, un servidor SSH escuchará las conexiones entrantes en el puerto 22 del Protocolo de control de transmisión ( TCP ). Debido a que este es un puerto estandarizado y bien conocido, es un objetivo para los actores de amenazas y bots maliciosos.

Los actores de amenazas lanzan bots que escanean una variedad de direcciones IP en busca de puertos abiertos. A continuación, se examinan los puertos para ver si existen vulnerabilidades que puedan explotarse. Pensar: "Estoy a salvo, hay objetivos más grandes y mejores que yo para que los malos apunten", es un razonamiento falso. Los bots no seleccionan objetivos basados ​​en ningún mérito; están buscando metódicamente sistemas que puedan violar.

Te nominas a ti mismo como víctima si no has asegurado tu sistema.

Fricción de seguridad

La fricción de seguridad es la irritación, en cualquier grado, que los usuarios y otras personas experimentarán cuando implemente medidas de seguridad. Tenemos una gran memoria y podemos recordar haber presentado a nuevos usuarios un sistema informático y escucharlos preguntar con voz horrorizada si realmente tenían que ingresar una contraseña cada vez que iniciaban sesión en el mainframe. Eso, para ellos, era una fricción de seguridad.

(Por cierto, la invención de la contraseña se le atribuye a Fernando J. Corbató, otra figura del panteón de informáticos cuyo trabajo combinado contribuyó a las circunstancias que llevaron al nacimiento de  Unix ).

La introducción de medidas de seguridad suele implicar algún tipo de fricción para alguien. Los dueños de negocios tienen que pagar por ello. Es posible que los usuarios de computadoras tengan que cambiar sus prácticas familiares, recordar otro conjunto de detalles de autenticación o agregar pasos adicionales para conectarse correctamente. Los administradores del sistema tendrán trabajo adicional que hacer para implementar y mantener las nuevas medidas de seguridad.

Endurecer y bloquear un sistema operativo Linux o similar a Unix puede resultar muy complicado, muy rápidamente. Lo que presentamos aquí es un conjunto de pasos fáciles de implementar que mejorarán la seguridad de su computadora sin la necesidad de aplicaciones de terceros y sin tener que buscar en su firewall.

Estos pasos no son la última palabra en seguridad SSH, pero lo harán avanzar mucho desde la configuración predeterminada y sin demasiada fricción.

Utilice la versión 2 del protocolo SSH

En 2006, el protocolo SSH se actualizó de la versión 1 a la versión 2. Fue una mejora significativa. Hubo tantos cambios y mejoras, especialmente en lo que respecta al cifrado y la seguridad, que la versión 2 no es compatible con la versión 1. Para evitar conexiones de clientes de la versión 1, puede estipular que su computadora solo aceptará conexiones de clientes de la versión 2.

Para hacerlo, edite el /etc/ssh/sshd_configarchivo. Haremos esto mucho a lo largo de este artículo. Siempre que necesite editar este archivo, este es el comando que debe usar:

sudo gedit / etc / ssh / sshd_config

Agrega la línea:

Protocolo 2

Y guarde el archivo. Vamos a reiniciar el proceso del demonio SSH. Nuevamente, haremos esto mucho a lo largo de este artículo. Este es el comando a utilizar en cada caso:

sudo systemctl reiniciar sshd

Comprobemos que nuestra nueva configuración está vigente. Saltaremos a una máquina diferente e intentaremos SSH en nuestra máquina de prueba. Y usaremos la -1 opción (protocolo 1) para forzar al sshcomando a usar la versión 1 del protocolo.

ssh -1 dave@howtogeek.local

Genial, nuestra solicitud de conexión fue rechazada. Asegurémonos de que todavía podemos conectarnos con el protocolo 2. Usaremos la -2opción (protocolo 2) para probar el hecho.

ssh -2 dave@howtogeek.local

El hecho de que el servidor SSH solicite nuestra contraseña es una indicación positiva de que se ha establecido la conexión y que está interactuando con el servidor. En realidad, debido a que los clientes SSH modernos usarán de forma predeterminada el protocolo 2, no necesitamos especificar el protocolo 2 siempre que nuestro cliente esté actualizado.

ssh dave@howtogeek.local

Y nuestra conexión es aceptada. Por lo tanto, sólo se rechazan las conexiones de protocolo 1 más débiles y menos seguras.

Evite el puerto 22

El puerto 22 es el puerto estándar para conexiones SSH. Si usa un puerto diferente, agrega un poco de seguridad a través de la oscuridad a su sistema. La seguridad a través de la oscuridad nunca se considera una verdadera medida de seguridad, y la he criticado en otros artículos. De hecho, algunos de los robots de ataque más inteligentes sondean todos los puertos abiertos y determinan qué servicio llevan, en lugar de basarse en una simple lista de búsqueda de puertos y asumir que brindan los servicios habituales. Pero usar un puerto no estándar puede ayudar a reducir el ruido y el tráfico en el puerto 22.

Para configurar un puerto no estándar, edite su archivo de configuración SSH:

sudo gedit / etc / ssh / sshd_config

Elimine el hash # del inicio de la línea "Port" y reemplace el "22" con el número de puerto de su elección. Guarde su archivo de configuración y reinicie el demonio SSH:

sudo systemctl reiniciar sshd

Veamos qué efecto ha tenido eso. En nuestra otra computadora, usaremos el sshcomando para conectarnos a nuestro servidor. El sshcomando usa por defecto el puerto 22:

ssh dave@howtogeek.local

Nuestra conexión es rechazada. Intentemos nuevamente y especifiquemos el puerto 470, usando la opción -p (puerto):

ssh -p 479 dave@howtogeek.local

Se acepta nuestra conexión.

Filtrar conexiones mediante envoltorios TCP

TCP Wrappers es una lista de control de acceso fácil de entender. Le permite excluir y permitir conexiones según las características de la solicitud de conexión, como la dirección IP o el nombre de host. Los envoltorios TCP deben usarse junto con, y no en lugar de, un firewall configurado correctamente. En nuestro escenario específico, podemos ajustar las cosas considerablemente mediante el uso de envoltorios TCP.

Los contenedores TCP ya estaban instalados en la máquina Ubuntu 18.04 LTS utilizada para investigar este artículo. Tenía que instalarse en Manjaro 18.10 y Fedora 30.

Para instalar en Fedora, use este comando:

sudo yum install tcp_wrappers

Para instalar en Manjaro, use este comando:

sudo pacman -Syu tcp-wrappers

Hay dos archivos involucrados. Uno tiene la lista de permitidos y el otro tiene la lista de denegados. Edite la lista de denegación usando:

sudo gedit /etc/hosts.deny

Esto abrirá el gediteditor con el archivo de denegación cargado en él.

Necesitas agregar la línea:

TODO TODO

Y guarde el archivo. Eso bloquea todo acceso que no ha sido autorizado. Ahora necesitamos autorizar las conexiones que desea aceptar. Para hacer eso, necesita editar el archivo de permiso:

sudo gedit /etc/hosts.allow

Esto abrirá el gediteditor con el archivo de permiso cargado en él.

Hemos agregado el nombre del demonio SSH SSHD, y la dirección IP de la computadora que vamos a permitir para hacer una conexión. Guarde el archivo y veamos si las restricciones y los permisos están vigentes.

Primero, intentaremos conectarnos desde una computadora que no está en el hosts.allowarchivo:

La conexión se rechaza. Ahora intentaremos conectarnos desde la máquina en la dirección IP 192.168.4.23:

Se acepta nuestra conexión.

Nuestro ejemplo aquí es un poco brutal: solo se puede conectar una computadora. Los envoltorios TCP son bastante versátiles y más flexibles que esto. Admite nombres de host, comodines y máscaras de subred para aceptar conexiones de rangos de direcciones IP. Le recomendamos que consulte la página de manual.

Rechazar solicitudes de conexión sin contraseñas

Aunque es una mala práctica, un administrador del sistema Linux puede crear una cuenta de usuario sin contraseña. Eso significa que las solicitudes de conexión remota de esa cuenta no tendrán contraseña para verificar. Esas conexiones serán aceptadas pero no autenticadas.

La configuración predeterminada de SSH acepta solicitudes de conexión sin contraseñas. Podemos cambiar eso muy fácilmente y asegurarnos de que todas las conexiones estén autenticadas.

Necesitamos editar su archivo de configuración SSH:

sudo gedit / etc / ssh / sshd_config

Desplácese por el archivo hasta que vea la línea que dice "#PermitEmptyPasswords no". Elimine el hash #del inicio de la línea y guarde el archivo. Reinicie el demonio SSH:

sudo systemctl reiniciar sshd

Utilice claves SSH en lugar de contraseñas

Las claves SSH proporcionan un medio seguro para iniciar sesión en un servidor SSH. Las contraseñas pueden ser adivinadas, descifradas o forzadas. Las claves SSH no están abiertas a este tipo de ataques.

Cuando genera claves SSH, crea un par de claves. Una es la clave pública y la otra es la clave privada. La clave pública se instala en los servidores a los que desea conectarse. La clave privada, como sugiere el nombre, se mantiene segura en su propia computadora.

Las claves SSH le permiten realizar conexiones sin una contraseña que son, en contra de la intuición, más seguras que las conexiones que utilizan autenticación de contraseña.

Cuando realiza una solicitud de conexión, la computadora remota usa su copia de su clave pública para crear un mensaje encriptado que se envía de vuelta a su computadora. Debido a que fue encriptado con su clave pública, su computadora puede desencriptarlo con su clave privada.

Luego, su computadora extrae cierta información del mensaje, en particular el ID de sesión, lo encripta y lo envía de vuelta al servidor. Si el servidor puede descifrarlo con su copia de su clave pública, y si la información dentro del mensaje coincide con lo que el servidor le envió, se confirma que su conexión proviene de usted.

Aquí, un usuario con claves SSH establece una conexión con el servidor en 192.168.4.11. Tenga en cuenta que no se les solicita una contraseña.

ssh dave@192.168.4.11

Las claves SSH merecen un artículo para sí mismas. Prácticamente, tenemos uno para ti. A continuación, se explica cómo crear e instalar claves SSH.

Deshabilitar la autenticación de contraseña por completo

Por supuesto, la extensión lógica del uso de claves SSH es que si todos los usuarios remotos se ven obligados a adoptarlas, puede desactivar la autenticación de contraseña por completo.

Necesitamos editar su archivo de configuración SSH:

sudo gedit / etc / ssh / sshd_config

Desplácese por el archivo hasta que vea la línea que comienza con "#PasswordAuthentication yes". Elimine el hash #del principio de la línea, cambie el "sí" a "no" y guarde el archivo. Reinicie el demonio SSH:

sudo systemctl reiniciar sshd

Deshabilitar el reenvío X11

El reenvío X11 permite a los usuarios remotos ejecutar aplicaciones gráficas desde su servidor a través de una sesión SSH. En manos de un actor de amenazas o un usuario malintencionado, una interfaz GUI puede facilitar sus propósitos malignos.

Un mantra estándar en ciberseguridad es que si no tiene una buena razón para encenderlo, apáguelo. Lo haremos editando su archivo de configuración SSH:

sudo gedit / etc / ssh / sshd_config

Desplácese por el archivo hasta que vea la línea que comienza con "# X11 No de reenvío". Elimine el hash #del inicio de la línea y guarde el archivo. Reinicie el demonio SSH:

sudo systemctl reiniciar sshd

Establecer un valor de tiempo de espera inactivo

Si hay una conexión SSH establecida a su computadora, y no ha habido actividad en ella durante un período de tiempo, podría representar un riesgo de seguridad. Existe la posibilidad de que el usuario haya abandonado su escritorio y esté ocupado en otro lugar. Cualquier otra persona que pase por su escritorio puede sentarse y comenzar a usar su computadora y, a través de SSH, su computadora.

Es mucho más seguro establecer un límite de tiempo de espera. La conexión SSH se interrumpirá si el período inactivo coincide con el límite de tiempo. Una vez más, editaremos su archivo de configuración SSH:

sudo gedit / etc / ssh / sshd_config

Desplácese por el archivo hasta que vea la línea que comienza con “#ClientAliveInterval 0” Elimine el hash #del inicio de la línea, cambie el dígito 0 al valor deseado. Usamos 300 segundos, que son 5 minutos. Guarde el archivo y reinicie el demonio SSH:

sudo systemctl reiniciar sshd

Establecer un límite para los intentos de contraseña

Definir un límite en la cantidad de intentos de autenticación puede ayudar a frustrar la adivinación de contraseñas y los ataques de fuerza bruta. Después del número designado de solicitudes de autenticación, el usuario será desconectado del servidor SSH. Por defecto, no hay límite. Pero eso se remedia rápidamente.

Nuevamente, necesitamos editar su archivo de configuración SSH:

sudo gedit / etc / ssh / sshd_config

Desplácese por el archivo hasta que vea la línea que comienza con "#MaxAuthTries 0". Elimine el hash #del inicio de la línea, cambie el dígito 0 al valor deseado. Hemos usado 3 aquí. Guarde el archivo cuando realizó los cambios y reinicie el demonio SSH:

sudo systemctl reiniciar sshd

Podemos probar esto al intentar conectarnos e ingresar deliberadamente una contraseña incorrecta.

Tenga en cuenta que el número de MaxAuthTries parecía ser uno más que el número de intentos permitidos al usuario. Después de dos malos intentos, nuestro usuario de prueba se desconecta. Esto fue con MaxAuthTries establecido en tres.

Desactivar inicios de sesión de root

Es una mala práctica iniciar sesión como root en su computadora Linux. Debe iniciar sesión como usuario normal y utilizarlo sudopara realizar acciones que requieran privilegios de root. Aún más, no debe permitir que root inicie sesión en su servidor SSH. Solo los usuarios habituales deben poder conectarse. Si necesitan realizar una tarea administrativa, también deberían usar sudo. Si se ve obligado a permitir que un usuario root inicie sesión, al menos puede obligarlo a usar claves SSH.

Por última vez, tendremos que editar su archivo de configuración SSH:

sudo gedit / etc / ssh / sshd_config

Desplácese por el archivo hasta que vea la línea que comienza con “#PermitRootLogin prohibit-password” Elimine el hash #del inicio de la línea.

• Si desea evitar que root inicie sesión, reemplace "prohibir contraseña" por "no".
• Si va a permitir que root inicie sesión pero los obligará a usar claves SSH, deje “prohibit-password” en su lugar.

Guarde sus cambios y reinicie el demonio SSH:

sudo systemctl reiniciar sshd

El último paso

Por supuesto, si no necesita SSH ejecutándose en su computadora, asegúrese de que esté deshabilitado.

sudo systemctl detener sshd

sudo systemctl deshabilitar sshd

Si no abre la ventana, nadie podrá entrar.