Protección DDoS de la capa de aplicación (capa 7)

Aplica a: ✔️ Application Gateway v2 ✔️ Front Door Premium

Azure Web Application Firewall (WAF) incluye varios mecanismos de defensa que ayudan a prevenir ataques de denegación de servicio distribuida (DDoS). Los ataques DDoS pueden tener como destino la capa de red (L3/L4) y la capa de aplicación (L7). Azure DDoS Protection le defiende frente a ataques volumétricos de capa de red de gran tamaño. Azure WAF, que funciona en el nivel 7, protege las aplicaciones web frente a ataques DDoS L7, como las inundaciones HTTP. En conjunto, estas defensas impiden que los atacantes lleguen a tu aplicación y afecten a su disponibilidad y rendimiento.

Los ataques a la capa de aplicación son baratos de lanzar y difíciles de distinguir del tráfico legítimo: cada solicitud parece válida por sí sola, y solo la tasa agregada, la distribución y la combinación de clientes revelan el ataque. Por tanto, la defensa efectiva en L7 depende menos de un control individual y más de una configuración en capas que ya esté establecida antes de que comience un ataque.

Elige tus capas de defensa

Utiliza el siguiente modelo cuando planifiques protección DDoS L7. Cada capa recoge el tráfico que la capa que tiene encima no recoge.

Nivel Qué hace Dónde configurarlo
Protección DDoS de plataforma Absorbe ataques volumétricos L3/L4 en el borde de Azure y en tus IPs públicas de origen Integrado de forma predeterminada en Azure Front Door; requiere Azure DDoS Network Protection para las direcciones IP públicas de Application Gateway y las direcciones IP públicas de origen
Mitigación automatizada de L7 Aprende cuál es su tráfico normal y limita a los clientes infractores durante un pico de tráfico, sin necesidad de ajustes de emergencia Conjunto de reglas de DDoS HTTP (versión preliminar) en Azure Front Door Premium y Application Gateway WAF v2
Verificación de cliente Separa a humanos y clientes legítimos del tráfico de ataque automatizado antes de bloquear Conjunto de reglas Bot Manager, desafío JavaScript, CAPTCHA
Limitación de velocidad Limita a cuántas solicitudes puede enviar cualquier cliente, geografía o endpoint Reglas personalizadas de limitación de frecuencia en Front Door y Application Gateway
Reglas personalizadas específicas Bloquea una firma de ataque conocida durante un incidente Aplicar reglas personalizadas (geolocalización, IP, ASN, huella digital del cliente, encabezado, URI)
Protección del origen Evita que el tráfico de ataque llegue a tu cómputo Caché, bloqueo de origen, escalado automático

Lista de verificación de configuración base

Completa estos pasos antes de que te ataquen. Ajústalos para ajustarlos a los requisitos de tu solicitud.

  1. Despliega Azure WAF con Azure Front Door Premium o Application Gateway WAF v2 para protegerte contra ataques a la capa de aplicación L7.
  2. Cambia la política de WAF a modo prevención. Una política en modo detección solo registra y no bloquea el tráfico. Verifica y ajusta primero la política contra el tráfico de producción para reducir falsos positivos, y luego activa la prevención.
  3. Asigna el conjunto de reglas HTTP DDoS (disponible tanto en Azure Front Door Premium como en Application Gateway WAF v2) para que la mitigación automatizada aprenda tu línea base de tráfico antes de necesitarla.
  4. Habilita el conjunto de reglas gestionado por Bot Manager para identificar y actuar sobre bots defectuosos conocidos.
  5. Configura al menos una regla de límite de tasa que abarca todo ( véase Limitación de tasa).
  6. Aumenta el número de instancias de origen para que haya suficiente capacidad libre y configura Application Gateway para que escale automáticamente sin imponer un número máximo bajo de instancias.
  7. Activa el almacenamiento en caché en Azure Front Door para que el tráfico pico repentino se absorba en el borde en lugar de en tu origen.
  8. Cubre tu exposición L3/L4, que varía según la plataforma. Véase : La protección DDoS de la plataforma varía según la plataforma. Bloquea tu origen para que solo acepte tráfico de Azure Front Door o Application Gateway.
  9. Activa el registro de diagnóstico en Log Analytics y construye las consultas en Analyze WAF y accede a los logsantes de un incidente.

