Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

Cette page a été traduite par l'API Cloud Translation.

Résoudre les problèmes liés à 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é Cloud Armor

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

Assurez-vous que la stratégie de sécurité 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 règle de sécurité Cloud Armor associée à ce service de backend.
```
gcloud compute backend-services describe BACKEND
```

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é 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'

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é 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 OWASP CRS. Si la règle n'est pas valide ou n'est pas pertinente, désactivez-la à l'aide de l'expression evaluatePreconfiguredWaf 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 :

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 "evaluatePreconfiguredWaf('xss-stable')"
   --action deny-403
   --preview

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 OWASP 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'

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

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

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 Cloud Armor avec Cloud CDN, les règles 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é Cloud Armor en aval empêche cette requête d'atteindre le serveur d'origine du CDN.

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 :

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.
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

Obtenir de l'aide