Descripción general del límite de frecuencia

Google Cloud Armor proporciona protección para tus aplicaciones de Google Cloud contra una variedad de ataques de la capa 3 y la capa 7. Las reglas basadas en tarifas te ayudarán a proteger tus aplicaciones de un gran volumen de solicitudes que llenan tus instancias y bloquean el acceso de los usuarios legítimos.

El límite de frecuencia puede hacer lo siguiente:

• Evitar que un cliente en particular agote los recursos de aplicaciones
• Protege tus instancias de aplicación contra aumentos erráticos e impredecibles en la tasa de solicitudes de los clientes.

Además, cuando un recurso se presenta a un gran volumen de tráfico desde una pequeña cantidad de clientes, puedes evitar que tus otros clientes se vean afectados por grandes aumentos de tráfico de esa pequeña cantidad de clientes, lo que habilita tus recursos para manejar la mayor cantidad de solicitudes posible.

Google Cloud Armor tiene dos tipos de reglas basadas en tarifas:

1. Limitación: Puedes aplicar un límite de solicitud máximo por cliente o en todos los clientes si regulas los clientes individuales a un umbral configurado por el usuario.
2. Bloqueo basado en tarifa: Puedes limitar la cantidad de solicitudes que coinciden con una regla por cliente y, luego, bloquear de forma temporal a esos clientes durante un período configurado si exceden un límite configurado por el usuario.

Si configuras una regla con una acción de bloqueo basada en la tarifa, no podrás cambiarla a una y limitar la acción más adelante. Sin embargo, cuando configuras una regla con una acción de limitación, puedes cambiarlo más adelante por una acción de bloqueo basada en la tarifa. Para obtener más información, consulta Límite de frecuencia basado en varias claves.

Google Cloud Armor aplica el umbral de límite de frecuencia a cada backend. Por ejemplo, si tienes dos servicios de backend y configuras una tarifa regla de límite con un umbral de 1,000 solicitudes por minuto, entonces cada backend puede recibir 1,000 solicitudes por minuto antes de que Google Cloud Armor aplica la acción de la regla.

Puedes obtener una vista previa de los efectos de las reglas de límite de frecuencia en una política de seguridad mediante el modo de vista previa y examinando los registros de tu solicitud.

Identifica clientes para el límite de frecuencia

Google Cloud Armor identifica clientes individuales para el límite de frecuencia mediante los siguientes tipos de claves a fin de agregar solicitudes y aplicar límites de frecuencia:

• TODO: Es una clave única para todos los clientes cuyas solicitudes cumplen con la condición de coincidencia de la regla.
• IP: Es una clave única para cada dirección IP de origen de cliente cuyas solicitudes cumplen con la condición de coincidencia de la regla.
• HTTP_HEADER: Una clave única para cada valor de encabezado HTTP único cuyo nombre es configurado. El valor de la clave se trunca a los primeros 128 bytes del valor del encabezado. El tipo de clave predeterminado es ALL si no existe tal encabezado o si intenta usar este tipo de clave con un balanceador de cargas de red del proxy externo.
• XFF_IP: una clave única para cada dirección IP de origen original del cliente es decir, la primera dirección IP de la lista de IP especificada en el Encabezado HTTP X-Forwarded-For. Si no hay ninguna, el tipo de clave se establece como la dirección IP. este encabezado está presente, si el valor no es una dirección IP válida o si intenta usar este tipo de clave con un balanceador de cargas de red del proxy externo.
• HTTP_COOKIE: Una clave única para cada valor de cookie HTTP cuyo nombre es configurado. El valor de la clave se trunca a los primeros 128 bytes del valor del encabezado. El tipo de clave se establece de forma predeterminada en ALL si no hay tal cookie presente o si deseas intenta usar este tipo de clave con un balanceador de cargas de red del proxy externo.
• HTTP_PATH: Es la ruta de URL de la solicitud HTTP. El valor de la clave se trunca a los primeros 128 bytes.
• SNI: La indicación de nombre del servidor en la sesión TLS de la solicitud HTTPS. El valor de la clave se trunca a los primeros 128 bytes. El tipo de clave se establece de forma predeterminada en ALL en una sesión de HTTP.
• REGION_CODE: Es el país o la región donde se origina la solicitud.
• TLS_JA3_FINGERPRINT: Huella digital TLS/SSL de JA3 si el cliente se conecta mediante HTTPS, HTTP/2 o HTTP/3. Si no está disponible, el tipo de clave se establece de forma predeterminada en TODOS Para obtener más información sobre JA3, consulta la referencia del lenguaje de las reglas.
• USER_IP: la dirección IP del cliente de origen, incluida en los encabezados configurado en userIpRequestHeaders y cuyo valor se completa con un proxy upstream. Si no hay una configuración userIpRequestHeaders o una IP no se puede resolver desde ella, el tipo de clave predeterminado es IP. Para ver más información, consulta la referencia del lenguaje de las reglas.

