Bloqueo de Acceso SSH a la Red Local en Sistemas Unix: Una Guía Exhaustiva

El protocolo SSH (Secure Shell) es una herramienta fundamental para la administración remota segura de sistemas en redes. Permite a los usuarios conectarse a servidores, routers, switches y una amplia gama de dispositivos de forma cifrada, garantizando la confidencialidad e integridad de los datos transmitidos. Sin embargo, para fortalecer la seguridad, a menudo surge la necesidad de restringir el acceso SSH, limitándolo específicamente a la red local. Este artículo explora en profundidad cómo lograr esta restricción en sistemas Linux utilizando configuraciones de firewall y ajustes del propio servicio SSH, proporcionando una comprensión detallada de los mecanismos subyacentes y las mejores prácticas.

Comprendiendo la Red Local y las Interfaces de Red

Antes de adentrarnos en los métodos de restricción, es crucial definir qué se entiende por "red local". En términos generales, una red local (LAN) es un conjunto de dispositivos interconectados dentro de un área geográfica limitada, como una oficina o un hogar. Estos dispositivos comparten una red privada, a menudo gestionada por un router o un switch. La dirección IP asignada a un dispositivo dentro de esta red local suele pertenecer a un rango privado (por ejemplo, 192.168.x.x, 10.x.x.x).

Los sistemas operativos Unix-like, incluyendo Linux, gestionan múltiples interfaces de red. Cada interfaz de red (por ejemplo, eth0 para Ethernet, wlan0 para Wi-Fi) tiene asociada una dirección IP y permite la comunicación con otras redes. Por defecto, el demonio SSH (sshd), el servicio que escucha y gestiona las conexiones SSH entrantes, está configurado para escuchar en todas las interfaces de red disponibles. Esto significa que, sin configuraciones adicionales, cualquier solicitud de conexión SSH que llegue al servidor, independientemente de la interfaz de red por la que acceda, será procesada.

Para comenzar a restringir el acceso, debemos identificar la interfaz de red que corresponde a nuestra red local. Esta información se puede obtener utilizando comandos como ip addr o ifconfig. Una vez identificada la interfaz de red local (por ejemplo, eth0 con una dirección IP como 192.168.1.100), podremos utilizar esta información para configurar las reglas de acceso.

Configuración del Servidor SSH (sshd_config)

El archivo de configuración principal para el demonio SSH en la mayoría de los sistemas Linux es /etc/ssh/sshd_config. Modificar este archivo nos permite ajustar el comportamiento del servidor SSH, incluyendo en qué interfaces de red debe escuchar.

Limitando el Escucha a la Interfaz Local

Por defecto, la línea #ListenAddress en sshd_config está comentada, lo que instruye a sshd a escuchar en todas las direcciones IP disponibles. Para restringir el acceso SSH a la red local, debemos localizar esta línea y modificarla.

1. Localizar y Descomentar ListenAddress: Abra el archivo /etc/ssh/sshd_config con un editor de texto con privilegios de superusuario (por ejemplo, sudo nano /etc/ssh/sshd_config). Busque la línea que comienza con #ListenAddress.

