Hardening Linux: Checklist Completa Servidor Producción

El hardening Linux en servidores de producción es el proceso de configuración proactiva para reducir la superficie de ataque. Se logra deshabilitando servicios innecesarios, aplicando parches automáticos, configurando firewalls y restricciones SSH, e implementando audit y monitorización.

| Área | Acción Prioritaria | Impacto |

|—|—|—|

| Actualizaciones | Habilitar unattended-upgrades | Cierra el 56% de las vías de ataque conocidas |

| SSH | Deshabilitar PasswordAuthentication | Elimina el brute force sobre credenciales |

| Firewall | UFW default deny incoming | Reduce la superficie expuesta al mínimo |

| Servicios | Deshabilitar avahi-daemon, cups | Elimina vectores de ataque locales |

| Audit | Instalar Auditd y AIDE | Detecta modificaciones no autorizadas |

He visto un servidor en producción permanecer activo 18 meses sin aplicar nunca la checklist de hardening. Un pentest externo encontró 8 criticidades en 20 minutos. Todas prevenibles con 2 horas de configuración. Cuando heredé un entorno con 300+ VM para asegurar, la falta de un estándar repetible era el problema principal. El 73% de los breches empieza con credenciales robadas (Verizon DBIR 2025). Un servidor sin hardening es una invitación abierta. Esta guía te proporciona la checklist operativa para asegurar cualquier máquina Linux antes del go-live.

Requisitos Previos / Entorno de Prueba

Para aplicar esta guía necesitas acceso root o privilegios sudo en una distribución Debian/Ubuntu. Prueba cada configuración en un clon de la máquina de producción antes de aplicarla. Un error en sshd_config puede dejarte fuera del sistema.

Hardening Linux servidor producción: actualizaciones automáticas de seguridad

El 56% de las violaciones explota vulnerabilidades para las que ya existía un parche disponible (CISA 2025). No aplicar las actualizaciones de seguridad es un riesgo inaceptable. Configura unattended-upgrades para instalar automáticamente los parches de seguridad del kernel y los paquetes críticos.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Verifica que el archivo /etc/apt/apt.conf.d/50unattended-upgrades tenga la sección security habilitada. Comprueba el estado con sudo unattended-upgrades --dry-run. Consulta la documentación oficial de Debian sobre unattended-upgrades para detalles avanzados.

Hardening SSH: los parámetros críticos

SSH es el primer vector de ataque en internet. La configuración por defecto permite el login root y la autenticación por contraseña. Cambia estos parámetros en /etc/ssh/sshd_config:

Port 2222
PermitRootLogin no
PasswordAuthentication no
AllowUsers [email protected]/24

Reinicia el servicio con sudo systemctl restart sshd. Usa solo claves ED25519 para el acceso. Lee también: Lynis Audit Linux: Guía Práctica de Hardening 2026

Firewall UFW: reglas mínimas para producción

El firewall debe seguir el principio de mínimo privilegio. Default deny incoming, default allow outgoing. Habilita solo los puertos estrictamente necesarios.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp comment 'SSH custom port'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Verifica con sudo ufw status verbose. Cada regla extra es una superficie de ataque extra.

Fail2ban: configuración para servidor expuesto

Fail2ban bloquea automáticamente las IP que muestran comportamientos maliciosos, como intentos de login repetidos. En un servidor expuesto a internet es obligatorio.

sudo apt install fail2ban
sudo systemctl enable fail2ban

Crea el archivo /etc/fail2ban/jail.local con parámetros restrictivos:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3

Deshabilitar servicios innecesarios

Cada servicio en ejecución es un potencial vector de ataque. Revisa qué está corriendo en tu máquina.

sudo systemctl list-units --type=service --state=running

En instalaciones desktop o servidores con paquetes extra, suele haber avahi-daemon, cups o bluetooth ejecutándose. Desactívalos.

sudo systemctl disable --now avahi-daemon
sudo systemctl disable --now cups

Si no sabes para qué sirve un servicio, documenta su función antes de deshabilitarlo.

Filesystem: mount options, /tmp noexec, separar /var

Las opciones de montaje limitan los daños en caso de compromisión. Monta /tmp con noexec, nosuid y nodev. Esto impide la ejecución de scripts maliciosos ubicados en /tmp, una técnica común para la escalada de privilegios.

Modifica /etc/fstab:

/tmp     none     swap     defaults,noexec,nosuid,nodev     0 0

