Web Application Firewall para redes de Azure

Azure Web Application Firewall (WAF) protege sus aplicaciones web frente a ataques comunes en la capa HTTP, como la inyección SQL, las secuencias de comandos entre sitios (XSS) y el recorrido de directorios. A diferencia de Azure Firewall, que inspecciona el tráfico en las capas 3 a 7 para las amenazas de nivel de red, WAF solo funciona en la capa 7 y comprende la semántica HTTP, incluidos encabezados de solicitud, cadenas de consulta, cuerpos de solicitud y cookies. Implemente WAF como una directiva asociada a Azure Application Gateway (regional) o Azure Front Door (perímetro global) para que coincida con el ámbito de protección con la arquitectura de la aplicación. Web Application Firewall es uno de los tres servicios principales de seguridad de red de Azure, junto con Azure Firewall y Azure DDoS Protection.

Lo que trata este artículo

En este artículo se describe la protección de capa HTTP mediante Azure Web Application Firewall. Obtendrá información sobre:

  • Comparación de plataformas entre WAF en Application Gateway v2 y WAF en Azure Front Door.
  • Conjuntos de reglas basados en OWASP, incluidos el conjunto de reglas predeterminado (DRS) y el conjunto de reglas principales (CRS).
  • Modo de detección frente al modo de prevención y cuándo usar cada uno.
  • Opciones de ámbito de las directivas de WAF: asociaciones globales, por sitio y por oyente.
  • Reglas personalizadas para la limitación de velocidad, el filtrado geográfico y la lógica específica de la aplicación.
  • Distinción entre WAF (HTTP de nivel 7) y Azure Firewall (red de capas 3 a 7).

Quién necesita este artículo

Implemente WAF cuando las cargas de trabajo cumplan uno o varios de los criterios siguientes:

  • Aplicaciones web orientadas al público: Las aplicaciones aceptan tráfico HTTP/HTTPS entrante desde Internet, exponiéndolos a las 10 vulnerabilidades principales de OWASP, incluidos los ataques por inyección, el abuso de autenticación roto y los intentos de exposición de datos confidenciales.
  • Requisitos de cumplimiento: Los marcos normativos como PCI DSS (Estándar de seguridad de datos del sector de tarjetas de pago) exigen un firewall de aplicaciones web delante de cualquier aplicación que procese los datos de tarjetas de pago.
  • Protección de API: Las API son accesibles públicamente y requieren protección contra el tráfico de solicitudes, cargas excesivas y ataques de nivel de protocolo que los firewalls de red no inspeccionan.
  • Mitigación de bots: Debe clasificar y controlar el tráfico automatizado, bloqueando bots malintencionados al tiempo que permite rastreos legítimos y servicios de supervisión.

Las organizaciones que solo necesitan filtrado de tráfico de nivel de red (IP, puerto y protocolo) sin inspección de solicitudes HTTP deben usar Azure Firewall o NSG en su lugar.

Enfoque lift-and-shift: Muchas aplicaciones internas reubicadas no tienen entrada desde Internet y no necesitan WAF. Agregue WAF solo cuando exponga una aplicación web a Internet durante o después de la migración.

Enfoque de modernización: Coloca las aplicaciones web orientadas al cliente con WAF en Azure Front Door para aplicaciones globales, o en Application Gateway para aplicaciones de una sola región, en función de si has elegido Front Door o Traffic Manager como método de entrega.

Enfoque multicloud: Instala un WAF de capa 7 en Application Gateway en el spoke para las aplicaciones web públicas migradas y asigna las protecciones web de otras nubes (como Google Cloud Armor) al WAF de Azure.

comparación de la plataforma waf de Azure

Azure WAF está disponible en dos plataformas. Cada plataforma integra la inspección de WAF en un punto diferente del flujo de tráfico.

Diagrama que muestra Azure Web Application Firewall arquitectura con las opciones de implementación de Application Gateway y Front Door

