Résoudre les problèmes liés à Google Cloud Armor

Suivez ces instructions pour résoudre les problèmes liés à vos stratégies de sécurité Google Cloud Armor.

Problèmes d'ordre général

Déboguer les stratégies de sécurité

Si vous avez besoin d'informations supplémentaires sur les événements particuliers qui déclenchent des règles préconfigurées, consultez la section Utiliser la journalisation des requêtes, puis activez la journalisation détaillée. Cloud Logging enregistre dans vos journaux un niveau de détail plus élevé que vous pouvez utiliser pour analyser et déboguer vos stratégies et vos règles.

Le trafic est autorisé malgré la configuration d'une règle de refus dans la stratégie de sécurité Google Cloud Armor

Pour régler ce problème, procédez comme suit :

  1. Assurez-vous que la stratégie de sécurité Google Cloud Armor est associée à un service de backend cible. Par exemple, la commande suivante décrit toutes les données associées au service de backend BACKEND. Les résultats renvoyés doivent inclure le nom de la stratégie de sécurité Google Cloud Armor associée à ce service de backend.

    gcloud compute backend-services describe BACKEND

  2. Consultez les journaux HTTP(S) pour déterminer la stratégie et la règle correspondant à votre trafic ainsi que l'action associée. Pour afficher les journaux, utilisez Cloud Logging.

    Vous trouverez ci-dessous un exemple de journal d'une requête autorisée avec les champs intéressants mis en surbrillance. Vérifiez les champs suivants et assurez-vous qu'ils correspondent à la règle que vous avez configurée pour refuser le trafic :

    • configuredAction doit correspondre à l'action configurée dans la règle.
    • name doit correspondre au nom de la stratégie de sécurité Google Cloud Armor associée à ce service de backend.
    • outcome doit correspondre à configuredAction.
    • priority doit correspondre au numéro de priorité de la règle.
      httpRequest:
   remoteIp: 104.133.0.95
   requestMethod: GET
   requestSize: '801'
   requestUrl: http://74.125.67.38/
   responseSize: '246'
   serverIp: 10.132.0.4
   status: 200
   userAgent: curl/7.35.0
     insertId: ajvis5ev4i60
     internalId:
       projectNumber: '895280006100'
     jsonPayload:
       '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
       enforcedSecurityPolicy:
         configuredAction: ACCEPT
         name: mydev-policy-log-test1
         outcome: ACCEPT
         priority: 2147483647
       statusDetails: response_sent_by_backend
     logName: projects/mydev-staging/logs/requests
     resource:
       labels:
         backend_service_name: BACKEND_SERVICE_NAME
         forwarding_rule_name: FORWARDING_RULE_NAME
         project_id: PROJECT_ID
         target_proxy_name: TARGET_HTTP_PROXY_NAME
         url_map_name: URL_MAP_NAME
         zone: global
       type: http_load_balancer
     severity: INFO
     timestamp: '2017-04-18T18:57:05.845960288Z'

  3. Passez en revue la hiérarchie des règles pour vous assurer que la bonne règle est mise en correspondance. Il est possible qu'une règle d'une priorité plus élevée avec une action d'autorisation corresponde à votre trafic. Utilisez la commande describe sur security-policies dans Google Cloud CLI afin d'afficher le contenu de la stratégie de sécurité Google Cloud Armor.

    Ainsi, l'exemple suivant montre comment une règle d'autorisation d'une priorité plus élevée (de priorité 100) correspond au trafic provenant de l'adresse IP 1.2.3.4, ce qui empêche la règle de refus d'une priorité inférieure (de priorité 200) de se déclencher et de bloquer le trafic.

    gcloud compute security-policies describe POLICY_NAME

    Sortie :

      creationTimestamp: '2017-04-18T14:47:58.045-07:00
  description: ''
  fingerprint: Yu5spBjdoC0=
  id: '2560355463394441057'
  kind: compute#securityPolicy
  name: POLICY_NAME
  rules:
  -action: allow
   description: allow high priority rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'1.2.3.4/32'
   preview: false
   priority: 100
  -action: deny
   description: deny lower priority rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'1.2.3.0/24
   preview: false
   priority: 200
  -action: deny
   description: default rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'*'
   preview: false
   priority: 2147483647
   selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp

La règle préconfigurée renvoie des faux positifs