2. Especificar la Dirección IP Local: Descomente la línea (elimine el # al principio) y reemplace ListenAddress con la dirección IP específica de su interfaz de red local. Por ejemplo, si su servidor SSH tiene la dirección IP 192.168.1.100 en su red local, la línea debería verse así:

   ListenAddress 192.168.1.100

   Si desea que sshd escuche en todas las interfaces de la red local, y su red local utiliza un rango de IPs específico, puede ser necesario configurar sshd para que escuche en la dirección de red correspondiente si su sistema lo permite, o listar explícitamente cada IP local si hay varias interfaces en la LAN. Sin embargo, la práctica más común y segura es especificar la IP principal de la interfaz de red local.

   

3. Reiniciar el Servicio SSH: Después de guardar los cambios en sshd_config, es esencial reiniciar el servicio SSH para que las nuevas configuraciones surtan efecto. Esto se puede hacer con los siguientes comandos, dependiendo de su sistema:

   • Para sistemas que utilizan systemd (la mayoría de las distribuciones modernas como Ubuntu 15.04+, Debian 8+, CentOS 7+, Fedora 15+):bashsudo systemctl restart sshd
   • Para sistemas que utilizan SysVinit (distribuciones más antiguas):bashsudo service ssh restart

Una vez reiniciado el servicio, su servidor SSH solo escuchará conexiones entrantes en la dirección IP local especificada. Si intenta conectarse desde una red externa (por ejemplo, utilizando datos móviles o una VPN que no está configurada para enrutar el tráfico a su LAN de forma que sshd la reconozca como local), el acceso será denegado.

Deshabilitar el Inicio de Sesión de Root

Otra medida de seguridad crucial es deshabilitar el inicio de sesión directo del usuario root a través de SSH. El usuario root tiene privilegios ilimitados en el sistema, y si un atacante logra obtener acceso a esta cuenta, puede causar daños significativos.

En el archivo /etc/ssh/sshd_config, busque la directiva PermitRootLogin. Por defecto, su valor suele ser "yes". Para mejorar la seguridad, se recomienda cambiarlo a "no".

PermitRootLogin no

Otras opciones para PermitRootLogin incluyen:

• "without-password": Permite el inicio de sesión de root solo con autenticación de clave pública.
• "forced-commands-only": Permite el inicio de sesión de root solo para ejecutar comandos específicos predefinidos.

La opción más segura es "no", ya que obliga a los usuarios a iniciar sesión con una cuenta de usuario estándar y luego utilizar el mecanismo sudo para elevar privilegios cuando sea necesario. El mecanismo sudo proporciona la capacidad de lanzar comandos como administrador (similar a root) o como otro usuario, manteniendo un registro de los comandos ejecutados, lo que es fundamental para la auditoría de seguridad.

Después de modificar PermitRootLogin, recuerde reiniciar el servicio sshd.

Restricción de Acceso SSH Mediante Firewall

Mientras que la configuración de sshd_config limita la escucha del servidor, un firewall proporciona una capa adicional y más granular de control sobre el tráfico de red que entra y sale del servidor. En Linux, las herramientas de firewall más comunes son iptables y ufw (Uncomplicated Firewall), que es una interfaz más amigable para iptables.

Utilizando ufw

ufw simplifica la administración de reglas de firewall. Para restringir el acceso SSH a la red local, podemos crear reglas que permitan conexiones SSH solo desde rangos de IP de nuestra red local.

1. Permitir SSH desde la Red Local: Supongamos que nuestra red local es 192.168.1.0/24. Podemos añadir una regla para permitir el tráfico SSH (puerto 22 por defecto) desde esta red:

   sudo ufw allow from 192.168.1.0/24 to any port 22

   Si su red local utiliza un rango de IP diferente, reemplace 192.168.1.0/24 por el suyo. Si desea permitir el acceso desde una dirección IP específica dentro de su red local, puede usar:

   sudo ufw allow from 192.168.1.100 to any port 22

2. Denegar SSH desde Otras Redes: Si ufw está configurado para denegar todo el tráfico entrante por defecto (lo cual es una buena práctica de seguridad), las reglas anteriores serán suficientes. Sin embargo, si necesita ser explícito o si su política por defecto es permitir todo, debe añadir una regla para denegar explícitamente las conexiones SSH desde cualquier otra fuente que no sea su red local.

   sudo ufw deny from any to any port 22

   Es crucial que la regla de denegación se aplique después de la regla de permiso, o que la política por defecto sea denegar. Si la regla de denegación se aplica antes, nunca se procesará la regla de permiso. En ufw, el orden de las reglas importa.

3. Habilitar ufw: Si ufw no está habilitado, debe activarlo:

   sudo ufw enable

   Se le advertirá que esto puede interrumpir las conexiones SSH existentes. Asegúrese de que su regla allow esté correctamente configurada antes de habilitar ufw.

4. Verificar el Estado: Para ver las reglas activas:bashsudo ufw status verbose

Utilizando iptables

iptables es una herramienta más potente pero también más compleja. Las reglas de iptables se gestionan directamente en la tabla filter y las cadenas INPUT, OUTPUT, FORWARD.

1. Permitir SSH desde la Red Local: Para permitir conexiones SSH (puerto TCP 22) desde la red 192.168.1.0/24:

   sudo iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT

2. Denegar SSH desde Otras Redes: Para denegar explícitamente el tráfico SSH desde cualquier otra fuente:

   sudo iptables -A INPUT -p tcp --dport 22 -j DROP

   Nuevamente, el orden es crítico. La regla ACCEPT debe preceder a la regla DROP para el puerto 22 si la política por defecto de la cadena INPUT es DROP. Si la política por defecto es ACCEPT, entonces la regla DROP es necesaria.

3. Política por Defecto: Es una buena práctica establecer una política por defecto restrictiva para la cadena INPUT:

   sudo iptables -P INPUT DROP

   Esto significa que todo el tráfico entrante será descartado a menos que una regla explícita lo permita.

4. Guardar Reglas: Las reglas de iptables no son persistentes por defecto y se pierden al reiniciar. Debe guardarlas. El método varía según la distribución:

   • En sistemas basados en Debian/Ubuntu:bashsudo apt-get install iptables-persistentsudo netfilter-persistent save
   • En sistemas basados en Red Hat/CentOS:bashsudo service iptables save

Consideraciones Adicionales de Seguridad para SSH

Restringir el acceso a la red local es un paso importante, pero la seguridad de SSH va más allá. Aquí hay otras medidas que complementan esta restricción:

Autenticación con Claves Seguras SSH

El uso de contraseñas para la autenticación SSH es vulnerable a ataques de fuerza bruta y diccionario. SSH es mucho más seguro y útil cuando se usa con pares de claves públicas/privadas para la autenticación.

• Generación de Claves: Los usuarios pueden generar un par de claves (pública y privada) utilizando ssh-keygen. La clave privada debe mantenerse secreta y nunca compartirse. La clave pública se coloca en el archivo ~/.ssh/authorized_keys del servidor para el usuario con el que se desea iniciar sesión.
• Ventajas: Las claves SSH son mucho más difíciles de adivinar que las contraseñas. Con RCDevs solutions, los usuarios pueden generar un nuevo par de claves por sí mismos o importar su clave pública existente para usar su clave privada para inicios de sesión SSH. Las claves públicas no necesitan ser desplegadas en cada servidor SSH.
• Configuración en sshd_config: Asegúrese de que PubkeyAuthentication yes esté habilitado en sshd_config.

Cambio del Puerto SSH Predeterminado

El puerto 22 es el puerto estándar para SSH. Los atacantes a menudo escanean este puerto. Cambiar el puerto SSH a uno no estándar puede ayudar a reducir la visibilidad del servicio SSH ante escaneos casuales, aunque no es una medida de seguridad por sí sola y debe combinarse con otras.

• Modificación en sshd_config: Busque la línea Port 22 y cámbiela a un número de puerto diferente (por ejemplo, Port 2222).
• Actualización del Firewall: Si cambia el puerto, debe actualizar sus reglas de firewall para permitir el tráfico en el nuevo puerto y, opcionalmente, denegar el tráfico en el puerto 22.
• Conexión al Nuevo Puerto: Al conectarse, deberá especificar el nuevo puerto: ssh -p 2222 usuario@servidor.

Limitación de Intentos de Inicio de Sesión

Configurar un límite en los intentos de contraseña para el inicio de sesión SSH puede reducir la efectividad de los ataques de fuerza bruta. Herramientas como fail2ban monitorean los logs del sistema en busca de intentos fallidos de inicio de sesión y bloquean temporalmente las direcciones IP que muestran un comportamiento sospechoso.

• User Blocking: fail2ban es muy útil para prevenir ataques de fuerza bruta, implementando un bloqueo de usuario (o más bien, de IP) tras un número determinado de intentos fallidos.

Centralización de Claves SSH y Cuentas

En entornos empresariales, la gestión de claves SSH y cuentas de usuario puede volverse compleja. Muchas o incluso todas las cuentas de inicio de sesión en Unix y Linux pueden quedar sin gobernar, sin la capacidad de determinar qué clave pertenece a qué identidad y si el acceso cumple con las directrices de IAM (Identity and Access Management) de la empresa. La solución es centralizar las claves SSH y las cuentas. Soluciones como SpanKey Server permiten gestionar y auditar centralmente las claves SSH.

• SpanKey Server: Permite etiquetar hosts gestionados (por ejemplo, todos los servidores web con la etiqueta "WEB") y centralizar la autenticación. También ofrece autenticación de factor adicional y modo offline para cuentas específicas.

Autenticación de Múltiples Factores (MFA)

Para una seguridad aún mayor, se puede implementar un factor adicional de autenticación para el inicio de sesión SSH y la transferencia de archivos SCP/SFTP. Esto podría ser un código generado por una aplicación de autenticación (como Google Authenticator) o un token físico.

• Configuración: Esto a menudo implica configurar ChallengeResponseAuthentication yes en sshd_config y asegurarse de que el módulo PAM (Pluggable Authentication Modules) correspondiente esté instalado y configurado. Si ChallengeResponseAuthentication se establece en "no", no permitirá conexiones donde se interactúe con el teclado, lo que puede impedir la configuración de un One Time Password.

Criptografía en SSH

El protocolo SSH utiliza criptografía robusta para garantizar la seguridad de las comunicaciones. Hay tres tipos principales de cifrado utilizados por OpenSSH:

1. Cifrado Simétrico: Utiliza una clave secreta compartida tanto para cifrar como para descifrar. La seguridad reside en que la clave secreta no se transmite directamente. Ambos extremos comparten datos públicos y los manipulan para calcular la clave secreta de forma independiente. Su desventaja es la necesidad de compartir la clave secreta.
2. Cifrado Asimétrico (Criptografía de Clave Pública): Utiliza un par de claves separadas: una pública y una privada. La clave pública se comparte, mientras que la privada se mantiene secreta. El cifrado asimétrico no se usa para cifrar la conexión SSH completa, sino principalmente durante el intercambio de claves para establecer la sesión simétrica.
3. Hashing: Es una función unidireccional utilizada para firmas digitales y verificación de integridad. No está destinada a ser descifrada. Se usa para asegurar que los mensajes no han sido alterados y para verificar la identidad del remitente.

Estos mecanismos criptográficos, combinados con protocolos de intercambio de claves (como Diffie-Hellman), aseguran que la conexión SSH sea confidencial y que los datos transmitidos sean íntegros.

Conclusión Parcial

Restringir el acceso SSH a la red local en sistemas Unix-like es una práctica de seguridad esencial. Al combinar la configuración del servidor SSH (sshd_config) para escuchar en interfaces específicas y deshabilitar el inicio de sesión de root, con la implementación de reglas de firewall (ufw o iptables) para controlar el tráfico de red, se puede crear una barrera significativa contra accesos no autorizados. Estas medidas, junto con la adopción de prácticas como la autenticación basada en claves, el cambio de puertos, la limitación de intentos de inicio de sesión y la autenticación de múltiples factores, forman una estrategia de seguridad robusta para la administración remota de sistemas. La elección de la configuración adecuada dependerá de los requisitos específicos de seguridad y la infraestructura de red de cada organización.

tags: #unix #como #puedo #bloquear #ssh #con