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.

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

  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 my-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 my-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. Utilisez Cloud Logging pour afficher les journaux.

    Voici un exemple de journal d'une requête autorisée avec les champs intéressants en gras. 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.
    • outcome doit correspondre à configuredAction ci-dessus.
    • priority doit correspondre au numéro de priorité de la règle.
    • name doit correspondre au nom de la stratégie de sécurité Google Cloud Armor associée à ce service de backend.
    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: ''
           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. 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 les stratégies de sécurité dans l'outil de ligne de commande gcloud pour afficher le contenu de la stratégie de sécurité Google Cloud Armor.

    Par exemple, l'exemple suivant montre comment une règle d'autorisation d'une priorité supérieure (à la priorité 100) correspond au trafic provenant de l'adresse IP 1.2.3.4, empêchant ainsi la règle de refus d'une priorité inférieure (à la priorité 200) de se déclencher et de bloquer le trafic.

    gcloud compute security-policies describe my-policy
    
    creationTimestamp: '2017-04-18T14:47:58.045-07:00
    description: ''
    fingerprint: Yu5spBjdoC0=
    id: '2560355463394441057'
    kind: compute#securityPolicy
    name: my-policy
    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 my-policy
       --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: my-policy
        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: ''
        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 my-policy \
       --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.

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

Si vous tentez de créer une stratégie de sécurité faisant référence à une liste d'adresses IP nommée et que la commande échoue, une erreur ressemblant à ceci s'affiche :

gcloud beta compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-abc')" \
    --action "allow"
ERROR: (gcloud.beta.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-abc\u0027)"}'. Error parsing Cloud Armor rule matcher expression: sourceiplist-abc 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é. Pour le vérifier, répertoriez les ensembles d'expressions préconfigurés actuels à l'aide de cette commande gcloud :

gcloud beta 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. Assurez-vous que le trafic provient d'une adresse IP figurant sur une liste d'autorisation d'adresses IP nommée. Ensuite, 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.

Tout d'abord, assurez-vous que la stratégie de sécurité est associée au backend approprié :

gcloud compute backend-services describe my-backend-service

Ensuite, vérifiez les règles figurant dans la stratégie de sécurité. Exemple :

 gcloud compute security-policies describe my-policy
---
…
name: my-policy
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 xyz referer
  kind: compute#securityPolicyRule
  match:
    expr:
      expression: request.headers['Referer'].contains('xyz')
  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 "xyz". Leurs priorités respectives sont également répertoriées.

Examinez ensuite 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 section Afficher les journaux (classique).

Voici un exemple de journal :

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

D'après le journal ci-dessus, la requête provient de 23.230.32.10, qui est couvert par la liste d'adresses IP publiques de Fastly, telle que présentée sur https://api.fastly.com/public-ip-list. 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 xyz. Comme la requête contient une URL de provenance http://www.xyz.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

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, il est possible que le trafic vers les services de backend ne réponde pas aux critères de génération d'un résultat.
  • Pour les questions sur le volume de trafic vers vos backends, consultez les statistiques de requête dans les tableaux de bord Cloud Monitoring, sous la ressource Règle de sécurité du réseau.

Les résultats sont trop bruyants

Contactez l'équipe d'assistance Cloud pour obtenir de l'aide concernant ce problème.