Hardening de servidores Linux: lista de comprobación práctica contra las técnicas de escalada

2026-11-05 · 9 min de lectura

Aprende un recorrido práctico para endurecer un servidor Linux: actualizar el sistema, reducir servicios expuestos, afinar SSH, controlar cuentas y sudo, aplicar permisos correctos, activar el firewall, auditar y monitorizar, para cerrar las puertas que los laboratorios usan para escalar privilegios.

Después de pasar por varias lecciones ofensivas (SUID, sudo mal configurado, tareas cron inseguras, Redis expuesto, SSH con credenciales filtradas), la conclusión se dibuja sola: la mayoría de intrusiones en servidores Linux aprovechan configuraciones por defecto o laxas, no vulnerabilidades sofisticadas. Un servidor bien endurecido obliga al atacante a trabajar mucho más y, en la mayoría de casos, lo detiene antes de llegar a root.

Hardening (endurecimiento) significa aplicar un conjunto de medidas de seguridad coordinadas para reducir la superficie de ataque, proteger los servicios esenciales y detectar lo que no se puede evitar. No es una herramienta: es una disciplina de capas, cada una dificultando un poco más la vida del atacante.

En esta lección vas a ver un recorrido práctico para endurecer un servidor Linux: actualizar, reducir servicios, afinar SSH, gestionar cuentas y sudo, aplicar permisos y bits especiales correctamente, activar un firewall, auditar y monitorizar. No es exhaustivo (hay guías como las CIS Benchmarks con cientos de controles), pero cubre el 80% del riesgo con el 20% del esfuerzo.

Prueba todos los cambios en un servidor de pruebas antes de aplicarlos a producción. Un error en SSH o en sudo puede dejarte fuera de la máquina.

El hardening es de capas#

Hardening por capas: actualizaciones, superficie, SSH, cuentas, permisos, firewall, auditoría y monitorización

Ningún cambio por separado es suficiente. La fuerza está en combinarlos: un servidor que tiene SSH endurecido pero cualquiera puede escribir en /etc/passwd sigue siendo vulnerable. Un servidor sin actualizaciones pero con un firewall estricto cae en cuanto el atacante encuentra la vía abierta correcta.

Vamos a recorrer las capas en orden habitual. Cada apartado incluye los comandos o archivos a modificar y el porqué del cambio.

Capa 1: actualizaciones#

Es la medida más rentable. Un parche aplicado antes de que se publique un exploit cierra la vulnerabilidad para siempre.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

# RHEL / Rocky / AlmaLinux
sudo dnf update -y
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Las actualizaciones desatendidas aplican parches de seguridad automáticamente. Para servidores críticos que no toleran reinicios inesperados, existe el live patching (Ubuntu Livepatch, Ksplice, kpatch), que aplica parches al kernel sin reiniciar.

Capa 2: reducir la superficie#

Cada servicio escuchando es un posible camino de entrada. Lista lo que hay y desactiva lo que no necesites.

# Ver qué servicios escuchan
sudo ss -tulpn

# Ver todos los servicios systemd y desactivar los innecesarios
sudo systemctl list-unit-files --state=enabled --type=service
sudo systemctl disable --now cups        # impresión
sudo systemctl disable --now avahi-daemon # descubrimiento mDNS
sudo systemctl disable --now bluetooth

