Configuración de firewall: UFW, iptables y diseño de políticas de seguridad

Un SMS de alerta del servidor te saca del sueño: en un entorno de pruebas, la base de datos recibió tráfico de escaneo anómalo. Al entrar al servidor, el firewall estaba desactivado. Lo activas de urgencia y encuentras un caos de reglas de prueba; el puerto SSH ni siquiera tenía limitación de velocidad.

Eso deja claro un problema habitual: mucha gente configura el firewall copiando unos comandos al azar, o no sabe distinguir UFW de iptables, y mucho menos diseñar una política de seguridad con criterio. Hoy vamos a tratarlo con calma.

Qué es realmente el firewall en Linux

Antes de hablar de firewalls, conviene aclarar un concepto que se confunde a menudo: Netfilter. Muchos creen que iptables es el firewall, y no es así.

Netfilter es el marco de procesamiento de paquetes de red en el kernel de Linux. En puntos clave de la pila de protocolos del kernel hay varios hooks: cada paquete que pasa los activa y ahí puedes enganchar tu lógica — interceptar, modificar o registrar.

iptables, UFW y nftables son solo interfaces de configuración en espacio de usuario. Las reglas que escribes con ellas se convierten al formato que Netfilter entiende y se ejecutan en el kernel.

Una analogía: Netfilter es el sistema de válvulas bajo el asfalto; iptables es la llave manual antigua; UFW, un panel táctil moderno. Los tres abren y cierran válvulas, pero la forma de operar es distinta.

Evolución de las herramientas en espacio de usuario

Las herramientas de firewall en Linux han cambiado bastante en los últimos años:

• iptables: la herramienta clásica, de alrededor de 2000. Opera Netfilter directamente; sintaxis compleja pero muy potente.
• nftables: sustituto moderno de iptables, desde 2014. Sintaxis más uniforme, mejor rendimiento; en Ubuntu reciente ya es el backend por defecto.
• UFW (Uncomplicated Firewall): herramienta simplificada de Ubuntu desde 2008. Por debajo sigue siendo iptables/nftables, pero los comandos son muy sencillos.
• firewalld: gestión dinámica en distribuciones Red Hat; permite cambiar reglas en caliente sin cortar conexiones.

Este artículo se centra en UFW e iptables porque son los más usados en operaciones reales. nftables es más moderno, pero los conceptos son parecidos; si dominas iptables, pasar a nftables no cuesta mucho.

UFW: configurar el firewall sin sufrir

Por qué UFW es tan popular

Quien ha usado iptables sabe la tensión al escribir reglas: un parámetro mal puesto y puedes cerrar SSH y quedarte fuera.

UFW apuesta por la simplicidad. Un comando abre un puerto; no hace falta memorizar -A INPUT -p tcp --dport 22 -j ACCEPT.

Comparación rápida:

iptables:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

UFW:

ufw allow ssh

La diferencia salta a la vista. UFW resuelve protocolo, seguimiento de estado e IPv6; tú solo dices «quiero abrir SSH».

Configuración básica: empezar desde cero

En un servidor nuevo, el firewall debería configurarse así:

Paso 1: política por defecto

La política por defecto define qué pasa cuando ninguna regla coincide. El principio de seguridad básico: denegar todo lo entrante, permitir todo lo saliente.

sudo ufw default deny incoming   # Rechazar todas las conexiones entrantes
sudo ufw default allow outgoing   # Permitir todas las salientes

Así, salvo que lo permitas explícitamente, ninguna petición externa entra. Muchos ponen allow por defecto por pereza y el servidor queda como una casa con la puerta abierta.

Paso 2: abrir los puertos necesarios

Trampa habitual: abre SSH antes de activar el firewall. Si no, la sesión remota se corta al instante.

sudo ufw allow ssh        # Abrir SSH (puerto 22)
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

Si SSH va en otro puerto (por ejemplo 2222):

sudo ufw allow 2222/tcp

Paso 3: activar el firewall

sudo ufw enable

El sistema avisa: «This may disrupt existing ssh connections». No entres en pánico: si antes ejecutaste allow ssh, no habrá problema. Confirma con y.

Paso 4: comprobar el estado

sudo ufw status verbose

La salida será algo así:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Si ves Status: active, el firewall ya está en marcha.

Técnicas avanzadas: endurecer la configuración

Perfiles de aplicación (App Profiles)