Capacidad WAF en Application Gateway v2 WAF en Azure Front Door
Ámbito de la implementación Regional (única región de Azure) Global (más de 192 puntos de presencia [PoP] en todo el mundo)
Punto de inspección Después de que el tráfico llegue a tu región En el PoP perimetral, antes de que el tráfico llegue al origen
Conjuntos de reglas admitidos DRS 2.2, DRS 2.1, CRS 3.2 DRS 2.2, DRS 2.1, DRS 2.0
Reglas personalizadas ✔ ✔
Protección de bots ✔ ✔ (solo nivel Premium)
Limitación de velocidad ✔ ✔
Geo-filtering ✔ ✔
Política por sitio ✔ (por listener, por ruta) ✔ (por endpoint)
Conjuntos de reglas administradas ✔ ✔ (Solo nivel Premium; Standard solo admite reglas personalizadas)
Inspección del cuerpo de la solicitud Hasta 128 KB (configurable) Hasta 128 KB (configurable)
Compatibilidad con el origen de Private Link N/A (en línea con App Gateway) ✔ (conectividad de origen privado)
Más adecuado para Aplicaciones de una sola región, equilibrio de carga L7 + WAF Aplicaciones multirregión, aceleración global + WAF

Note

Azure Front Door tiene dos niveles: Estándar y Premium. Los conjuntos de reglas administrados (incluida drS y protección contra bots) solo están disponibles en Front Door Premium. Front Door Standard solo admite reglas personalizadas. Front Door (clásico) solo admite DRS 1.1 o versiones anteriores.

Cómo elegir tu plataforma WAF

Use los siguientes criterios de decisión:

  • Elija WAF en Application Gateway cuando la aplicación se implemente en una sola región y ya use Application Gateway para el equilibrio de carga de nivel 7, la terminación TLS o el enrutamiento basado en rutas de acceso. WAF añade inspección HTTP en línea sin introducir un salto de servicio adicional.
  • Elija WAF en Azure Front Door cuando la aplicación abarque varias regiones, requiere equilibrio de carga global o ventajas de la aceleración de la red de entrega de contenido (CDN). Front Door WAF inspecciona el tráfico en el punto de presencia (PoP) de perímetro más cercano. El servicio bloquea las solicitudes malintencionadas antes de atravesar la red troncal Azure para llegar al origen. Este enfoque reduce la exposición a la superficie expuesta a ataques y absorbe los ataques volumétricos de la capa 7 en el borde.
  • Elija ambas (superpuestas) cuando una aplicación multiregión atendida por Front Door también requiera directivas de WAF regionales que difieren para cada back-end. Front Door proporciona protección global de primera línea, mientras que Application Gateway WAF aplica reglas personalizadas específicas de la región más cerca de la carga de trabajo.

Consideraciones de diseño

Enfoque de diseño de WAF lift-and-shift

  • Omita el WAF para las cargas de trabajo realojadas de uso exclusivamente interno que no tengan ninguna ruta de entrada desde Internet; vuelva a evaluarlo cuando publique una aplicación en Internet.
  • Cuando expongas una aplicación web, inicia el WAF en modo de detección para establecer una línea de base del tráfico y, a continuación, cambia al modo de prevención una vez que hayas eliminado los falsos positivos.
  • Utiliza el WAF de Application Gateway para una aplicación web reubicada en una sola región a la que ya hayas asignado Application Gateway para el enrutamiento de capa 7.
  • Reutilice el propósito de sus reglas de protección web implementadas en sus instalaciones (por ejemplo, la cobertura de OWASP) como política inicial.

Modernización del enfoque de diseño de WAF

  • Ejecute WAF en modo de prevención desde el principio para las aplicaciones orientadas al cliente y adopte el conjunto de reglas administradas más reciente, por lo que la cobertura realiza un seguimiento de las nuevas amenazas de OWASP automáticamente.
  • Habilite la administración de bots para separar los rastreadores legítimos de la automatización malintencionada en las aplicaciones públicas.
  • Administra la directiva del WAF como código para que los backends regionales activos-activos se mantengan sincronizados a lo largo de tu canal de implementación.
  • Combina el WAF perimetral con el firewall del hub para una defensa en profundidad y habilita el descuento en la facturación de WAF de Application Gateway activando DDoS Network Protection en la VNet.