Quita paquetes que no uses. apt purge o dnf remove.
Minimiza los módulos del kernel cargados (lsmod, /etc/modprobe.d/*.conf).
Los servicios que deben escuchar solo en localhost deben bindear a 127.0.0.1, no a 0.0.0.0.

Esta sola capa elimina un porcentaje enorme de riesgo en servidores que llevan tiempo funcionando con paquetes acumulados.

Capa 3: SSH#

Tras las actualizaciones, SSH es casi siempre la puerta más importante. Las claves de /etc/ssh/sshd_config:

Port 22                           # considerar un puerto no estándar reduce ruido
Protocol 2
PermitRootLogin no                # nunca root directo
PasswordAuthentication no         # solo claves
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers maria backup           # lista blanca de usuarios
AllowTcpForwarding no             # a no ser que necesites pivoting legítimo
X11Forwarding no

Tras cambios, sudo systemctl reload sshd y comprueba que puedes abrir una sesión nueva antes de cerrar la actual. Es la forma más común de bloquearse uno mismo fuera.

Para servidores críticos, añade MFA con pam_google_authenticator o certificados SSH con vencimiento.

Capa 4: cuentas y sudo#

# Buscar cuentas con UID 0 que no sean root
awk -F: '$3==0 {print $1}' /etc/passwd

# Buscar cuentas con contraseña vacía o shell interactivo
awk -F: '($2=="" || $2=="!" || $2=="*") {print $1}' /etc/shadow

# Deshabilitar cuentas inactivas
sudo passwd -l usuario_viejo
sudo usermod --expiredate 1 usuario_viejo

Reglas:

Una cuenta por persona, nunca compartir credenciales.
Los servicios tienen su propio usuario sin shell (/usr/sbin/nologin).
sudo con comandos exactos, no (ALL) ALL ni editores con NOPASSWD. Revisa la lección de sudo mal configurado para los detalles.
/etc/sudoers con permisos 440, editado con visudo.
Políticas de contraseñas: longitud mínima en /etc/security/pwquality.conf, no contraseñas repetidas, caducidad razonable.

Capa 5: permisos y bits especiales#

Revisa que no haya nada escribible que no deba serlo y que los binarios SUID coincidan con una lista esperada.

# Archivos accesibles mundialmente (escribibles por cualquiera)
find / -xdev -type f -perm -0002 2>/dev/null

# SUID y SGID
find / -xdev -perm /6000 -type f 2>/dev/null | sort > suid_actual.txt

# Montar carpetas de usuario con nosuid y nodev
# /etc/fstab
# /home   ext4   defaults,nosuid,nodev   0 2
# /tmp    tmpfs  defaults,nosuid,nodev,noexec  0 0

Archivos críticos: /etc/passwd en 644, /etc/shadow en 640 (grupo shadow), /etc/sudoers en 440.
/boot y configuraciones del cargador de arranque solo accesibles por root.
Repasa la lección de permisos en Linux para el detalle fino.

Capa 6: firewall#

Un firewall por defecto en denegar es una red de seguridad barata.

# Debian / Ubuntu con ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# RHEL / Rocky con firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Y no olvides el egress filtering (limitar salidas). Un servidor web no suele necesitar conectarse por SSH a internet; bloquearlo corta reverse shells y túneles.

Capa 7: fail2ban y detección de fuerza bruta#

Automatiza bloqueos ante patrones de intento repetido.

sudo apt install fail2ban

Configuración mínima en /etc/fail2ban/jail.local:

[sshd]
enabled = true
maxretry = 3
findtime = 10m
bantime = 1h

[recidive]
enabled = true
bantime = 1w

recidive es un meta-jail que alarga el bloqueo cuando la misma IP reincide muchas veces.

Capa 8: SELinux o AppArmor#

Los MAC (Control de Acceso Obligatorio) limitan lo que cada proceso puede hacer aunque corra como root.

SELinux: por defecto en RHEL y derivadas. Nunca lo desactives «para que funcione»; usa audit2allow para afinar políticas.
AppArmor: por defecto en Ubuntu. Perfiles por aplicación en /etc/apparmor.d/.

Una aplicación comprometida con un perfil estricto puede verse incapaz de leer archivos sensibles aunque consiga ejecución, lo que compra tiempo para detectar y responder.

Capa 9: auditd y logs#

Que algo quede registrado es tan importante como que no ocurra.

sudo apt install auditd

# Reglas típicas en /etc/audit/rules.d/
# Vigilar cambios en /etc/passwd y /etc/shadow
-w /etc/passwd -p wa -k identidad
-w /etc/shadow -p wa -k identidad

# Ejecuciones de comandos sensibles
-a exit,always -F arch=b64 -S execve -F path=/usr/bin/sudo -k sudo_uso

Los logs deben enviarse a un servidor externo (syslog remoto, Loki, ELK, Wazuh) para que un atacante local no pueda borrarlos.

Capa 10: monitorización y backup#

Monitoriza CPU, memoria, procesos y conexiones salientes anómalas. Prometheus, Grafana, Zabbix, Netdata.
Haz copias de seguridad cifradas, probadas, fuera del servidor. Un backup que no se restaura nunca no vale nada.
Prueba la restauración periódicamente.

Sin backups, un ransomware es un desastre; con backups mal protegidos, el atacante los cifra también.

Lista de comprobación rápida#

Lista de comprobación: antes de exponer un servidor a internet

Antes de exponer un servidor a internet, al menos:

[ ] Sistema actualizado y actualizaciones de seguridad automáticas activadas
[ ] Solo los servicios imprescindibles escuchando en el exterior
[ ] SSH sin contraseñas, sin root, con lista blanca y MaxAuthTries bajo
[ ] Una cuenta por persona, sin UID 0 extra, cuentas inactivas deshabilitadas
[ ] sudo con comandos exactos y sin NOPASSWD para editores o intérpretes
[ ] Firewall en denegar por defecto, con ufw o firewalld configurado
[ ] fail2ban activo para SSH y otros servicios públicos
[ ] SELinux en enforcing o AppArmor con perfiles activos
[ ] auditd con reglas sobre /etc, /var/log y comandos sensibles
[ ] Logs enviados a un servidor externo
[ ] Monitorización y alertas básicas funcionando
[ ] Copias de seguridad cifradas, verificadas y restaurables

Para servidores de producción, complementa con las CIS Benchmarks para tu distribución, que añaden controles detallados en kernel, red, auditoría y aplicaciones.

Hardening y productividad: encontrar el equilibrio#

Un error habitual al empezar con hardening es pasarse. Si cierras tanto el servidor que los administradores legítimos no pueden trabajar, la práctica terminará encontrando atajos: contraseñas compartidas, reglas de sudo demasiado amplias para «no estar pidiendo permiso todo el tiempo», puertos abiertos «temporalmente» para una migración urgente. Al final el servidor queda menos seguro que antes.

La regla sensata es aplicar las capas en el orden descrito, probar que todo sigue funcionando después de cada una, y solo entonces pasar a la siguiente. Un cambio que rompe el servicio no se mantiene en producción; uno que se mantiene durante meses sin dar problemas es el que de verdad vale. También es útil documentar las excepciones (por qué cierto puerto está abierto, por qué cierta regla de sudo existe): así cuando venga alguien nuevo no las revierte pensando que son errores de configuración.

Errores comunes#

Aplicar hardening «porque sí» sin probar en un entorno similar. Un cambio mal medido puede dejar el servidor inaccesible.
Desactivar SELinux para «que funcione una app». Lo correcto es afinar la política, no quitar la defensa.
Confiar solo en el firewall perimetral. El servidor debe estar endurecido aunque esté detrás de un firewall de red.
No automatizar. Si no es reproducible (Ansible, Chef, scripts), la próxima vez se olvidará algo.
Olvidar las copias de seguridad. El hardening evita incidentes; las copias los sobreviven.

Preguntas frecuentes#

¿Hay una guía oficial con todos los controles?#

Sí: las CIS Benchmarks (Center for Internet Security) publican guías por distribución con cientos de controles numerados y nivel de aplicación. Son la referencia del sector.

¿Hardening automático con Ansible?#

Existen roles ya listos como DevSec Hardening o ansible-lockdown, que aplican las recomendaciones CIS de forma reproducible. Son un gran punto de partida.

¿SELinux o AppArmor?#

Depende de tu distribución. RHEL y derivadas usan SELinux; Ubuntu y SUSE usan AppArmor. Ambas son efectivas si se mantienen activas con perfiles razonables.

¿El hardening frena a atacantes avanzados?#

No a todos, pero los ralentiza enormemente. Un servidor endurecido convierte una intrusión «de un click» en una operación de días o semanas, suficientes para que los sistemas de detección lo noten.

¿Dónde practico?#

En los laboratorios enlazados al final de esta lección y, sobre todo, sobre tus propios servidores: el mejor ejercicio es tomar una VM recién instalada y aplicarle estas medidas una a una.

Resumen#

El hardening combina varias capas: actualizaciones, reducción de superficie, SSH, cuentas, permisos, firewall, fail2ban, MAC, auditoría y monitorización.
Cada capa dificulta una técnica concreta vista en las lecciones ofensivas de /aprende.
Ninguna es suficiente por sí sola; su valor está en combinarlas.
Las CIS Benchmarks y roles como DevSec Hardening permiten aplicar cientos de controles de forma reproducible.
Las copias de seguridad cifradas y probadas son el último seguro cuando todo lo demás falla.