UFW incluye App Profiles: muchos servicios (Nginx, Apache, OpenSSH) tienen perfiles predefinidos.

Ver perfiles disponibles:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

sudo ufw app list

Salida posible:

Available applications:
  Apache
  Apache Full
  Apache Secure
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Abrir por nombre de aplicación:

sudo ufw allow 'Nginx Full'

Eso abre HTTP (80) y HTTPS (443) de una vez, sin dos reglas manuales.

Limitación de velocidad: contra fuerza bruta

SSH es un blanco habitual de fuerza bruta. UFW trae limitación integrada:

sudo ufw limit ssh

Significa: si una IP intenta más de 6 conexiones en 30 segundos, se bloquea temporalmente. Mucho más seguro que allow ssh a secas.

Restringir por IP

A veces solo quieres que ciertas IP accedan a un servicio, por ejemplo un panel de base de datos solo desde la red interna:

# Solo permitir 192.168.1.100 en MySQL
sudo ufw allow from 192.168.1.100 to any port 3306

# Denegar una IP maliciosa
sudo ufw deny from 203.0.113.100

Registro de eventos

Los logs del firewall son clave para diagnosticar:

sudo ufw logging on
sudo ufw logging medium   # Niveles: low/medium/high

Los logs están en /var/log/ufw.log, con entradas como:

Mar 15 10:23:45 server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=203.0.113.100 DST=... PROTO=TCP SPT=54321 DPT=22

[UFW BLOCK] indica que el firewall bloqueó esa petición.

Límites de UFW

UFW es práctico, pero tiene techo:

• NAT y reenvío de puertos: soporte limitado; escenarios complejos siguen pidiendo iptables
• Cadenas de reglas complejas: sin cadenas personalizadas ni anidación condicional
• Filtrado por contenido: no filtra, por ejemplo, payloads maliciosos en HTTP

Si necesitas más, toca pasar a iptables.

iptables: control fino

Arquitectura de iptables

iptables es más complejo que UFW, pero la lógica es clara: entender la estructura tabla → cadena → regla.

Tablas (Tables)

Cada tabla hace un tipo de trabajo:

• filter (por defecto): filtrado de paquetes, aceptar o rechazar
• nat: traducción de direcciones (NAT), reescribir origen/destino
• mangle: modificar TOS, TTL y otros metadatos
• raw: excepciones que evitan el seguimiento de conexión

En la mayoría de casos solo usas filter.

Cadenas (Chains)

Las cadenas son conjuntos de reglas ejecutadas en orden. filter tiene cinco cadenas integradas:

• INPUT: paquetes entrantes (destino es esta máquina)
• OUTPUT: paquetes salientes (origen es esta máquina)
• FORWARD: paquetes reenviados (esta máquina solo enruta)
• PREROUTING: antes del enrutamiento
• POSTROUTING: después del enrutamiento

El día a día se trabaja sobre INPUT y OUTPUT; FORWARD entra al actuar como router o gateway.

Orden de coincidencia

Las reglas se evalúan de arriba abajo; la primera coincidencia ejecuta la acción y no se miran las siguientes.

Ejemplo:

iptables -A INPUT -s 192.168.1.100 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j DROP

192.168.1.100 coincide con la primera ACCEPT y pasa; no llega a la segunda. Si inviertes el orden, 192.168.1.100 cae en el DROP de la red /24 y nunca alcanza la excepción.

Principio clave: reglas más específicas arriba, más generales abajo.

Desglose de la sintaxis básica

Formato general:

iptables -t nombre_tabla -A nombre_cadena condiciones -j acción

Parámetros habituales:

• -t: tabla (filter por defecto, se puede omitir)
• -A: añadir al final de la cadena (Append)
• -I: insertar en una posición (Insert)
• -D: borrar regla (Delete)
• -L: listar reglas (List)
• -F: vaciar todas las reglas (Flush)
• -P: política por defecto (Policy)

Condiciones de coincidencia

• -s: IP de origen (p. ej. -s 192.168.1.100)
• -d: IP de destino
• -p: protocolo (tcp, udp, icmp)
• --sport: puerto de origen
• --dport: puerto de destino
• -i: interfaz de entrada (p. ej. -i eth0)
• -o: interfaz de salida
• -m state --state: seguimiento de estado de conexión

Acciones (Target)

• ACCEPT: aceptar el paquete
• DROP: descartar en silencio
• REJECT: rechazar y devolver error
• LOG: registrar (no bloquea; sigue la cadena)
• RETURN: salir de la cadena actual y volver a la superior