Enfoque de diseño de WAF multinube

  • Aloje un WAF de capa 7 en Application Gateway en la VNet spoke para que se inspeccione el tráfico web público sin asociar direcciones IP públicas directamente a las máquinas virtuales.
  • Asigne las protecciones web existentes de otras nubes (por ejemplo, AWS WAF o Google Cloud Armor) a los conjuntos de reglas administradas de Azure WAF para mantener la cobertura.
  • Inspecciona las comunicaciones hacia el público a través del WAF y mantén la inspección del tránsito este-oeste y entre nubes en el firewall del concentrador de la Virtual WAN.
  • Durante la transición, ejecuta primero el WAF en modo de detección (aprendizaje) y, a continuación, aplica las reglas una vez que hayas confirmado los patrones de tráfico legítimos.

Prerequisites

Antes de implementar Azure Web Application Firewall, asegúrese de que tiene:

  • Recurso de Application Gateway v2 o Azure Front Door: WAF se implementa como una directiva asociada a una de estas plataformas. Debe tener una instancia existente de Application Gateway v2 o un perfil de Azure Front Door aprovisionado antes de crear y asociar una directiva WAF.
  • Carga de trabajo HTTP/HTTPS orientada al público: La aplicación debe recibir tráfico HTTP/HTTPS entrante. WAF inspecciona la semántica de nivel de solicitud y no proporciona ninguna ventaja para cargas de trabajo que no son HTTP o servicios puramente internos.
  • Descripción de los patrones de tráfico HTTP: La familiaridad con los patrones de solicitud normales de la aplicación (encabezados, parámetros de consulta y contenido del cuerpo) le ayuda a configurar exclusiones y ajustar reglas para minimizar los falsos positivos durante la transición del modo de detección a prevención.

Conjuntos de reglas y procesamiento de reglas

WAF usa conjuntos de reglas para detectar patrones malintencionados en solicitudes HTTP. Comprender la jerarquía de reglas y el orden de procesamiento le ayuda a optimizar WAF para sus aplicaciones específicas.

Conjuntos de reglas administradas

Microsoft mantiene conjuntos de reglas administrados basados en patrones de conjuntos de reglas principales (CRS) de OWASP. El conjunto de reglas recomendado para las nuevas implementaciones es DRS 2.2 (conjunto de reglas predeterminado). DRS 2.2 se basa en OWASP CRS 3.3.4 y añade firmas de Microsoft Threat Intelligence.

Conjunto de reglas Basado en Compatibilidad con la plataforma Recommendation
DRS 2.2 OWASP CRS 3.3.4 + Microsoft Threat Intel App Gateway v2, Front Door Premium Recomendado para nuevas implementaciones
DRS 2.1 OWASP CRS 3.3 App Gateway v2, Front Door Premium Generación anterior; compatible con ambas plataformas
DRS 2.0 OWASP CRS 3.2 Solo para Front Door Premium Compatible; versión Front Door N-2
CRS 3.2 OWASP CRS 3.2 Solo para App Gateway v2 Compatible; uso de DRS 2.2 para nuevas implementaciones

Los conjuntos de reglas DRS y CRS usan la puntuación de anomalías. Cada regla de coincidencia contribuye a una puntuación en lugar de bloquear inmediatamente la solicitud. Cuando la puntuación de anomalía acumulada supera un umbral configurable, el WAF actúa (bloquear o registrar). Este enfoque reduce los falsos positivos en comparación con el bloqueo por reglas individuales, ya que una única coincidencia de baja confianza no activa la aplicación de la directiva.

Reglas personalizadas

Las reglas personalizadas se ejecutan antes de las reglas administradas y usan números de prioridad para controlar el orden de evaluación (número inferior = prioridad más alta). Use reglas personalizadas para:

  • Limitación de velocidad: Restrinja las solicitudes de cada dirección IP de cliente dentro de un período de tiempo para mitigar los ataques por fuerza bruta y relleno de credenciales.
  • Filtrado geográfico: Permitir o denegar el tráfico en función del país o región del cliente de origen.
  • Listas de IP permitidas y denegadas: Permite las IP de socios conocidos o bloquea a los actores maliciosos conocidos antes de que se evalúen las reglas administradas.
  • Inspección del encabezado de solicitud: Aplique requisitos específicos de la aplicación, como claves de API obligatorias o tipos de contenido esperados.

