Hardening de servidores Linux: checklist de seguridad imprescindible

1. Introducción

El Hardening de servidores Linux sigue siendo la tarea que más retorno da por hora invertida en seguridad, y sin embargo es la que más se abandona a la improvisación. Un servidor recién instalado y conectado a Internet pública recibe intentos de acceso por fuerza bruta en cuestión de minutos, y la mayoría de los escaneos automatizados solo buscan exactamente lo que un servidor sin endurecer expone: SSH con contraseña, puertos de administración abiertos y paquetes sin actualizar. En este artículo he preparado un checklist de hardening de servidores Linux completo, aplicable en orden a cualquier distribución (Debian, Ubuntu, RHEL o Rocky), con configuración real de sshd, cortafuegos UFW, fail2ban y SELinux, y con los comandos de verificación que te permitirán demostrar el resultado en una auditoría. Al final dejas un servidor defendible: parcheado, con acceso mínimo, con denegación por defecto y con registro auditable de lo que ocurre. El texto asume que ya tienes responsabilidad sobre el equipo y busca resultados verificables, como corresponde a un plan serio de hardening de servidores Linux.

2. Evaluación inicial y actualizaciones

El hardening de servidores Linux empieza antes de tocar un solo servicio: hay que saber qué hay instalado, qué escucha y qué versión de sistema corre. El primer bloque del checklist es un inventario rápido y la puesta al día de paquetes, porque todo el resto de controles se ejecuta sobre un sistema que ya no tiene vulnerabilidades conocidas pendientes:

# Inventario inicial: servicios expuestos y sistema operativo
ss -tulpn | column -t
cat /etc/os-release | head -3
uname -r
# Puesta al día y paquetes con vulnerabilidades conocidas
sudo apt update && sudo apt full-upgrade -y
apt list --upgradable
sudo reboot

Fig. 1 – Inventario de servicios expuestos y actualización completa del sistema, punto de partida del hardening de servidores Linux.

Los puertos que muestra ss -tulpn son tu superficie de ataque real: todo lo que escuche en 0.0.0.0 es accesible desde fuera salvo que el firewall lo impida. La regla práctica del hardening de servidores Linux es simple: si un puerto no figura en el inventario de servicios, no debe abrirse. Para las actualizaciones en producción, programa ventanas mensuales y usa el sistema automático de parches de seguridad en paralelo; los servidores críticos no pueden esperar treinta días a un ciclo manual. El inventario es la primera evidencia que pedirá una auditoría de hardening de servidores Linux.

Una herramienta que recomiendo ejecutar antes y después del checklist es Lynis, un auditor de seguridad de sistemas Unix que puntúa el endurecimiento y sugiere remediaciones concretas con referencia a normas. El informe de la primera pasada te servirá de línea base y el de la segunda, como evidencia de mejora. Para cumplimiento formal, los perfiles de referencia del CIS Benchmark para tu distribución son el estándar que exigen la mayoría de las auditorías de terceros. Contar con una línea base comparable convierte el hardening de servidores Linux en un proceso medible.

3. Endurecimiento del servicio SSH

SSH es el componente más atacado de cualquier servidor y el primer apartado del checklist. El hardening de servidores Linux pasa por prohibir el acceso con contraseña, desactivar la raíz y limitar quién puede conectarse y desde dónde. Esta configuración de /etc/ssh/sshd_config es la que aplicamos de serie:

Port 2222
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
MaxSessions 4
PermitEmptyPasswords no
AllowUsers ops jaymon
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
Protocol 2

Fig. 2 – Directivas de endurecimiento en /etc/ssh/sshd_config.

Cambiar el puerto a 2222 no es seguridad silenciosa —la detectan en horas—, pero elimina la mayoría del ruido automatizado, así que lo mantenemos, siempre con el firewall cerrado en paralelo. La verificación crítica antes de recargar el servicio es sudo sshd -t: si la respuesta está vacía, la sintaxis es correcta. Después recarga con sudo systemctl reload ssh, y lo más importante: abre una segunda sesión en paralelo y comprueba que el acceso por clave funciona desde el mismo terminal antes de cerrar la conexión actual. Un solo error aquí deja a todo el equipo fuera del servidor. La disciplina de probar en paralelo es, en sí misma, una práctica clave del hardening de servidores Linux.

