Firewall con UFW: configuración segura en Linux

Un firewall filtra el tráfico de red según reglas y decide qué conexiones llegan al servidor. UFW simplifica esa política sobre netfilter en Ubuntu, pero debe activarse con orden: inventarie servicios, conserve primero el acceso SSH, aplique permisos acotados y compruebe IPv4 e IPv6 antes de cerrar la sesión.

El error peligroso no suele estar en la sintaxis. Está en aplicar una política razonable a un inventario equivocado. Si su acceso administrativo usa otro puerto, una red privada o una VPN, copiar una receta genérica puede dejar el servidor perfectamente protegido de usted mismo.

Esta guía parte de un servidor Ubuntu administrado a distancia. Los comandos necesitan privilegios administrativos y deben adaptarse a sus direcciones, interfaces y servicios reales. Mantenga abierta la sesión actual, prepare una segunda terminal y confirme que dispone de consola o modo de rescate del proveedor.

Qué protege un firewall y qué queda fuera

UFW es una interfaz para gestionar un firewall local basado en netfilter. La política actúa en el propio servidor: compara el tráfico con reglas y permite, rechaza o descarta conexiones. También conserva el estado necesario para que las respuestas de conexiones permitidas puedan regresar.

Un firewall reduce la superficie de red expuesta. No corrige una versión vulnerable, una contraseña débil, un panel con permisos excesivos ni una aplicación que autoriza mal a sus usuarios. Si permite el acceso a un servicio inseguro, la regla ha hecho exactamente su trabajo; el servicio sigue siendo inseguro.

Defensa por capas significa coordinar estas decisiones, no confiar en una sola. Antes de culpar a UFW, pregunte por el tráfico: puede quedar bloqueado en el perímetro cloud, atravesar ambas capas y fracasar porque el servicio no escucha o porque la aplicación rechaza la identidad.

Haga inventario antes de tocar las reglas

Primero averigüe qué está activo. El estado de UFW indica si ya existe una política. La lista de sockets muestra qué procesos escuchan y en qué direcciones. Las direcciones del sistema revelan si el servidor utiliza IPv6 además de IPv4.

sudo ufw status verbose
sudo ufw show added
sudo ss -lntup
ip -brief address
sudo ufw app list

Lea la salida con una pregunta sencilla: qué servicio necesita recibir conexiones iniciadas desde fuera. Una base de datos ligada únicamente a la dirección local no necesita un permiso público. Un panel interno quizá deba aceptar solo la red de administración. Un servidor web público suele necesitar HTTP y HTTPS.

Anote antes de continuar:

• el puerto y el protocolo reales de SSH;
• la dirección pública desde la que administra, si es estable;
• los servicios públicos y los que deben quedar internos;
• las reglas del firewall cloud o del router situado delante;
• el estado de IPv6 y las direcciones por las que responde el servidor;
• la ruta de consola, KVM o rescate si la red deja de funcionar.

Escuchar no equivale a estar accesible. Un proceso puede escuchar en todas las interfaces y seguir bloqueado por UFW. A la inversa, una regla abierta no crea un servicio donde no hay proceso escuchando.

Preserve SSH antes de activar UFW

No ejecute el encendido a ciegas. UFW avisa cuando se activa dentro de una sesión SSH, pero la advertencia no conoce su arquitectura. Primero confirme el puerto, el perfil y el origen desde el que realmente se conecta.

Si SSH utiliza su puerto habitual y la dirección administrativa es estable, una regla acotada se parece a esta:

sudo ufw allow proto tcp from 203.0.113.10 to any port 22 comment 'SSH admin'

La dirección del ejemplo es documental. Sustitúyala por su dirección real. Si su conexión cambia con frecuencia, no copie el filtro de origen: valore una VPN administrativa, un bastión o una regla temporal más amplia hasta disponer de una ruta estable.

También puede existir un perfil de aplicación llamado OpenSSH. Compruébelo antes de confiar en su nombre:

sudo ufw app info OpenSSH

El perfil no es una promesa. Describe puertos y protocolos instalados en ese sistema. Puede quedar desactualizado si cambió la configuración del servicio, y no todas las aplicaciones incluyen un perfil. Compare siempre el perfil con la escucha real.

Mantenga abierta la sesión original. Después de aplicar la regla, abra una segunda conexión SSH y déjela activa. Esa prueba no sustituye una consola fuera de banda, pero detecta un error antes de que cierre su única puerta.

Defina una política simple y permisos acotados

Para un servidor que inicia conexiones hacia fuera y publica pocos servicios, una base habitual es denegar nuevas conexiones entrantes y permitir salidas. No la adopte si el equipo funciona como router, pasarela o tiene requisitos de salida estrictos; esos casos necesitan una política diseñada para tráfico reenviado.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Después añada solo los servicios públicos comprobados. Para un servidor web convencional:

sudo ufw allow 80/tcp comment 'HTTP public'
sudo ufw allow 443/tcp comment 'HTTPS public'

Acote por origen cuando pueda. Un panel, una métrica o una base de datos rara vez necesita aceptar Internet completo. La forma extendida permite combinar origen, protocolo y puerto:

