Un firewall de red y un WAF pueden aparecer juntos en la arquitectura de una web, pero no responden a la misma pregunta. El primero controla flujos como direcciones, protocolos y puertos; el segundo analiza peticiones HTTP y reglas relacionadas con la aplicación. Confundirlos produce controles mal ubicados y expectativas incorrectas.
La comparación debe partir del recorrido de una petición y del tipo de decisión que cada componente puede tomar.
Qué ve un firewall de red o del host
Un firewall puede permitir o denegar tráfico hacia un puerto, restringir orígenes y limitar conexiones salientes. Es útil para que una base de datos no quede expuesta a Internet o para que SSH solo sea accesible desde una red de administración. Su visibilidad no incluye necesariamente el significado del contenido HTTP.
El firewall del host aplica una política cerca del proceso y puede actuar aunque no exista un dispositivo de red dedicado. Requiere, sin embargo, que el equipo conozca sus reglas y conserve una ruta de recuperación.
Qué ve un WAF
Un WAF se coloca delante de la aplicación o en un proxy inverso y puede inspeccionar método, ruta, cabeceras, parámetros y cuerpo de peticiones HTTP. Sus reglas buscan patrones que suelen asociarse a entradas maliciosas o comportamientos anómalos. La visibilidad permite tomar decisiones que un filtro de puerto no puede tomar.
El WAF puede ayudar con aplicaciones y APIs, pero necesita conocer rutas legítimas, tamaños y formatos. Una regla demasiado amplia puede bloquear usuarios reales; una demasiado permisiva puede dejar pasar una petición que requiere revisión.
Dos capas, dos tipos de fallo
Si el puerto web no debe estar abierto para un origen, la decisión corresponde al firewall. Si una ruta pública recibe parámetros sospechosos, un WAF puede ser una capa adicional. Si la aplicación autoriza a un usuario a consultar el pedido de otra persona, el problema está en la lógica y debe corregirse en el código.
Un WAF no repara una consulta insegura, una mala gestión de sesión ni un fallo de autorización. Un firewall de red tampoco garantiza que una petición permitida sea correcta.
Reglas y falsos positivos
Las reglas administradas o personalizadas deben probarse con tráfico realista y registrarse con suficiente contexto para investigar. Excluir una ruta completa para evitar falsos positivos puede crear un hueco mayor que el problema original. Es preferible ajustar la validación de la aplicación y delimitar la excepción.
En APIs, el contenido puede ser JSON y las rutas legítimas pueden parecerse a patrones de ataque. La prueba debe incluir errores, cargas normales y versiones distintas del cliente antes de endurecer la política.
Cómo se complementan
Una arquitectura razonable puede filtrar puertos y orígenes con el firewall, terminar HTTPS en un proxy y aplicar reglas HTTP antes de llegar al backend. La aplicación continúa validando identidad, permisos, tipos y reglas de negocio. Los logs de cada capa deben poder relacionarse por tiempo o identificador de petición.
El operador debe saber quién mantiene cada control y qué ocurre si uno deja de estar disponible. Añadir capas también añade configuración, latencia y alertas que alguien debe revisar.
Qué control corresponde a cada capa
Protege el puerto y el flujo con un firewall; inspecciona la forma de una petición con un WAF; corrige la lógica, actualiza el software y limita permisos en la aplicación y el sistema. Antes de elegir, dibuja el recorrido, identifica el riesgo y define una prueba. Ninguno de los dos controles ofrece protección completa si el resto del servicio permanece vulnerable.
Comparar decisiones en el recorrido
Un firewall puede impedir que Internet alcance una base de datos y permitir únicamente el puerto del proxy. El WAF puede inspeccionar la petición que el proxy entrega a la aplicación. Después, el código comprueba identidad, permisos y reglas de negocio. Cada capa recibe una parte distinta de la responsabilidad.
Si el WAF se cae, la arquitectura debe definir si se bloquea el tráfico, se permite una degradación controlada o se utiliza otra ruta. Si el firewall cambia una regla, hay que saber qué aplicaciones y equipos dependían de ella.
Medir el coste de las reglas
Observa latencia, respuestas bloqueadas, falsos positivos y rutas excluidas. Una regla que bloquea muchas peticiones puede parecer eficaz mientras impide funciones legítimas. Una excepción amplia puede eliminar la cobertura justo donde la aplicación es más vulnerable.
Relaciona logs del firewall, WAF y backend mediante una marca de petición cuando sea posible. Esa trazabilidad ayuda a saber si el bloqueo ocurrió antes de llegar a la aplicación y evita atribuir al control equivocado una mejora o un fallo.
Evitar huecos entre controles
Si el WAF está delante del backend, el firewall debería impedir que el backend sea accesible directamente desde Internet cuando no lo necesita. De lo contrario, una petición puede saltarse la capa de inspección. La red, el proxy y la aplicación deben compartir una definición clara de qué origen es confiable.
Las revisiones deben incluir rutas nuevas, APIs, websockets y cambios de formato. Una política diseñada para formularios HTML puede no cubrir una API JSON, y una regla que inspecciona una capa no reemplaza la validación específica de la aplicación.