Seguridad con 2 tipos de firewall diferentes: ¿por qué?

Dos firewalls, dos capas: uno frena tráfico y segmenta la red; el WAF protege webs y APIs frente a bots e inyecciones con trazabilidad real.

La seguridad con 2 tipos de firewall diferentes funciona cuando cada uno vigila una parte distinta del problema: un firewall de red (perimetral o de nueva generación) decide qué tráfico puede entrar o moverse por la infraestructura, y un WAF (firewall de aplicaciones web) entiende lo que ocurre dentro de una petición web, ahí donde suelen esconderse los ataques “educados”, los que viajan por HTTPS como si fueran normales. La combinación no va de duplicar barreras, va de cubrir huecos distintos con criterio.

En la práctica, el primer cortafuegos recorta superficie, frena exploraciones, limita conexiones raras y ordena la circulación entre zonas; el segundo se coloca delante de webs, paneles y APIs para detectar patrones de abuso, intentos de inyección, bots y trampas que un filtro de red no ve o no debería intentar ver. Cuando se habla de seguridad en entornos conectados, lo que da ventaja no es “tener un firewall”, sino tener dos que se entiendan y que dejen rastro útil cuando algo se tuerce.

Dos firewalls, dos capas: qué se gana y qué se pierde

La confusión suele empezar por el nombre. “Firewall” se usa para todo, como si fuera una manta que tapa cualquier frío, y luego llegan los golpes: un ataque que entra por tráfico permitido, una web que cae por peticiones legítimas en apariencia, un panel que se expone sin querer, una API que se usa como pasillo trasero. Con dos tipos de firewall diferentes se gana una cosa muy concreta: mirada doble sobre el mismo trayecto, desde el borde de la red hasta la capa donde se toman decisiones de negocio.

El firewall de red trabaja como control de acceso y como urbanismo: define zonas, carriles, límites, y corta lo que no encaja con la política. El WAF trabaja como intérprete y detector de intenciones: analiza rutas, parámetros, cabeceras, cookies, cuerpos de petición; distingue lo raro de lo habitual y, si está bien afinado, frena ataques que parecen una visita más. No es una metáfora bonita, es un reparto de tareas que encaja con cómo se ataca hoy: mucho automatismo, mucha prueba y error, y mucha explotación de puntos blandos en aplicaciones.

También se pierde algo si se hace mal, y conviene decirlo sin rodeos: se pierde tiempo, se pierde rendimiento y se pierde paz cuando se instalan dos capas sin diseño. Un WAF mal afinado bloquea tráfico legítimo y genera falsos positivos que desesperan; un firewall de red con reglas heredadas y excepciones eternas termina siendo un colador con buenas intenciones. La gracia está en que cada uno haga lo suyo, y lo haga con registro, coherencia y límites claros.

Hay otro punto que no se suele contar en voz alta: dos firewalls distintos obligan a elegir qué se considera “normal”. Esa decisión, que suena filosófica pero es pura operación, marca la diferencia entre seguridad útil y seguridad de escaparate. En cuanto se define qué servicios existen, qué rutas web son válidas, qué integraciones llaman a qué endpoints, qué IPs necesitan acceso y cuáles no, aparece una ventaja real: el ataque deja de ser un susto abstracto y se convierte en señales medibles.

Firewall de red: el filtro grueso que ordena la casa

Un firewall de red decide sobre tráfico a nivel de conexiones y flujos: quién habla con quién, por qué puerto, con qué protocolo, durante cuánto tiempo, a qué velocidad, con qué patrón. Puede estar en el perímetro, separando internet de la red interna, pero su papel más útil muchas veces está dentro, cortando caminos entre zonas. Esa idea de “todo dentro es confianza” hace tiempo que cruje; un cortafuegos bien puesto entre segmentos reduce el clásico desastre del movimiento lateral, cuando una intrusión pequeña se convierte en un paseo turístico por servidores y servicios.

En una red real aparecen enseguida los ingredientes que un firewall de red maneja mejor que nadie: NAT, reglas por zonas, políticas para VPN, control de salidas (egress) para evitar que un sistema comprometido “llame a casa”, límites de conexiones por segundo, bloqueo de escaneos, filtrado por reputación, detección de patrones típicos de intrusión en red, y un largo etcétera que, bien aplicado, hace que el atacante tenga que trabajar más. Aquí hay un detalle que separa un despliegue serio de uno decorativo: no basta con permitir entradas; hay que vigilar y limitar también las salidas, porque muchas brechas se consolidan cuando el sistema ya dentro empieza a comunicarse fuera sin control.

