Hardening Linux VPS : checklist para agencias tras la entrega

Por qué un runbook formalizado lo cambia todo para una agencia

Lo que este runbook aporta a tu agencia

• Reproducibilidad: cada técnico sigue exactamente los mismos pasos, en el mismo orden, en cada nuevo VPS cliente.
• Trazabilidad: auditd registra quién hizo qué, cuándo y qué comando — prueba conservable en caso de incidente o auditoría de cliente.
• Delegación segura: un junior puede entregar un servidor endurecido sin improvisar, porque el runbook contiene las decisiones en su lugar.
• Defensa contractual: una cláusula de seguridad en tu contrato de mantenimiento solo es defendible con un registro de ejecución fechado.
• Reducción de la superficie de ataque: la checklist elimina los olvidos clásicos — root SSH abierto, auditd sin activar — los puntos de entrada más explotados.
• Consistencia entre clientes: misma base segura para todos, diferencias solo donde el pliego de condiciones del cliente lo exija.

Requisitos previos y alcance de la checklist

Bloque 1 — Actualizaciones e inventario inicial

1. 01

   Actualización del sistema e inventario

   La primera acción tras el login como root es llevar el sistema a su nivel de parches actual.

   apt update && apt upgrade -y
   apt install -y auditd audispd-plugins curl gnupg2 ufw fail2ban

   Registra en tu runbook: la fecha, la versión del kernel (uname -r) y la lista de paquetes instalados (dpkg -l > /root/inventory-$(date +%F).txt). Este archivo de inventario constituye la línea base del servidor en la entrega — es el documento que presentarás si un cliente cuestiona el estado inicial de su máquina.

   Referencia CIS Benchmark: control CIS 1.1 (Ubuntu Linux 24.04 LTS Benchmark, sección «Configuración inicial»).

2. 02

   Activar actualizaciones de seguridad automáticas

   apt install -y unattended-upgrades
   dpkg-reconfigure --priority=low unattended-upgrades

   Verifica que la línea Unattended-Upgrade::Allowed-Origins incluya ${distro_id}:${distro_codename}-security. Para una cartera de clientes, activa las actualizaciones automáticas y programa una revisión mensual de las actualizaciones no relacionadas con seguridad — requieren validación humana.

   Referencia CIS: control CIS 1.9 (Garantizar que se instalen actualizaciones, parches y software de seguridad adicional).

Bloque 2 — Usuario sudo y bloqueo de root

1. 03

   Crear una cuenta de administración dedicada

   Nunca uses root para las tareas habituales. Crea una cuenta nominativa por técnico o una cuenta de servicio de agencia:

   useradd -m -s /bin/bash adminagencia
   usermod -aG sudo adminagencia
   passwd adminagencia

   Consejo para la agencia: usa un nombre de cuenta identificable en los logs (juan.garcia o agency-admin), no un genérico admin. Cuando auditd registra una acción, queda registrada la cuenta ejecutante — un nombre genérico inutiliza la auditoría.

2. 04

   Deshabilitar el login root por SSH

   sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
   grep PermitRootLogin /etc/ssh/sshd_config

   Atención: solo recarga sshd después de verificar que tu usuario sudo puede conectarse y ejecutar sudo su. De lo contrario te quedarás sin acceso al servidor.

   Referencia CIS: control CIS 5.2.8 (Garantizar que el login root SSH esté deshabilitado).

Bloque 3 — Autenticación por clave SSH

1. 05

   Desplegar la clave pública de la agencia

   mkdir -p /home/adminagencia/.ssh
   chmod 700 /home/adminagencia/.ssh
   echo "<CLAVE_PUBLICA_AGENCIA>" >> /home/adminagencia/.ssh/authorized_keys
   chmod 600 /home/adminagencia/.ssh/authorized_keys
   chown -R adminagencia:adminagencia /home/adminagencia/.ssh

   Consejo para la agencia: mantén un repositorio versionado de claves públicas (un archivo por técnico, rotación anual). Cada clave desplegada en un VPS cliente debe estar referenciada en ese repositorio — es lo que permite revocar el acceso cuando un colaborador deja el equipo.

