Las buenas prácticas para las reglas de firewall van mucho más allá de bloquear tráfico malicioso: se trata de escribir reglas lo suficientemente precisas para detener a los atacantes sin romper los servicios que tu equipo usa a diario. La mayoría de los errores de configuración siguen patrones predecibles: reglas demasiado amplias, tráfico de salida completamente descontrolado, o políticas de permitir-todo que eran "temporales" y nunca se cambiaron. Esta guía repasa los errores reales que cometen administradores de sistemas y desarrolladores, y los valores por defecto más inteligentes que los reemplazan.
Tabla de contenidos
Reglas de entrada y salida explicadas
Todo firewall evalúa el tráfico en dos direcciones, y tratarlas como una sola preocupación es donde muchos equipos se equivocan.
Las reglas de entrada (inbound) controlan el tráfico que llega a tu servidor o red desde el exterior. Cuando alguien se conecta a tu servidor web en el puerto 80 o 443, eso es tráfico de entrada. Cuando un atacante sondea el puerto 22 buscando un acceso SSH, también es tráfico de entrada. Tus reglas de entrada deciden si esas conexiones pasan o no.
Las reglas de salida (outbound) controlan el tráfico que sale de tu servidor. Un servidor comprometido comunicándose con un host de comando y control, una aplicación mal configurada filtrando datos hacia un endpoint externo, o un contenedor descargando paquetes desde un registro inesperado: todo eso es tráfico de salida. La mayoría de los equipos configuran la entrada con cuidado y dejan la salida completamente abierta, lo cual es un error grave.
En entornos cloud como AWS Security Groups, las reglas de entrada y salida se configuran por separado. En Linux
iptables
o
nftables
, se corresponden con las cadenas INPUT y OUTPUT. En Windows Firewall, aparecen literalmente etiquetadas como "Reglas de entrada" y "Reglas de salida" en la interfaz gráfica. El concepto es universal; la implementación varía según la plataforma.
Errores comunes de configuración de firewall
1. Permitir 0.0.0.0/0 en puertos sensibles
Este es el patrón más peligroso en la configuración de un firewall. Permitir que todo internet llegue a puertos como estos es buscar problemas:
| Puerto | Servicio | Riesgo de 0.0.0.0/0 |
|---|---|---|
| 22 | SSH | Ataques de fuerza bruta, relleno de credenciales, explotación de vulnerabilidades SSH |
| 3306 | MySQL | Intentos de acceso directo a la base de datos, inyección SQL a nivel de red, exfiltración de datos |
| 5432 | PostgreSQL | Igual que MySQL - los puertos de bases de datos públicas son escaneados constantemente por herramientas automatizadas |
| 27017 | MongoDB | Históricamente responsable de filtraciones masivas de datos cuando se dejó abierto sin autenticación |
| 3389 | RDP | Vector de distribución de ransomware, fuerza bruta, exploits tipo BlueKeep |
El caso de MongoDB merece una mención especial. Decenas de miles de bases de datos fueron borradas y retenidas como rehenes entre 2017 y 2019 porque las instancias de MongoDB eran accesibles públicamente sin ningún tipo de autenticación. El comprobador de listas negras de IP es un recordatorio útil de que monitorizar la exposición importa, porque "nadie lo va a encontrar" no es una estrategia de seguridad.
2. Ignorar el tráfico de salida (egress)
Dejar el tráfico de salida completamente sin restricciones significa que un host comprometido puede comunicarse libremente con la infraestructura del atacante, exfiltrar datos o participar en una botnet. Un servidor que ejecuta una aplicación web no tiene ninguna razón legítima para iniciar conexiones salientes hacia IPs arbitrarias en puertos arbitrarios. Restringir el egress únicamente a lo necesario - tu resolver DNS, tu repositorio de paquetes, tus endpoints de API - limita drásticamente lo que un atacante puede hacer incluso después de obtener acceso.
3. Errores en el orden de las reglas
Considera esta configuración de iptables:
# BAD: This allow-all rule fires first
-A INPUT -j ACCEPT
-A INPUT -s 203.0.113.0/24 -p tcp --dport 22 -j DROPLa regla DROP para SSH desde esa subred es completamente inútil porque cada paquete llega primero a la regla ACCEPT. La solución es colocar las reglas específicas antes que las generales, y poner la denegación por defecto al final.
4. Rangos de puertos demasiado amplios
Reglas como "permitir TCP 1024-65535 de entrada" son comunes en configuraciones heredadas y prácticamente no tienen valor como control de seguridad. Si tu aplicación usa el puerto 8080, escribe una regla para el puerto 8080. Si necesitas un rango para FTP pasivo, documenta exactamente qué rango tiene configurado tu servidor y restringe a ese. Los rangos amplios existen porque alguien no quiso buscar el puerto correcto, no porque fueran necesarios.
5. Dejar las reglas de permitir-todo por defecto
Los proveedores cloud suelen tener reglas permisivas por defecto durante el aprovisionamiento. El grupo de seguridad predeterminado de AWS permite todo el tráfico de salida. Las nuevas máquinas virtuales de Azure reciben una regla de entrada "AllowAzureLoadBalancerInBound" que está bien, pero la regla de salida por defecto permite todo. Estos valores predeterminados están diseñados para empezar rápido, no para producción. En el momento en que muevas una carga de trabajo a producción, revisa y ajusta cada regla por defecto.
6. Sin registro en las reglas de denegación
Un firewall que descarta tráfico silenciosamente no te dice nada. Sin registro en tus reglas de denegación, no puedes distinguir entre un atacante sondeando tus puertos y un servicio legítimo mal configurado. Habilita el registro al menos en tus reglas de denegación por defecto para tener una línea base de lo que se está bloqueando.
Valores por defecto más inteligentes que realmente funcionan
La siguiente estructura de política de seguridad de red funciona en la mayoría de los entornos y te da un punto de partida sólido que puedes ajustar, en lugar de un desorden permisivo que tienes que limpiar.
Reglas de entrada
- Por defecto: DENEGAR todo el tráfico de entrada. Empieza sin permitir nada y abre explícitamente solo lo necesario.
- Puerto 80 (HTTP) y 443 (HTTPS): Permite desde 0.0.0.0/0 solo si es un servidor web de acceso público. Si es solo interno, restringe a tu rango de IPs internas.
- Puerto 22 (SSH): Permite ÚNICAMENTE desde direcciones IP específicas o bloques CIDR - la IP de tu oficina, el nodo de salida de tu VPN, tu bastion host. Nunca desde 0.0.0.0/0.
- Puerto 3389 (RDP): Igual que SSH - solo IPs específicas, o mejor aún, ponlo detrás de una VPN y no lo expongas a internet en absoluto.
- Puerto 3306 (MySQL) y 5432 (PostgreSQL): Permite solo desde las IPs privadas de tus servidores de aplicación. Estos puertos nunca deben ser accesibles desde internet público.
- ICMP (ping): Permite desde rangos de confianza para diagnósticos. Bloquearlo por completo complica la resolución de problemas sin un beneficio de seguridad significativo.
Reglas de salida
- Puerto 53 (DNS): Permite solo hacia tus resolvers DNS designados (por ejemplo, el resolver interno de tu VPC o una IP específica como 1.1.1.1).
- Puerto 80 y 443: Permite hacia destinos conocidos - tus repositorios de paquetes, tus APIs, tu CDN. Si puedes enumerarlos, hazlo.
- Puerto 25 (SMTP): Bloquea el SMTP de salida a menos que este servidor sea explícitamente un servidor de correo. Un servidor comprometido enviando spam es un indicador habitual de una brecha de seguridad.
- Todo lo demás: DENEGAR por defecto.
Aquí tienes un ejemplo mínimo de iptables que aplica este enfoque para un servidor web:
# Flush existing rules
iptables -F
# Default policies: deny all inbound and outbound
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Allow established/related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Inbound: HTTP and HTTPS from anywhere (public web server)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Inbound: SSH only from your office IP
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.50 -j ACCEPT
# Outbound: DNS to internal resolver
iptables -A OUTPUT -p udp --dport 53 -d 10.0.0.2 -j ACCEPT
# Outbound: HTTPS for package updates
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
# Log dropped inbound packets
iptables -A INPUT -j LOG --log-prefix "DROPPED-IN: " --log-level 4Para entender con más profundidad cómo funciona el filtrado de puertos a nivel de protocolo, la especificación TCP en RFC 793 explica exactamente qué ocurre durante el establecimiento de una conexión, que es precisamente lo que tu firewall intercepta al evaluar las reglas contra los paquetes de entrada.
Reglas separadas para Dev, Staging y Prod
Uno de los hábitos más infravalorados en la configuración de firewalls es tratar cada entorno como algo distinto, con su propio conjunto de reglas. Usar el mismo grupo de seguridad o política de firewall en dev y prod es la razón por la que los puertos de depuración "temporales" terminan expuestos en producción.
Una forma práctica de estructurarlo:
- Dev: Entrada más permisiva desde el rango de IPs de tu equipo. Puertos 8080, 8443 y otros puertos de desarrollo abiertos. Puertos de base de datos accesibles desde las máquinas de los desarrolladores. Registro opcional.
- Staging: Replica las reglas de prod lo más fielmente posible. El objetivo es detectar problemas relacionados con el firewall antes de que lleguen a producción. Añade acceso para las IPs de tu equipo de QA.
- Prod: Las reglas más estrictas. Sin puertos de depuración. Sin acceso directo a la base de datos desde fuera de la subred privada. Todas las reglas de denegación con registro habilitado. SSH restringido a un bastion host o VPN únicamente.
Etiqueta tus reglas de firewall con el entorno al que pertenecen. En AWS, usa etiquetas de recurso en los grupos de seguridad. En Terraform u otras herramientas de IaC, usa conjuntos de reglas basados en variables para que las reglas de dev y prod compartan la misma estructura pero con valores diferentes. Esto facilita enormemente las auditorías.
También puedes usar nuestra herramienta de ping para verificar rápidamente si un host en un entorno determinado es accesible a nivel de red antes de realizar comprobaciones específicas de puertos.
Verifica qué está realmente expuesto
Escribir reglas de firewall es solo la mitad del trabajo. La otra mitad es confirmar que lo que pretendías bloquear está realmente bloqueado, y que lo que pretendías permitir es realmente accesible. Aquí es donde muchos equipos se saltan un paso y despliegan sistemas mal configurados.
Después de aplicar cualquier cambio en tu configuración de firewall, ejecuta una comprobación de puertos externa desde fuera de tu red. Esto simula lo que vería un atacante, no lo que tu monitorización interna cree que está expuesto.
Cosas que comprobar después de cada cambio en el firewall:
- Puerto 22 (SSH): Debe aparecer como CERRADO o TIMEOUT desde cualquier IP que no esté en tu lista de permitidos.
- Puerto 3306 (MySQL) y 5432 (PostgreSQL): Nunca deben aparecer como ABIERTOS desde internet público.
- Puerto 3389 (RDP): Debe estar CERRADO o en TIMEOUT a menos que lo hayas expuesto deliberadamente con restricciones de IP.
- Puerto 80 y 443: Deben estar ABIERTOS en los servidores web de acceso público.
- Cualquier puerto de aplicación personalizado: Verifica que coincida con tu intención - abierto donde sea necesario, cerrado en todo lo demás.
También puedes usar nuestra herramienta de consulta DNS para confirmar que el nombre de host que estás probando resuelve a la IP que esperas antes de ejecutar comprobaciones de puertos, algo muy útil cuando trabajas con entornos donde los registros DNS y las IPs reales de los servidores no siempre coinciden.
Descubre exactamente qué puertos están expuestos tras aplicar tus reglas de firewall
Usa nuestro comprobador de puertos gratuito para verificar si SSH (22), RDP (3389), MySQL (3306), PostgreSQL (5432) y otros puertos sensibles están realmente abiertos o cerrados desde el exterior, para confirmar que tus reglas de firewall funcionan como pretendías, no solo que están escritas correctamente.
Comprueba tus puertos abiertos →
Los AWS Security Groups son esencialmente firewalls con seguimiento de estado (stateful) asociados a instancias EC2 u otros recursos. Funcionan con el mismo principio de reglas de entrada y salida, pero son stateful por defecto, lo que significa que si permites tráfico de entrada en el puerto 443, el tráfico de respuesta se permite automáticamente en la salida sin necesidad de una regla adicional. Los firewalls stateless tradicionales como iptables requieren reglas explícitas en ambas direcciones para cada conexión, a menos que uses seguimiento de conexiones (conntrack). Los Security Groups tampoco admiten reglas de denegación explícita: solo puedes permitir tráfico, y todo lo que no esté explícitamente permitido se deniega.
Bloquear ICMP por completo suele generar más problemas de los que resuelve. El ping se usa para diagnósticos legítimos, y ICMP también transporta mensajes de Path MTU Discovery que afectan al rendimiento de TCP. Un enfoque mejor es permitir ICMP desde rangos de IP de confianza (tu equipo, tu sistema de monitorización) y bloquearlo desde 0.0.0.0/0. Así mantienes tu servidor fuera de los escáneres casuales de internet sin perder capacidad de diagnóstico. Bloquear ICMP no oculta de forma significativa un servidor ante atacantes determinados: los escaneos TCP SYN funcionan perfectamente sin respuestas de ping.
Antes de aplicar cualquier regla de restricción de SSH, verifica que tienes un método de acceso alternativo: acceso por consola cloud (AWS EC2 Instance Connect, GCP Cloud Shell, Azure Serial Console), una consola física o una interfaz de gestión fuera de banda. Luego añade tu regla de permiso para la IP específica en el puerto 22 antes de aplicar la denegación por defecto. Prueba la nueva regla en una sesión de terminal separada antes de cerrar tu conexión actual. Si tu IP es dinámica, considera usar una VPN con una IP de salida estática en lugar de permitir directamente tu IP doméstica.
MySQL (3306) y PostgreSQL (5432) son escaneados constantemente por herramientas automatizadas que buscan bases de datos expuestas. Incluso con contraseñas robustas, la exposición pública crea una superficie de ataque innecesaria: bypasses de autenticación, vulnerabilidades zero-day y ataques de fuerza bruta sobre credenciales se convierten en vectores de ataque viables. Las bases de datos solo deben ser accesibles desde las IPs privadas de tus servidores de aplicación, nunca desde internet público. Si necesitas acceso remoto a la base de datos para administración, rútalo a través de una VPN o un túnel SSH en lugar de abrir el puerto de la base de datos públicamente.
Como mínimo, audita las reglas de firewall trimestralmente y después de cada cambio significativo en la infraestructura: nuevos servicios desplegados, salida de miembros del equipo (sus IPs permitidas deben eliminarse), cambios de arquitectura o incidentes de seguridad. Las herramientas automatizadas pueden ayudar: AWS Config puede alertar sobre cambios en los grupos de seguridad, y herramientas como la detección de drift de estado en Terraform detectan cambios manuales no autorizados. Ejecuta también una comprobación de puertos externa después de cada auditoría para verificar que las reglas coinciden con la realidad. Las reglas que parecen correctas en un archivo de configuración no siempre se comportan como se espera tras interacciones complejas entre reglas.
En Kubernetes y entornos de contenedores, las políticas de red reemplazan las reglas de firewall tradicionales para el tráfico este-oeste (entre servicios). Los recursos NetworkPolicy de Kubernetes te permiten definir qué pods pueden comunicarse con cuáles y en qué puertos. Para el tráfico norte-sur (externo al clúster), se aplican los grupos de seguridad del balanceador de carga del proveedor cloud o las reglas del controlador de ingress. El principio clave es el mismo: denegación por defecto, permiso explícito. Herramientas como Calico o Cilium ofrecen una aplicación de políticas de red más granular que la implementación predeterminada de Kubernetes.