Puedes usar las claves anteriores de forma individual o puedes aplicar el límite de frecuencia según una combinación de hasta tres teclas. Puedes usar varios HTTP-HEADER o HTTP-COOKIE, y solo uno de los otros tipos de claves. Para ver más información, consulta Límite de frecuencia basado en varias claves.

Nota: Los datos clave del límite de frecuencia se clasifican como Datos del Servicio, lo que se procesan como se describe en el Aviso de Privacidad de Google Cloud. Los datos clave del límite de frecuencia no se tratan como Datos del cliente. Si tu carga de trabajo está sujeta a regímenes regulatorios o a otros requisitos de cumplimiento requisitos que requieren transparencia o aprobación de acceso revisa los tipos de clave cuyos valores pueden contener información sensible.

Tráfico de regulación

La acción throttle en una regla te permite aplicar una solicitud por cliente de seguridad para proteger los servicios de backend. Esta regla aplica el umbral para limitar el tráfico de cada cliente que cumpla con las condiciones de coincidencia en la regla. El umbral se configura como una cantidad específica de solicitudes en un intervalo de tiempo determinado.

Por ejemplo, puedes establecer el límite de la solicitud en 2,000 solicitudes en 1,200 segundos (20 minutos). Si un cliente envía 2,500 solicitudes en un período de 1,200 segundos, se limita alrededor del 20% del tráfico del cliente hasta que el volumen de solicitudes permitido sea igual o inferior al umbral establecido.

Cuando la tasa de tráfico de un cliente es inferior o igual a rate_limit_threshold_count, las solicitudes siguen el conform_action que siempre es una acción allow. La solicitud permite la política de seguridad y llega a su destino. Cuando la tasa de tráfico de un cliente supera el rate_limit_threshold_count especificado, Google Cloud Armor aplica exceed_action, que puede ser deny o redirect para las solicitudes para el resto del intervalo del umbral.

Establece estos parámetros para controlar la acción:

• rate_limit_threshold_count: Es la cantidad de solicitudes por cliente permitidas dentro de un intervalo de tiempo especificado. El valor mínimo es 1, y el valor máximo es 10,000.
  • interval_sec: Es la cantidad de segundos en el intervalo de tiempo. El valor debe ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 segundos.
• exceed_action: Cuando una solicitud supera el rate_limit_threshold_count, Google Cloud Armor aplica el exceed_action configurado. Los valores posibles para exceed_action son los siguientes:
  • deny(status): Se rechaza la solicitud y se muestra el código de error especificado Se muestran (los valores válidos son 403, 404, 429 y 502). Te recomendamos que utilices Código de respuesta 429 (Too Many Requests).
  • redirect: La solicitud se redirecciona a reCAPTCHA. evaluación o a una URL diferente, según el exceed_redirect_options parámetro.
• exceed_redirect_options: Cuando exceed_action es redirect, usa este parámetro para especificar la acción de redireccionamiento:
  • type: Escribe para la acción de redireccionamiento, ya sea GOOGLE_RECAPTCHA o EXTERNAL_302.
  • target: Es el objetivo de URL para la acción de redireccionamiento. Solo es aplicable cuando type es EXTERNAL_302.
• conform_action: Esta es la acción que se realiza cuando la cantidad de solicitudes es menor que rate_limit_threshold_count. Siempre es una acción allow.

Bloquear clientes según los porcentajes de solicitudes

La acción rate_based_ban en una regla te permite aplicar una configuración por cliente para bloquear temporalmente a los clientes que superen el límite configuró exceed_action para todas las solicitudes del cliente de una configuración durante un período de tiempo. El umbral se configura como una cantidad específica de solicitudes en un intervalo de tiempo determinado. Puedes bloquear el tráfico de forma temporal durante un período configurado por el usuario ('ban_duration_sec'), siempre que el tráfico coincida con la condición de coincidencia especificada y exceda el umbral configurado.