Conjunto de reglas de protección contra bots

Ambas plataformas ofrecen un conjunto de reglas de protección de bots que clasifica el tráfico automatizado en buenos bots (motores de búsqueda comprobados), bots incorrectos (escáneres malintencionados conocidos) y bots desconocidos. Configure las acciones para cada categoría: permita los bots buenos, bloquee los bots maliciosos y desafíe a los bots desconocidos con limitación de tasa o CAPTCHA.

Modo de detección vs. modo de prevención

Las directivas de WAF funcionan en uno de los dos modos que determinan cómo controla el sistema las solicitudes coincidentes:

Mode Comportamiento Caso de uso
Detección Registra las solicitudes coincidentes, pero no las bloquea. Las solicitudes siguen enviándose al backend. Implementación inicial y ajuste de reglas. Supervisa qué reglas se activan sin afectar al tráfico de producción.
Prevención Bloquea las solicitudes coincidentes y devuelve una respuesta 403. Registra la solicitud bloqueada. Cargas de trabajo de producción una vez finalizado el ajuste de las reglas. Protección activa contra ataques.
  1. Implementación en modo de detección: Active el WAF con el conjunto de reglas elegido en el modo de detección. Encamine el tráfico de producción a través del WAF.
  2. Análisis de registros: Revise los registros de WAF para identificar falsos positivos. Determina las reglas que se activan con el tráfico legítimo de las aplicaciones.
  3. Crear exclusiones: En el caso de las reglas que generan falsos positivos, defina exclusiones que especifiquen los campos de solicitud (encabezados, cookies y parámetros de consulta) para omitir las reglas específicas.
  4. Cambiar al modo de prevención: Después de 1–2 semanas de registros de detección limpios con tasas de falsos positivos aceptables, cambie al modo de prevención para habilitar el bloqueo activo.
  5. Supervisión continua: Continúe con los registros de supervisión después de cambiar al modo de prevención. Las nuevas características de la aplicación o los cambios de API pueden introducir nuevos patrones falsos positivos.

Importante

Ejecute siempre las cargas de trabajo de producción en modo de prevención. El modo de detección no proporciona protección. Solo registra posibles ataques. Use el modo de detección solo durante la fase de optimización inicial o cuando solucione un problema específico de falsos positivos.

Ámbito y asociación de la política WAF

Una directiva waf es un recurso de Azure independiente que contiene la selección de modo, la configuración del conjunto de reglas, las reglas personalizadas y las exclusiones. Asocie la política a uno o varios objetivos para controlar el alcance de la protección.

Ámbito de la política WAF de Application Gateway

En Application Gateway, asocie una directiva WAF con tres niveles de granularidad:

  • Global (para toda la puerta de enlace): La directiva se aplica a todos los oyentes y reglas de ruta de la Application Gateway. Use el ámbito global cuando todas las aplicaciones detrás de la puerta de enlace compartan los mismos requisitos de protección.
  • Nivel de agente de escucha: Una directiva waf diferente se aplica a un agente de escucha específico (combinación de nombre de host y puerto). Utiliza el ámbito a nivel de oyente cuando varias aplicaciones compartan una puerta de enlace pero necesiten ajustes de reglas o exclusiones diferentes.
  • Nivel de regla de ruta de acceso: Una directiva de WAF se aplica a una regla de ruta de acceso URL específica dentro de un listener. Utilice el ámbito de las reglas de ruta para un control granular de las aplicaciones con distintos niveles de sensibilidad en el back-end.

Cuando se aplican varios ámbitos a una misma solicitud, tiene prioridad la directiva más específica: la regla de ruta anula la de nivel de listener, que a su vez anula la global.

Ámbito de la directiva WAF de Front Door

En Front Door, las directivas de WAF se asocian a nivel de punto de conexión o de ruta. Cada punto de conexión de Front Door puede tener su propia directiva de WAF. Este enfoque permite perfiles de protección específicos de la aplicación dentro de una única instancia de Front Door.

Uso compartido de políticas entre recursos

