Endurecimiento de VPS (Hardening y Seguridad de Linux VPS)

1. Visión general del concepto y problema sistémico

Inmediatamente después de la inicialización de un servidor virtual (VPS) en un proveedor de nube (Hetzner, DigitalOcean, AWS), la instancia es escaneada por botnets globales en los primeros 5-15 minutos. Por defecto, muchas imágenes de SO tienen habilitada la autenticación por contraseña para el usuario root, puertos de servicio abiertos y carecen de protección básica contra ataques de fuerza bruta.

Endurecimiento de VPS (Hardening del servidor) es un reglamento de ingeniería para fortalecer la seguridad del sistema operativo Linux según los estándares de CIS Benchmarks (Center for Internet Security). El objetivo del endurecimiento es:

• Minimizar la superficie de ataque (Attack Surface).
• Eliminar completamente la posibilidad de acceso por contraseña a través de canales no seguros.
• Aislar la ejecución de procesos bajo el superusuario (Root).
• Configurar la auditoría de eventos, el cierre automático de vulnerabilidades de día cero (0-day) y el filtrado de paquetes a nivel de núcleo.

Estado inicial del VPS (Alto riesgo):
[Internet] ---> [Puerto 22: SSH (Root + Contraseña)] ---> [Compromiso total del sistema]

Después del Hardening (Defensa en múltiples capas):
[Internet] ---> [Firewall UFW (Default Deny)]
                     |
                     v
                [Fail2ban (Bloqueo de escáneres)]
                     |
                     v
                [SSH: Solo claves Ed25519, Non-Root sudo]
                     |
                     v
                [Actualizaciones autónomas (unattended-upgrades)]

2. Taxonomía arquitectónica y modelo mental

El endurecimiento se despliega en cuatro planos de seguridad aislados:

1. Nivel de autenticación y control de acceso (Identity & Access):
   • Desactivación total del acceso directo como root a través de SSH (PermitRootLogin no).
   • Prohibición de la autenticación por contraseña (PasswordAuthentication no).
   • Creación de un usuario no privilegiado con membresía obligatoria en el grupo sudo.
   • Instalación de claves criptográficas Ed25519.
2. Nivel de red (Network Perimeter):
   • Activación de ufw con política de denegación de todos los paquetes entrantes (default deny incoming).
   • Apertura solo de puertos vitales (por ejemplo, 2222/tcp, 80/tcp, 443/tcp).
   • Despliegue de fail2ban para el baneo automático de hosts que generan solicitudes anómalas.
3. Nivel del sistema operativo y núcleo (OS & Kernel):
   • Ajuste de parámetros sysctl para proteger la pila de red (prohibición de redirecciones ICMP, protección contra ataques SYN-flood).
   • Activación de actualizaciones de seguridad avanzadas (unattended-upgrades).
4. Nivel de aplicaciones y entorno de ejecución (Runtime Isolation):
   • Ejecución de contenedores Docker y agentes de IA bajo UID/GID no privilegiados sin acceso a /var/run/docker.sock.

3. Pipeline técnico y mecánica interna

Paso 1. Creación de un usuario sudo y despliegue de clave SSH

Conectándose al servidor limpio con una contraseña temporal de root, se crea inmediatamente un usuario ingeniero:

# Creación del usuario deploy con directorio home y zsh/bash
adduser --gecos "" deploy
usermod -aG sudo deploy

# Copia de la clave pública Ed25519
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Paso 2. Endurecimiento del demonio OpenSSH (/etc/ssh/sshd_config.d/99-hardening.conf)

Se crea un archivo de configuración SSH aislado para protegerlo de sobrescrituras durante las actualizaciones de paquetes:

# Cambio de puerto (opcional, pero recomendado)
Port 2222

# Prohibición total del acceso root y contraseñas
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Permitir solo claves criptográficas confiables
PubkeyAuthentication yes
AuthenticationMethods publickey

# Protección de sesiones contra cuelgues
ClientAliveInterval 300
ClientAliveCountMax 2

# Desactivación de funciones de redirección inseguras
X11Forwarding no
AllowTcpForwarding yes

Prueba de la configuración antes del reinicio:

# Validación de la sintaxis (si la salida está vacía, la configuración es correcta)
sudo sshd -t
sudo systemctl restart sshd

Paso 3. Configuración de parámetros del núcleo de Linux (/etc/sysctl.d/99-security.conf)

# Protección contra ataques TCP SYN Flood
net.ipv4.tcp_syncookies = 1

# Prohibición de redirección de paquetes de enrutamiento (protección contra Man-in-the-Middle)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Ignorar respuestas ICMP falsificadas
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Prohibición del enrutamiento de origen IP
net.ipv4.conf.all.accept_source_route = 0

Aplicación de cambios en el núcleo sin reinicio:

sudo sysctl --system

4. Escenarios prácticos de ingeniería en producción

01. Endurecimiento automatizado a través de Cloud-Init en Hetzner Cloud

Al crear un servidor virtual a través de Terraform o el panel de control de Hetzner, se pasa un script de User Data (cloud-init). El servidor se inicia ya con root cerrado, un usuario previamente creado, reglas UFW generadas y SSH configurado en un puerto no estándar, eliminando completamente la ventana de vulnerabilidad en los primeros minutos de vida de la máquina.

02. Actualización automática de parches de seguridad del núcleo sin intervención

Configuración del paquete unattended-upgrades en Ubuntu:

sudo apt install unattended-upgrades update-notifier-common
sudo dpkg-reconfigure --priority=low unattended-upgrades

El servidor descarga e instala automáticamente actualizaciones críticas de seguridad desde los repositorios oficiales de Security cada noche, y la utilidad needrestart reinicia automáticamente los servicios comprometidos sin reiniciar el sistema operativo.

03. Aislamiento del tráfico interno del demonio Docker

Docker intenta automáticamente exponer puertos en todas las interfaces de red (0.0.0.0). Durante el endurecimiento, el archivo /etc/docker/daemon.json se configura con una restricción de enlace por defecto:

{
  "iptables": true,
  "live-restore": true,
  "userland-proxy": false
}

Esto garantiza que los servicios sin un mapeo explícito al host local permanezcan dentro del puente de red virtual de Docker y no expongan puertos a internet público.

5. Errores comunes, trampas y seguridad

1. Bloqueo accidental (SSH Lockout): El error más común de un ingeniero: cerrar el acceso por contraseña y prohibir root, olvidando verificar si la clave pública para el nuevo usuario funciona o si el nuevo puerto está permitido en UFW. Nunca cierre la sesión de terminal inicial hasta que se haya conectado exitosamente en una pestaña paralela.
2. Almacenamiento de la contraseña sudo en scripts o .bash_history: Usar echo "password" | sudo -S ... en scripts de shell o ingresar contraseñas en la terminal lleva a fugas en texto claro en el historial de comandos. Utilice sudo visudo para delegar comandos específicos sin contraseña (NOPASSWD) para cuentas de servicio especializadas en CI/CD.
3. Ignorar la seguridad de la consola Out-of-band del proveedor: Incluso un servidor perfectamente endurecido puede ser comprometido si la cuenta en la consola del proveedor de hosting (Hetzner Cloud Console, DigitalOcean Dashboard) está protegida solo por una contraseña simple sin autenticación de dos factores de hardware (2FA / WebAuthn). El acceso a la consola del proveedor es equivalente al acceso físico directo a la placa base del servidor.