Por ejemplo, puedes establecer el límite de la solicitud en 2,000 solicitudes en 1,200 segundos (20 minutos). Si un cliente envía 2,500 solicitudes en un plazo de 1,200 segundos, Google Cloud Armor aplica el exceed_action al tráfico de ese cliente que supere los 2,000 segundos hasta que hayan transcurrido 1,200 segundos completos y por un tiempo adicional la cantidad de segundos que estableces como período de duración del bloqueo. Si el período de duración del bloqueo se establece en 3600, por ejemplo, el tráfico del cliente se prohibiría durante 3,600 segundos (una hora) después del final del intervalo límite.

Cuando el porcentaje de solicitudes de un cliente está por debajo del límite de frecuencia, se permite de inmediato que la solicitud continúe con el servicio de backend. Cuando la tasa de tráfico de un cliente supera el rate_limit_threshold_count especificado, Google Cloud Armor aplica el exceed_action a todas las solicitudes entrantes del cliente durante el resto del intervalo límite y el siguiente ban_duration_sec segundos, sin importar si se superó o no el umbral.

Con esta configuración, es posible bloquear de manera accidental los clientes de bienvenida que solo excedan la tasa de solicitudes permitidas. Para evitar esto y bloquear solo a los clientes que suelen superar el porcentaje de solicitudes, tiene la opción de realizar un seguimiento de las solicitudes totales de los clientes en comparación con una configuración de umbral adicional, preferentemente más larga, llamada ban_threshold_count. En este modo, el cliente está bloqueado para el ban_duration_sec configurado solo si el porcentaje de solicitudes supera el ban_threshold_count configurado. Si el porcentaje de solicitudes no supere el ban_threshold_count, se seguirán limitando las solicitudes a rate_limit_threshold_count. A los efectos de ban_threshold_count, el total del cliente, que consisten en todas las solicitudes entrantes antes de la limitación, se cuentan.

Estos parámetros controlan la acción de una regla rate_based_ban:

• rate_limit_threshold_count: Es la cantidad de solicitudes por cliente permitidas dentro de un intervalo de tiempo especificado. El valor mínimo es 1 y el valor máximo es 10,000.
  • interval_sec: Es la cantidad de segundos en el intervalo de tiempo. El valor debe ser 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 o 3600 segundos.
• exceed_action: Cuando una solicitud supera el rate_limit_threshold_count, Google Cloud Armor aplica el exceed_action configurado. Los valores posibles para exceed_action son los siguientes:
  • deny(status): Se rechaza la solicitud y se muestra el código de error especificado. Los valores válidos para el código de error son 403, 404, 429 y 502. Mié se recomienda usar el código de respuesta 429 (Too Many Requests).
  • redirect: La solicitud se redirecciona a reCAPTCHA. evaluación o a una URL diferente, según el exceed_redirect_options parámetro.
• exceed_redirect_options: Cuando exceed_action es redirect, usa este parámetro para especificar la acción de redireccionamiento:
  • type: Escribe para la acción de redireccionamiento, ya sea GOOGLE_RECAPTCHA o EXTERNAL_302.
  • target: Es el objetivo de URL para la acción de redireccionamiento. Solo es aplicable cuando type es EXTERNAL_302.
• conform_action: Esta es la acción que se realiza cuando la cantidad de solicitudes es menor que rate_limit_threshold_count. Siempre es una acción allow.
• ban_threshold_count: Esta es la cantidad de solicitudes permitidas por cliente. dentro de un intervalo de tiempo específico, durante el cual Google Cloud Armor bloquea solicitudes. Si se especifica, la clave se bloquea en las instancias ban_duration_sec cuando la cantidad de solicitudes que exceden la rate_limit_threshold_count también superan este valor de ban_threshold_count.
  • ban_threshold_interval_sec: la cantidad de segundos en el intervalo de tiempo para tu ban_threshold_count. El valor debe ser 10, 30, 60, 120, 180, 240. 300, 600, 900, 1200, 1800, 2700 o 3, 600 segundos.