La protección DDoS de la plataforma varía según la plataforma

Las defensas L7 solo importan si las direcciones IP públicas subyacentes sobreviven a un ataque volumétrico, y las dos plataformas WAF de Azure no parten desde el mismo lugar.

Azure Front Door tiene protección DDoS de plataforma por defecto. Azure Front Door es un servicio de borde distribuido globalmente, y su borde está protegido por la protección DDoS de infraestructura de Azure sin coste adicional y sin configuración. El tráfico termina en el borde de la puerta principal en lugar de en una dirección IP que poseas, así que no tienes ninguna IP pública tuya para que un atacante la pueda atacar en L3/L4. Esa protección es inherente a la plataforma, así que no compras ni activas nada para conseguirla.

La Pasarela de Aplicaciones necesita protección de red DDoS de Azure. Una pasarela de aplicaciones es un recurso regional con una dirección IP pública en tu propia red virtual. La protección predeterminada a nivel de infraestructura de Azure protege la propia plataforma de Azure, pero no te proporciona mitigación ajustada por recurso, telemetría o informes de ataques para esa IP. Para proteger la IP pública de la pasarela contra ataques volumétricos L3/L4, activa la Protección de Red DDoS de Azure en la red virtual que la contiene. Este es un servicio de pago, comprado por separado.

Consecuencias prácticas al elegir o diseñar un despliegue:

  • Si estás detrás de Azure Front Door, presupuesta para controles L7; la protección de bordes L3/L4 ya está ahí.
  • Si usas Application Gateway y no has activado la protección de red contra DDoS, tus reglas de WAF pueden estar perfectamente ajustadas y aun así ser eludidas por un ataque volumétrico contra la IP pública de la puerta de enlace. Habilítelo.
  • En cualquier caso, las IP públicas de origen que expongas siguen necesitando protección de red DDoS en Azure, además de bloqueo para que solo el servicio WAF pueda acceder a ellas. Un frontend protegido delante de un origen no protegido y públicamente accesible no está protegido.

Para más información, consulta Introducción a Azure DDoS Protection y Protege la puerta de enlace de aplicaciones con Azure DDoS Network Protection.

Protección automatizada con el conjunto de reglas HTTP DDoS (vista previa)

Los controles estáticos como filtros IP, geofiltros y límites fijos de tasa a menudo no pueden seguir el ritmo de botnets distribuidas: los umbrales son suposiciones, siempre están activados y debes ajustarlos a medida que evolucionan los patrones de tráfico. El conjunto de reglas HTTP DDoS es el primer modelo automatizado de protección de capa 7 de Azure WAF que aprende, detecta y defiende con una configuración mínima del usuario. Está disponible en versión previa tanto en Azure Front Door Premium como en Application Gateway WAF v2. Una vez asignado, establece continuamente una línea de base del tráfico normal y, cuando los aumentos repentinos indican un ataque, bloquea selectivamente a los clientes maliciosos sin necesidad de realizar ajustes de emergencia.

El diseño es el mismo en ambas plataformas en los aspectos que más importan:

  • Dos umbrales, evaluados juntos. El conjunto de reglas aprende tanto un umbral global (por perfil de Puerta Frontal o por pasarela de aplicación) como umbrales individuales basados en IP. Los umbrales basados en IP se aplican solo después de que se supera el umbral global. Este diseño impide que el conjunto de reglas actúe sobre picos de unas pocas direcciones IP a menos que realmente empujen el tráfico total más allá de la norma.
  • Ámbito por recurso. Los umbrales se aprenden a nivel global de recursos. Si asignas una política WAF con el conjunto de reglas a múltiples perfiles de puerta frontal o múltiples gateways, el servicio calcula los umbrales por separado para cada uno.
  • Sensibilidad. Cada regla ofrece tres niveles de sensibilidad. Una sensibilidad más alta aplica un umbral más bajo; Una sensibilidad más baja aplica un umbral más alto. Medio es la configuración predeterminada y recomendada.
  • Orden de evaluación. El WAF evalúa primero el conjunto de reglas HTTP DDoS, incluso antes de las reglas personalizadas. Una regla personalizada con una acción Permitir omite todas las demás inspecciones WAF, pero no pasa por alto el conjunto de reglas HTTP DDoS.
  • Omisión del conjunto de reglas para el tráfico de confianza. Una regla personalizada con una acción de Permitir no ayuda aquí: evita todos los demás conjuntos de reglas pero no el de HTTP DDoS. Utiliza excepciones de WAF en su lugar, que puedes aplicar a una regla específica, a un grupo de reglas específico o a un conjunto de reglas administradas completo, incluido el conjunto de reglas HTTP DDoS. Véase Excluir el tráfico de confianza con excepciones.
  • Requiere un tráfico sostenido. El conjunto de reglas solo puede actuar una vez que aprende líneas de base fiables. Si un recurso no recibe suficiente tráfico durante la fase de aprendizaje, el conjunto de reglas no lo detectará ni protegerá hasta que lo haga. Consulta la tabla de plataformas para conocer el requisito específico.