La détection des attaques XSS et SQLi est basée sur la correspondance de signature statique sur les en-têtes de requête HTTP et d'autres paramètres L7. Ces modèles d'expression régulière sont sujets aux faux positifs. Vous pouvez utiliser la règle préconfigurée pour la détection XSS et SQLi en mode aperçu, puis rechercher d'éventuels faux positifs dans le journal.

Si vous en trouvez un, vous pouvez comparer le contenu du trafic avec les règles ModSecurity CRS. Si la règle n'est pas valide ou n'est pas pertinente, désactivez-la à l'aide de l'expression evaluatePreconfiguredExpr et spécifiez l'ID de la règle dans l'argument exclude ID list.

Après avoir examiné les journaux et supprimé tous les faux positifs, désactivez le mode aperçu.

Pour ajouter une règle préconfigurée en mode aperçu :

  1. Créez une stratégie de sécurité avec l'ensemble d'expressions préconfiguré en mode aperçu :

    gcloud compute security-policies rules create 1000
   --security-policy POLICY_NAME
   --expression "evaluatePreconfiguredExpr('xss-stable')"
   --action deny-403
   --preview

  2. Dans les journaux HTTP(S), recherchez des champs de requête HTTP tels que url et cookie. Par exemple, le champ requestUrl se compare positivement à l'ID de règle ModSecurity CRS 941180 :

    httpRequest:
  remoteIp: 104.133.0.95
  requestMethod: GET
  requestSize: '801'
  requestUrl: http://74.125.67.38/foo?document.cookie=1010"
  responseSize: '246'
  serverIp: 10.132.0.4
  status: 200
  userAgent: curl/7.35.0
insertId: ajvis5ev4i60
internalId:
  projectNumber: '895280006100'
jsonPayload:
  '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
  enforcedSecurityPolicy:
    configuredAction: ACCEPT
    name: POLICY_NAME
    outcome: ACCEPT
    priority: 2147483647
    preconfiguredExprIds: [ 'owasp-crs-v030001-id941180-xss' ]
  statusDetails: response_sent_by_backend
logName: projects/mydev-staging/logs/requests
resource:
  labels:
    backend_service_name: BACKEND_SERVICE
    forwarding_rule_name: mydev-forwarding-rule
    project_id: mydev-staging
    target_proxy_name: mydev-target-http-proxy
    url_map_name: mydev-url-map
    zone: global
  type: http_load_balancer
severity: INFO
timestamp: '2017-04-18T18:57:05.845960288Z'

  3. Excluez l'ID de règle ModSecurity CRS 941180 en mettant à jour la règle dans la stratégie de sécurité Google Cloud Armor :

    gcloud compute security-policies rules update 1000 \
    --security-policy POLICY_NAME \
    --expression "evaluatePreconfiguredExpr('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
    --action deny-403 \
    --preview

  4. Passez en revue les journaux, puis désactivez le mode aperçu pour mettre en œuvre la règle.

Les clients avec des signatures refusées ne sont ni bloqués, ni refusés

Si vous utilisez Google Cloud Armor avec Cloud CDN, les stratégies de sécurité ne sont appliquées que pour les requêtes de contenu dynamique, les défauts de cache (miss) ou d'autres requêtes destinées au serveur d'origine du CDN. Les succès de cache (hit) sont diffusés même si la stratégie de sécurité Google Cloud Armor en aval empêche cette requête d'atteindre le serveur d'origine du CDN.

Réduisez les risques liés au corps POST qui dépasse 8 Ko lors de l'utilisation de règles WAF préconfigurées

Lorsqu'une règle WAF préconfigurée est évaluée dans une règle de sécurité Google Cloud Armor, jusqu'à 8 Ko du corps POST sont inspectés afin de détecter des correspondances de signature par rapport aux règles WAF. Cette approche fournit une inspection et une protection à faible latence de couche 7, tout en maintenant la disponibilité pour les autres clients Google.

Vous pouvez limiter le risque lié aux requêtes POST plus importantes en créant une règle dans vos règles de sécurité pour vous assurer qu'aucun contenu non inspecté n'atteint les backends. Créez une règle pour refuser le trafic dépassant 8 Ko (8 192 octets) dans la taille du corps POST. L'exemple de code suivant montre comment créer cette règle :