Comparte una única directiva de WAF entre varias instancias de Application Gateway o puntos de conexión de Front Door. Azure Firewall Manager proporciona visibilidad y administración centralizadas en todas las directivas de WAF, independientemente de la plataforma. Use directivas compartidas cuando varios recursos requieran una protección idéntica para simplificar la administración y mantener una posición de seguridad coherente.

Distinción de Azure Firewall

WAF y Azure Firewall protegen diferentes capas de la pila de protocolos de red y desempeñan funciones complementarias. Implementa ambas para lograr una defensa en profundidad.

Attribute Firewall de aplicaciones web Azure Firewall
Capa de OSI Capa 7 (solo HTTP/HTTPS) Capas 3–7 (red y aplicación)
Tipo de tráfico Solicitudes HTTP/HTTPS entrantes a aplicaciones web Todas las direcciones de tráfico (norte-sur, este-oeste)
Foco de inspección Semántica HTTP: encabezados, cuerpo, cookies, URI Direcciones IP, puertos, protocolos, FQDN, direcciones URL
Motor de reglas Coincidencia de patrones basados en OWASP + puntuación de anomalías Reglas de red, reglas de aplicación, reglas NAT
Modelo de implementación Integrado con App Gateway o Front Door Aislado en la subred de concentrador con enrutamiento mediante UDR
Ataques típicos bloqueados inyección SQL, XSS, CSRF, recorrido de directorios Escaneo de puertos, comunicaciones de retorno con C2, exfiltración por DNS

Use WAF para la protección de aplicaciones HTTP y Azure Firewall para la inspección centralizada del tráfico de red. En una arquitectura de tipo hub-and-spoke, el tráfico desde Internet hacia una aplicación web normalmente pasa a través de Azure Firewall (para DNAT y la inspección a nivel de red) y, a continuación, a través de Application Gateway con WAF (para la inspección en la capa HTTP). Consulte Azure Firewall y inspección del tráfico para el componente de nivel de red.

Consideraciones de seguridad

Las siguientes prácticas de seguridad le ayudan a obtener la mayor protección frente a WAF:

  • Modo de prevención para producción: Nunca deje las cargas de trabajo de producción en modo de detección. El modo de detección proporciona visibilidad, pero sin aplicación, dejando las aplicaciones expuestas a ataques.
  • El ajuste de reglas está en curso: Las aplicaciones evolucionan. Los nuevos puntos de conexión de API, parámetros y tipos de contenido pueden provocar falsos positivos en los conjuntos de reglas existentes. Revise los registros de WAF periódicamente después de las implementaciones.
  • Integración de Log Analytics: Enviar registros de diagnóstico de WAF a un espacio de trabajo de Log Analytics. Utilice el libro de trabajo de WAF para visualizar las solicitudes bloqueadas, las reglas activadas y las distribuciones de puntuaciones de anomalías.
  • DDoS y WAF juntos: WAF protege contra ataques de aplicación de capa 7, pero no mitiga los ataques DDoS de capa de red volumétrica. Combina WAF con Azure DDoS Protection para una protección integral.
  • Bloqueo de origen: Cuando utilice el WAF de Front Door, configure su origen para que acepte tráfico únicamente desde la etiqueta de servicio de Front Door. Sin bloqueo de origen, los atacantes pueden omitir Front Door y enviar solicitudes directamente a la dirección IP de origen.
  • Protección de datos confidenciales: Los registros de WAF pueden contener datos de solicitud. Configure reglas de depuración de registros para ocultar campos confidenciales (encabezados de autorización, cookies o contenido del cuerpo) en los registros de diagnóstico del WAF.

En los artículos siguientes se tratan temas relacionados con la seguridad de red:

Aprende más

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

A continuación, en el itinerario de lift-and-shift:

Configuración de la supervisión de la red migrada: valide la conectividad y el rendimiento después de configurar el firewall de aplicaciones web.

A continuación en su proceso de modernización:

Habilitar la protección contra DDoS para puntos de conexión públicos: proteja los recursos de ip pública frente a ataques de denegación de servicio distribuidos.

A continuación, en el itinerario entre nubes:

Implemente sus aplicaciones migradas: asigne los equilibradores de carga de AWS y Google Cloud a sus equivalentes en Azure para sus cargas de trabajo multinube.

  • Last updated on