Diferencias entre plataformas

Característica Azure Front Door Premium. Application Gateway WAF v2
Fase de aprendizaje Los valores de referencia se calculan en una ventana móvil; la detección comienza en un plazo de 24 a 36 horas para los perfiles que hayan recibido tráfico durante al menos el 50 % de los últimos siete días Las líneas de base se establecen durante un mínimo de 24 horas; el conjunto de reglas no detecta ni bloquea hasta que se complete la fase de aprendizaje de 24 horas
Tráfico insuficiente Si un perfil ha recibido tráfico durante menos de 50% de los últimos siete días, el conjunto de reglas no detectará ni bloqueará hasta que exista suficiente tráfico para establecer referencias fiables Si la pasarela no recibe suficiente tráfico durante la fase de aprendizaje de 24 horas para establecer líneas de base fiables, el conjunto de reglas no detectará ni bloqueará ataques hasta que lo haga
Mitigation Las direcciones IP infractoras se colocan en una lista de penalización y se bloquean durante el tiempo que dure la penalización Las direcciones IP infractores se colocan en una caja de penalización y se bloquean durante 15 minutos
Identificadores de reglas 500100 (tasa de solicitudes del cliente), 500110 (bots sospechosos) 500100 (tasa de solicitudes del cliente), 500110 (bots sospechosos)
Métricas adicionales Web Application Firewall HTTPDDoSRuleset está activo Tamaño del área de penalización, bloques del área de penalización

Reglas del conjunto de reglas

Actualmente, el reglamento contiene dos reglas. Cada regla mantiene sus propias líneas base de tráfico y es configurable con su propia sensibilidad y acción:

Rule Descripción
500100: Anomalía detectada en alta tasa de solicitudes de clientes Establece una línea base para todo el tráfico del perfil de Front Door o de la puerta de enlace de aplicaciones a la que está asociada la directiva. Cuando un cliente supera el umbral aprendido, se activa la acción configurada y la dirección IP problemática se coloca en la caja de penalización.
500110: Posibles bots que envían un gran volumen de solicitudes Mantiene líneas de base separadas, generalmente mucho más estrictas, para el tráfico clasificado como bots por Microsoft Threat Intelligence. Los bots clasificados como de alto riesgo se bloquean inmediatamente una vez que se supera el umbral global.

El cuadro de penalización

Ambas plataformas aplican medidas de mitigación a través de una zona de penalización. Cuando el tráfico de un cliente supera el umbral de una de las reglas del conjunto de reglas, esa dirección IP del cliente se coloca en la caja de penalización y es bloqueada por el WAF durante la duración de la caja de penalización, que es de 15 minutos en la Pasarela de Aplicación. Cuando termina el período, la dirección IP recupera el acceso, a menos que vuelva a exceder el umbral, en cuyo caso regresa al período de penalización.

Este diseño es importante para cómo lees tu telemetría: solo se registra el golpe inicial de la regla. Las solicitudes bloqueadas adicionales mientras la dirección IP ya está en la caja de penalización no se registran en Puerta Principal, por lo que los recuentos basados en registros subestiman el número de solicitudes bloqueadas. En Application Gateway, utiliza la métrica de bloques de la caja de penalización para el recuento real de bloques y el tamaño de la caja de penalización para cuántas direcciones IP están actualmente penalizadas.

