Cómo configurar el firewall UFW en Ubuntu en 5 pasos

Ubuntu trae UFW instalado, pero apagado. Quien levanta un VPS, instala nginx, Postgres y Redis y sigue de largo suele terminar con media docena de puertos abiertos a internet sin darse cuenta. UFW (Uncomplicated Firewall) es una capa simple sobre iptables/nftables que lo resuelve con unos pocos comandos. Este tutorial va paso a paso, incluido el error clásico que te deja afuera de tu propio servidor.

Qué es UFW y por qué usarlo

¿Qué es UFW en Ubuntu?

UFW es la interfaz de línea de comandos de Ubuntu para gestionar el firewall del kernel (netfilter) sin escribir reglas de iptables a mano. Defines qué conexiones de entrada y salida se permiten o se bloquean, y él las traduce a las reglas reales.

La lógica de seguridad es la del mínimo privilegio: denegar por defecto todo lo que entra y abrir solo lo que el servidor necesita ofrecer. Un servicio olvidado escuchando en 0.0.0.0 deja de ser un problema, porque el firewall lo bloquea antes de que llegue cualquier paquete.

Paso 1: revisa el estado actual

sudo ufw status verbose

En una instalación nueva, la respuesta es Status: inactive. Antes de activar nada, mira qué está escuchando realmente:

sudo ss -tulpn

Este comando lista los puertos TCP/UDP abiertos y el proceso dueño de cada uno. Es tu lista de lo que hay que permitir — o cerrar. Si usas Windows, el equivalente en PowerShell está en el post sobre Get-NetTCPConnection para ver puertos abiertos.

Paso 2: define la política por defecto

sudo ufw default deny incoming
sudo ufw default allow outgoing

La primera línea bloquea toda conexión de entrada sin regla explícita. La segunda deja que el servidor hable con el mundo (actualizaciones, DNS, APIs). Es el valor por defecto del propio UFW, pero declararlo evita sorpresas si alguien modificó /etc/default/ufw.

Paso 3: abre SSH ANTES de activar

Este es el error que se lleva puesto a quien usa VPS: activar el firewall con política deny incoming sin haber abierto el puerto de SSH. La sesión actual normalmente sigue viva, pero cualquier conexión nueva es rechazada — y si la sesión se cae, perdiste el acceso (solo te salva la consola del proveedor).

sudo ufw allow OpenSSH

El perfil OpenSSH abre el puerto 22/tcp. Si cambiaste el puerto en sshd_config, abre el número correcto:

sudo ufw allow 2222/tcp

Mejor aún: en vez de abrirlo a todo el mundo, usa limit, que bloquea temporalmente las IP que hacen 6 o más intentos de conexión en 30 segundos:

sudo ufw limit OpenSSH

Es una protección básica contra fuerza bruta. Para algo más sofisticado, combínalo con fail2ban, que lee los logs y banea por más tiempo. Y el firewall no sustituye configurar el propio demonio: mira los 7 ajustes esenciales de SSH hardening.

Paso 4: abre solo los servicios necesarios

Ejemplos comunes:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 5432 proto tcp

• Líneas 1 y 2: web (HTTP y HTTPS) abierta a cualquier origen.
• Línea 3: SSH solo desde una IP específica (cambia 203.0.113.10 por tu IP fija o la de tu VPN). Es la regla más fuerte contra escáneres.
• Línea 4: base de datos accesible solo desde la red local. Una base de datos expuesta a internet es una de las causas más comunes de filtraciones.

Si usas la regla de IP única para SSH, elimina la regla genérica de SSH después de probar una conexión nueva en otra terminal.

Paso 5: activa y verifica

sudo ufw enable
sudo ufw status numbered

UFW avisa que la activación puede interrumpir conexiones SSH existentes; confirma con y solo si ya hiciste el paso 3. El listado numerado muestra cada regla con un índice. Para borrar una regla:

sudo ufw delete 3

Los números cambian tras cada eliminación, así que ejecuta status numbered de nuevo antes de borrar la siguiente. Para activar el registro de intentos bloqueados:

sudo ufw logging on

Los bloqueos aparecen en /var/log/ufw.log (o en el journal, según la configuración). Conviene echarle un vistazo de vez en cuando: es una foto del tipo de escaneo que recibe tu IP.

Trampas que casi nadie cuenta

¿Docker ignora las reglas de UFW?

Sí: los puertos publicados con -p 8080:80 en Docker se abren directamente en las reglas de iptables y pasan por fuera de UFW. La propia documentación de Docker advierte que UFW no puede bloquear ese tráfico.

En la práctica, un contenedor de base de datos con -p 5432:5432 queda accesible desde internet aun con deny incoming activo. Dos salidas: publicar el puerto solo en loopback (-p 127.0.0.1:5432:5432) o, cuando el servicio solo necesita hablar con otros contenedores, no publicar ningún puerto.

¿Y IPv6?

Verifica que IPV6=yes esté en /etc/default/ufw. Con eso activo, las reglas valen para IPv4 e IPv6. Sin él, el servidor puede estar protegido en v4 y abierto de par en par en v6.

¿Cómo probar desde afuera?

Desde tu computadora (no desde el servidor), ejecuta nmap -Pn IP-DEL-SERVIDOR y compara con la lista de puertos que decidiste abrir. Escanea solo servidores tuyos o con autorización.

Un firewall es una capa, no la solución

UFW reduce la superficie de ataque, pero no arregla contraseñas débiles, software desactualizado ni credenciales filtradas. Trátalo como la primera puerta cerrada de una casa con varias. Si administras acceso remoto en Windows, el razonamiento es el mismo, y el post sobre cómo proteger RDP contra fuerza bruta muestra cómo aplicarlo. Empieza hoy con ss -tulpn en tu servidor: lo que no reconozcas en esa lista es el primer candidato a cerrar.