Proteger las conexiones SSH le ayuda a proteger su sistema y sus datos Linux. Los administradores de sistemas y los usuarios domésticos también necesitan proteger las computadoras con acceso a Internet. A continuación se muestran 10 formas sencillas de ayudarle a proteger su servidor SSH .
Algunos conceptos básicos sobre la seguridad SSH
SSH significa Secure Shell. El protocolo SSH o herramienta de software permite a los administradores y usuarios del sistema realizar conexiones seguras a computadoras remotas utilizando ese protocolo.
El protocolo SSH es un protocolo cifrado diseñado para proporcionar una conexión segura a través de una red insegura como Internet. SSH en Linux se basa en la versión portátil del proyecto OpenSSH. Se implementa en un modelo clásico cliente-servidor con un servidor SSH que acepta conexiones de clientes SSH. El cliente se utiliza para conectarse al servidor y exponer la sesión a usuarios remotos. El servidor acepta la conexión e inicia la sesión.
En su configuración predeterminada, el servidor SSH "escuchará" las conexiones entrantes en el Protocolo de control de transmisión (TCP), puerto 22. Dado que se trata de un puerto estandarizado y popular, es un objetivo para amenazas de actores y bots maliciosos.
Los actores maliciosos lanzan bots que escanean rangos de direcciones IP en busca de puertos abiertos. Luego prueba estos puertos en busca de vulnerabilidades explotables. Pensar que estoy a salvo, que hay muchos objetivos más grandes y mejores que yo a los que los malos pueden apuntar es completamente incorrecto. Estos robots no eligen sus objetivos basándose en ningún criterio, solo buscan una manera de penetrar el sistema.
Serás una víctima si no proteges tu sistema.
Fricción de seguridad
Un punto de fricción de seguridad es cualquier situación en la que la tarea principal se impide o se retrasa debido a requisitos de seguridad.
La fricción de seguridad causa incomodidad (en cualquier nivel) a los usuarios y a otras personas cuando se implementan medidas de seguridad. Las personas nuevas en los sistemas informáticos pueden preocuparse si realmente tendrán que ingresar una contraseña cada vez que inicien sesión en la computadora central. Para ellos, esto también es una forma de fricción en materia de seguridad.
La introducción de medidas de seguridad a menudo implicará algún tipo de fricción para algunas personas. Los empresarios deben pagar por estas medidas. Es posible que los usuarios de computadoras tengan que cambiar hábitos o recordar información de autenticación diferente, agregando pasos para conectarse exitosamente. Los administradores del sistema tendrán trabajo adicional que hacer para implementar y mantener las nuevas medidas de seguridad.
Ajustar y bloquear un sistema operativo tipo Linux o Unix puede ser rápido. Las medidas de seguridad aquí son un conjunto de pasos fáciles de seguir que mejorarán la seguridad informática sin la necesidad de aplicaciones de terceros ni una intervención profunda del firewall .
Utilice el protocolo SSH versión 2
En 2006, el protocolo SSH se actualizó de la versión 1 a la versión 2. Esta es una actualización significativa. Hay muchos cambios y mejoras, especialmente en cifrado y seguridad, y la versión 2 no es compatible con la versión 1. Para evitar conexiones de clientes de la versión 1, puede especificar que las computadoras solo acepten conexiones de la versión 2.
Para hacer esto, edite el archivo /etc/ssh/sshd_config usando el siguiente comando:
sudo gedit /etc/ssh/sshd_config