Monitorización durante la vista previa

Cuando una dirección IP supera un umbral, se registra una entrada de registro con una acción Bloquear para el conjunto de reglas HTTP DDoS y la métrica del WAF Managed Rule Match se incrementa.

  • Front Door: use la métrica Web Application Firewall Request count filtrada por nombre de regla para contabilizar los bloqueos, y la métrica Web Application Firewall HTTPDDoSRuleset Is Active, que informa de 1 una vez que el aprendizaje ha finalizado y el conjunto de reglas está listo para actuar frente al tráfico que supera los umbrales aprendidos.
  • Pasarela de Aplicación: cada solicitud bloqueada posterior desde una dirección IP penalizada incrementa la métrica de Igualación de Reglas Gestionadas, y las métricas de tamaño de la caja de penalización y de bloques de la caja de penalización rastrean directamente la casilla de penalización.

Exentar tráfico confiable con excepciones

Los sondes de salud, la monitorización sintética, las pruebas de carga, las integraciones con socios y los trabajos internos por lotes generan tráfico que parece una inundación pero no lo es. Históricamente, no hay forma de eximirlos del conjunto de reglas DDoS, porque una regla personalizada de Permitir omite el conjunto de reglas por defecto, el conjunto básico y la protección contra bots, pero deliberadamente no evita el conjunto de reglas HTTP DDoS.

Las excepciones de WAF cierran esa brecha. Una excepción evita la inspección WAF para solicitudes que coincidan con atributos específicos, con alcance a una sola regla, un grupo de reglas o un conjunto de reglas gestionado completo. Puedes aplicar excepciones al conjunto de reglas DDoS de HTTP, así como a DRS, CRS y Protección contra Bots.

Las excepciones coinciden en:

  • Dirección IP remota (igual o coincidencia IP), que es la opción habitual para eximir rangos conocidos de monitorización, pruebas de carga o fuentes asociadas del conjunto de reglas DDoS
  • URI de solicitud
  • Solicita nombre y valor de cabecera, emparejado con Igual, Empieza con, Termina con o Contiene

Guía para usar excepciones con el conjunto de reglas DDoS:

  • Define el alcance de la forma más acotada posible. Prefiero una excepción por regla antes que eximir todo el conjunto de reglas. Una excepción amplia ofrece a un atacante una vía documentada para eludir tu mitigación automatizada. Si un generador de carga solo necesita exención de la norma 500100, no lo eximas también de la 500110.
  • Excluya fuentes, no rutas. Una excepción basada en IP para un arnés de prueba conocido está acotada. Una excepción basada en URI en un endpoint público es una puerta abierta para cualquiera que la encuentre.
  • Revísalas de forma periódica. Las excepciones añadidas para una prueba de carga única podrían seguir vigentes un año después.
  • Cuidado con los límites. Cada política WAF soporta hasta 60 excepciones, y cada Puerta Principal soporta un total de 60 en todas las políticas asociadas. Una única excepción puede contener hasta 600 direcciones IP, 10 URI o 10 cabeceras de solicitud.
  • Las excepciones requieren el motor WAF de próxima generación y el conjunto de reglas gestionado versión DRS 2.1 o posterior.

Utiliza la herramienta adecuada para cada tarea: las exclusiones omiten la inspección de un elemento de la solicitud (una cookie o un encabezado problemático) mientras se sigue inspeccionando el resto; las excepciones omiten reglas o conjuntos de reglas específicos para las solicitudes coincidentes; una regla personalizada de Allow omite todo excepto el conjunto de reglas HTTP DDoS.

Importante

Las excepciones WAF y el conjunto de reglas HTTP DDoS están en vista previa tanto en Azure Front Door como en Application Gateway WAF v2. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.

Desafía antes de bloquear

