Seguridad en Linux para empresas: bastionado, SSH seguro y control de accesos

Introducción al Problema#

Linux tiene fama bien ganada de ser más seguro que Windows por defecto. Esa fama, paradójicamente, puede ser su mayor vulnerabilidad en entornos empresariales: los administradores lo instalan, lo dejan con la configuración de fábrica, y asumen que "Linux se cuida solo".

La realidad es que un servidor Linux recién instalado tiene SSH activo escuchando en el puerto 22 con soporte para contraseñas (incluyendo root), sin límite de intentos de login, y prácticamente sin auditoría de eventos. Es un target conocido y perfectamente explotable con herramientas automatizadas que cualquiera puede descargar.

El bastionado (término preferido en Linux sobre "hardening") es el proceso de configurar el sistema para reducir esa exposición: cerrar lo que no se necesita, reforzar lo que sí se usa, y registrar todo. No es complicado, pero requiere hacerlo sistemáticamente.

Caso Real o Ejemplo Cotidiano#

Una empresa de desarrollo web tenía un servidor Ubuntu 22.04 corriendo su plataforma de staging. El servidor estaba accesible por SSH desde cualquier IP — la configuración por defecto — y se autenticaba con usuario y contraseña. No tenía fail2ban ni ningún mecanismo de throttling de intentos.

A las 2 AM del jueves (horario en que nadie lo veía), un bot de ataque automatizado detectó el puerto 22 abierto vía escaneo masivo de internet. En las siguientes 4 horas, el bot probó sistemáticamente combinaciones de usuario/contraseña conocidas: root/root, root/123456, admin/admin, ubuntu/ubuntu, y miles de variantes extraídas de bases de datos de brechas previas.

A las 6 AM, encontró una coincidencia: el desarrollador que configuró el servidor había dejado el usuario deploy con contraseña deploy2023! — una contraseña que había reutilizado de otro proyecto.

El servidor fue comprometido. Se instaló un criptominer, que consumió el 100% de CPU durante días hasta que alguien notó que la plataforma de staging iba lenta. El análisis forense reveló que no había ningún log de los intentos fallidos previos porque la auditoría estaba desactivada.

Riesgos para la Empresa#

Explicación Técnica Sencilla#

SSH (Secure Shell) es el protocolo estándar para administrar servidores Linux de forma remota. Es seguro en su diseño, pero su seguridad depende de cómo esté configurado.

Autenticación por contraseña vs por clave pública:

La autenticación por contraseña funciona como un cerrojo con combinación numérica: si alguien prueba suficientes combinaciones, eventualmente la abre. La autenticación por clave pública funciona con una llave física única: sin la llave privada exacta, no hay acceso posible sin importar cuánto tiempo se intente.

# Contraseña → vulnerable a fuerza bruta
ssh usuario@servidor → "¿contraseña?" → bot prueba 10.000/hora

# Clave pública → matemáticamente imposible de forzar
ssh -i ~/.ssh/mi_clave usuario@servidor → autenticación instantánea

fail2ban — el portero con memoria:

fail2ban monitorea los logs del sistema y cuando detecta una IP que falla el login N veces en M minutos, la bloquea automáticamente en el firewall. Es simple, liviano, y extremadamente efectivo contra ataques automatizados.

# Configuración típica de fail2ban para SSH
[sshd]
maxretry = 5       # 5 intentos fallidos
findtime = 600     # en 10 minutos
bantime = 3600     # = bloqueo por 1 hora

sudo con principio de mínimo privilegio:

En lugar de que todos los administradores tengan ALL=(ALL) ALL en sudoers (acceso irrestricto), configurar que cada usuario tenga solo los comandos que realmente necesita:

# Mal: acceso sudo irrestricto
juan ALL=(ALL) ALL