gcloud compute security-policies rules create 10 \
    --security-policy my-policy \
    --expression "int(request.headers['content-length']) > 8192" \
    --action deny-403 \
    --description "Block requests great than 8KB"

Problèmes liés aux listes d'adresses IP nommées

Cette section fournit des informations sur la résolution des problèmes liés aux listes d'adresses IP nommées.

Adresses IP dans une liste d'adresses IP nommée

Les adresses IP dans les listes correspondent toujours aux adresses IP des sites Web des fournisseurs répertoriés dans le guide sur les listes d'adresses IP nommées Google Cloud Armor. Si vous avez des questions sur les listes, contactez l'équipe d'assistance Cloud.

Les adresses IP d'une liste d'adresses IP nommée sont obsolètes dans Google Cloud Armor.

Google Cloud Armor synchronise quotidiennement ses listes avec des fournisseurs de listes d'adresses IP. Il est possible que des données non actualisées soient différées de quelques heures ou d'une journée par rapport à celles d'un fournisseur. Toutefois, si vous pensez que le temps de retard de ces données est plus long que prévu (par exemple, plus d'une semaine), contactez l'équipe d'assistance Cloud.

Difficulté à créer une stratégie de sécurité faisant référence à une liste d'adresses IP nommée

Vous pouvez tenter de créer une stratégie de sécurité référençant une liste d'adresses IP nommée, à l'aide d'une commande telle que :

gcloud compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-example')" \
    --action "allow"

Si la commande échoue, l'erreur qui s'affiche ressemble à ceci :

ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-example\u0027)"}'.
Error parsing Google Cloud Armor rule matcher expression: sourceiplist-example
is not a valid preconfigured expression set.

Assurez-vous que le fournisseur en question est accepté et que le nom de la liste d'adresses IP est correctement renseigné. Vous pouvez le vérifier à l'aide de la commande gcloud suivante afin de répertorier les ensembles d'expressions préconfigurés actuels :

gcloud compute security-policies list-preconfigured-expression-sets

Le trafic est bloqué malgré une règle préconfigurée pour une liste d'autorisation d'adresses IP nommée.

Il se peut que le trafic soit bloqué à partir d'une adresse IP figurant sur une liste d'adresses IP nommée :

  1. Assurez-vous que le trafic provient d'une adresse IP figurant sur une liste d'autorisation d'adresses IP nommée.

  2. Vérifiez si d'autres règles de sécurité avec une priorité plus élevée peuvent bloquer le trafic. Si le problème persiste, contactez l'équipe d'assistance Cloud.

  3. Assurez-vous que la stratégie de sécurité est associée au service de backend approprié :

    gcloud compute backend-services describe BACKEND_SERVICE

  4. Vérifiez les règles figurant dans la stratégie de sécurité. Exemple :

     gcloud compute security-policies describe POLICY_NAME

    La commande renvoie des informations semblables à ce qui suit :

    ---
…
name: POLICY_NAME
rules:
-action: allow
 description: allow fastly ip addresses
 kind: compute#securityPolicyRule
 match:
    expr:
      expression: evaluatePreconfiguredExpr('sourceiplist-fastly')
 preview: false
 priority: 100
-action: deny(403)
 description: Default rule, higher priority overrides it
 kind: compute#securityPolicyRule
 match:
    config:
      srcIpRanges:
      -'*'
    versionedExpr: SRC_IPS_V1
 preview: false
 priority: 2147483647
-action: deny(404)
 description: deny altostrat referer
 kind: compute#securityPolicyRule
 match:
    expr:
      expression: request.headers['Referer'].contains('altostrat')
 preview: false
 priority: 50
…

    La stratégie de sécurité ci-dessus contient trois règles : une règle de refus par défaut, une règle d'autorisation pour les adresses IP de Fastly et une règle de refus pour une URL de provenance contenant altostrat. Leurs priorités respectives sont également répertoriées.

  5. Examinez les journaux pour déterminer quelle règle est mise en correspondance avec votre trafic et l'action associée. Pour en savoir plus sur la journalisation, consultez la page Utiliser l'explorateur de journaux.

    Voici un exemple de journal :

     httpRequest: {
    referer: "http://www.altostrat.com/"
    remoteIp: "23.230.32.10"
    requestMethod: "HEAD"
    requestSize: "79"
    requestUrl: "http://www.example.com/"
    responseSize: "258"
    status: 404
    userAgent: "Mozilla/5.0"
  }
  …
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    enforcedSecurityPolicy: {
      configuredAction: "DENY"
      name: "POLICY_NAME"
      outcome: "DENY"
      priority: 50
    }
    statusDetails: "denied_by_security_policy"
  }
  …

    D'après le journal précédent, la requête provient de 23.230.32.10, qui est couvert par la liste d'adresses IP publiques de Fastly. Cependant, la requête est associée à une règle de refus dont la priorité est supérieure à 50. Si l'on compare cette valeur à celle figurant dans la stratégie de sécurité, la règle correspond à la règle de refus d'une URL de provenance contenant altostrat. Comme la requête contient une URL de provenance http://www.altostrat.com/, l'application des règles de sécurité fonctionne correctement.