El bloqueo es un instrumento contundente durante un ataque L7: el tráfico de ataque suele llegar desde direcciones IP y geografías que también transportan usuarios reales. Las pruebas de desafío permiten diferenciar el tráfico automatizado del tráfico humano sin los efectos colaterales de un bloqueo directo, y representan el cambio más importante en la forma en que Azure WAF gestiona los ataques de inundación de capa 7 en comparación con una estrategia de limitación de tasa basada únicamente en bloqueos.

  • El desafío de JavaScript es un desafío invisible que no requiere interacción humana. Si el navegador calcula correctamente el desafío, WAF valida al cliente como un no-bot y continúa evaluando las reglas restantes; las solicitudes que fallan se bloquean. Úsalo como el reto por defecto para el tráfico web general. Las peticiones al endpoint de desafío no se reenvían a tu backend y no cuentan para limitar la tasa.
  • CAPTCHA es un desafío interactivo que requiere la participación del usuario, reservado mejor para flujos de alto valor como inicio de sesión, registro y pago, donde el abuso automatizado es costoso y se aceptan unos segundos de fricción del usuario. La validez de la cookie de desafío es configurable en la configuración de políticas entre 5 y 1.440 minutos, con un valor por defecto de 30 minutos. El CAPTCHA implica cargos adicionales basados en el uso.

Planifica en función de las limitaciones de ambas funciones antes de desplegarlas:

  • No se soportan llamadas AJAX ni API. No pongas desafíos delante de las rutas de la API. Usa límites de tasa y reglas de coincidencia ahí en su lugar.
  • Los desafíos están diseñados para recursos HTML, no para imágenes incrustadas, CSS o archivos JavaScript.
  • En la primera petición que desencadena un desafío, el cuerpo POST está limitado a 64 KB en Azure Front Door y 128 KB en Application Gateway.
  • Ninguna de las dos funciones es compatible con Internet Explorer; ambas soportan versiones actuales de Microsoft Edge, Chrome, Firefox y Safari.
  • El desafío JavaScript se vuelve a emitir cuando cambia la dirección IP de un cliente y para solicitudes de origen cruzado (CORS).
  • En Application Gateway, el desafío de JavaScript está en vista previa y no está soportado para reglas personalizadas con límite de tasa. Application Gateway para contenedores WAF no lo soporta.

Limitación de velocidad

Como mínimo, crea una regla de límite de tasa que bloquee una alta tasa de solicitudes de cualquier cliente individual. Establece esta regla como tu límite de tasa de menor prioridad (valor numérico más alto), para que se evalúen primero reglas de límite de tasa o de coincidencia más específicas.

Azure Front Door (portal de entrada de Azure)

  • Se aplican límites de velocidad por dirección IP de socket, que es la dirección del cliente que abre la conexión TCP a Azure Front Door y podría ser un proxy en lugar del usuario final.
  • Los umbrales se evalúan durante una ventana fija de uno o cinco minutos. Una vez que se supera el umbral, Azure Front Door bloquea todo el tráfico que cumpla con la regla durante el resto de la ventana. Utiliza la ventana de cinco minutos para mitigar inundaciones HTTP: un atacante bloqueado en el primer minuto permanece bloqueado durante los cuatro restantes.
  • Las ventanas más grandes con el umbral aceptable más bajo son la configuración anti-DDoS más eficaz. Las ventanas más grandes y los valores de umbral más altos también hacen que el ajuste sea más preciso con respecto al umbral configurado. A umbrales muy bajos (por debajo de aproximadamente 200 solicitudes por minuto), algunas solicitudes por encima del umbral pueden pasar, porque las peticiones de un cliente pueden llegar a servidores Front Door cuyos contadores aún no se han actualizado.
  • Las reglas de limitación de velocidad solo admiten las acciones Registrar y Bloquear; Permitir no es compatible.
  • Aplica una regla a todo el tráfico haciendo coincidir la cabecera Host cuya longitud sea mayor que 0, porque toda solicitud válida a Azure Front Door tiene una.