3.1 Autenticación por clave con restrict

Sobre esa base, el siguiente nivel del hardening de servidores Linux es aplicar restrict en las claves autorizadas para limitar qué puede hacer cada operador: sin forwarding de agente o de puertos y con comando asignado solo y exclusivamente el necesario. Una línea así en ~/.ssh/authorized_keys convierte la clave en una credencial de funciones, no en una llave maestra. Las claves restringidas reducen el radio de explosión de cualquier fuga, un objetivo constante del hardening de servidores Linux. Un ejemplo:

restrict,port-forwarding="none",command="/usr/local/bin/backup-run" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

Fig. 3 – Clave SSH con restricciones restrict y comando único asignado.

4. Cortafuegos por defecto denegar con UFW

El segundo gran bloque del checklist es la red: políticas de firewall explícitas, denegación por defecto y apertura solo de los puertos inventariados. En Ubuntu y Debian, UFW es la capa de gestión de iptables/nftables más sencilla de auditar. Secuencia de aplicación:

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 80,443/tcp
sudo ufw allow from 10.10.10.0/24 to any port 3306 proto tcp
sudo ufw enable
sudo ufw status verbose

Fig. 4 – Configuración de UFW con política de denegación por defecto.

Fíjate en la dirección de la apertura de MySQL: la regla no abre el puerto a todo Internet, sino solo a la subred de administración. Esa es la diferencia entre un firewall decorativo y una política de red real en el hardening de servidores Linux. El orden de las reglas importa y UFW evalúa por prioridad, así que revisa sudo ufw status numbered antes de dar el servicio por configurado. La comprobación final de la superficie de ataque es repetir ss -tulpn y cruzar puertos escuchando con los permitidos en UFW: todo lo que no cuadre es un agujero. Con esta secuencia, la capa de red del hardening de servidores Linux queda cerrada y comprobada.

5. Detección de ataques con fail2ban

Un servidor endurecido todavía recibe ataques; lo que no puede permitirse es que no queden registrados ni mitigados. fail2ban vigila los logs de autenticación y bloquea las fuentes que fallan repetidamente. La configuración de /etc/fail2ban/jail.local que usamos combina baneo temporal con baneo permanente tras persistir:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
ignoreip = 127.0.0.1/8 10.10.10.0/24

[sshd]
enabled = true
port    = 2222
backend = systemd
maxretry = 4
bantime  = 24h

Fig. 5 – Jail de fail2ban para SSH con baneo de 24 horas tras 4 intentos.

Tras recargar con sudo systemctl restart fail2ban, la verificación operativa es sudo fail2ban-client status sshd, que muestra el número de IPs baneadas y el total de baneos acumulados. Los ratios que observo en entornos reales son reveladores: un servidor con SSH estándar acumula decenas de intentos por minuto en Internet pública, y con las directivas anteriores, casi el cien por cien de esas conexiones se abortan antes de la autenticación. El proyecto fail2ban incluye jails para otros servicios (Apache, Nginx, Postfix); añádelos según tu inventario, pero el de SSH es innegociable. La detección de fuerza bruta es la tercera línea del hardening de servidores Linux y la que evita bloqueos sucios.

5.1 Monitorizar los bloqueos

El hardening de servidores Linux no termina cuando la regla está activa: conviene consumir esos eventos. Las IPs que aparecen repetidas en fail2ban de varios servidores son candidatas a bloqueo a nivel de red en el paquete o en el firewall perimetral, y los logs de baneo deben llegar a tu SIEM igual que cualquier otro evento de autenticación. Así, un baneo automatizado deja de ser un ruido y se convierte en inteligencia sobre el adversario. Convertir los bloqueos en inteligencia es el grado final de madurez del hardening de servidores Linux.

