Cómo asegurar un servidor Linux: guía completa de hardening (2026)

Tu servidor es vulnerable en minutos

Cuando expones un servidor Linux a internet, los bots de escaneo empiezan a probar contraseñas y puertos al instante. Un VPS recién creado con configuración por defecto puede verse comprometido en menos de una hora. La buena noticia: el 90% del riesgo se elimina con una docena de ajustes bien entendidos. Esta guía, basada en el repositorio open-source How To Secure A Linux Server (29K+ estrellas) y en los CIS Benchmarks, te lleva paso a paso por el hardening esencial.

1. Antes de empezar: identifica tus principios

Antes de tocar nada, decide qué proteges y hasta dónde estás dispuesto a sacrificar comodidad por seguridad. Los principios básicos:

• Principio de mínimo privilegio: cada usuario y proceso tiene solo los permisos imprescindibles.
• Defensa en profundidad: varias capas (SSH + firewall + fail2ban), ninguna sola es suficiente.
• Deny by default: todo lo que no necesitas, cerrado.
• Elige bien la distro: usa LTS con soporte a largo plazo (Ubuntu LTS, Debian, RHEL/Alma/Rocky) y mantenla actualizada.

2. SSH: el mayor retorno de inversión

SSH es la puerta principal de cualquier servidor y el vector de ataque más común. Endurecerlo es el mayor ROI de toda la guía.

2.1 Claves públicas/privadas con ed25519

Desactiva las contraseñas y autentica por clave. Genera una clave local y cópiala al servidor:

ssh-keygen -t ed25519 -a 100
ssh-copy-id usuario@tu-servidor

2.2 Endurece /etc/ssh/sshd_config

• PermitRootLogin no — nunca acceso root directo por red.
• PasswordAuthentication no — solo claves.
• AllowGroups admins — solo usuarios del grupo admins pueden entrar.
• MaxAuthTries 3 — limita intentos por conexión.
• PubkeyAuthentication yes y AuthorizedKeysFile .ssh/authorized_keys.
• Protocol 2, ciphers y KEX modernos (curve25519, AES-GCM, MACs ETM).
• X11Forwarding no, AllowAgentForwarding no a menos que los necesites.

Después de cada cambio, valida con sshd -t y recarga: systemctl reload ssh. Nunca cierres la sesión actual sin abrir otra de prueba: te puedes quedar fuera de tu propio servidor.

2.3 2FA/MFA para SSH

Para usuarios privilegiados, añade una segunda capa con TOTP (Google Authenticator / Authy):

sudo apt install libpam-google-authenticator
google-authenticator   # genera el secreto y QR

Configura PAM y exige AuthenticationMethods publickey,keyboard-interactive en sshd_config. Con esto, robar la clave privada ya no basta.

3. Los básicos que todo servidor necesita

• Limitar sudo y su: crea un grupo con permisos y usa reglas explícitas en /etc/sudoers.d/. Nada de usuarios con sudo genérico.
• Actualizaciones automáticas: instala unattended-upgrades y actívalo para parches de seguridad (solo del repositorio -security) con alertas por email.
• Contraseñas seguras: fuerza política de contraseñas robusta (longitud mínima, complejidad) con libpam-pwquality.
• Cliente NTP: hora sincronizada (chrony/systemd-timesyncd) para logs fiables y autenticación por tiempo.
• Sandbox de aplicaciones: ejecuta servicios sospechosos o de terceros con FireJail para limitar su alcance.
• Asegurar /proc: oculta información del kernel a procesos no privilegiados (hidepid) para dificultar el reconocimiento.

4. La red: firewall UFW + fail2ban

El firewall es tu primera línea. Con UFW establece política denegar por defecto y abre solo lo imprescindible:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw --force enable

Añade fail2ban para bloquear IPs que fallan repetidamente la autenticación (generalmente con banaction = ufw y 3 intentos en 10 minutos = baneo de 1 hora). UFW limita conexiones, fail2ban detecta patrones: juntos se complementan.

5. Hardening como código: Ansible y golden images

El hardening manual no escala y se pierde en cada servidor nuevo. Lo profesional es tratarlo como infraestructura como código:

• Escribe un playbook de Ansible que aplique toda la configuración: sshd, UFW, fail2ban, unattended-upgrades, sysctl.
• Genera una golden image ya endurecida (AMI/Vagrant/Docker base) y valídala con CIS Benchmarks usando herramientas como OpenSCAP o Lynis.
• Así cada nuevo despliegue sale endurecido por defecto, sin depender de memoria ni de scripts sueltos.

Un nivel 1 de CIS cubre ~200 controles clave; el nivel 2 añade defensa en profundidad para los servidores más sensibles. Empieza por SSH + auditd + firewall: concentran la mayor reducción de riesgo con el menor esfuerzo operativo.

Checklist rápido antes de exponer cualquier servidor

1. Claves ed25519 y PasswordAuthentication no.
2. PermitRootLogin no.
3. Firewall UFW deny by default con solo 22/80/443.
4. fail2ban activo con jail sshd.
5. unattended-upgrades para parches de seguridad.
6. MFA/TOTP para usuarios con sudo.
7. Backup y snapshot antes de tocar nada.
8. Valida con lynis audit system o un escaneo OpenSCAP.

¿Y ahora qué?

Este post nace de la guía open-source How To Secure A Linux Server, que amplía cada apartado con profundidad y el porqué de cada decisión. En Codeia.dev estamos montando una ruta completa de DevOps y seguridad práctica para desarrolladores y agentes de IA: del servidor seguro al despliegue de pipelines automatizados. Si quieres que esto sea un curso completo, dímelo en los comentarios.