• ban_duration_sec: Esta es la cantidad adicional de segundos en los que se bloquea a un cliente después de que transcurrió el período interval_sec. El valor debe ser 60, 120, 180, 240, 300, 600, 900, 1,200, 1,800, 2,700 o 3,600 segundos.

Política de seguridad de límite de frecuencia predeterminada

Cuando configuras unapolítica de seguridad predeterminada durante la creación del balanceador de cargas, el umbral predeterminado es de 500 solicitudes durante cada intervalo de un minuto (un rate_limit_threshold_count y interval_sec de 500 y 60, respectivamente). Si deseas seleccionar un umbral diferente, te recomendamos que sigas los pasos que se indican a continuación para ajustar los parámetros:

1. Habilita Cloud Logging y consulta la cantidad máxima cantidad de solicitudes que llegaron por dirección IP y por minuto durante un día o más tiempo en tu servicio de backend protegido por Google Cloud Armor.

   Por ejemplo, supongamos que crees que el 99% del tráfico de red que recibes no debería verse afectado por la regla de límite de frecuencia. En este caso, recomendamos que establezcas tu umbral de límite de frecuencia en el percentil 99 de la cantidad máxima de solicitudes por dirección IP y por minuto de distribución generado a partir de los datos de Cloud Logging.

2. Si aún observas reglas de límite de frecuencia predeterminadas que bloquean el tráfico legítimo, considera realizar los siguientes pasos adicionales:

   1. Habilita el almacenamiento en caché (Cloud CDN o Media CDN).
   2. Aumenta el intervalo de tiempo de la limitación (solicitudes recibidas por varios minutos, en lugar de por 60 segundos).
   3. Puedes bloquear a los clientes para reducir aún más el impacto del ataque después de la ola inicial. La acción rate_based_ban de Google Cloud Armor te permite hacerlo mediante el bloqueo de todos los clientes que excedan los límites demasiadas veces dentro de un período especificado por el usuario. Por ejemplo, se puede bloquear durante 15 minutos a los clientes que superen los límites 10 veces en un minuto.

Aplicación de umbrales

Los límites configurados para la regulación y las bloqueos basadas en tasas se aplican de forma independiente en cada una de las regiones de Google Cloud en las que se implementan tus servicios de backend HTTP(S). Por ejemplo, si tu servicio se implementa en dos regiones, cada una de las dos regiones limita cada clave al umbral configurado, por lo que tu servicio de backend puede experimentar volúmenes de tráfico agregado entre regiones que son el doble del límite configurado. Si el umbral configurado se establece en 5,000 solicitudes, el servicio de backend puede recibir 5,000 solicitudes de una región y 5,000 solicitudes de la segunda región.

Sin embargo, para la dirección IP del tipo de clave, es razonable suponer que el tráfico de la misma dirección IP de cliente se dirige a la región más cercana a la región en la que se implementan los backends. En este caso, el límite de frecuencia se puede considerar como aplicable a nivel de servicio de backend, sin importar las regiones en las que se implemente.

Es importante tener en cuenta que los límites de frecuencia que se aplican son aproximados y pueden no ser estrictamente precisos en comparación con los umbrales configurados. Además, en casos excepcionales, debido al comportamiento de enrutamiento interno, es posible que el límite de frecuencia se aplique en más regiones que las regiones en las que se implementan, lo que afecta la exactitud. Por estos motivos, te recomendamos que uses el límite de frecuencia solo para la mitigación de abusos o a fin de mantener la disponibilidad de las aplicaciones y los servicios, no para aplicar requisitos estrictos de cuota o licencia.

Logging

Cloud Logging registra el nombre de la política de seguridad, la prioridad de la regla de límite de frecuencia coincidente, el ID de la regla, la acción asociada y otra información en tus registros de solicitudes. Para obtener más información sobre el registro detallado, consulta Usa el registro de solicitudes.

Integración en reCAPTCHA

Puedes aplicar límite de frecuencia a algunos recursos de reCAPTCHA para hacer lo siguiente: mitigar el abuso de tokens y limitar su reutilización. Estos recursos incluyen tokens de acción, tokens de sesión y cookies de exención. Para obtener más información usando el límite de frecuencia con reCAPTCHA, consulta el Descripción general de la administración de bots.

¿Qué sigue?

• Configura el límite de frecuencia