Problèmes liés aux résultats générés par Security Command Center

Cette section contient des informations sur les problèmes liés aux résultats générés par Security Command Center.

La fiche Google Cloud Armor n'apparaît pas dans Security Command Center

Activez les résultats de Google Cloud Armor dans l'interface Security Command Center.

Les résultats de Google Cloud Armor n'apparaissent pas dans Security Command Center

Si les résultats de Google Cloud Armor n'apparaissent pas dans Security Command Center, le trafic vers les services de backend peut ne pas répondre aux critères d'obtention d'un résultat.

Pour toute question concernant le volume de trafic vers vos backends, consultez les statistiques des requêtes dans les tableaux de bord Cloud Monitoring sous Stratégies de sécurité réseau.

Les résultats sont trop bruyants

Pour obtenir de l'aide concernant ce problème, contactez l'équipe d'assistance Cloud.

Problèmes liés à Google Cloud Armor Adaptive Protection

Suivez ces instructions pour résoudre les problèmes liés à Adaptive Protection.

Adaptive Protection est activé pour une stratégie de sécurité, mais aucun journal n'est disponible dans Cloud Logging

Les journaux Adaptive Protection sont générés séparément des journaux de requêtes Google Cloud Armor et apparaissent dans une autre ressource dans Cloud Logging. Les journaux et les événements Adaptive Protection se trouvent sous la ressource Règle de sécurité du réseau dans Cloud Logging. Il faut compter une période d'entraînement d'au moins une heure après l'activation d'Adaptive Protection dans une stratégie de sécurité avant que cette fonctionnalité ne commence à générer des alertes concernant des attaques suspectes. Pendant la période d'entraînement, Adaptive Protection apprend à partir du trafic de requêtes entrantes et développe des références distinctes pour chaque service de backend protégé par cette stratégie de sécurité. Adaptive Protection peut ensuite identifier une activité suspecte.

Si vous activez Adaptive Protection pour une stratégie de sécurité et que vous n'observez aucune alerte après une période d'entraînement d'une heure, cela signifie qu'il n'y a aucune activité pouvant être identifiée comme un ciblage potentiellement malveillant sur un quelconque service de backend associé à cette stratégie de sécurité.

Si l'attaque potentielle ou le trafic anormal persistent sur des périodes plus longues, dépassant plusieurs heures, alors Adaptive Protection commence à considérer ce comportement comme un comportement de référence et ne continue pas à générer d'alertes sur des modèles de trafic similaires. Lorsque l'attaque potentielle s'estompe et les modèles de trafic sont revenus au comportement de référence d'origine, soit parce que l'attaque a pris fin, soit parce que vous l'avez bloquée avec les règles Google Cloud Armor appropriées, Adaptive Protection génère des alertes sur les comportements futurs du trafic qui vont être considérés comme des départs d'attaque par rapport au comportement de référence.

Adaptive Protection analyse le trafic qui serait autorisé par une stratégie de sécurité Google Cloud Armor. Si vous définissez la règle par défaut pour refuser avec une liste d'autorisation restreinte pour le trafic, puis Adaptive Protection détecte uniquement les activités malveillantes sur le trafic qui réussit l'évaluation avec par rapport à la liste d'autorisation.

Adaptive Protection a généré un trop grand nombre d'alertes ou de journaux dans Cloud Logging

Une alerte Adaptive Protection fournit un score de confiance, qui indique dans quelle mesure les modèles Adaptive Protection identifient l'activité détectée comme étant anormale et représentant potentiellement une attaque. Vous pouvez filtrer l'entrée spécifique du journal via Cloud Logging pour n'afficher (ou ne transférer en aval) que les alertes dont le score de confiance est supérieur à un seuil particulier.