Configuración práctica: firewall de producción

Flujo completo para un entorno serio:

Paso 1: limpiar reglas existentes

Los servidores nuevos suelen traer reglas por defecto; vacíalas primero:

sudo iptables -F        # Vaciar todas las reglas
sudo iptables -X        # Borrar cadenas personalizadas
sudo iptables -t nat -F
sudo iptables -t mangle -F

Paso 2: política por defecto

Igual que en UFW: denegar entradas por defecto.

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Paso 3: permitir conexiones ya establecidas

Regla imprescindible: deja pasar respuestas y tráfico de conexiones abiertas.

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Cuando visitas un sitio, la petición es OUTPUT (ACCEPT por defecto); la respuesta es INPUT. Sin esta regla, las respuestas caen en DROP y no recibes datos.

ESTABLISHED = conexión ya establecida; RELATED = conexiones relacionadas (p. ej. datos FTP).

Paso 4: abrir puertos necesarios

# SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# HTTPS
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Paso 5: limitar ICMP (opcional)

ICMP es el protocolo de ping. Algunas políticas desactivan ping:

# Permitir ping
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# O denegar ping
sudo iptables -A INPUT -p icmp -j DROP

Paso 6: registrar en log

Antes del DROP final, una regla LOG ayuda a diagnosticar:

sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 4

--limit 5/min evita inundar los logs: como máximo 5 entradas por minuto.

Paso 7: DROP final explícito

La política por defecto ya es DROP, pero una regla explícita deja la intención clara:

sudo iptables -A INPUT -j DROP

Paso 8: guardar las reglas

iptables no persiste por defecto; al reiniciar se pierde todo. En Ubuntu/Debian:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

sudo apt install iptables-persistent
sudo netfilter-persistent save

O guardado manual:

sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6  # Reglas IPv6

Ver el estado de las reglas

sudo iptables -L -n -v --line-numbers

• -n: mostrar números (sin resolver DNS, más rápido)
• -v: modo detallado (contadores de paquetes)
• --line-numbers: numerar reglas

Ejemplo de salida:

