Protección DDoS contra la 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 capta tráfico que la capa superior no.

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 por defecto en Azure Front Door; requiere protección de red DDoS de Azure para IPs públicas de la Puerta de Aplicación y IPs públicas de origen
Mitigación automatizada de L7 Aprende tu tráfico normal y limita el control de los clientes que incurren durante una sobrecarga, sin ajustes de emergencia Conjunto de reglas HTTP DDoS (preview) 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 límite de tasa en Puerta Principal y Pasarela de Aplicaciones
Reglas personalizadas dirigidas Bloquea una firma de ataque conocida durante un incidente Coincidir con reglas personalizadas (geo, IP, ASN, huella del cliente, cabecera, 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 DDoS, tus reglas WAF pueden ajustarse perfectamente y aún así ser evitadas por un ataque volumétrico a la IP pública del gateway. 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 frontal protegido delante de un origen no protegido y accesible públicamente no está protegido.

Para más información, consulta la visión general de Azure DDoS Protection y Protect your application gateway with 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 la base del tráfico normal y, cuando los picos indican un ataque, bloquea selectivamente a los clientes infractores sin necesidad de ajuste 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.
  • Con el alcance 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.
  • Saltarse el reglamento para tráfico confiable. 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 WAF en su lugar, que puedes asignar a una regla específica, grupo de reglas o a un conjunto de reglas gestionado completo, incluyendo el conjunto de reglas HTTP DDoS. Consulta Exenta de tráfico confiable 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 el requisito específico.

Diferencias entre plataformas

Característica Azure Front Door Premium. WAF v2 de Application Gateway
Fase de aprendizaje Las líneas base se calculan sobre una ventana móvil; La detección comienza en un plazo de 24–36 horas para perfiles que recibieron tráfico durante al menos 50% de los últimos siete días Las líneas base se aprenden durante un mínimo de 24 horas; El reglamento no detecta ni bloquea hasta que completa 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 infractores se colocan en una caja de penalización y se bloquean durante la duración de la caja Las direcciones IP infractores se colocan en una caja de penalización y se bloquean durante 15 minutos
IDs 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, bloqueos 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 la base de todo el tráfico en el perfil de puerta principal o en la pasarela de aplicación a la que está vinculada la política. 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: Sospechosos de bots enviando altas tasas 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 mitigan mediante una caja 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 periodo, la dirección IP recupera el acceso a menos que vuelva a superar el umbral, lo que la devuelve a la caja 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 de bloque para el conjunto de reglas HTTP DDoS y los incrementos de la métrica WAF Managed Rule Match .

  • Puerta Frontal: utiliza la métrica de recuento de solicitudes Web Application Firewall filtrada por nombre de regla para contar bloques, y la métrica Web Application Firewall HTTPDDoSRuleset Is Active, que informa 1 una vez que el aprendizaje está completo y el conjunto de reglas está listo para actuar sobre el 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:

  • Mira el alcance lo más limitado posible. Prefiero una excepción por regla antes que eximir todo el conjunto de reglas. Una excepción amplia otorga al atacante un camino documentado alrededor de 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.
  • Fuentes exentas, no caminos. 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 con un horario. 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 el trabajo: las exclusiones saltan la inspección de un elemento de una solicitud (una cookie o encabezado ruidoso) mientras inspeccionas el resto; las excepciones saltan reglas o conjuntos de reglas específicas para coincidir solicitudes; una regla personalizada de Permitir evita 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 los términos de uso complementarios de para las versiones preliminares de Microsoft Azure.

Reta 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. Los desafíos permiten separar la automatización de los humanos sin el daño colateral de un bloqueo total, y son el mayor cambio en cómo Azure WAF gestiona inundaciones L7 en comparación con una estrategia de límite de tasa solo por bloques.

  • 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. Ventanas más grandes y valores umbral más altos también hacen cumplir una aproximación más cercana 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 límite de tasa solo admiten acciones de registro y bloqueo ; No se permite permitir el permiso.
  • Aplica una regla a todo el tráfico emparejando en una Host cabecera con longitud mayor que 0 porque cada solicitud válida a Azure Front Door tiene una.

WAF v2 de Application Gateway

  • 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. A partir de la segunda ventana, se permite tráfico hasta el umbral, produciendo un efecto de limitación en lugar de una interrupción total para los clientes que coinciden.

  • 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 límite de tasa requieren el último motor WAF (selecciona CRS 3.2 o posterior como conjunto de reglas por defecto) y no están soportadas en nubes aisladas.

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

  • Los umbrales no se aplican exactamente, así que no uses limitación de velocidad para un control de tráfico detallado. Úsalo para mitigar tasas anómalas y mantener la disponibilidad. Usa especial precaución con las reglas de emparejamiento ancho que usan GeoLocation o None; un umbral mal elegido puede causar cortes frecuentes y cortos para 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 Reparto 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
Geografías de cola larga Un goteo de tráfico legítimo Umbral agresivo, o una acción de desafío en lugar de un bloqueo
Geografías a las que no sirves Prácticamente cero Bloquea directamente o redirige a una página estática

Cómo implementes los niveles depende de la plataforma:

  • WAF de la Puerta de Servicio de Enlace v2 : usar GroupByVariable: GeoLocation (o GeoLocationXFFHeader detrás de una CDN o proxy) para que todo el tráfico de una geografía comparta un contador, y crear una regla de límite de tasa por nivel con su propio umbral. Como una brecha actúa contra todos los clientes en esa geografía, dimensiona estos umbrales de forma conservadora y valida primero la acción de registro: una regla geológica de coincidencia amplia mal configurada puede causar cortes frecuentes y cortos para tráfico legítimo.
  • Azure Front Door - los contadores son por dirección IP de socket, así que construye los niveles con condiciones de geo-coincidencia: una regla de límite de tasa por nivel, emparejada en los países correspondientes, cada uno con su propio umbral. Cada cliente en una geografía de cola larga obtiene entonces un techo mucho más bajo que los clientes en tus mercados principales, sin que el comportamiento de un cliente afecte a los demás.

Algunas prácticas que mantienen esto sostenible:

  • Ordena las reglas de más específicas a menores: reglas de mercado primario con mayor prioridad (menor valor numérico), luego secundaria, después de cola larga, con la regla global de todo como límite de prioridad más baja.
  • Prefiero una acción de desafío a un bloque para geografías 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.
  • Remide después de lanzamientos de marketing, expansiones regionales y grandes eventos de productos. Una configuración que tiene en cuenta la geografía solo es tan buena como la base de 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 de tu propio tráfico

Utiliza la siguiente consulta de Log Analytics para dimensionar la regla 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 máximo suele ser un rastreador o un cliente mal configurado, y adaptarse a él deja la regla demasiado generosa para ayudar 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 AS (ASN): Mitigar inundaciones procedentes de un proveedor de alojamiento o red de tránsito de la que tus usuarios legítimos no proceden, 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 dactilar con tus registros de tiempo de paz antes de aplicarla. 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. Despliega primero en la acción de Registro , confirma que la huella solo aparece en el tráfico de ataque, luego cambia a Bloquear o a una regla de límite de tasa.
  • Combina JA4 con otras condiciones para mitigar quirúrgicamente durante un incidente. Por ejemplo, limita la velocidad en lugar de bloquear una huella digital específica de JA4 y un ASN desde el que no sirves usuarios, o una huella digital de JA4 y un URI de solicitud.
  • Restriccionesde etiquetas de servicio y tamaño en los componentes de la solicitud.

Dos prácticas que importan durante un incidente:

  • Crea reglas de Permitir coincidencias para tráfico legítimo conocido para reducir falsos positivos y dales una prioridad mayor (valor numérico menor) que tus reglas de límite de bloque y tasa. Recuerda que una regla de Permitir omite otras inspecciones WAF pero no el conjunto de reglas 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 gestionadas (Azure Front Door) o Reglas gestionadas (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 el volumen máximo en el borde y reducen la tasa de solicitudes que llega a tu origen, que suele ser la diferencia entre un rendimiento degradado y una caída.
  • Orígenes de la escala con headroom. 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 HTTP DDoS está activo y revisa sus bloques por nombre de regla. En Application Gateway, comprueba también el tamaño de la casilla de penalización y las métricas de bloques de caja de penalización , ya que solo aparece el primer bloque por dirección IP en los registros. Revisa las coincidencias de las reglas de límite 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. Desafia en lugar de bloquear donde el tráfico está mezclado. 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 Origin protegido mientras ajustas: verifica que la caché está activada, confirma el bloqueo de Origin y escala el espacio.
  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"

Mejores habladores y mejores agentes de usuario a través de la ventana de ataque (Azure Front Door mostrado; sustituto ApplicationGatewayAccessLog de 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