Fehlerbehebung bei Cloud Armor-Problemen

Verwenden Sie diese Anweisungen zur Fehlerbehebung bei Problemen mit Google Cloud Armor-Sicherheitsrichtlinien.

Allgemeine Probleme

In diesem Abschnitt werden häufige Probleme behandelt, die bei der Verwendung von Cloud Armor auftreten.

Debugging von Sicherheitsrichtlinien

Wenn Sie weitere Informationen zu bestimmten Ereignissen benötigen, die vorkonfigurierte Regeln auslösen, lesen Sie Anfrage-Logging verwenden und aktivieren Sie die ausführliche Protokollierung. Cloud Logging zeichnet eine höhere Detailebene in Ihren Logs auf, mit der Sie Ihre Richtlinien und Regeln analysieren und Fehler beheben können.

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

Führen Sie zur Behebung die folgenden Schritte aus:

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

    gcloud compute backend-services describe BACKEND

    Ersetzen Sie BACKEND durch den Namen des Backend-Dienstes.

  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 muss der Aktion entsprechen, die in der Regel konfiguriert ist.
    • name muss mit dem Namen der Cloud Armor-Sicherheitsrichtlinie übereinstimmen, die diesem Backend-Dienst zugeordnet ist.
    • outcome muss mit configuredAction übereinstimmen.
    • priority muss 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'

    Diese Ausgabe enthält die folgenden Werte:

    • BACKEND_SERVICE_NAME: der Name des Backend-Dienstes.
    • FORWARDING_RULE_NAME: der Name der Weiterleitungsregel.
    • PROJECT_ID: die Projekt-ID.
    • TARGET_HTTP_PROXY_NAME: der Name des Ziel-HTTP-Proxys.
    • URL_MAP_NAME: der Name des URL-Mappings.

  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 für die security-policies in der Google Cloud CLI, um den Inhalt der Cloud Armor-Sicherheitsrichtlinie aufzurufen.

    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

    Ersetzen Sie POLICY_NAME durch den Namen der Sicherheitsrichtlinie.

    Die Ausgabe sieht etwa so aus:

    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 Layer 7-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 OWASP CRS-Regeln vergleichen. Wenn Sie von einer älteren CRS-Version migrieren, finden Sie im Versionsvergleich der WAF-Regeln eine Liste der Regel änderungen und -umbenennungen. Wenn die Regel ungültig oder nicht relevant ist, deaktivieren Sie sie mit dem Ausdruck evaluatePreconfiguredWaf 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 "evaluatePreconfiguredWaf('xss-stable')"
     --action deny-403
     --preview

    Ersetzen Sie POLICY_NAME durch den Namen der Sicherheitsrichtlinie.

  2. Prüfen Sie die HTTP(S)-Logs auf HTTP-Anfragefelder wie url und cookie. Beispielsweise ist der Vergleich von requestUrl mit der OWASP CRS-Regel-ID 941180 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-v042200-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'

    Dieses Log enthält die folgenden Werte:

    • POLICY_NAME: der Name der Sicherheitsrichtlinie.
    • BACKEND_SERVICE: der Name des Backend-Dienstes.

  3. Schließen Sie die OWASP CRS-Regel-ID 941180 aus. Aktualisieren Sie hierzu die Regel in der Cloud Armor-Sicherheitsrichtlinie.

     gcloud compute security-policies rules update 1000 \
     --security-policy