Adaptive Protection fournit un mécanisme pour signaler les alertes constituant des faux positifs, comme décrit dans la section Surveiller, envoyer des commentaires et signaler les erreurs d'événements. Notez que le signalement de faux positifs peut ne pas entraîner de modifications immédiates sur les éléments déclenchant une alerte Adaptive Protection. Au fil du temps, les modèles Adaptive Protection apprennent à détecter que ces modèles de trafic sont normaux et acceptables, et Adaptive Protection cesse de déclencher des alertes sur ces modèles.

Si les alertes Adaptive Protection sont trop fréquentes sur un sous-ensemble de services de backend dans une stratégie de sécurité, elles peuvent suggérer que le trafic normal de ces services de backend présente des fluctuations significatives qui sont constamment identifiées par Adaptive Protection comme des comportements anormaux. Vous pouvez créer une stratégie de sécurité distincte, sans activer Adaptive Protection, et associer ces services de backend à la nouvelle stratégie de sécurité.

Un incident spécifique signalé par Adaptive Protection est considéré comme un faux positif ou n'est pas pertinent

Adaptive Protection fournit un mécanisme permettant de signaler les fausses alertes. Suivez la procédure décrite à la section Surveiller, envoyer des commentaires et signaler les erreurs d'événements. Notez que le signalement de faux positifs peut ne pas entraîner de modifications immédiates sur les éléments déclenchant une alerte Adaptive Protection. Au fil du temps, les modèles Adaptive Protection apprennent à détecter que ces modèles de trafic sont normaux et acceptables, et Adaptive Protection cesse de déclencher des alertes sur ces modèles.

Comment savoir si mes règles de sécurité périphérique sont appliquées ?

Vous pouvez vérifier les actions effectuées sur la base de vos règles de sécurité de périphérie en consultant les tableaux de bord de surveillance, les métriques de surveillance ou la journalisation par requête.

Tableaux de bord de surveillance

Cloud Monitoring est disponible sur la page Règles de sécurité réseau, sous Surveillance. Vous pouvez utiliser la répartition par règle de sécurité sur la page pour mesurer le nombre de requêtes autorisées et refusées par la règle de sécurité périphérique configurée. Vous pouvez également examiner la répartition par service de backend pour déboguer un service de backend particulier. Pour en savoir plus sur le tableau de bord Cloud Monitoring, consultez la page Surveiller les stratégies de sécurité Google Cloud Armor.

Métriques de surveillance

Les métriques brutes qui mesurent les requêtes autorisées et refusées sont disponibles pour les stratégies de sécurité périphérique. Pour en savoir plus, consultez la section Métriques de surveillance pour les stratégies de sécurité.

Journalisation par requête

La décision de la règle de sécurité périphérique est consignée dans les journaux de requête d'équilibrage de charge sous enforcedEdgeSecurityPolicy. Il s'agit d'un élément distinct de enforcedSecurityPolicy, qui capture la décision de la règle de sécurité de backend.

Gestion des robots

Cette section contient des informations sur la résolution des problèmes de gestion des robots.

Les utilisateurs ne sont pas exemptés comme prévu

Vous avez peut-être configuré des règles de stratégie de sécurité avec une action de redirection d'évaluation reCAPTCHA, et vous constatez que certains utilisateurs qui, selon vous, sont légitimes, n'ont pas été exemptés comme prévu. Suivez les étapes ci-dessous pour résoudre les problèmes.

Commencez par vérifier dans les journaux par requête s'il existe une règle de stratégie de sécurité qui correspond au trafic avec une priorité plus élevée et dans laquelle l'action est différente. Recherchez en particulier les champs configured_action et outcome. Notez que pour qu'un utilisateur soit exempté, au moins deux requêtes sont impliquées. La requête initiale est envoyée sans cookie d'exemption, et les requêtes suivantes sont accompagnées d'un cookie d'exemption si l'utilisateur passe l'évaluation reCAPTCHA. Par conséquent, au moins deux entrées de journal sont attendues.

  • Si GOOGLE_RECAPTCHA est l'action configurée et REDIRECT est l'action la requête a été redirigée pour une évaluation reCAPTCHA.
  • Si GOOGLE_RECAPTCHA apparaît en tant qu'action configurée et ACCEPT en tant que résultat, cela signifie que la requête n'a pas été exemptée de redirection vers l'évaluation reCAPTCHA.
  • Si vous voyez des valeurs différentes dans les champs ci-dessus, une règle ayant une action différente a été mise en correspondance. Dans ce cas, il est normal que l'utilisateur ne soit pas redirigé ou exempté.

