[WAF vs Firewall] Gran confusión

Un caso real

Hace menos de un año, estaba haciendo doble click en una arquitectura de un cliente con una web crítica de e-commerce sobre Azure App Service.
El entorno ya tenía su Network Security Group (NSG) y su Azure Firewall perfectamente configurados, extremadamente cerrado para ser mas preciso.
Puertos cerrados, IPs controladas, reglas limpias. Todo parecía de manual.

Un día, recibimos alertas de comportamiento anómalo: el tipico intento de inyección en el login, como casi siempre cuando das de alta el servicio sin hardenizado, consultas SQL sospechosas y hasta una pequeña caída en la API pública.
La red, según los logs, estaba perfecta. Nada extraño.
Pero los ataques entraban igual.

Ahí vino el clásico momento de “mare miaaa”. La red estaba segura, pero la aplicación no.
El firewall no entiende de payloads HTTP ni de parámetros maliciosos en un formulario por ejemplo.
Es ahí en donde necesitábamos control y gestión sobre sa capa, aqui la maravillosa idea de, necesitamos un WAF.

Activamos Azure Web Application Firewall (WAF) sobre un Application Gateway, configuramos las reglas OWASP 3.2, ajustamos el modo de detección a prevención, y… magia: los mismos patrones que antes se colaban, ahora quedaban registrados y bloqueados.
Sin tocar una línea del código.

De mientras...

Mientras escribía este post, me acompañó “Told” de Kiasmos — un tema que, de alguna manera, resume la esencia de lo que quería transmitir: equilibrio, ritmo y calma entre lo técnico y lo humano.

👉 Te dejo aquí el tema, por si querés escucharlo mientras leés o reflexionás sobre tu propia “paz digital”.

Cuándo usar uno, cuándo usar ambos

Usá un Firewall cuando:

• Querés controlar tráfico entre redes, subredes o zonas (Internet ↔ Backend, VNet ↔ VNet).

• Necesitás registrar, auditar o limitar conexiones.

• Querés proteger a nivel de infraestructura, no de aplicación.

Usá un WAF cuando:

• Tenés aplicaciones web o APIs expuestas a Internet.

• Querés inspeccionar contenido HTTP y aplicar protección OWASP.

• No podés confiar solo en la validación de tu código.

Usá ambos cuando:

• Tu aplicación es pública o crítica, y no querés elegir entre “proteger la casa” o “proteger lo que hay adentro”.
  Uno filtra el acceso al edificio; el otro, vigila cada paquete que entra por la puerta.

Dónde y por qué colocar el WAF en este diseño

Contexto del diagrama
Tienes un Front Door público, un Azure Firewall en el hub, una Web App integrada a VNet con Route All, y Private Endpoints (Web/App y SQL). El tráfico público entra por Front Door y el backend es privado.

Elección de ubicación

En el borde global: Front Door WAF, recomendado

• Por qué aquí: filtra todo lo que llega desde Internet antes de tocar tu red. Es ideal cuando ya usas Front Door y los orígenes son privados mediante Private Link (requiere Front Door Premium).

• Qué protege: HTTP/HTTPS hacia la Web App (y APIs). No protege SQL directamente (para SQL el control es de acceso, no WAF).

• Ventajas clave

  • Escala y latencia en la red perimetral de Microsoft.

  • Mitigación temprana de ataques L7 (OWASP, bots, rate limiting, geo/IP).

  • Políticas por ruta (p. ej., endurecer /login y /api).

  • Compatible con end-to-end TLS y orígenes privados por Private Link.

• Cuándo es suficiente: sitios y APIs públicos con un único front door global y backends privados.

Flujo recomendado

Internet → Front Door (WAF) → (Private Link) → VNet → Web App ↓ Azure Firewall*

*El Firewall sigue aplicando control L3/L4/egreso, pero no sustituye al WAF.

En la capa regional: Application Gateway WAF, como complemento

• Por qué aquí: agrega defensa en profundidad y escenarios regionales (multi-región activo/activo, requisitos locales, afinado por app).

• Qué protege: tráfico HTTP/HTTPS dentro de la región, normalmente después de Front Door (FD → AppGW WAF → App Service).

• Ventajas

  • Políticas por app/región.

  • Integración con Private Link/ILB y afinado fino de exclusiones.

• Cuándo usar además del Front Door WAF: cargas muy críticas, false-positives que requieren tuning por región, requisitos de segregación o inspección dual.
  
  

Qué NO hace don WAF aquí

No inspecciona ni “protege” Azure SQL; su exposición es privada. Para SQL aplica acceso privado, Azure AD, Defender for SQL y reglas de Firewall de SQL.

Checklist de implementación, Front Door WAF

1. Front Door Premium + origen privado por Private Link.

2. Crear una WAF Policy y asociarla al endpoint o ruta:

   • Managed Rules OWASP (3.x) en Prevention con Anomaly Scoring.

   • Rate limiting (p. ej., /login y /api/*).

   • Bot Management y bloqueo de IP/ASN/Geo según riesgo.

   • Request size/body limits y denegación de métodos no usados (PUT/DELETE si no aplican).

   • Exclusiones mínimas para campos específicos que generen falsos positivos.

3. TLS: certificado en Front Door + re-encripción al origen (end-to-end TLS).

4. Logs: habilitar Diagnostic Settings a Log Analytics; crear alertas (alto puntaje de anomalía, spikes, reglas personalizadas).

5. Tuning: iniciar en Detection, revisar 3–7 días, pasar a Prevention por rutas priorizadas.
   
   

Resumen de decisión

• Si ya tienes Front Door y orígenes privados → WAF en Front Door: mejor cobertura, menor latencia, control por ruta, bots y rate limiting en el borde.

• Si necesitas doble capa o políticas por región/app → añade Application Gateway WAF detrás de Front Door (defensa en profundidad).

• Azure Firewall permanece para L3/L4/egreso y segmentación; no sustituye al WAF.

Que quiero que te lleves..

Ahora que identificaste cuando sí y cuando no, recuerda la famosa frase “Hagamos el amor, no la guerra”, nacida en los años 60 como símbolo del movimiento pacifista contra la violencia, encaja perfectamente en el mundo cloud: durante años se enfrentaron los defensores del Firewall y del WAF, pero en realidad no son enemigos, sino aliados. El Firewall protege la red; el WAF, la aplicación. Juntos promueven la armonía digital, porque la verdadera seguridad no está en competir, sino en complementarse.

En tech, como en la vida, hagamos "la defensa", no la guerra.

Gracias por pasarte y dedicarle tiempo a la lectura!

Fuente de la imagen

Fuente de la imagen