Separa /var y /tmp en particiones distintas. Si un proceso descontrolado llena los logs en /var, no bloqueará la partición root. Aplica las mismas opciones restrictivas a /dev/shm.

Auditd: registrar las acciones críticas

No puedes proteger lo que no ves. Auditd registra las llamadas al sistema críticas. AIDE verifica la integridad de los archivos. Instala ambos.

sudo apt install aide auditd
sudo aideinit

Configura Auditd para rastrear las modificaciones a usuarios y archivos críticos:

sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes

El comando sudo aideinit crea la base de datos inicial de integridad de archivos. Programa un chequeo diario mediante cron para detectar modificaciones no autorizadas en los binarios del sistema.

Lynis: puntuación de seguridad y qué corregir

Lynis es una herramienta de audit automático que evalúa la configuración de tu servidor y asigna una puntuación. Ejecuta el escaneo y lee el reporte.

sudo apt install lynis
sudo lynis audit system

Una puntuación superior a 85 es aceptable para entornos genéricos. Para entornos regulados, apunta a 90+. Lynis te indica exactamente qué corregir y te proporciona la sugerencia específica para cada ítem. No ignores los warnings sobre los permisos de los archivos de configuración.

CIS Benchmark: el estándar para entornos enterprise/regulados

Si tu organización debe cumplir con NIS2 art.21 o ISO 27001:2022, el CIS Benchmark es la referencia. Proporciona cientos de controles específicos para cada distribución Linux.

Aplica los parámetros de red y kernel recomendados por el CIS Benchmark para mitigar ataques a nivel de red y memory corruption:

sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w kernel.randomize_va_space=2

El primero habilita el reverse path filtering para bloquear el spoofing IP. El segundo activa el ASLR (Address Space Layout Randomization) para dificultar los exploits basados en buffer overflow. Haz los cambios persistentes en /etc/sysctl.conf. Lee también: Fail2ban en Linux: Configuración Completa y Seguridad SSH

Checklist final: 20 puntos a verificar antes del go-live

Esta es la checklist operativa que aplico en cada servidor antes de pasarlo a producción.

1. Unattended-upgrades habilitado para seguridad
2. SSH en un puerto no estándar
3. PermitRootLogin no en sshd_config
4. PasswordAuthentication no en sshd_config
5. AllowUsers configurado con IP de origen
6. UFW habilitado con default deny incoming
7. Solo puertos 80, 443 y SSH abiertos
8. Fail2ban activo con bantime 3600
9. avahi-daemon, cups y bluetooth deshabilitados
10. Postfix configurado para solo local delivery (si no se necesita envío externo)
11. /tmp montado con noexec, nosuid, nodev
12. /dev/shm montado con noexec, nosuid, nodev
13. /var en partición separada
14. Auditd instalado y reglas activas
15. AIDE inicializado y check diario configurado
16. Contraseña compleja requerida (pam_pwquality)
17. Usuarios con privilegios sudo mínimos necesarios
18. sysctl net.ipv4.conf.all.rp_filter=1
19. sysctl kernel.randomize_va_space=2
20. Lynis audit ejecutado con puntuación superior a 85

Errores Comunes y Resolución de Problemas

El error más frecuente es quedarse fuera de SSH. Cuando modificas sshd_config, no cierres la sesión actual. Abre un segundo terminal y verifica que el nuevo login funcione. Si algo falla, restaura la configuración desde el terminal aún activo.

Otro error común es configurar unattended-upgrades sin excluir paquetes críticos para la aplicación. Si una actualización automática rompe una dependencia en producción, el downtime está garantizado. Usa la directiva Unattended-Upgrade::Package-Blacklist para los paquetes sensibles.

No olvides reiniciar el servidor después de aplicar parches del kernel. Unattended-upgrades no reinicia la máquina por defecto sin la configuración Automatic-Reboot.

Para aplicar esta checklist en 50 servidores sin hacerlo a mano, usa Ansible. Crea un playbook con los tasks para cada ítem. Lo hice para un entorno con 300+ VM. Reduce el tiempo de despliegue de días a horas y garantiza coherencia.

Conclusiones con Puntos Clave Operativos

El hardening no es un evento único. Es un proceso continuo. La checklist te protege de las amenazas comunes, pero debes monitorizar, actualizar y auditar el sistema regularmente. Aplica estos 20 puntos antes del go-live. Usa Lynis para medir tu puntuación. Integra AIDE y Auditd para tener visibilidad. Cuando estandaricé este procedimiento en más de 300 VM, las alertas por intentos de intrusión cayeron un 70%. Menos ruido, más seguridad real.