Checklist de Hardening inicial para VPS recién creados en Hetzner y OVH
En el instante en que tu proveedor de cloud (Hetzner Cloud, OVH, DigitalOcean o AWS) te asigna una dirección IPv4 pública, tu servidor pasa a formar parte del radar de miles de bots automatizados.
Si revisas /var/log/auth.log apenas quince minutos después de encender una máquina con la configuración por defecto, verás cientos de intentos fallidos de autenticación por fuerza bruta contra el usuario root buscando contraseñas comunes como admin, 123456 o ubuntu.
Aplicar un proceso estricto de hardening (endurecimiento de seguridad) durante los primeros 10 minutos es la diferencia entre un servidor fiable y una máquina secuestrada para minería de criptomonedas o ataques DDoS.
Aquí tienes el checklist técnico paso a paso para aplicar en cualquier VPS con Ubuntu o Debian.
1. Actualizar el sistema y crear un usuario no root
Nunca operes como root directamente en tu trabajo diario. Comienza actualizando los repositorios e instalando paquetes esenciales:
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ufw fail2ban unattended-upgrades
Crea un usuario administrador dedicado y asígnale permisos de sudo:
# Crear nuevo usuario (sustituye 'devops' por tu nombre elegido)
adduser devops
# Añadirlo al grupo de administradores
usermod -aG sudo devops
Copia tu clave pública SSH a este nuevo usuario antes de continuar:
# En tu máquina local:
ssh-copy-id devops@IP_PUBLICA_DEL_VPS
Comprueba que puedes abrir una nueva terminal e iniciar sesión con ssh devops@IP_PUBLICA_DEL_VPS sin que te pida contraseña antes de pasar al siguiente paso.
2. Hardening estricto de SSH (sshd_config)
El 95% de los ataques automatizados a servidores se dirigen contra el puerto SSH esperando autenticación por contraseña. Desactivarla anula de raíz estos vectores de ataque.
Edita la configuración del demonio SSH:
sudo nano /etc/ssh/sshd_config
Asegúrate de configurar las siguientes directivas con estos valores exactos:
# Desactivar inicio de sesión directo para root
PermitRootLogin no
# Forzar autenticación criptográfica por claves públicas
PubkeyAuthentication yes
# Desactivar por completo la autenticación por contraseña
PasswordAuthentication no
ChallengeResponseAuthentication no
# Limitar reintentos de autenticación por sesión
MaxAuthTries 3
# Desconectar sesiones inactivas
ClientAliveInterval 300
ClientAliveCountMax 2
Valida la sintaxis del archivo antes de reiniciar para evitar quedarte fuera:
sudo sshd -t
Si no devuelve ningún error, reinicia el servicio SSH:
sudo systemctl restart ssh
(Nota: Mantén tu sesión actual abierta y comprueba en una ventana nueva que el acceso sigue funcionando).
3. Configurar el cortafuegos UFW
Por defecto, los puertos no declarados deben ser inaccesibles. La política debe ser denegar por defecto y permitir únicamente los servicios imprescindibles.
# 1. Establecer políticas por defecto
sudo ufw default deny incoming
sudo ufw default allow outgoing
# 2. Permitir SSH (imprescindible antes de activarlo)
sudo ufw allow ssh
# 3. Permitir tráfico web estándar (HTTP y HTTPS)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# 4. Activar el cortafuegos
sudo ufw enable
Verifica el estado con sudo ufw status verbose. Si utilizas Docker en tu VPS, recuerda revisar nuestra guía sobre cómo solucionar la brecha de Docker con UFW en Ubuntu.
4. Activar Fail2ban con baneo progresivo
Fail2ban monitoriza los archivos de log en busca de intentos fallidos repetidos y bloquea temporalmente las direcciones IP atacantes mediante reglas de firewall.
Crea un archivo local de configuración para no sobreescribir las actualizaciones del paquete:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
Configura la cárcel para SSH:
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 3
findtime = 10m
bantime = 1h
Reinicia y comprueba el servicio:
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
5. Activar actualizaciones de seguridad automáticas
La mayoría de brechas conocidas explotan vulnerabilidades ya parcheadas por los desarrolladores de la distribución meses atrás. Activa unattended-upgrades para que los parches de seguridad del kernel y librerías críticas se apliquen automáticamente:
sudo dpkg-reconfigure --priority=low unattended-upgrades
Resumen del Checklist de Verificación
| Control | Estado Deseado | Comando de Validación |
|---|---|---|
| Root Login | Deshabilitado (no) |
grep "^PermitRootLogin" /etc/ssh/sshd_config |
| Passwords SSH | Deshabilitado (no) |
grep "^PasswordAuthentication" /etc/ssh/sshd_config |
| Firewall UFW | Activo (default: deny) |
sudo ufw status verbose |
| Fail2ban | Activo monitorizando SSH | sudo fail2ban-client ping |
| Auto Updates | Activo para seguridad | systemctl is-active unattended-upgrades |
Automatizar la auditoría continua
Aplicar este checklist una vez está bien, pero en el día a día las configuraciones se degradan: alguien instala una base de datos de pruebas y deja el puerto abierto, o un script modifica permisos en /etc/.
Para mantener la tranquilidad sin tener que conectarte por SSH a verificar cada parámetro, utiliza FerroSentry, nuestro agente de seguridad open source en Rust:
- Audita 9 módulos de seguridad internos en segundo plano.
- Consume menos de 15 MB de RAM y menos del 0.2% de CPU.
- Te avisa al instante si alguien rehabilita contraseñas o un contenedor Docker abre puertos no deseados.
Puedes auditar tu infraestructura en 30 segundos con el plan gratuito de SecuryBlack.