La segmentación, dicho sin pompa, es poner puertas interiores. No tiene sentido que un equipo de oficina pueda hablar libremente con un servidor de bases de datos, ni que un dispositivo IoT tenga acceso a servicios críticos, ni que un entorno de pruebas tenga autopista hacia producción. Un firewall de red permite dibujar esas fronteras con reglas comprensibles y auditables. Cuando ocurre un incidente, esa separación es oro: lo que no puede hablar, no puede propagarse.

El cifrado añade la tensión de siempre. Con HTTPS todo viaja protegido, y eso es bueno, pero al firewall de red le quita visibilidad. Para recuperar parte de esa visión existe la inspección TLS (desencriptar y reencriptar), que puede aportar detección y control, pero también introduce problemas: certificados, compatibilidades, carga de CPU, latencia, y discusiones internas porque no todo el tráfico debería inspeccionarse igual. Un despliegue responsable separa lo que se inspecciona de lo que no, define excepciones justificadas y mide el impacto; cuando no se hace, la inspección acaba desactivada “temporalmente” y ese temporal se vuelve permanente. La seguridad, otra vez, no falla por falta de tecnología, falla por operación y disciplina.

Stateful y NGFW sin humo

Un firewall “stateful” clásico entiende el estado de una conexión y filtra con más inteligencia que un simple cortafuegos basado en reglas estáticas. Permite, por ejemplo, bloquear tráfico no solicitado o incoherente con una sesión legítima, y eso ya corta mucho ruido. Un NGFW (firewall de nueva generación) añade capacidades que suelen ser decisivas en entornos modernos: inspección más profunda, detección de intrusiones, control por aplicación, integración con identidad, análisis de amenazas, políticas más expresivas. No convierte la red en invulnerable, pero sí vuelve más difícil la vida al atacante oportunista y al automatizado.

La diferencia práctica se nota en escenas concretas. Un firewall básico puede dejar pasar tráfico “permitido” aunque sea claramente anómalo en volumen o patrón; un NGFW puede reconocer que, aunque el puerto sea el habitual, el comportamiento parece un ataque de fuerza bruta, un escaneo o un intento de evasión. También ayuda a cortar el clásico “todo por el puerto 443”, esa costumbre de encapsular de todo en HTTPS para que parezca inocuo. Y aun así, conviene mantener una idea clara: la capa de red filtra el camino, pero no entiende de verdad la lógica de una aplicación. Ahí es donde entra el segundo protagonista.

WAF: el filtro fino que entiende la web

Un WAF (Web Application Firewall) está diseñado para proteger aplicaciones web y APIs analizando el contenido de las peticiones y respuestas. No mira solo “de dónde viene” el tráfico, mira qué trae dentro: parámetros sospechosos, cadenas típicas de inyección, scripts ocultos, rutas imposibles, cabeceras manipuladas, sesiones con comportamiento extraño, bots que hacen clic a velocidad inhumana. Es una defensa pensada para un mundo donde el ataque más rentable no es tirar una puerta, sino colarse por una rendija y salir con datos.

Los ataques más comunes que un WAF detecta tienen nombres que ya son parte del paisaje: inyección SQL, XSS, traversal de rutas, inclusión de archivos, ejecución de código, manipulación de cookies, abuso de formularios, intentos de saltarse autenticación, y, cada vez más, abuso de APIs mediante llamadas repetidas, enumeración de recursos y explotación de endpoints poco vigilados. La clave no está en memorizar el catálogo, sino en entender lo que comparten: son ataques que viajan en tráfico permitido, con apariencia de normalidad. Una conexión a la web, un POST al login, una búsqueda, un carrito… y dentro, la intención.

Un WAF no solo bloquea; también hace algo muy periodístico, si se quiere llamar así: deja constancia. Registra qué se intentó, desde dónde, con qué patrón, contra qué ruta, con qué respuesta. Cuando un incidente se investiga, esos registros son los que permiten reconstruir la secuencia: primero probaron tal endpoint, luego insistieron en tal parámetro, después cambiaron de IP, luego subieron el ritmo. Sin esa trazabilidad, todo queda en un “algo pasó” que no sirve para corregir.