Deuxièmement, il existe plusieurs exigences du côté de l'utilisateur pour qu'il soit être exemptés d'être redirigés pour l'évaluation reCAPTCHA.

  1. L'internaute doit utiliser un navigateur.
  2. Le navigateur doit activer JavaScript pour permettre le chargement correct de la redirection. avec reCAPTCHA JavaScript intégré.
  3. Le navigateur doit activer les cookies pour permettre la définition et l'association automatique du cookie d'exemption.
  4. L'utilisateur doit réussir l'évaluation reCAPTCHA. Par exemple, il doit résoudre les défis pop-up, le cas échéant.

Les utilisateurs qui ne répondent pas à l'une des exigences ci-dessus ne recevront pas d'exemption, même si une règle avec l'action de redirection pour l'évaluation reCAPTCHA est mise en correspondance.

Troisièmement, l'évaluation reCAPTCHA n'est exécutée que lorsque la redirection intégrant le code JavaScript reCAPTCHA s'affiche. Pour cela la redirection pour l'évaluation reCAPTCHA ne s'applique pour les requêtes qui attendent une réponse qui aboutira à un affichage en pleine page. Les autres requêtes, telles que le chargement des éléments d'une page ou les requêtes provenant d'un script intégré dont il n'est pas prévu d'afficher la réponse, ne sont pas censées faire l'objet d'une évaluation reCAPTCHA. Par conséquent, nous vous recommandons d'appliquer cette action avec une condition de correspondance pour les chemins d'URL qui remplissent cette condition.

Par exemple, supposons que vous ayez une page Web contenant des éléments intégrés tels que des images, des liens vers d'autres pages Web et des scripts. Vous ne souhaitez pas appliquer l'action de redirection d'évaluation reCAPTCHA aux chemins d'URL qui hébergent des images ou qui sont censés être accessibles par des scripts lorsqu'un rendu de page complet n'est pas attendu. Au lieu de cela, vous pouvez appliquer l'action de redirection pour l'évaluation reCAPTCHA pour les chemins d'URL qui hébergent des pages Web, comme la page Web principale ou d'autres pages Web associées.

Enfin, si la page de redirection s'affiche correctement, vérifiez dans l'outil de développement fourni par le navigateur si un cookie d'exemption est défini et s'il est joint aux requêtes suivantes pour le même site. Pour obtenir de l'aide, vous pouvez contacter l'équipe d'assistance Cloud.

Problèmes de limitation du débit

Le trafic n'est pas limité comme prévu

Vous constaterez peut-être que le trafic n'est pas limité comme prévu alors qu'une adresse IP cliente envoie des niveaux élevés de trafic à une application, à un taux dépassant le seuil que vous avez défini. Suivez les étapes ci-dessous pour diagnostiquer le problème.

Tout d'abord, vérifiez si une règle de priorité supérieure autorise le trafic provenant de cette adresse IP. Examinez les journaux pour voir si une règle ALLOW a été déclenchée pour l'adresse IP. Il peut s'agir d'une règle ALLOW seule, ou d'une autre règle THROTTLE ou RATE_BASED_BAN.

Si vous trouvez une règle de priorité supérieure, effectuez l'une des opérations suivantes :

  1. Modifiez les priorités pour vous assurer que la règle de limitation du débit a une priorité plus élevée en lui attribuant une valeur numérique inférieure.
  2. Excluez l'adresse IP de l'expression correspondante dans la règle ayant une priorité plus élevée.

Le problème peut également être dû à un seuil mal défini. Dans ce cas, les requêtes sont mises en correspondance avec précision, mais l'action de conformité est déclenchée. Examinez les journaux pour vérifier que c'est bien le cas, puis réduisez le seuil dans votre règle.

Enfin, l'adresse IP peut ne pas correspondre à la règle de limitation ou d'exclusion basée sur le débit. Pour résoudre ce problème, recherchez une erreur dans la condition de correspondance, puis remplacez la condition de correspondance de la règle par la valeur correcte.

Étape suivante