Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Trusted Cloud von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei Cloud Armor-Problemen

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

Allgemeine Probleme

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:

Prüfen Sie, ob die Cloud Armor-Sicherheitsrichtlinie 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 Cloud Armor-Sicherheitsrichtlinie enthalten, die diesem Back-End-Dienst zugeordnet ist.
```
gcloud compute backend-services describe BACKEND
```

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

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 den security-policies des 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

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 OWASP-CRS-Regeln vergleichen. 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:

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

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

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 POLICY_NAME \
    --expression "evaluatePreconfiguredWaf('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
    --action deny-403 \
    --preview

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 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 Cloud Armor-Sicherheitsrichtlinie verhindern würde, dass die Anfrage den CDN-Ursprungsserver erreicht.

Probleme mit der Ratenbegrenzung

Traffic wird nicht wie erwartet gedrosselt

Angenommen, Sie stellen fest, dass eine Client-IP-Adresse sehr viel Traffic an eine Anwendung mit einer Rate sendet, die den von Ihnen festgelegten Grenzwert überschreitet, der Traffic jedoch nicht wie erwartet gedrosselt wird. Um das Problem zu untersuchen, führen Sie die im Folgenden Schritte aufgeführten aus.

Prüfen Sie zuerst, ob eine Regel mit höherer Priorität Traffic von dieser IP-Adresse zulässt. Prüfen Sie anhand der Logs, ob eine ALLOW-Regel für die IP-Adresse ausgelöst wurde. Dies kann eine einzelne ALLOW-Regel sein oder in Verbindung mit einer anderen THROTTLE- oder RATE_BASED_BAN-Regel auftreten.

Wenn eine Regel mit höherer Priorität vorhanden ist, führen Sie einen der folgenden Schritte aus:

Ändern Sie die Prioritäten und legen Sie für Ratenbegrenzungsregel eine höhere Priorität fest. Weisen Sie ihr dazu einen niedrigeren numerischen Wert zu.
Schließen Sie die IP-Adresse aus dem Abgleichausdruck in der Regel mit der höheren Priorität aus.

Das Problem kann auch auftreten, weil der Grenzwert falsch festgelegt wurde. In diesem Fall werden die Anfragen exakt abgeglichen, die Compliance-Aktion wird aber ausgelöst. Prüfen Sie anhand der Logs, ob dies der Fall ist, und reduzieren Sie dann den Grenzwert in Ihrer Regel.

Schließlich stimmt möglicherweise die IP-Adresse nicht mit der Regel zur Drosselung oder ratenbasierten Sperre überein. Um dieses Problem zu beheben, prüfen Sie auf einen möglichen Fehler in der Abgleichbedingung und ändern Sie dann die Abgleichbedingung der Regel auf den richtigen Wert.

Nächste Schritte

Supportoptionen