Firewall frente a WAF: qué ve y qué detiene cada uno

Qué decide un firewall con estado

Un firewall de capa 3/4 sigue las conexiones y juzga cada una nueva por sus direcciones, su puerto y el estado del flujo al que pertenece. Cisco Firepower, OPNsense y netfilter lo hacen bien: un puerto que ninguna regla abre está cerrado, una respuesta se permite solo para una conexión que inició el interior, y los puertos de gestión responden solo a los rangos que están en la lista de permitidos. Su visión termina en la capa de transporte. Con TLS en la ruta no puede ver dentro de la carga útil en absoluto a menos que termine la sesión, e incluso en claro no tiene concepto de URL, de cabecera, de código de estado de respuesta ni de login.

Qué añade un WAF

Un firewall de aplicaciones web lee la transacción HTTP después de la terminación TLS, lo que en la práctica significa que vive en el proxy inverso o junto a él. Añade tres clases de control que el firewall no puede expresar. Las reglas de firma, como ModSecurity con el OWASP Core Rule Set, detectan inyección, traversal y payloads de exploits conocidos en la petición. Las reglas de comportamiento cuentan por cliente y por ruta: peticiones por minuto en la ruta de login, respuestas de login fallido por dirección, señales de bot en cabeceras y tiempos. Las reglas positivas declaran qué acepta una ruta, como qué métodos, qué tipos de contenido y qué tamaño de cuerpo, y rechazan el resto.

Un WAF no sustituye al firewall. Solo ve el tráfico que llega hasta él, y no sabe nada de SSH, de los puertos de base de datos ni del plano de gestión.

Dónde se hace visible el abuso de login

Un login fallido es un hecho en la respuesta. La aplicación responde a un POST a la ruta de login con un estado o una redirección que distingue el fallo del éxito, y el proxy lo escribe en su registro de acceso en cada intento. Contar fallos por cliente y por minuto es una línea de awk sobre ese registro, y es la señal que un filtro de paquetes no tiene forma de ver.

El control tiene que estar indexado por cliente, no por cuenta. El bloqueo de cuenta por sí solo detiene los intentos contra un nombre de usuario y deja fuera a su propietario, mientras el bot pasa al siguiente nombre de su lista. Un límite de tasa por cliente en la ruta de login hace lo que el bloqueo no puede:

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

HAProxy expresa la misma idea con una stick table indexada por dirección de origen, y un conjunto de reglas de WAF puede contar directamente el código de respuesta de login fallido.

Cómo encajan los dos

El orden es firewall, después terminación TLS y el proxy con sus reglas de WAF, después la aplicación. La detección pertenece a la capa 7, porque ahí están las pruebas. La aplicación de la medida puede estar en cualquiera de las dos capas. El proxy puede responder al cliente infractor con un 429 o un 403 en su siguiente petición, lo que basta para la mayor parte del abuso. Para un cliente que insiste, el proxy puede empujar la dirección a la tabla dinámica del filtro de paquetes durante un periodo fijado, lo que además corta las otras conexiones de ese cliente y no le cuesta nada al firewall por paquete.

Dos puntos de diseño van antes de armar ese bucle de realimentación. Los rangos de gestión y de monitorización del operador entran primero en la lista de permitidos, para que una prueba o una errata no pueda dejar fuera a las personas que operan la plataforma. Y las direcciones compartidas son reales: un NAT de oficina o un NAT de operador pone a muchas personas detrás de una dirección, así que los bloqueos llevan una caducidad corta y una forma documentada de levantarlos. Toda la cadena se prueba después desde un host fuera de la red, como la encontraría un atacante, antes de que nadie confíe en ella.

Qué no ve ninguno de los dos

Una contraseña correcta. El credential stuffing con una contraseña filtrada y válida parece un login correcto para todas las capas. Esa brecha se cierra con autenticación multifactor en la cuenta y con la lista de permitidos para las rutas administrativas en el firewall, de modo que una credencial válida sea inútil desde una dirección que no es la suya.