Hay varias formas de desplegar un WAF, y eso cambia su eficacia. Puede vivir en un proxy inverso, en un balanceador, integrado en un gateway de API, en un CDN o como servicio gestionado. En el borde suele frenar bots y ataques masivos antes de que toquen infraestructura; cerca de la aplicación puede entender mejor rutas internas y reglas específicas. En arquitecturas modernas aparece otra vuelta: WAF delante de servicios concretos, con reglas por microservicio, y controles de rate limiting por endpoint. No suena romántico, pero reduce el daño cuando alguien encuentra una ruta olvidada y decide explotarla con paciencia.

Aquí hay un riesgo silencioso: pensar que el WAF es una excusa para no corregir vulnerabilidades. El WAF ayuda como parche virtual, puede mitigar mientras se arregla el código, pero no reemplaza el arreglo. Si una aplicación tiene una vulnerabilidad seria y se confía todo a reglas, el día que el atacante encuentre una variación que evade la firma, la caída es más dura. El WAF es capa, no muleta.

Cuando bloquear bien es difícil

El WAF vive con un enemigo cotidiano: el falso positivo. Bloquear un ataque claro es relativamente fácil; bloquear sin romper tráfico legítimo es lo que cuesta. Por eso los despliegues sensatos arrancan observando, afinando y luego endureciendo. Un WAF con reglas genéricas puede confundir comportamiento raro con malicia, especialmente en aplicaciones con formularios complejos, parámetros libres o integraciones que no siguen patrones “bonitos”. Y cuando un WAF rompe el negocio, lo primero que ocurre casi siempre es que alguien pide “bajar la seguridad” a lo bruto, desactivar reglas, abrir excepciones amplias. Ese es el momento delicado: o se gobierna con método, o se vuelve a la casilla de salida.

En la afinación entran cosas muy terrenales: definir qué rutas son públicas y cuáles no, limitar métodos HTTP donde no hacen falta, poner umbrales de velocidad por endpoint, distinguir tráfico humano de automatizado, controlar el abuso de credenciales filtradas, detectar enumeraciones de recursos, frenar scraping agresivo. Un WAF que entiende la API como primera clase —no como “otra web”— suele marcar diferencia, porque muchas aplicaciones ya son, en realidad, un conjunto de APIs con un frontal. Si el WAF solo protege “la página”, pero la API es accesible y poco vigilada, el atacante entra por donde hay menos ruido.

La elección entre WAF gestionado y WAF operado internamente también es un hecho, no una moda. Un servicio gestionado puede mitigar rápido ataques voluminosos y ofrecer inteligencia colectiva frente a bots; un WAF interno da control fino y puede integrarse con particularidades de la aplicación. Ninguna opción es “la buena” por defecto. Lo que sí es universal es que, sin operación constante, el WAF envejece: reglas sin revisar, rutas nuevas sin protección, endpoints que aparecen y nadie incorpora al modelo. En seguridad, lo que no se mantiene se convierte en pasado.

La combinación en la práctica: escenarios, límites y mantenimiento

La teoría suena limpia: firewall de red filtra, WAF protege la aplicación. La práctica tiene barro, y ese barro importa. En una pyme con pocos servicios expuestos, el firewall de red suele ser el primer salto serio: dejar de depender de un equipo básico, definir VPN con políticas, separar al menos usuarios de servidores, controlar salidas. En cuanto hay una web con formulario, un panel de gestión o una tienda, el WAF pasa de “sería bonito” a “tiene sentido”, porque la exposición pública atrae automatismos. No hace falta ser un objetivo famoso para recibir ataques; basta con estar ahí, visible, con una ruta de login y un puerto abierto. Los bots no discriminan por tamaño, discriminan por oportunidad.

En un comercio electrónico, el reparto de tareas se vuelve más evidente. El firewall de red puede proteger el acceso a sistemas internos, limitar tráfico extraño, separar zonas, y frenar intentos de saturación en capas bajas; el WAF, en cambio, se enfrenta a lo que duele de verdad en ese negocio: toma de cuentas, abuso de formularios, pruebas de credenciales reutilizadas, automatización de compras, scraping de precios, manipulación de carritos, explotación de cupones. Son ataques que no “rompen” la red, rompen la lógica. Y la lógica vive en HTTP, en endpoints, en sesiones, en cookies. Sin WAF, esa guerra se libra con herramientas improvisadas.