sudo ufw allow proto tcp from 198.51.100.0/24 to any port 9100 comment 'Metrics network'

No confunda una red de ejemplo con su red operativa. Verifique además que el firewall cloud permite el mismo flujo. Si una capa abre todo y otra bloquea, el bloqueo funciona; si ambas abren de más, ninguna compensa a la otra.

El orden de las reglas sí cambia el resultado

UFW evalúa reglas en orden y la primera coincidencia manda. Por eso una excepción específica debe aparecer antes que una regla general que coincida con el mismo tráfico. Una política amplia colocada demasiado pronto puede ocultar la intención de las líneas posteriores.

El orden no es decoración. Una regla amplia colocada antes puede resolver el tráfico y dejar sin efecto una excepción posterior. Use la vista numerada para revisar la secuencia:

sudo ufw status numbered

Puede insertar una regla en una posición concreta, pero hágalo solo después de leer la lista actual:

sudo ufw insert 1 allow proto tcp from 203.0.113.10 to any port 22 comment 'SSH admin'

La numeración cambia cuando se insertan o eliminan reglas. Vuelva a consultar el estado después de cada modificación; borrar varios números siguiendo una captura antigua es una forma eficiente de quitar la regla equivocada.

Compruebe IPv4 e IPv6 como dos rutas reales

UFW administra reglas para IPv4 e IPv6 cuando este último está habilitado. Una regla genérica puede aparecer en ambas familias. El detalle importante es operativo: si el servidor tiene una dirección IPv6 pública, compruebe esa ruta con el mismo cuidado que IPv4.

grep '^IPV6=' /etc/default/ufw
ip -6 address show scope global
sudo ufw status verbose

No desactive IPv6 para ocultar una revisión incompleta. Si la red lo utiliza, eliminarlo sin estudiar DNS, supervisión y conectividad puede crear otra avería. Si no debe usarse, retire primero la dependencia y documente la decisión.

Las reglas acotadas a una dirección IPv4 no cubren un origen IPv6. Diseñe cada permiso para las rutas que existen y pruebe desde el exterior. La ausencia de una prueba IPv6 no demuestra que el servicio esté cerrado.

Active solo cuando exista una salida de emergencia

Antes de activar, revise el cambio sin aplicarlo y confirme de nuevo el permiso administrativo:

sudo ufw --dry-run enable
sudo ufw status verbose

El modo de simulación muestra la operación prevista, pero no puede validar su acceso desde Internet ni la política del proveedor. Para eso necesita una segunda conexión y, en un servidor importante, consola o rescate fuera de banda.

Cuando el inventario y la ruta SSH estén confirmados, active UFW:

sudo ufw enable

Abra entonces una nueva sesión SSH. Pruebe también cada servicio público desde una red externa. La sesión antigua puede seguir viva aunque las nuevas conexiones estén bloqueadas; por eso no basta con mirar una terminal que ya estaba conectada.

Si pierde acceso nuevo pero conserva la sesión original, no cierre nada. Revise el estado, corrija la regla y pruebe otra vez. Si toda la red desaparece, use la consola del proveedor y desactive temporalmente la política:

sudo ufw disable

Desactivar conserva las reglas para investigarlas. Reiniciar la configuración borra la política y es una medida distinta; no la use como reflejo durante un incidente.

Registros, borrado y mantenimiento

El registro ayuda a distinguir un puerto cerrado de una regla que bloquea tráfico. Empiece con un nivel moderado y observe el volumen antes de aumentarlo:

sudo ufw logging low
sudo journalctl -k -g UFW --since today

Según la configuración de registro del sistema, los eventos también pueden aparecer en un archivo dedicado. Registrar no sustituye alertar. Un disco lleno por ruido de red es otra avería, así que vigile la rotación y el espacio disponible.

Para retirar una regla, muestre primero la lista numerada:

sudo ufw status numbered
sudo ufw delete 3
sudo ufw status numbered

El número es solo un ejemplo. Lea la regla completa antes de confirmar. Tras borrarla, vuelva a listar porque las posiciones habrán cambiado. Cuando sea posible, borrar mediante la regla original expresa mejor la intención y evita depender de un número momentáneo.

Revise UFW cuando cambie un servicio, una dirección administrativa, una interfaz, un perfil de aplicación o el firewall cloud. Una regla olvidada también es deuda operativa. Si ya no puede explicar por qué existe, investigue antes de conservarla por costumbre.

Cuándo UFW encaja y cuándo necesita otra herramienta

UFW encaja bien en un servidor Ubuntu con una política local comprensible: pocos servicios públicos, permisos por origen y administración directa. Ofrece una interfaz clara para reglas simples sin obligarle a manipular toda la estructura de netfilter.

No es la mejor capa única para una pasarela compleja, un router con abundante tráfico reenviado, políticas dinámicas entre contenedores o una infraestructura gobernada centralmente. En esos casos, diseñe la política con la herramienta que conoce la topología completa y evite que varios gestores reescriban las mismas reglas.

La decisión práctica es modesta: use UFW cuando pueda describir cada permiso, probarlo y rescatar el servidor. Si necesita reglas que nadie puede explicar sin abrir varios sistemas, el problema ya no es el comando. Es la propiedad de la política.