# Bien: solo lo que necesita
juan ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/tail -f /var/log/nginx/*

Cómo Prevenirlo#

1. Deshabilitar el login de root por SSH: En /etc/ssh/sshd_config, configurar PermitRootLogin no. Si necesitás acceso root, primero entrás como usuario normal y luego escalás con sudo. Así, comprometer una cuenta de usuario no da acceso root directo.

2. Cambiar el puerto SSH por defecto: Cambiar de 22 a un puerto alto (ej. 2222 o mayor) no es seguridad real — un escaneo con nmap lo encuentra igual — pero reduce el 95% del ruido de bots que solo buscan el puerto 22. Combinar con AllowUsers para limitar qué usuarios pueden conectarse.

3. Deshabilitar autenticación por contraseña en SSH: Una vez que tenés claves configuradas, en /etc/ssh/sshd_config configurar PasswordAuthentication no. Solo las claves privadas conocidas pueden autenticar. Los bots de diccionario dejan de ser relevantes.

4. Instalar y configurar fail2ban: apt install fail2ban en Ubuntu/Debian. Crear /etc/fail2ban/jail.local con la configuración de SSH. fail2ban también puede proteger otros servicios: nginx, apache, postfix. Una IP con comportamiento abusivo queda bloqueada automáticamente.

5. Aplicar principio de mínimo privilegio en sudo: Revisar /etc/sudoers (con visudo). Ningún usuario debería tener ALL=(ALL) ALL salvo administradores designados. Para usuarios operacionales, listar solo los comandos específicos que necesitan.

6. Activar auditd para auditoría del sistema: apt install auditd en Ubuntu. auditd registra llamadas al sistema: quién ejecutó qué comando, cuándo se modificó qué archivo, quién hizo su o sudo. Es el sistema nervioso del forense en Linux. Sin auditd, un compromiso puede no dejar ninguna evidencia.

7. Configurar restricción de IP para SSH: Si los administradores se conectan desde IPs fijas (o vía VPN), usar el firewall (ufw/iptables) para permitir SSH solo desde esas IPs: ufw allow from 192.168.1.0/24 to any port 22.

Herramientas Recomendadas#

Lynis (cisofy.com/lynis): El escáner de hardening más popular para Linux. Gratuito y open source, corre directamente en el servidor y genera un reporte de cientos de verificaciones: configuración SSH, servicios innecesarios, permisos de archivos críticos, configuración del firewall, versiones de software vulnerables. El "hardening index" al final del reporte da un número concreto para medir progreso. Ejecutar lynis audit system periódicamente es una buena práctica.

fail2ban (fail2ban.org): Herramienta de protección activa contra ataques de fuerza bruta. Monitorea logs en tiempo real y bloquea IPs con comportamiento abusivo. Compatible con SSH, Apache, Nginx, Postfix, y docenas de servicios más. Gratuito, liviano, y extremadamente efectivo contra bots automatizados.

auditd (linux audit framework): El framework de auditoría nativo del kernel Linux. Registra eventos del sistema con granularidad quirúrgica: accesos a archivos, ejecución de comandos, cambios de privilegios. Indispensable para cumplimiento normativo (PCI DSS, ISO 27001) y para forense post-incidente.

CIS-CAT Pro (center for internet security): Herramienta de auditoría que evalúa el servidor contra los CIS Benchmarks de Linux. La versión Community está disponible gratuitamente. Genera un reporte HTML con cada control evaluado, su estado (pass/fail), y la corrección recomendada. Es el estándar para auditorías formales de hardening Linux.

Checklist Final#

• El login de root por SSH está deshabilitado (PermitRootLogin no)
• La autenticación por contraseña en SSH está deshabilitada (PasswordAuthentication no)
• Todos los administradores usan claves SSH (pares RSA 4096 bits o Ed25519)
• fail2ban está instalado y activo para SSH (y otros servicios expuestos)
• El acceso SSH está limitado a IPs autorizadas o a través de VPN
• Los usuarios en sudoers tienen solo los permisos mínimos necesarios
• auditd está instalado, activo y configurado para registrar eventos críticos
• El firewall local (ufw/iptables) está activo con política default DROP
• Los servicios innecesarios están deshabilitados y desinstalados
• Las actualizaciones de seguridad están configuradas para aplicarse automáticamente
• Lynis se ejecuta periódicamente y el hardening index se monitorea

CVE / Vulnerabilidades Relacionadas#

CVE-2025-2749 — Escalada de privilegios en PAM (Linux)#

Esta vulnerabilidad afecta al módulo PAM (Pluggable Authentication Modules) de Linux, el subsistema que gestiona la autenticación en el sistema operativo. Bajo ciertas condiciones de configuración, permite a un usuario con acceso al sistema escalar privilegios de forma no autorizada.

PAM es el "árbitro" de autenticación en Linux: valida quién puede iniciar sesión, con qué método, y bajo qué condiciones. Una vulnerabilidad en PAM es especialmente seria porque afecta a toda la cadena de autenticación — SSH, sudo, y login de consola.

La mitigación requiere actualizar el paquete pam a la versión parcheada y revisar la configuración de /etc/pam.d/ para asegurarse de que no hay módulos o configuraciones no estándar que amplíen la superficie. En un servidor correctamente bastionado con principio de mínimo privilegio, el impacto de esta vulnerabilidad es significativamente menor — un usuario sin sudo no puede escalar aunque explote PAM.

Conclusión y CTA#

Linux es un excelente punto de partida para la seguridad — pero no es inmune. La diferencia entre un servidor Linux comprometido y uno que no lo fue no suele ser una vulnerabilidad de día cero: es fail2ban instalado o no, autenticación por clave o por contraseña, auditoría activa o desactivada.

Las herramientas necesarias son gratuitas. El conocimiento para aplicarlas es accesible. Lo que falta, en la mayoría de los casos, es el tiempo para hacerlo sistemáticamente — y ahí es donde un proceso de hardening documentado hace la diferencia.

¿Querés auditar el estado de seguridad de tus servidores Linux? Contactanos o continuá con el siguiente artículo: VPN corporativa: cómo proteger el acceso remoto de tu empresa.