Hardening inicial de un Cloud Server Ubuntu: SSH, UFW y Fail2Ban

Un servidor cloud te da libertad para desplegar aplicaciones, automatizaciones y bases de datos. Pero esa libertad también exige criterio operativo.

En esta guía vas a ver una implementación práctica de hardening inicial de un Cloud Server Ubuntu, enfocada en tres capas básicas: SSH, firewall con UFW y Fail2Ban. Los comandos están orientados a Ubuntu/Debian e incluyen puntos de verificación y advertencias para no comprometer disponibilidad ni seguridad.

La idea no es memorizar comandos sueltos, sino dejar un flujo repetible: preparar el servidor, instalar las herramientas necesarias, configurar lo mínimo seguro, probar que funciona y cerrar con controles básicos de seguridad.

¿Qué es el hardening inicial?

El hardening inicial es el conjunto de ajustes mínimos que conviene aplicar antes de exponer un servidor a Internet.

No convierte al servidor en invulnerable, pero reduce ataques comunes como fuerza bruta por SSH, servicios abiertos por error y configuraciones demasiado permisivas.

¿Cuándo conviene aplicarlo?

Este procedimiento es útil si:

Vas a publicar una aplicación web, API, panel o base de datos administrada por tu equipo.
Recibiste un Cloud Server nuevo y todavía no definiste reglas de acceso.
Necesitas una base repetible para servidores Ubuntu o Debian.

Requisitos previos

Antes de empezar, asegúrate de contar con:

Cloud Server Ubuntu 22.04, 24.04 o superior.
Acceso root inicial o usuario con sudo.
Llave SSH generada en tu equipo local.
Un plan de recuperación por consola si vas a cambiar reglas de red.

Puertos necesarios

Según el uso del servidor, estos son los puertos básicos que podrías necesitar:

22/tcp o el puerto SSH elegido.
80/tcp si publicas HTTP.
443/tcp si publicas HTTPS.

Paso 1: Actualizar el sistema y crear un usuario operativo

El primer paso es partir de un sistema actualizado y evitar operar siempre como root.

sudo apt updatesudo apt upgrade -ysudo adduser deploysudo usermod -aG sudo deploy

Advertencia: no cierres la sesión root hasta comprobar que el nuevo usuario puede usar sudo.

Paso 2: Configurar acceso por llave SSH

Ahora copia la llave pública al usuario operativo y valida que el ingreso funcione correctamente.

ssh-copy-id deploy@IP_DEL_SERVIDORssh deploy@IP_DEL_SERVIDORsudo whoami

Si el comando sudo whoami devuelve root, el usuario puede ejecutar tareas administrativas.

Advertencia: antes de desactivar el acceso por contraseña, prueba una segunda terminal con acceso por llave.

Paso 3: Endurecer SSH

El siguiente paso es reducir la superficie de ataque deshabilitando el login directo como root y el acceso por contraseña.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.baksudoedit /etc/ssh/sshd_configsudo sshd -tsudo systemctl reload ssh

Dentro de /etc/ssh/sshd_config, revisa y ajusta las directivas necesarias según tu política de acceso.

Advertencia: un error en sshd_config puede dejarte afuera del servidor. Ejecuta siempre sudo sshd -t antes de recargar el servicio.

Paso 4: Activar UFW con reglas mínimas

Con SSH validado, puedes configurar el firewall para permitir solo los puertos necesarios.

sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw allow OpenSSHsudo ufw allow 80/tcpsudo ufw allow 443/tcpsudo ufw enable

Para revisar el estado del firewall:

sudo ufw status verbose

Advertencia: abre el puerto SSH real antes de habilitar UFW, sobre todo si cambiaste el puerto 22.

Paso 5: Instalar Fail2Ban y verificar bloqueos

Fail2Ban suma una defensa automática contra intentos repetidos de acceso fallido por SSH.

sudo apt install fail2ban -ysudo systemctl enable --now fail2bansudo fail2ban-client status sshd

Con esto puedes verificar si la jail de SSH está activa y si Fail2Ban está monitoreando intentos fallidos.

Advertencia: Fail2Ban ayuda, pero no reemplaza el uso de llaves SSH, actualizaciones del sistema ni una política de firewall clara.

Reforzar la seguridad antes de publicar

Antes de dar por terminado el despliegue, revisa tres puntos:

Que el servicio público sea realmente el que querías publicar.
Que los puertos internos no hayan quedado expuestos.
Que los secretos no estén en archivos versionados o historiales de shell.

Si el procedimiento toca bases de datos, runners, automatizaciones o certificados, prueba primero en un entorno secundario.

También conviene documentar cómo se reinicia el servicio, cómo se actualiza, dónde están los logs y cuál es el comando de verificación rápida. Esa información vale mucho cuando otra persona del equipo tiene que intervenir.

Problemas frecuentes

Me quedé sin acceso por SSH

Revisa si UFW permitió el puerto correcto. Si tienes consola de recuperación, entra al servidor y ejecuta:

sudo ufw status verbose

Fail2Ban no muestra la jail `sshd`

Confirma que el servicio SSH escribe logs en la ruta usada por la distribución y que Fail2Ban está activo.

sudo systemctl status fail2bansudo fail2ban-client status

SSH no recarga

Ejecuta este comando para ver el error exacto antes de reiniciar el servicio:

sudo sshd -t

Corrige el problema informado y recién después recarga SSH:

sudo systemctl reload ssh

Conclusión

Si vas a desplegar aplicaciones en DonWeb Cloud, aplica esta base antes de instalar el stack principal. Te va a ayudar a reducir incidentes simples y te deja un punto de partida más ordenado para crecer.