Fehlerbehebung bei Google Cloud Armor-Problemen

Verwenden Sie diese Anweisungen zur Fehlerbehebung bei Problemen mit Ihren Sicherheitsrichtlinien für Google Cloud Armor.

Allgemeine Probleme

Traffic ist trotz einer in der Google Cloud Armor-Sicherheitsrichtlinie konfigurierten Ablehnungsregel zulässig

Führen Sie zur Behebung die folgenden Schritte aus:

  1. Prüfen Sie, ob die Sicherheitsrichtlinie von Google Cloud Armor an einen Ziel-Back-End-Dienst angehängt ist. Der folgende Befehl beschreibt beispielsweise alle Daten, die dem Back-End-Dienst BACKEND zugeordnet sind. Die zurückgegebenen Ergebnisse sollten den Namen der Google Cloud Armor-Sicherheitsrichtlinie enthalten, die diesem Back-End-Dienst zugeordnet ist.

    gcloud compute backend-services describe BACKEND
    
  2. Prüfen Sie die HTTP(S)-Protokolle, um herauszufinden, welche Richtlinie und Regel für Ihren Traffic zusammen mit der zugehörigen Aktion übereinstimmen. Verwenden Sie Cloud Logging, um die Logs aufzurufen.

    Das folgende Beispiel zeigt eine zulässige Anfrage, in der die relevanten Felder hervorgehoben sind. Prüfen Sie, ob die folgenden Felder mit der Regel übereinstimmen, die Sie konfiguriert haben, um den Traffic abzulehnen:

    • configuredAction sollte der Aktion entsprechen, die in der Regel konfiguriert ist.
    • name sollte mit dem Namen der Google Cloud Armor-Sicherheitsrichtlinie übereinstimmen, die diesem Back-End-Dienst zugeordnet ist.
    • outcome sollte configuredAction entsprechen.
    • priority sollte der Prioritätsnummer der Regel entsprechen.
      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. Kontrollieren Sie die Hierarchie der Regeln, damit die richtige Regel abgeglichen wird. Es kann sein, dass eine Regel höherer Priorität mit einer "allow"-Aktion Ihrem Traffic entspricht. Verwenden Sie den Befehl describe in security-policies im gcloud-Befehlszeilentool, um den Inhalt der Google Cloud Armor-Sicherheitsrichtlinie anzuzeigen.

    Das folgende Beispiel zeigt, wie eine allow-Regel mit höherer Priorität (Priorität 100) mit dem Traffic von der IP-Adresse 1.2.3.4 übereinstimmt. Damit wird verhindert, dass die deny-Regel mit der niedrigeren Priorität (Priorität 200) den Traffic auslöst und blockiert.

    gcloud compute security-policies describe POLICY_NAME
    

    Ausgabe:

      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
    

Vorkonfigurierte Regel gibt falsch-positive Ergebnisse zurück

Die XSS- und SQLi-Erkennung basiert auf einem statischen Signaturabgleich mit HTTP-Anfrageheadern und anderen L7-Parametern. Diese Muster für reguläre Ausdrücke sind anfällig für falsch-positive Ergebnisse. Sie können die vorkonfigurierte Regel für die XSS- und SQLi-Erkennung im Vorschaumodus verwenden und dann das Log auf falsch-positive Werte prüfen.

Wenn Sie ein falsch-positives Ergebnis finden, können Sie den Inhalt des Traffics mit den ModSecurity-CRS-Regeln vergleichen. Wenn die Regel ungültig oder nicht relevant ist, deaktivieren Sie sie mit dem Ausdruck evaluatePreconfiguredExpr und geben Sie die Regel-ID im Argument exclude ID list an.

Deaktivieren Sie den Vorschaumodus, nachdem Sie die Logs überprüft und alle falsche positiven Ergebnisse entfernt haben.

So fügen Sie eine vorkonfigurierte Regel im Vorschaumodus hinzu:

  1. Erstellen Sie eine Sicherheitsrichtlinie mit dem vorkonfigurierten Ausdruck, der im Vorschaumodus festgelegt ist:

    gcloud compute security-policies rules create 1000
       --security-policy POLICY_NAME
       --expression "evaluatePreconfiguredExpr('xss-stable')"
       --action deny-403
       --preview
    
  2. Prüfen Sie die HTTP(S)-Logs auf HTTP-Anfragefelder wie url und cookie. Beispielsweise ist der Vergleich von requestUrl mit der CRS-Regel-ID 941180 von ModSecurity positiv:

    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. Schließen Sie die CRS-Regel-ID 941180 von ModSecurity aus. Aktualisieren Sie hierzu die Regel in der Google Cloud Armor-Sicherheitsrichtlinie.

    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. Kontrollieren Sie die Logs noch einmal und deaktivieren Sie dann den Vorschaumodus, um die Regel zu implementieren.

Clients mit abgelehnten Signaturen werden nicht blockiert oder abgelehnt

Wenn Sie Google Cloud Armor mit Cloud CDN verwenden, werden Sicherheitsrichtlinien nur für Anfragen für dynamischen Inhalt, Cache-Fehler oder andere Anfragen durchgesetzt, die für den CDN-Ursprungsserver bestimmt sind. Cache-Treffer werden auch dann bereitgestellt, wenn die nachgelagerte Google Cloud Armor-Sicherheitsrichtlinie verhindern würde, dass die Anfrage den CDN-Ursprungsserver erreicht.