Agregue la siguiente línea:
Protocol 2
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Y guarde el archivo, luego reinicie el proceso del demonio SSH usando el siguiente comando:
sudo systemctl restart sshd
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Pruebe la nueva configuración en acción cambiando a otra máquina e intentando realizar SSH en la máquina de prueba. Usaremos la opción -1 (protocolo 1) para forzar que el comando ssh use la versión 1 del protocolo.
ssh -1 dave@howtogeek.local
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Solicitud de conexión rechazada. Asegúrese de poder conectarse al protocolo 2. Usaremos -2 (protocolo 2) para realizar la prueba.
ssh -2 dave@howtogeek.local
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
El hecho de que el servidor SSH solicite una contraseña es una señal positiva de que se ha realizado la conexión y estás interactuando con el servidor. Los clientes SSH modernos utilizarán de forma predeterminada el protocolo 2; no es necesario especificar el protocolo 2 siempre que el cliente esté actualizado.
ssh dave@howtogeek.local
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
La conexión ha sido aceptada.
Evite la puerta 22
El puerto 22 es el puerto estándar para conexiones SSH. Si se utiliza un puerto diferente, agrega un poco de Seguridad a través de la oscuridad (STO) a su sistema. La seguridad a través de la ambigüedad nunca debe considerarse una medida de seguridad real. De hecho, algunos robots de ataque más inteligentes exploran todos los puertos abiertos y deciden qué servicio están realizando, en lugar de confiar en una simple lista de búsqueda de puertos y asumir que brindan un servicio normalmente. Pero usar un puerto no estándar puede ayudar a reducir el tráfico incorrecto en el puerto 22.
Para configurar un puerto no estándar, edite el archivo de configuración SSH como se indica arriba.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Elimine el # al comienzo de la línea Puerto y reemplace 22 con el número de su elección. Guarde el archivo de configuración y reinicie el demonio SSH.
En otra computadora usaremos el comando ssh para conectarnos al servidor. El comando ssh predeterminado usa el puerto 22:
ssh dave@howtogeek.local
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Conexión denegada. Inténtelo nuevamente y especifique el puerto 470 usando la opción –p (puerto):
ssh -p 479 dave@howtogeek.local
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Conexión confirmada.
Conecte el filtro usando TCP Wrappers
TCP Wrappers son una lista de control de acceso fácil de entender. Le permite negar 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 TCP Wrappers deben usarse con un firewall configurado correctamente, no en lugar de él.
TCP Wrappers viene preinstalado en máquinas Ubuntu 18.04 LTS . Debe instalarse en Manjaro 18.10 y Fedora 30.
Para instalar en Fedora, use el siguiente comando:
sudo yum install tcp_wrappers
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Para instalar en Manjaro, use este comando:
sudo pacman -Syu tcp-wrappers
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Se incluyen dos archivos, un archivo contiene la lista de permitidos y el otro archivo contiene la lista de denegados. Edite la lista de denegación usando el siguiente comando:
sudo gedit /etc/hosts.deny
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
El comando anterior abrirá el editor gedit y el archivo se negará a cargarse.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Necesitas agregar la línea:
ALL : ALL
Y guarde el archivo. Esta línea bloqueará todo acceso no autorizado. Ahora, necesitamos otorgar permisos a las conexiones que desea aceptar. Para hacer eso, necesita editar el archivo de permisos:
sudo gedit /etc/hosts.allow
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
El comando anterior abrirá el editor gedit con el archivo descargable.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Hemos añadido el nombre del demonio SSH, SSHD, y la dirección IP del ordenador que permite realizar la conexión. Guarde el archivo y vea si las restricciones y permisos están vigentes.
Primero, intentará conectarse desde una computadora que no está en el archivo hosts.allow:
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Conexión denegada. Intentaremos conectarnos desde una máquina con dirección IP 192.168.4.23:
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Conexión aceptada.
El ejemplo aquí solo permite que se conecte una máquina. Los contenedores TCP son bastante flexibles, admiten nombres de host, comodines y máscaras de subred para aceptar conexiones desde rangos de direcciones IP.
Rechazar solicitudes de conexión sin contraseña
Aunque no es bueno, los administradores de sistemas Linux pueden crear cuentas de usuario sin contraseñas. Eso significa que no se requiere contraseña para conexiones remotas desde esta cuenta. Estas conexiones serán aceptadas pero no autenticadas.
La configuración predeterminada para SSH acepta solicitudes de conexión sin contraseña. Podemos cambiarlo fácilmente y asegurarnos de que todas esas conexiones estén autenticadas.
Debe editar el archivo de configuración SSH.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Desplácese hacia abajo en el archivo hasta que vea la línea que dice #PermitEmptyPasswords no . Elimine # al principio de la línea y guarde el archivo. Reinicie el demonio SSH.
Utilice claves SSH en lugar de contraseñas
Las claves SSH proporcionan una forma segura de iniciar sesión en un servidor SSH. Las contraseñas se pueden descifrar, adivinar o forzar de forma bruta . Las claves SSH no son vulnerables a este tipo de ataques.
Al generar una clave 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 se guarda de forma segura en su computadora.
Las claves SSH permiten realizar conexiones sin contraseña, lo que es más seguro que las conexiones que utilizan autenticación de contraseña.
Al realizar una solicitud de conexión, la computadora remota utiliza una copia de la clave pública para crear un mensaje cifrado que se envía a la computadora. Dado que está cifrado con la clave pública, la computadora puede descifrarlo con la clave privada.
Luego, la computadora extrae información del mensaje, la cifra y la envía de regreso al servidor. Si el servidor puede descifrarlo con una copia de la clave pública. Si la información del mensaje coincide con lo que le envió el servidor, se confirmará la conexión.
Aquí, el usuario realiza la conexión al servidor en 192.168.4.11 con la clave SSH. Tenga en cuenta que no se les solicita que ingresen una contraseña.
ssh dave@192.168.4.11
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Deshabilitar completamente la autenticación de contraseña
Puede desactivar completamente la autenticación de contraseña si utiliza claves SSH. Necesitamos editar el archivo de configuración SSH.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Desplácese hacia abajo en el archivo hasta que vea la línea que comienza con #PasswordAuthentication sí . Elimine # al principio de la línea, cambie sí a no y guarde el archivo. Reinicie el demonio SSH.
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, pero los malos actores lo explotan fácilmente. Es mejor desactivarlo editando el archivo de configuración SSH.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Desplácese hacia abajo en el archivo hasta que vea la línea #X11Reenvío no , elimine el # al principio de la línea y guarde el archivo. Reinicie el demonio SSH.
Establecer el valor del tiempo de espera de inactividad
Si se establece una conexión SSH con una computadora y no hay actividad en ella durante un período de tiempo, esto puede representar un riesgo para la seguridad.
Por lo tanto, debes establecer un límite de tiempo de espera. La conexión SSH se desconectará si no hay actividad dentro del límite de tiempo. Una vez más, necesitamos editar el archivo de configuración SSH.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Desplácese hacia abajo en el archivo hasta que vea la línea que comienza con #ClientAliveInterval 0 . Elimine el # al principio de la línea, cambie el número 0 al valor deseado. Por lo general, la gente lo configura en 300 segundos, que son 5 minutos. Guarde el archivo y reinicie el demonio SSH.
Establecer un límite en el número de entradas de contraseña
Definir un límite en la cantidad de confirmaciones puede ayudar a evitar adivinanzas de contraseñas y ataques de fuerza bruta. Después del número especificado de solicitudes de autenticación, el usuario será desconectado del servidor SSH. De forma predeterminada, no hay límite para la cantidad de intentos de contraseña, pero puede editarlo en el archivo de configuración SSH.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Desplácese hacia abajo en el archivo hasta que vea la línea que comienza con #MaxAuthTries 0 . Al eliminar el # al principio de la línea, el número cambia al valor deseado. Puede configurarlo en 3. Guarde el archivo cuando realice cambios y reinicie el demonio SSH.
Puedes probar esto intentando conectarte e ingresando la contraseña incorrecta.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Tenga en cuenta que el número de MaxAuthTries es mayor que el número de intentos permitidos al usuario. Después de dos intentos fallidos, se desconecta, lo que significa que MaxAuthTries está configurado en 3.
Deshabilitar el inicio de sesión raíz
Se recomienda no iniciar sesión como root, simplemente utilizarlo como usuario normal en Linux y utilizar sudo para realizar acciones que requieran permisos de root. Tampoco debe permitir que root inicie sesión en el servidor SSH. Sólo los usuarios normales pueden conectarse. Si necesitan realizar una tarea de nivel administrativo, también pueden usar sudo. Si debe permitir que el usuario raíz inicie sesión, puede obligarlo a usar una clave SSH.
Edite el archivo de configuración para deshabilitar el inicio de sesión raíz.
![Cómo proteger un servidor SSH Cómo proteger un servidor SSH]()
Desplácese hacia abajo en el archivo hasta que vea la línea que comienza con #PermitRootLogin prohibit-password , elimine el # al principio de la línea.
- Si desea evitar que root inicie sesión, reemplace prohibir contraseña por no.
- Si permite que root inicie sesión pero fuerza el uso de una clave SSH, deje la contraseña prohibida intacta.
Guarde los cambios y reinicie el demonio SSH.
Último paso
Por supuesto, si no necesita que SSH se ejecute en su computadora, desactívelo con el siguiente comando:
sudo systemctl stop sshd
sudo systemctl disable sshd
¡Te deseo éxito!