Application Gateway WAF v2

  • La limitación de velocidad utiliza un algoritmo de ventana deslizante . Todo el tráfico coincidente se elimina durante la primera ventana en la que se supera el umbral. Desde la segunda ventana en adelante, se permite el tráfico hasta el umbral, lo que produce un efecto de limitación de caudal en lugar de una interrupción total para los clientes correspondientes.

  • Las reglas requieren un GroupByUserSession, que controla cómo se cuentan las solicitudes. Esta función te permite limitar la velocidad por algo distinto a la IP del cliente:

    GroupByVariable Úselo cuando
    ClientAddr (valor predeterminado) Caso normal con contadores independientes por IP fuente
    ClientAddrXFFHeader Tu gateway está detrás de un CDN o proxy y la IP real del cliente está en X-Forwarded-For
    GeoLocation Quieres limitar el tráfico por país o región durante una inundación geográficamente concentrada
    GeoLocationXFFHeader Igual que antes, usando la dirección IP en X-Forwarded-For
    None Un único contador compartido para un patrón muy parecido, como una página de inicio de sesión o una lista de agentes de usuario sospechosos

  • Las reglas de limitación de tasa requieren el motor WAF más reciente (selecciona CRS 3.2 o posterior para el conjunto de reglas predeterminado) y no son compatibles con nubes aisladas físicamente.

  • La Pasarela de Aplicación cuenta los umbrales de forma independiente para cada punto final al que está vinculada la política. Una única directiva en cinco oyentes mantiene cinco conjuntos de contadores.

  • Los umbrales no se respetan con exactitud, así que no uses la limitación de tasa para un control preciso del tráfico. Úsalo para mitigar tasas anómalas y mantener la disponibilidad. Extrema la precaución con las reglas de coincidencia amplia que usan GeoLocation o None; un umbral mal elegido puede causar interrupciones breves y frecuentes en el tráfico legítimo.

Establecer umbrales conscientes de la geografía

Un umbral global único debe ser lo suficientemente generoso para tu país más activo, lo que lo hace demasiado generoso en el resto de los casos. La mayoría de las aplicaciones tienen un perfil geográfico muy sesgado en tiempos de paz: un puñado de países o regiones producen casi todo tráfico legítimo, y el resto produce un goteo. El tráfico de ataque rara vez respeta esa distribución. Dimensionar umbrales por geografía convierte esa asimetría tanto en una señal de detección como en un control de mitigación.

Empieza midiendo tu distribución en tiempos de paz durante al menos una semana completa, de modo que se representen los efectos de días laborables, fines de semana y zonas horarias:

  • En Azure Front Door, divide la métrica de conteo de solicitudes por la dimensión ClientCountry.

  • En Log Analytics, deriva el país a partir de la dirección IP del cliente en el registro de acceso:

    AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(7d)
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize Requests = count(), Clients = dcount(clientIp_s) by Country
| extend ShareOfTraffic = round(100.0 * Requests / toscalar(
      AzureDiagnostics
      | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
      | count), 2)
| order by Requests desc

Luego agrupa los resultados en niveles y establece un umbral para cada uno:

Nivel Cuota en tiempo de paz Tratamiento recomendado
Mercados principales Los países que producen la mayor parte de tu tráfico Un umbral generoso por cliente, dimensionado a partir del propio p99 de ese país para que los usuarios reales nunca se vean afectados
Mercados secundarios Tráfico significativo pero modesto Umbral por cliente más ajustado, dimensionado a partir del p99 de ese país en lugar del global
Zonas geográficas de cola larga Un pequeño volumen de tráfico legítimo Umbral agresivo, o una acción de desafío en lugar de un bloqueo
Regiones a las que no das servicio Prácticamente cero Bloquea directamente o redirige a una página estática

Cómo implementes los niveles depende de la plataforma:

  • Application Gateway WAF v2 - use GroupByVariable: GeoLocation (o GeoLocationXFFHeader detrás de una CDN o un proxy) para que todo el tráfico de una misma zona geográfica comparta un contador, y cree una regla de limitación de velocidad para cada nivel con su propio umbral. Dado que una brecha afecta a todos los clientes de esa zona geográfica, establezca estos umbrales de forma conservadora y valídelos primero en la acción de registro: una regla geográfica de coincidencia amplia configurada incorrectamente puede provocar interrupciones breves y frecuentes en el tráfico legítimo.
  • Azure Front Door: los contadores se aplican por dirección IP de socket, por lo que debe crear los niveles con condiciones de coincidencia geográfica: una regla de límite de tasa por nivel, que coincida con los países pertinentes, cada una con su propio umbral. Cada cliente en un mercado geográfico secundario recibe entonces un límite máximo mucho más bajo que el de los clientes de tus mercados principales, sin que el comportamiento de un cliente influya en los demás.