Probleme mit benannten IP-Adresslisten

Dieser Abschnitt enthält Informationen zum Beheben von Problemen mit benannten IP-Adresslisten.

IP-Adressen in einer benannten IP-Adressliste

Die IP-Adressen in den Listen entsprechen immer den IP-Adressen der Anbieter-Websites, die im Google Cloud Armor-Leitfaden für benannte IP-Adresslisten aufgeführt sind. Wenn Sie Fragen zu den Listen haben, wenden Sie sich an das Cloud-Supportteam.

IP-Adressen in einer benannten IP-Adressliste in Google Cloud Armor sind veraltet

Google Cloud Armor synchronisiert seine Listen täglich mit Anbietern von IP-Adressenlisten. Es ist möglich, dass veraltete Daten vorliegen, die ein paar Stunden oder einen Tag Verzug gegenüber den Daten bei einem Anbieter aufweisen. Wenn Sie jedoch der Ansicht sind, dass die veralteten Daten länger als erwartet zurückliegen, z. B. mehr als eine Woche, wenden Sie sich an das Cloud-Supportteam.

Schwierigkeiten beim Erstellen einer Sicherheitsrichtlinie, die auf eine benannte IP-Adressliste verweist

Sie könnten eine Sicherheitsrichtlinie erstellen, die auf eine benannte IP-Adressliste verweist. Verwenden Sie dazu einen Befehl wie diesen:

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

Wenn der Befehl fehlschlägt, sieht der Fehler in etwa so aus:

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.

Prüfen Sie, ob der Anbieter unterstützt wird und der Name der IP-Adressliste korrekt angegeben ist. Sie können dies mit dem folgenden gcloud-Befehl prüfen, um die aktuellen vorkonfigurierten Ausdruckssätze aufzulisten:

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

Traffic wird trotz einer vorkonfigurierten Regel für eine benannte Zulassungsliste für IP-Adressen blockiert

Möglicherweise wird der Traffic von einer IP-Adresse blockiert, die sich in einer benannten IP-Adressliste befindet.

  1. Kontrollieren Sie, ob der Traffic von einer IP-Adresse kommt, die sich auf einer benannten Liste zugelassener IP-Adressen befindet.

  2. Prüfen Sie, ob andere Sicherheitsregeln mit einer höheren Priorität den Traffic blockieren können. Sollte das Problem weiterhin bestehen, wenden Sie sich an das Cloud-Supportteam.

  3. Prüfen Sie, ob die Sicherheitsrichtlinie mit dem richtigen Back-End-Dienst verknüpft ist:

    gcloud compute backend-services describe BACKEND_SERVICE
    
  4. Prüfen Sie die Regeln in der Sicherheitsrichtlinie. Beispiel:

     gcloud compute security-policies describe POLICY_NAME
    

    Die Ausgabe des Befehls sieht in etwa so aus:

    ---
    …
    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 xyz referer
     kind: compute#securityPolicyRule
     match:
        expr:
          expression: request.headers['Referer'].contains('xyz')
     preview: false
     priority: 50
    …
    

    Die obige Sicherheitsrichtlinie enthält drei Regeln: eine standardmäßige "deny"-Regel, eine "allow"-Regel zum Zulassen von IP-Adressen von Fastly und eine "deny"-Regel für eine Referenz, die xyz enthält. Die jeweiligen Prioritäten sind ebenfalls aufgeführt.

  5. Prüfen Sie die Logs, um festzustellen, welche Regel mit Ihrem Traffic und der zugehörigen Aktion übereinstimmt. Weitere Informationen zum Logging finden Sie unter Logs in der Legacy-Loganzeige ansehen für die Cloud Logging API.

    Das folgende Beispiel zeigt ein Protokoll:

     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: "POLICY_NAME"
          outcome: "DENY"
          priority: 50
        }
        statusDetails: "denied_by_security_policy"
      }
      …
    

    Die Anfrage aus dem vorhergehenden Log stammt von 23.230.32.10, das von der öffentlichen IP-Adressliste von Fastly abgedeckt ist. Die Anfrage wird jedoch mit einer deny-Regel mit einer höheren Priorität von 50 abgeglichen. Beim Vergleich mit dem Inhalt der Sicherheitsrichtlinie entspricht die Regel der deny-Regel für einen Referrer, der xyz enthält. Da die Anfrage den Referrer http://www.xyz.com/ enthält, funktioniert die Erzwingung der Sicherheitsregel ordnungsgemäß.

Probleme mit Ergebnissen im Security Command Center

Die Google Cloud Armor-Karte wird nicht im Security Command Center angezeigt

Aktivieren Sie die Google Cloud Armor-Ergebnisse in der Security Command Center-Oberfläche.

Ergebnisse aus Google Cloud Armor werden nicht im Security Command Center angezeigt

Wenn die Ergebnisse von Google Cloud Armor nicht im Security Command Center angezeigt werden, erfüllt der Traffic zu den Back-End-Diensten möglicherweise nicht die Kriterien dafür.

Prüfen Sie bei Fragen zum Trafficvolumen zu Ihren Back-Ends die Anfragestatistik in den Cloud Monitoring-Dashboards unter Netzwerksicherheitsrichtlinie.

Die Ergebnisse sind zu ungenau

Wenn Sie Hilfe zu diesem Problem benötigen, wenden Sie sich an das Cloud-Supportteam.

Nächste Schritte