Chain INPUT (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination
1      42  2848 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED,RELATED
2       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
3       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "iptables denied: "
6       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

UFW frente a iptables: cuál elegir

Tras todo esto, quizá sigas dudando: ¿UFW o iptables?

Diferencia central: facilidad frente a flexibilidad

La verdad sobre el rendimiento

Muchos creen que iptables rinde más; en realidad el motor es el mismo — Netfilter en el kernel. La diferencia real es el número de reglas: más reglas, más lenta la coincidencia. En servidores pequeños y medianos casi no se nota.

Cuándo usar cada uno

UFW recomendado cuando:

• VPS, servidores en la nube o dedicados
• Despliegue de web o API
• Sin necesidades de red complejas (sin NAT ni reenvío de puertos)
• No quieres aprender la sintaxis de iptables
• Configuración rápida (p. ej. respuesta urgente a un ataque)

iptables recomendado cuando:

• Gateway, router o servidor VPN
• NAT, reenvío de puertos o balanceo de carga
• Cadenas complejas y condiciones anidadas
• Despliegue masivo (decenas de servidores con scripts)
• Filtrado avanzado (contenido, velocidad, horario)
• Equipo de operaciones con especialista de red

¿Se pueden mezclar?

No se recomienda. UFW e iptables tocan las mismas reglas de Netfilter; mezclarlos genera conflictos.

Ejemplo: abres SSH con iptables y luego UFW lo deniega; gana la última regla y te quedas fuera.

Si no hay remedio, recuerda el orden: las reglas de UFW viven entre before.rules y after.rules; las que añades con iptables a mano pueden quedar tapadas por las reglas por defecto de UFW.

Principios clave del diseño de políticas de firewall

Dominar la herramienta es solo el primer paso; hace falta una política coherente. Muchos añaden reglas al tuntún y acaban con agujeros.

Principio 1: denegación por defecto (Default Deny)

Es la base de la configuración segura.

Idea central: salvo permiso explícito, todo se rechaza.

El anti-ejemplo es «permitir por defecto»: abrir todo y luego ir cerrando puertos «peligrosos». Eso falla porque:

1. No sabes qué puertos son realmente riesgo (un atacante escanea los 65535)
2. Un puerto olvidado abierto es una puerta trasera

Lo correcto:

# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# iptables
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

Luego abres solo lo que el negocio exige. Por cada puerto, pregúntate: ¿para qué sirve? ¿Puedo limitar la IP de origen?

Principio 2: mínimos privilegios

Cada regla debe hacer una cosa y abrir el mínimo necesario.

Puertos:

• ❌ ufw allow 3306 (todo el mundo puede llegar a MySQL)
• ✅ ufw allow from 192.168.1.100 to any port 3306 (solo una IP concreta)

Servicios:

• ❌ Abrir todos los puertos internos
• ✅ Solo lo expuesto a internet (web, API); lo interno por red privada o VPN

SSH:

• ❌ ufw allow ssh (cualquiera puede intentar entrar)
• ✅ ufw allow from IP_empresa to any port 22 + ufw limit ssh

Principio 3: defensa en profundidad (Defense-in-Depth)

El firewall no lo cubre todo; es la primera capa. Un esquema completo tiene varias:

1. Firewall de red (UFW/iptables): bloquea tráfico malicioso
2. Firewall de aplicación (WAF): filtra inyección SQL, XSS, etc. en HTTP
3. Protección en el host (SELinux/AppArmor): limita permisos de procesos
4. Detección de intrusos (IDS/IPS): monitoriza comportamiento anómalo
5. Auditoría periódica: análisis de logs y escaneo de vulnerabilidades

Ejemplo: el firewall abre HTTP 80; el WAF revisa payloads en la petición; SELinux restringe qué archivos puede leer el servidor web. Si algo pasa las tres capas, aún queda la seguridad del código (validación de entrada, permisos).

Principio 4: segmentación de red (Network Segmentation)

En redes grandes no todo puede estar en la misma bolsa; hay que dividir zonas.

Modelo típico:

• DMZ (zona desmilitarizada): servicios públicos (web, correo)
• Red interna: bases de datos, servicios internos, oficina
• Zona de gestión: operaciones, monitorización, logs

Ventajas:

1. Aislar fallos: si cae la DMZ, el atacante debe cruzar otra barrera para la red interna
2. Limitar propagación: un gusano en una zona no cruza el firewall a otra
3. Permisos granulares: distintos niveles de acceso por zona

En iptables, la cadena FORWARD es clave para segmentar:

# De DMZ a red interna: solo acceso a base de datos
iptables -A FORWARD -s dmz_network -d internal_network -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD -s dmz_network -d internal_network -j DROP

Principio 5: auditoría y actualización periódicas

La configuración del firewall no es «configurar y olvidar».

Revisión de reglas:

• Mensual: ¿reglas caducadas? (puertos de prueba olvidados)
• Trimestral: ¿los puertos abiertos siguen alineados con el negocio?
• Anual: limpiar redundancias y optimizar rendimiento

Análisis de logs:

• Semanal: ¿qué IP se bloquearon y por qué?
• Alertas por umbral de tráfico anómalo
• Trazabilidad de ataques para endurecer reglas

Responder a cambios:

• Nuevo servicio: evaluar riesgo antes de abrir puertos
• Incidente: ajustar reglas, bloquear IP maliciosas, subir limitación de velocidad
• Cambio de negocio: borrar reglas que ya no hacen falta y reducir superficie expuesta

Práctica en producción: evitar trampas

Pasos seguros en el flujo de configuración

Paso 1: validar en entorno de prueba

Nunca pruebes reglas nuevas directamente en producción. Configura en una VM o desarrollo, verifica y luego sube a prod.

Paso 2: dejar salida SSH

Antes de tocar reglas, confirma que SSH está abierto. Con puerto personalizado:

# UFW
ufw allow 2222/tcp  # Puerto SSH personalizado

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

Paso 3: abrir puertos de forma gradual

No abras todo de golpe. Primero lo esencial (SSH), comprueba que entras; luego web; después el resto.

Paso 4: documentar cambios

Cada cambio en el firewall debe quedar registrado:

• Fecha y hora
• Qué cambió
• Motivo
• Resultado de la verificación

Puedes versionar los ficheros de reglas con Git o llevar un documento.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Errores frecuentes y soluciones

Error 1: quedarse fuera por SSH

Síntoma: tras activar el firewall, SSH se corta y no vuelves a entrar.

Causa: no abriste SSH antes, o el orden de reglas es malo (DROP antes que ACCEPT).

Prevención:

1. Revisa el puerto SSH actual antes de configurar
2. Primero ufw allow ssh, luego ufw enable
3. Con iptables, la regla SSH debe ir antes del DROP

Emergencia:

• VPS: consola del proveedor (sin SSH)
• Nube: modo recuperación o sistema de rescate del proveedor
• Físico: acceso local

Error 2: orden de reglas incorrecto

Síntoma: un puerto tiene regla ACCEPT pero sigue sin conectar.

Causa: un DROP anterior hace match primero.

Diagnóstico:

iptables -L -n -v --line-numbers

Revisa números y confirma que ACCEPT va antes que DROP.

Solución:

# Borrar regla en posición incorrecta
iptables -D INPUT 3

# Insertar en la posición correcta
iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT

Error 3: configuración sin persistir

Síntoma: tras reiniciar, las reglas desaparecen.

Causa: iptables solo vive en memoria.

Solución:

# Ubuntu/Debian
sudo apt install iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo service iptables save

UFW persiste por defecto; no hace falta nada extra.

Error 4: IPv6 ignorado

Síntoma: IPv4 bien, IPv6 no responde.

Causa: iptables solo cubre IPv4; IPv6 usa ip6tables.

Solución:

# Reglas IPv6 (análogas a IPv4)
sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

# Guardar
sudo ip6tables-save > /etc/iptables/rules.v6

UFW gestiona IPv6 automáticamente.

Consejos de diagnóstico

Cuando algo falla, sigue este orden:

1. Estado del firewall

# UFW
sudo ufw status verbose

# iptables
sudo iptables -L -n -v

Confirma que está activo y que las reglas son las esperadas.

2. Conectividad de puertos

# Desde fuera
telnet server_ip 22
nc -zv server_ip 80

# En local
sudo netstat -tulnp | grep :22

3. Logs del firewall

# UFW
tail -f /var/log/ufw.log

# iptables
tail -f /var/log/kern.log | grep "iptables"

Busca peticiones bloqueadas.

4. Desactivar temporalmente para aislar

# UFW
sudo ufw disable

# iptables
sudo iptables -F

Prueba conectividad: ¿es el firewall o el servicio?

Atención: con el firewall desactivado el servidor queda expuesto; restaura en cuanto termines el diagnóstico.

Resumen: construir tu sistema de seguridad con firewall

Repasemos lo esencial.

Elección de herramienta

• Escenarios simples: UFW basta; se configura en minutos
• Escenarios complejos: iptables, más flexible para gateway, NAT y filtrado avanzado
• No mezclar: una sola herramienta para evitar conflictos de reglas

Principios de configuración

• Denegación por defecto: rechazar entradas; abrir solo lo necesario
• Mínimos privilegios: reglas acotadas; limitar IP de origen
• Defensa en profundidad: el firewall es la primera capa; suma WAF, SELinux, etc.
• Segmentación de red: aislar DMZ, red interna y gestión
• Auditoría periódica: revisión mensual, evaluación trimestral, refactor anual

Puntos prácticos

• SSH primero: asegura acceso SSH antes de activar el firewall
• Orden de reglas: en iptables, de lo específico a lo general
• Persistencia: guarda reglas de iptables para que sobrevivan al reinicio
• IPv6: ip6tables por separado; UFW lo hace solo
• Prueba antes de prod: valida en entorno de prueba
• Conserva logs: activa registro y revisa tráfico anómalo

Siguientes pasos

Para profundizar en firewall y seguridad de servidores:

• nftables: sustituto moderno de iptables, sintaxis más uniforme
• firewalld: gestión dinámica con cambios en caliente
• WAF: Nginx ModSecurity, Cloudflare WAF
• Detección de intrusos: Fail2ban (bloqueo automático de fuerza bruta), OSSEC
• SELinux/AppArmor: control de permisos a nivel de host

Configurar el firewall es la base de la seguridad del servidor. Si dominas UFW e iptables y entiendes el diseño de políticas, tu servidor deja de ser una casa con la puerta abierta. Y quizá recibas menos SMS de alerta a las tres de la madrugada.

Referencias

• UFW Essentials: Common Firewall Rules and Commands - DigitalOcean
• UFW vs iptables: Simple Firewall Rules That Actually Work - WeHaveServers
• Difference Between ufw vs. nftables vs. iptables - Baeldung on Linux
• Firewall Design Principles In Network Security - Fortinet
• Linux Firewall: Configuration, Tools, Best Practices - TuxCare
• Ubuntu Community Help Wiki - UFW