Fundamentos de Configuración de Firewall: Protege Tu Red

Un firewall actúa como barrera entre tu red y el mundo exterior, decidiendo qué tráfico pasa y qué se bloquea. Ya sea que estés protegiendo una red doméstica, configurando un servidor web o administrando infraestructura empresarial, entender cómo configurarlo es fundamental para la seguridad. Esta guía recorre los conceptos esenciales, enfoques prácticos de configuración y patrones comunes que aplican a distintos tipos de firewall.

“There are only two types of companies: those that have been hacked and those that will be.”

— Robert Mueller

Tipos de Firewalls y sus Modelos de Configuración

No todos los firewalls funcionan igual. Los firewalls de filtrado de paquetes examinan paquetes individuales según direcciones IP, puertos y protocolos. Son rápidos y directos, pero no entienden el contexto de la aplicación. Los firewalls con inspección de estado rastrean el estado de las conexiones, permitiendo automáticamente el tráfico de retorno y bloqueando conexiones entrantes no solicitadas. Los firewalls de capa de aplicación van más allá e inspeccionan el contenido real del tráfico, filtrando según cabeceras HTTP, consultas SQL u otros datos específicos de la aplicación.

La mayoría de los sistemas modernos usan firewalls con inspección de estado por defecto. En Linux se suele usar iptables, nftables o ufw (Uncomplicated Firewall). Windows incluye Windows Defender Firewall. Los proveedores cloud tienen sus propios equivalentes: security groups en AWS, reglas de firewall en Google Cloud y network security groups en Azure. Los principios subyacentes son consistentes en todos ellos: define qué está permitido, bloquea todo lo demás y registra lo importante.

La primera decisión clave es si usar política de permiso por defecto o denegación por defecto. La denegación por defecto bloquea todo excepto el tráfico que explícitamente permitas. Requiere más trabajo inicial, pero reduce considerablemente la superficie de ataque. El permiso por defecto es más fácil para empezar, pero te deja expuesto a servicios que olvidaste que estaban corriendo. Para cualquier sistema expuesto a internet, la denegación por defecto es la única opción sensata.

Conceptos Fundamentales de Configuración

Toda regla de firewall tiene los mismos ingredientes básicos: direcciones de origen y destino, puertos, protocolos y una acción (permitir, denegar o registrar). Las reglas se procesan en orden y gana la primera coincidencia. Ese orden importa enormemente. Una regla amplia de "permitir todo" al principio de la lista anulará las reglas de "denegar" más específicas que vengan después, que nunca llegarán a ejecutarse.

El origen y destino pueden ser direcciones IP individuales como 192.168.1.50, rangos CIDR como 10.0.0.0/8, o valores especiales como "any" o "localhost". Los puertos corresponden a servicios específicos: 22 para SSH, 80 para HTTP, 443 para HTTPS, 3306 para MySQL. Los protocolos son TCP, UDP, ICMP u otros. TCP está orientado a conexión y gestiona la mayor parte del tráfico de aplicaciones. UDP es sin conexión y se usa para DNS, VoIP y streaming de video. ICMP maneja diagnósticos como ping.

La inspección de estado simplifica mucho la gestión de reglas. Cuando permites tráfico HTTPS saliente, el firewall automáticamente permite los paquetes de respuesta entrantes. No necesitas reglas separadas para ambas direcciones. Por eso la mayoría de las configuraciones se centran en las reglas de entrada: el tráfico saliente suele estar permitido por defecto, con excepciones puntuales para prevención de pérdida de datos o requisitos de cumplimiento normativo.

Ejemplos Prácticos de Configuración

Aquí tienes una configuración básica con ufw para un servidor web con SSH, HTTP y HTTPS:

# Restablecer valores por defecto y habilitar
sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Permitir SSH (limitar tasa de conexiones para prevenir fuerza bruta)
sudo ufw limit 22/tcp

# Permitir tráfico web
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Activar el firewall
sudo ufw enable

# Verificar estado
sudo ufw status verbose