En medios digitales y plataformas con picos de audiencia, la pareja también encaja: el firewall de red ayuda a mantener control de accesos y segmentación, y el WAF contribuye a absorber tráfico anómalo en capa 7, filtrar bots y reducir impactos por abuso de rutas concretas. Aquí aparece una realidad incómoda: no todo pico es éxito. A veces un pico es un ataque disfrazado de interés. Sin registros y sin capas, distinguirlo llega tarde.

En entornos híbridos o en nube, el concepto se reparte: el “firewall de red” puede ser un appliance tradicional, pero también puede estar representado por controles de perímetro, firewalls virtuales, políticas de seguridad en la red del proveedor, y segmentación mediante zonas y reglas internas. El WAF puede integrarse en el balanceador o vivir en un servicio perimetral. Lo importante no es el formato, es la función: separar y filtrar en red, analizar y bloquear en aplicación. Cuando una organización piensa que “la nube ya lo trae”, suele confundirse con lo que trae por defecto: trae piezas, sí, pero no trae el diseño ni la disciplina.

En arquitecturas con contenedores y orquestación, el escenario se vuelve más granular: hay servicios que nacen y mueren, rutas que cambian, escalado automático. Aquí el WAF suele colocarse como frontera estable delante del tráfico web, y el control de red se complementa con políticas internas. Además entra un tercer actor que no conviene ignorar aunque el foco sea “dos tipos”: el firewall de host, el cortafuegos del propio servidor o instancia, que añade contención local. No sustituye a los otros, pero ayuda a que un fallo no se convierta en contagio. La seguridad efectiva tiende a ser así, un conjunto de límites bien puestos; no se ve en un póster, se ve cuando algo falla y no arrastra todo lo demás.

El mantenimiento, por cierto, es donde se decide si la combinación sirve o estorba. Dos firewalls implican dos capas de reglas, dos fuentes de logs, dos puntos donde un cambio puede romper algo. La forma adulta de gestionarlo es con trazabilidad: cambios registrados, pruebas, ventanas controladas, y un mapa claro de “qué protege a qué”. Cuando ese mapa no existe, la seguridad se convierte en superstición: se toca una regla y se reza. Y en algún momento, se deja de tocar nada, que es la antesala del incidente.

Cuando el ataque llega con traje y corbata

Las intrusiones más dañinas rara vez entran con luces y sirenas. Entran como una petición web normal, o como una conexión permitida, o como un usuario que parece legítimo. Por eso la seguridad con 2 tipos de firewall diferentes tiene sentido: porque divide el trabajo entre lo que es “camino” y lo que es “contenido”, entre lo que es “quién y cómo se conecta” y lo que es “qué intenta hacer dentro”. El firewall de red corta rutas indebidas y reduce el terreno; el WAF corta intenciones maliciosas que viajan dentro del tráfico permitido. Ninguno, por sí solo, cubre todo lo que duele.

La señal más clara de que ambos están bien integrados no es un panel bonito, es un patrón: cuando aparece actividad anómala, los registros cuentan una historia coherente. El firewall de red muestra de dónde llega el ruido, qué intenta tocar, cómo se mueve; el WAF muestra qué rutas buscaba, qué parámetros manipulaba, qué evasiones probaba, qué tipo de abuso repetía. Esa doble visión acelera decisiones: bloquear una fuente, ajustar una regla, cerrar un endpoint, endurecer un límite. Sin esa visión, la reacción suele ser torpe: bloquear por desesperación, abrir por pánico, volver a bloquear porque algo se rompe. Oscilación, puro desgaste.

También conviene asumir un hecho simple: los firewalls no sustituyen control de identidad, ni arreglan permisos mal puestos, ni convierten contraseñas débiles en fuertes. Lo que sí hacen, cuando se despliegan como pareja con roles distintos, es crear fricción para el atacante y tiempo para el defensor. Fricción para que el ataque automatizado falle antes, tiempo para detectar antes, tiempo para responder mejor. Y en seguridad, el tiempo es un multiplicador silencioso: un minuto puede ser una alerta; una hora puede ser un incidente; un día puede ser un desastre.

Cuando se mira el conjunto con frialdad, el argumento final no es una frase grandilocuente, es un balance operativo: dos capas bien elegidas reducen superficie, recortan abuso, segmentan daños, mejoran trazabilidad y obligan a ordenar la infraestructura y las aplicaciones. Esa ordenación, con firewall de red y WAF cumpliendo cada uno su papel, es lo que convierte la seguridad en algo verificable, menos retórico, más real.