2. 06

   Deshabilitar la autenticación por contraseña

   Una vez verificada la clave (prueba desde otro terminal antes de confirmar):

   sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
   sed -i 's/^#\?ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/' /etc/ssh/sshd_config
   systemctl reload sshd

   Referencia CIS: control CIS 5.2.19 (Garantizar que la autenticación SSH por contraseña esté deshabilitada).

Bloque 4 — Firewall UFW

1. 07

   Configurar UFW con política de denegación por defecto

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

   Abre solo los puertos realmente utilizados por el proyecto del cliente. Si la aplicación del cliente no usa un puerto de correo directo, no lo abras.

   Para la instalación de fail2ban y las opciones avanzadas de UFW, consulta los artículos dedicados: Proteger un VPS con fail2ban y Firewall UFW en VPS.

   Referencia CIS: control CIS 3.5.1 (Garantizar que un paquete de firewall esté instalado).

Bloque 5 — fail2ban

1. 08

   Activar fail2ban con la jaula SSH

   cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

   Edita /etc/fail2ban/jail.local y ajusta la sección [sshd]:

   [sshd]
   enabled = true
   maxretry = 5
   findtime = 600
   bantime = 3600

   systemctl enable fail2ban
   systemctl start fail2ban
   fail2ban-client status sshd

   Para una cartera de clientes, considera CrowdSec como sustituto o complemento: su lista de bloqueo comunitaria mancomuniza la inteligencia de miles de servidores.

Bloque 6 — auditd: el registro de trazabilidad

1. 09

   Activar auditd y configurar las reglas mínimas

   auditd es el componente que las agencias olvidan con mayor frecuencia — y sin embargo es el que proporciona la prueba oponible en caso de incidente.

   systemctl enable auditd
   systemctl start auditd

   Crea un archivo de reglas de agencia en /etc/audit/rules.d/agency.rules:

   # Registrar todas las elevaciones de privilegios
   -w /etc/sudoers -p wa -k sudoers_changes
   -w /etc/sudoers.d/ -p wa -k sudoers_changes
   
   # Registrar conexiones SSH
   -w /var/log/auth.log -p wa -k auth_log
   
   # Registrar modificaciones en archivos de configuración del sistema
   -w /etc/ssh/sshd_config -p wa -k sshd_config
   -w /etc/passwd -p wa -k passwd_changes
   -w /etc/shadow -p wa -k shadow_changes
   
   # Registrar comandos ejecutados como root
   -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

   augenrules --load
   auditctl -l

   Referencia CIS: control CIS 4.1.1 (Garantizar que la auditoría esté habilitada) y CIS 4.1.3 (Garantizar que se recopilen eventos que modifiquen información de fecha y hora).

2. 10

   Exportar y conservar los logs de auditd

   Los logs de auditd deben conservarse fuera del servidor para ser oponibles. Configura una exportación a tu sistema centralizado (rsyslog, Loki o un simple rsync diario al almacenamiento de la agencia):

   # Ejemplo: exportación rsyslog al colector de la agencia
   echo ':programname, isequal, "auditd" @<IP_COLECTOR_AGENCIA>:514' \
     >> /etc/rsyslog.d/99-auditd-remote.conf
   systemctl restart rsyslog

   Conserva al menos 90 días de logs. El RGPD no fija un período mínimo de retención para logs de seguridad, pero marcos como CIS Controls v8 (control 8.3) recomiendan al menos 90 días en local y 1 año en archivo frío.

Bloque 7 — Verificación final y acta de entrega

# Verificar servicios activos
systemctl is-active ufw fail2ban auditd sshd

# Confirmar que root no puede conectarse por SSH
grep PermitRootLogin /etc/ssh/sshd_config

# Verificar reglas UFW
ufw status verbose

# Verificar reglas auditd cargadas
auditctl -l

# Revisar últimas conexiones
last -n 10

Runbook de agencia vs. configuración improvisada

Desplace la tabla

Resolución de errores: los más frecuentes al aplicar el runbook

sshd -t && systemctl reload sshd

# En /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Automatic-Reboot "false";

Ir más lejos: bastionado y monitorización continua