La opción limit en SSH bloquea las IPs que intentan más de 6 conexiones en 30 segundos, lo que detiene la mayoría de los ataques de fuerza bruta en seco. Dicho esto, la autenticación de dos factores sigue siendo imprescindible para cualquier servicio SSH expuesto a internet. La limitación de tasa y el 2FA juntos ofrecen protección real.

Para iptables, la misma configuración requiere reglas más explícitas:

# Vaciar reglas existentes
iptables -F

# Establecer políticas por defecto
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Permitir conexiones ya establecidas
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Permitir loopback
iptables -A INPUT -i lo -j ACCEPT

# Permitir SSH con limitación de tasa
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Permitir HTTP y HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Guardar reglas
iptables-save > /etc/iptables/rules.v4

Presta atención a la regla de seguimiento de estado (--ctstate ESTABLISHED,RELATED). Una sola línea gestiona todo el tráfico de retorno de cada conexión saliente que inicias: actualizaciones de software, llamadas a APIs, correo electrónico, todo. Está haciendo un trabajo silencioso pero fundamental.

Patrones Comunes de Configuración

Aislamiento del servidor de base de datos: restringe el acceso a la base de datos solo a los servidores de aplicación. Supongamos que tu base de datos está en 10.0.2.50 y tus servidores de aplicación están en la subred 10.0.1.0/24. Configura el firewall del servidor de base de datos para aceptar conexiones únicamente desde esa subred:

# En el servidor de base de datos
ufw default deny incoming
ufw allow from 10.0.1.0/24 to any port 3306 proto tcp
ufw allow from 10.0.1.0/24 to any port 22 proto tcp  # SSH desde la subred de aplicación
ufw enable

Configuración de bastion host: crea un servidor de salto reforzado para acceder a la infraestructura interna. El bastión acepta SSH solo desde IPs conocidas, y los servidores internos solo aceptan SSH desde el bastión:

# En el bastion host
ufw allow from 203.0.113.50 to any port 22  # IP de la oficina
ufw allow from 198.51.100.25 to any port 22  # IP de casa

# En los servidores internos
ufw allow from 10.0.0.10 to any port 22  # IP interna del bastión

Combina este patrón con una guía de creación de contraseñas robustas y autenticación basada en certificados, y tendrás una defensa en profundidad real.

Configuración de DMZ: ubica los servicios públicos en una zona desmilitarizada, aislada tanto de internet como de tu red interna. El tráfico de internet solo llega a los hosts de la DMZ, mientras que estos tienen acceso limitado a los recursos internos:

Registro y Monitoreo

Los logs del firewall revelan patrones de ataque, errores de configuración y tráfico legítimo que bloqueaste sin querer. Activa el registro para los paquetes denegados, pero sé selectivo. Registrar cada paquete descartado en un servidor expuesto a internet genera un volumen enorme de ruido de fondo: escáneres, bots y el caos general que golpea constantemente cualquier IP pública.

# Registrar paquetes denegados con limitación de tasa
ufw logging medium

# En iptables, registrar con prefijo identificador
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-denied: " --log-level 4
iptables -A INPUT -j DROP

La limitación de tasa (--limit 5/min) mantiene los logs manejables. El prefijo facilita filtrar específicamente los eventos del firewall. Revisa los logs regularmente como parte de tu checklist de auditoría de seguridad. Presta especial atención a estos patrones:

• Intentos repetidos de conexión a puertos cerrados (escaneo de puertos)
• Intentos de conexión desde ubicaciones geográficas inusuales
• Volúmenes de tráfico o temporización fuera de lo normal
• Servicios legítimos que están siendo bloqueados (lo que indica que hay que corregir las reglas)

Las implementaciones maduras suelen enviar los logs del firewall a un SIEM o agregador de logs como el stack ELK, Splunk o un servicio de logging nativo en la nube. Configura alertas automatizadas para patrones sospechosos —por ejemplo, 100 intentos SSH en un minuto— para poder responder antes de que algo se rompa.

Pruebas y Validación

Nunca des por sentado que tu firewall funciona como esperas. Prueba desde fuera de tu red usando una conexión separada o una VM en la nube. La herramienta nmap escanea puertos abiertos