6. SELinux y controles administrativos finales

El último bloque del checklist sube el nivel con el control de acceso obligatorio. En RHEL, Rocky y AlmaLinux, SELinux está activo por defecto pero a menudo en modo permisivo: el sistema se comporta como antes y avisa de lo que heredaría. El hardening de servidores Linux pasa por fijar su estado en enforcing, revisar las denegaciones y solucionar causas raíz, no parches:

getenforce
sudo setsebool -P httpd_can_network_connect on
sudo semanage port -a -t ssh_port_t -p tcp 2222
ls -Z /etc/passwd
sudo ausearch -m AVC -ts recent | grep denied | head

Fig. 6 – Operaciones básicas de gestión de SELinux en modo enforcing.

El flujo de trabajo recomendado: primero setenforce 1 para pasar a enforcing en caliente y comprobar que los servicios críticos siguen respondiendo; después se ajustan booleans y contextos con semanage y setsebool cuando una denegación legítima aparezca en ausearch; y finalmente se fuerza permissive a enforcing en /etc/selinux/config para que sobreviva al reinicio. Si tu distribución usa AppArmor (Ubuntu), el equivalente es comprobar los perfiles activos con aa-status y habilitar los que faltan para los procesos expuestos. El control de acceso obligatorio distingue el hardening de servidores Linux avanzado de la configuración básica.

6.1 Checklist final de verificación

Cierra el pasillo con una pasada completa, elemento por elemento, con el estado que debe cumplir cada control. Este repaso final es el momento en que el hardening de servidores Linux se convierte en procedimiento documentado. La tabla siguiente es el checklist de verificación final de nuestro procedimiento:

#	Control	Comando de verificación	Estado correcto
1	Paquetes al día	apt list –upgradable	Sin actualizaciones pendientes
2	Login root SSH	grep PermitRootLogin /etc/ssh/sshd_config	no
3	Contraseñas SSH	grep PasswordAuthentication /etc/ssh/sshd_config	no
4	Firewall activo	sudo ufw status verbose	Status: active, deny incoming
5	Baneos activos	sudo fail2ban-client status sshd	Jail activa y baneos > 0
6	SELinux/AppArmor	getenforce / aa-status	Enforcing / perfiles activos
7	Registros remotos	rsyslog + forward a SIEM	Eventos en el SIEM últimos 5 min

Tabla 1 – Checklist final de verificación del hardening de servidores Linux.

Además de los siete puntos, tres controles administrativos que la tabla no recoge pero que ningún checklist serio omite: mantener las copias de seguridad fuera de banda y probadas, fijar una política de rotación de claves y credenciales, y revisar trimestralmente los usuarios con acceso. El hardening de servidores Linux sin proceso de revisión es una foto que envejece; el checklist trimestral la mantiene actualizada.

7. Conclusión

El hardening de servidores Linux es un conjunto finito de acciones con orden y verificación, y cuando se ejecuta completo transforma un servidor genérico en un activo defensivo: superficie de ataque mínima, acceso exclusivamente por clave con restricciones, firewall de denegación por defecto, detección de fuerza bruta automatizada y control de acceso obligatorio activo. Todo medible con los comandos de la tabla final.

El orden de aplicación importa: actualiza y evalúa, endurece SSH, cierra la red con UFW, añade fail2ban y termina con SELinux y los controles administrativos. Después ejecuta Lynis de nuevo para cuantificar la mejora y guarda ambos informes como evidencia. Cuando el siguiente pentest o la siguiente auditoría pregunte «¿qué tiene este servidor endurecido?», tendrás no solo la respuesta, sino el registro de verificación que la demuestra. Repite el ciclo cada trimestre y tu hardening de servidores Linux será un programa, no una acción puntual.

¿Necesitas ayuda con Hardening de servidores Linux?

En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.

Contacta con nosotros para una evaluación gratuita de tu infraestructura.