Algunas prácticas que mantienen esto sostenible:

  • Ordena las reglas de más específica a menos específica: las reglas del mercado principal con mayor prioridad (valor numérico más bajo), luego las secundarias, luego las de cola larga, y deja la regla global de captura general como tu regla de limitación de tasa de menor prioridad.
  • Prefiere una acción de desafío en lugar de un bloqueo para las zonas geográficas de cola larga. El tráfico procedente de un país con poco volumen legítimo es sospechoso en conjunto, pero aún contiene usuarios reales: viajeros, usuarios de VPN y empleados remotos.
  • Vuelve a medir después de los lanzamientos de campañas de marketing, las expansiones regionales y los eventos importantes del producto. Una configuración con conocimiento geográfico solo es tan buena como la línea base sobre la que se dimensionó.
  • Observa la señal inversa durante un incidente: un país que normalmente contribuye con 1% de tráfico que de repente contribuye con 40% es una de las formas más rápidas de confirmar que estás viendo un ataque y no un crecimiento orgánico.

Elige un umbral a partir de tu propio tráfico

Utiliza la siguiente consulta de Log Analytics para dimensionar la regla de captura general. Para la Pasarela de Aplicaciones, sustituye FrontdoorAccessLog por ApplicationGatewayAccessLog.

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

Para dimensionar los umbrales por geografía descritos anteriormente, añade el país a la misma consulta:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

Fija el umbral por encima del percentil 99 del tráfico en tiempos de paz, no en el máximo. El valor máximo suele corresponder a un rastreador o a un cliente mal configurado, y dimensionar la regla en función de ese valor la hace demasiado permisiva para ser útil durante un ataque.

Reglas personalizadas para mitigación dirigida

Crea reglas WAF personalizadas para bloquear o limitar la velocidad de ataques HTTP y HTTPS que tengan firmas identificables, como un agente de usuario específico, encabezado, cookie, patrón de cadena de consulta, URI o una combinación de ellos. Más allá de la coincidencia de cadenas, las reglas personalizadas WAF de Azure Front Door pueden coincidir en:

  • Geolocalización: Bloquea el tráfico fuera de tu región de servicio o redirígalo a una página estática.
  • La dirección IP del cliente (CIDR) y las listas de restricciones IP para direcciones y rangos que identificaste como maliciosos.
  • Número de AS (ASN): Mitiga las inundaciones procedentes de un proveedor de hospedamiento o una red de tránsito de la que no proceden tus usuarios legítimos, sin enumerar rangos de IP.
  • Huella dactilar del cliente (JA4): Coincidencia en la huella digital JA4, un hash derivado de las características de handshake TLS y HTTP del cliente. Debido a que las herramientas de ataque y los clientes de botnet producen una huella digital consistente independientemente de la dirección IP desde la que envíen, JA4 es una de las firmas más duraderas disponibles durante un ataque distribuido: rotar entre miles de direcciones IP de origen no cambia la huella, y bloquear o limitar la velocidad en ella elimina toda la botnet con una sola regla. Verifica la huella digital comparándola con tus registros en condiciones normales antes de aplicar la medida. Los navegadores populares y los SDKs comunes comparten huellas dactilares entre un número enorme de usuarios legítimos, por lo que un bloque JA4 sin validar puede ser extremadamente amplio. Impleméntelo primero en modo Log, confirme que la huella digital aparece solo en el tráfico de ataque y, después, cambie a Bloquear o a una regla de limitación de tasa.
  • Combina JA4 con otras condiciones para lograr una mitigación precisa durante un incidente. Por ejemplo, aplica un límite de tasa en lugar de bloquear una huella digital JA4 específica y un ASN desde el que no prestas servicio a usuarios, o una huella digital JA4 y un URI de solicitud.
  • Etiqueta de servicio y restricciones de tamaño en los componentes de la solicitud.

