Hardening de servidores Linux en producción

Por qué importa el hardening desde el día 1

Un servidor Linux recién instalado es un servidor inseguro. La configuración por defecto de la mayoría de distribuciones prioriza la compatibilidad sobre la seguridad. El hardening es el proceso de reducir la superficie de ataque: desactivar lo que no se usa, reforzar lo que se usa y registrar todo lo que ocurre.

En entornos que manejan datos sensibles o requieren alta disponibilidad, el hardening no es opcional. Pero es una práctica que cualquier sysadmin debería aplicar por defecto, independientemente del sector.

1. Gestión de usuarios y privilegios

El primer vector de ataque son siempre las credenciales. Estas son las medidas que aplico desde el primer boot:

Deshabilitar el login directo de root via SSH. Siempre.
Crear un usuario administrativo con nombre no obvio y añadirlo a sudo.
Aplicar política de contraseñas fuertes con pam_pwquality.
Configurar expiración de contraseñas (chage) para cuentas de servicio.
Revisar y eliminar cuentas de usuario innecesarias del sistema.
Restringir el uso de su al grupo wheel.

# Deshabilitar login root por SSH
sed -i 's/^PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config

# Forzar autenticación por clave pública
sed -i 's/^PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config

systemctl restart sshd

2. Configuración de SSH

SSH es la puerta de entrada principal a un servidor Linux. Cada parámetro mal configurado es un riesgo:

Cambiar el puerto por defecto (22) a un puerto no estándar — no elimina el riesgo pero reduce el ruido.
Usar solo autenticación por clave pública, nunca por contraseña.
Definir una whitelist de usuarios permitidos con AllowUsers.
Configurar MaxAuthTries 3 y LoginGraceTime 30.
Deshabilitar X11Forwarding y AllowAgentForwarding si no son necesarios.
Usar fail2ban para banear IPs con demasiados intentos fallidos.

3. Firewall con nftables / iptables

Principio de mínimo privilegio aplicado a red: bloquear todo por defecto, abrir solo lo necesario. En servidores cloud, esto se complementa con los Security Groups de AWS, pero el firewall a nivel de OS es una capa adicional imprescindible.

# Ejemplo con nftables — política por defecto DROP
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Permitir loopback y conexiones establecidas
nft add rule inet filter input iif lo accept
nft add rule inet filter input ct state established,related accept

# Permitir SSH (puerto personalizado)
nft add rule inet filter input tcp dport 2222 accept

# Permitir HTTPS
nft add rule inet filter input tcp dport 443 accept

4. Actualizaciones y gestión de vulnerabilidades

A partir de cierto número de servidores, el parcheo manual deja de ser viable. El proceso recomendado:

Activar actualizaciones de seguridad automáticas (unattended-upgrades en Debian/Ubuntu).
Usar herramientas de escaneo de vulnerabilidades (integradas con AWS Inspector en entornos cloud).
Definir un SLA interno para aplicar parches críticos: máximo 72 horas desde publicación del CVE.
Mantener un inventario actualizado de versiones de software instalado.

5. Auditoría con auditd

No puedes proteger lo que no puedes ver. auditd es el sistema de auditoría del kernel de Linux y es esencial para cumplimiento normativo (ISO 27001, ENS, etc.):

# Instalar y habilitar auditd
apt install auditd audispd-plugins -y
systemctl enable --now auditd

# Reglas básicas: registrar accesos a ficheros sensibles
auditctl -w /etc/passwd -p wa -k identity
auditctl -w /etc/sudoers -p wa -k privilege_escalation
auditctl -w /var/log/auth.log -p wa -k auth_log

# Registrar ejecuciones de comandos privilegiados
auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

6. Monitorización y alertas

El hardening sin monitorización es seguridad ciega. En entornos AWS usamos CloudWatch Agent para centralizar logs y métricas. On-prem, Prometheus + Grafana o una solución SIEM según el tamaño del entorno.

Centralizar logs de sistema, SSH y auditd en una plataforma externa al servidor.
Alertas sobre: intentos de login fallidos, cambios en ficheros críticos, procesos nuevos con uid 0.
Monitorizar integridad de ficheros con AIDE o Tripwire.

7. Estrategia de Disaster Recovery

La seguridad incluye la capacidad de recuperarse. En entornos con requisitos de alta disponibilidad o cumplimiento normativo es imprescindible tener y probar planes de recuperación:

Backups automatizados y verificados periódicamente (un backup no probado no es un backup).
RTO y RPO definidos y documentados por servicio.
Ejercicios de DR al menos una vez al año, con métricas de tiempo de recuperación.

La seguridad perfecta no existe. El objetivo es que el coste de atacarte sea mayor que el beneficio que obtiene el atacante.

El checklist completo

Deshabilitar login root por SSH
Autenticación por clave pública únicamente
Cambiar puerto SSH por defecto
Instalar y configurar fail2ban
Firewall con política DROP por defecto
Eliminar paquetes y servicios innecesarios
Actualizaciones de seguridad automáticas
Configurar auditd con reglas de auditoría
Centralización de logs en sistema externo
Monitorización de integridad de ficheros
Backups automatizados y testados
Plan de DR documentado y probado