El cortafuegos (firewall) sigue siendo la primera línea de defensa perimetral de cualquier infraestructura conectada a Internet, pero su papel ha cambiado profundamente. Ya no basta con un filtro de paquetes que decide por dirección IP y puerto: la superficie de ataque actual exige inspección de estado, control de aplicaciones de capa 7, protección frente a denegación de servicio y un modelo de confianza cero. En esta guía técnica desarrollamos cómo diseñar reglas de ingress y egress robustas, cuándo añadir un WAF y cómo orquestar la mitigación de DDoS sin estrangular el tráfico legítimo.
Tipos de firewall y la pila de filtrado
Un cortafuegos opera en una o varias capas del modelo OSI, y entender cuál protege qué evita configuraciones redundantes o, peor, agujeros silenciosos. El filtrado de paquetes sin estado (capas 3 y 4) decide únicamente por cabeceras IP/TCP/UDP; es rápido pero ciego al contexto de la conexión. El firewall con estado (stateful) mantiene una tabla de conexiones (conntrack en Linux) y solo admite paquetes que pertenezcan a sesiones establecidas o relacionadas, lo que neutraliza la mayoría del spoofing trivial.
Por encima encontramos el firewall de nueva generación (NGFW), que añade inspección profunda de paquetes (DPI), identificación de aplicación independiente del puerto y, a menudo, IPS integrado. Finalmente, el Web Application Firewall (WAF) trabaja exclusivamente en capa 7 sobre HTTP/HTTPS y entiende parámetros, cabeceras y cuerpos de petición. Un error frecuente es esperar que un NGFW detenga una inyección SQL: el tráfico va cifrado en TLS y, sin terminación ni descifrado, el NGFW solo ve un flujo opaco. Esa función corresponde al WAF.
Diseño de reglas de ingress: política de denegación por defecto
La regla de oro es default deny: todo lo que no esté explícitamente permitido se bloquea. En la práctica esto significa cerrar la cadena INPUT y abrir solo lo imprescindible. Un esqueleto típico con nftables sería:
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
iif "lo" accept
ct state invalid drop
tcp dport 22 ip saddr 203.0.113.0/24 accept # SSH solo desde la VPN corporativa
tcp dport { 80, 443 } accept # tráfico web público
ip protocol icmp icmp type echo-request limit rate 5/second accept
}
}Los principios que sostienen esta configuración son tres. Primero, mínimo privilegio: SSH no se expone a 0.0.0.0/0 sino al rango de la VPN. Segundo, orden de evaluación: las reglas se evalúan secuencialmente, así que las de mayor frecuencia (conexiones establecidas) van arriba para reducir el coste de CPU. Tercero, limitación de tasa sobre ICMP y nuevos SYN para amortiguar barridos y floods. Documentar cada regla con su justificación de negocio es lo que diferencia una política mantenible de un amasijo que nadie se atreve a tocar dos años después.
Egress filtering: el control que casi nadie configura
La mayoría de las organizaciones filtra el tráfico entrante y deja la salida completamente abierta. Es un fallo grave: el filtrado de egress es lo que corta la cadena de un ataque ya en curso. Un servidor comprometido necesita comunicarse con su servidor de mando y control (C2), exfiltrar datos o descargar la segunda fase del malware; si la salida está restringida a los destinos y puertos legítimos, el atacante queda contenido.
Una política de egress razonable para un servidor de aplicaciones permite DNS solo hacia los resolutores internos, HTTPS hacia el repositorio de paquetes y la API del proveedor cloud, y NTP hacia las fuentes autorizadas; todo lo demás se descarta y se registra. Bloquear conexiones salientes a puertos como 6667 (IRC, clásico de botnets) o el tráfico TCP/53 no esperado revela tunneling de DNS. El egress filtering también ayuda a cumplir el principio de minimización de la norma ISO/IEC 27001 en su control de seguridad de las comunicaciones (A.8.20 y siguientes del Anexo A de la revisión 2022).
WAF: protección de la capa de aplicación
El WAF inspecciona cada petición HTTP contra un conjunto de reglas. El estándar de facto en el mundo abierto es el OWASP Core Rule Set (CRS), mantenido por la OWASP Foundation, que cubre las categorías del OWASP Top 10: inyección, cross-site scripting, deserialización insegura, etc. El CRS funciona con un modelo de puntuación de anomalías (anomaly scoring): cada coincidencia suma puntos y, al superar un umbral, la petición se bloquea. Esto reduce los falsos positivos frente al bloqueo regla a regla.
El despliegue de un WAF debe pasar siempre por una fase de modo detección (paranoia level bajo, solo log) antes de activar el bloqueo. Activar el CRS directamente en producción con paranoia level 4 garantiza tickets de soporte el primer día porque legítimas peticiones con caracteres especiales se rechazan. El flujo correcto es: desplegar en detección, recoger una semana de tráfico real, afinar exclusiones por endpoint, y solo entonces pasar a bloqueo progresivo subiendo el nivel de paranoia.
Mitigación de DDoS por capas
Un firewall por sí solo no detiene un ataque volumétrico que satura el enlace antes de llegar a tu regla. La defensa frente a DDoS se organiza por la capa atacada. Los ataques volumétricos (UDP flood, amplificación NTP/DNS/memcached) se mitigan aguas arriba, en el proveedor o en un servicio de scrubbing con capacidad de absorción medida en Tbps. Los ataques de protocolo (SYN flood, Ping of Death) se contienen con SYN cookies, límites de conexiones por origen y la tabla de estado del propio firewall. Los ataques de capa de aplicación (HTTP flood, Slowloris) requieren el WAF, rate limiting por sesión y desafíos JavaScript o CAPTCHA.
La INCIBE recomienda combinar protección distribuida en el borde con planes de respuesta documentados, porque ninguna defensa única cubre el espectro completo. Un patrón eficaz es declarar umbrales de tasa: por ejemplo, máximo 100 nuevas conexiones por segundo por IP, con escalado automático a modo de desafío cuando se superan.
Segmentación de red y el modelo de confianza cero
El perímetro tradicional, donde todo lo de dentro se consideraba de confianza y todo lo de fuera no, ha muerto con la nube híbrida y el teletrabajo. El modelo Zero Trust parte de un principio distinto: nunca confiar, siempre verificar. Cada petición, venga de donde venga, se autentica y autoriza como si procediera de una red hostil. El cortafuegos sigue siendo pieza clave, pero su lógica cambia: deja de proteger un único perímetro para hacer cumplir microsegmentación entre cargas de trabajo.
La microsegmentación divide la red en zonas pequeñas con políticas estrictas entre ellas. Un servidor web de la zona desmilitarizada (DMZ) puede hablar con el servidor de aplicaciones por el puerto 8080, pero no directamente con la base de datos; solo el servidor de aplicaciones llega a la base de datos por el puerto 5432. Si el servidor web se compromete, el atacante no puede saltar lateralmente a la base de datos porque la regla east-west lo impide. Esta defensa contra el movimiento lateral es lo que limita el alcance de una intrusión, y es uno de los pilares que recoge el marco de ciberseguridad del NIST y los controles de la familia ISO/IEC 27000 sobre segregación en las redes.
Implementar microsegmentación con un firewall de host (nftables, Windows Filtering Platform) o con políticas de red en orquestadores de contenedores permite aplicar la regla del mínimo privilegio a nivel de proceso, no solo de subred. El coste es la complejidad operativa: mantener cientos de reglas east-west exige automatización e infraestructura como código para que la política sea versionada, revisable y reproducible.
Registro, correlación y respuesta
Un cortafuegos sin registro es un guardia que no toma notas. Cada decisión relevante —especialmente los descartes— debe enviarse a un sistema centralizado de gestión de eventos de seguridad (SIEM), donde se correlaciona con otras fuentes. Un único intento de conexión bloqueado no significa nada; cien intentos desde la misma IP a cien puertos distintos en un minuto es un escaneo de puertos que merece alerta. La correlación es lo que convierte ruido en inteligencia accionable.
Los registros deben incluir marca de tiempo sincronizada por NTP, IP de origen y destino, puerto, protocolo, regla aplicada y acción. Para cumplir con las obligaciones de trazabilidad y conservación de evidencias, conviene definir una política de retención coherente con los requisitos legales y con la guía de la INCIBE sobre gestión de incidentes. La integración del firewall con el SIEM cierra el bucle: detección, alerta y, en arquitecturas maduras, respuesta automatizada que actualiza dinámicamente las reglas para bloquear una IP ofensora durante un ataque en curso.
Tabla comparativa: dónde actúa cada control
| Control | Capa OSI | Detiene | No detiene |
|---|---|---|---|
| Filtro de paquetes | 3-4 | IP/puerto no autorizados | Ataques de aplicación |
| Firewall stateful | 3-4 | Paquetes fuera de sesión, spoofing | Payloads maliciosos válidos |
| NGFW / IPS | 3-7 | Firmas conocidas, apps no deseadas | Tráfico cifrado sin terminación |
| WAF | 7 | Inyección, XSS, HTTP flood | Ataques volumétricos de red |
| Scrubbing upstream | 3-4 | DDoS volumétrico (Tbps) | Lógica de negocio |
Errores comunes en la configuración
El primero es la regla "permitir todo" temporal que se queda para siempre: una entrada de diagnóstico que abre un puerto a 0.0.0.0/0 y nadie revierte. El segundo es confiar solo en la IP de origen para autenticar, ignorando que se puede falsear o proceder de un proxy. El tercero es no registrar los descartes: sin logs de las reglas drop es imposible investigar un incidente. El cuarto es el WAF en modo monitor permanente que detecta pero nunca bloquea. Y el quinto, dejar el plano de gestión (interfaz de administración del firewall) accesible desde Internet en lugar de una red de gestión aislada.
Preguntas frecuentes
¿Un firewall stateful sustituye a un WAF? No. Operan en capas distintas. El stateful valida que la conexión sea legítima a nivel de red y transporte; el WAF analiza el contenido HTTP. Una inyección SQL viaja dentro de una conexión TCP perfectamente válida, así que el stateful la deja pasar y solo el WAF la detiene.
¿Hace falta filtrar la salida si ya filtro la entrada? Sí, son objetivos diferentes. El ingress evita intrusiones; el egress contiene un equipo ya comprometido e impide la exfiltración y la comunicación con servidores C2. Es un requisito habitual en auditorías de ISO/IEC 27001 y marcos de cumplimiento.
¿Conviene terminar TLS en el firewall para inspeccionar? Depende. La terminación permite que el WAF vea el contenido, pero introduce un punto donde el tráfico viaja descifrado y obliga a gestionar certificados con rigor. En entornos con datos personales hay que valorar el impacto frente al RGPD y documentar el tratamiento.
¿Cada cuánto se revisan las reglas? Al menos trimestralmente, y siempre tras cambios de arquitectura. Las revisiones detectan reglas obsoletas, solapamientos y permisos demasiado amplios que se acumulan con el tiempo.
Conclusión
Configurar un cortafuegos hoy no es escribir una lista de puertos abiertos, sino orquestar una defensa en capas donde cada control hace lo que sabe hacer: el firewall stateful valida la sesión, el egress filtering contiene la fuga, el WAF protege la aplicación y el scrubbing upstream absorbe el volumen. El factor que decide el resultado no es la tecnología, sino la disciplina operativa: política de denegación por defecto, registro exhaustivo de descartes, despliegue del WAF en detección antes de bloqueo y revisiones periódicas que poden las reglas muertas. Un firewall bien gobernado es transparente para el usuario legítimo y un muro infranqueable para el resto. En Summum Marketing diseñamos e implantamos estas políticas adaptadas a cada arquitectura, midiendo siempre el impacto sobre el tráfico real antes de pasar a producción.