Dos prácticas que importan durante un incidente:

  • Crea reglas de coincidencia de Permitir para el tráfico legítimo conocido con el fin de reducir los falsos positivos, y asígnales una prioridad más alta (valor numérico más bajo) que a tus reglas de bloqueo y de límite de tasa. Recuerda que una regla Allow omite otras inspecciones del WAF, pero no omite el conjunto de reglas de HTTP DDoS.
  • La evaluación de reglas se detiene en cualquier acción excepto Log, y los números de prioridad deben ser únicos. Reserva un bloque de números de baja prioridad para reglas de emergencia para poder insertar uno durante un ataque sin renumerar.

Las reglas gestionadas no están dirigidas a la defensa contra ataques DDoS, pero protegen contra otros ataques comunes y deberían mantenerse activadas. Consulta Reglas administradas (Azure Front Door) o Reglas administradas (Application Gateway).

Proteger el origen

  • Bloquear el acceso a IPs públicas en el origen y restringir el tráfico entrante para que solo Azure Front Door o Application Gateway puedan acceder a ella. Sigue las indicaciones para asegurar tráfico hacia Azure Front Door Origins.
  • Asegúrese de que no haya direcciones IP expuestas públicamente en la red virtual del Gateway de Aplicaciones.
  • Activa la caché en Azure Front Door. Las respuestas en caché absorben los picos de tráfico en la red perimetral y reducen la tasa de solicitudes que llega a tu servidor de origen, lo que a menudo marca la diferencia entre una degradación del rendimiento y una interrupción del servicio.
  • Escala los orígenes con margen de maniobra. Las mitigaciones automáticas y manuales tardan en activarse; La capacidad sobrante cubre esa carencia.

Responder a un ataque activo

  1. Confirma que es un ataque, no un crecimiento orgánico. Revisa los WAF y los registros de acceso para detectar un cambio repentino en la tasa de solicitudes, el recuento de IPs del cliente, la mezcla geográfica, la distribución de agentes de usuario y los URI solicitados.
  2. Comprueba qué ya está atenuando. Confirma que el conjunto de reglas de HTTP DDoS está activo y revisa sus bloqueos según el nombre de la regla. En Application Gateway, comprueba también las métricas Penalty box size y Penalty box blocks, ya que en los registros solo aparece el primer bloqueo de cada dirección IP. Revisa las coincidencias de las reglas de limitación de tasa.
  3. Compara la mezcla geográfica con tu línea base. Un país que normalmente aporta una pequeña cuota de tráfico dominándolo de repente es una señal de ataque rápida y de alta confianza. También te indica qué nivel de límite de tasas debes endurecer primero.
  4. Aumenta la sensibilidad antes de escribir nuevas reglas. Aumentar la sensibilidad del conjunto de reglas HTTP DDoS o reducir un umbral de límite de tasa existente es más rápido y seguro que crear una nueva regla bajo presión.
  5. Plantee un desafío en lugar de bloquear cuando el tráfico es mixto. Aplica el desafío de JavaScript a las rutas HTML afectadas y CAPTCHA a flujos sensibles.
  6. Escribe una regla dirigida solo una vez que hayas identificado una firma duradera: ASN, huella dactilar del cliente, combinación de cabecera, geografía o patrón de URI. Despliéchalo primero en Log Action si el patrón también coincide con usuarios reales.
  7. Mantén el origen protegido mientras optimizas: verifica que la caché esté activada, confirma el bloqueo del origen y escala horizontalmente.
  8. Después del incidente, vuelve a calcular los umbrales del límite de tasas con los nuevos datos de tráfico y mantén las reglas de emergencia que hayan demostrado ser correctas en modo Registro si no quieres que se apliquen continuamente.

Analizar WAF y registros de acceso

Monitoriza el tráfico usando los logs WAF de Azure para detectar anomalías y utilízalos para identificar direcciones IP sospechosas que envían un número inusualmente alto de solicitudes, cadenas de agentes de usuario inusuales o patrones anómalos de cadenas de consulta.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Principales emisores y principales agentes de usuario durante la ventana de ataque (se muestra Azure Front Door; sustituye ApplicationGatewayAccessLog por Application Gateway):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

Para más información, consulta Azure WAF with Azure Front Door y Azure WAF with Azure Application Gateway.

Contenido relacionado

  • Last updated on