Fehlerbehebung bei Google 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 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, mit dem Back-End-Dienst BACKEND verknüpft ist. 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 muss mit dem Namen der Google Cloud Armor-Sicherheitsrichtlinie übereinstimmen die an diesen Back-End-Dienst angehängt sind.
    • 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 den security-policies des Google Cloud CLI, um den Inhalt der Google 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 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.

Risiko für POST-Textkörper minimieren, der 8 KB überschreitet, wenn vorkonfigurierte WAF-Regeln verwendet werden

Wenn eine vorkonfigurierte WAF-Regel in einer Google Cloud Armor-Sicherheitsrichtlinie ausgewertet wird, werden bis zu 8 KB des POST-Textkörpers auf Signaturübereinstimmungen mit den WAF-Regeln geprüft. Dieser Ansatz bietet Ihnen eine Layer-7-Prüfung und Layer-7--Schutz mit niedriger Latenz und gleichzeitig die Verfügbarkeit für andere Google-Kunden.

Sie können das Risiko von größeren POST-Anfragen minimieren. Erstellen Sie dazu in Ihren Sicherheitsrichtlinien eine Regel, damit keine nicht geprüften Inhalte Ihre Back-Ends erreichen. Erstellen Sie eine Regel, die Traffic über 8 KB (8.192 Byte) in der POST-Textgröße ablehnt. Das folgende Codebeispiel zeigt, wie diese Regel erstellt wird:

gcloud compute security-policies rules create 10 \
    --security-policy my-policy \
    --expression "int(request.headers['content-length']) > 8192" \
    --action deny-403 \
    --description "Block requests great than 8KB"

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 compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-example')" \
    --action "allow"

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

ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-example\u0027)"}'.
Error parsing Google Cloud Armor rule matcher expression: sourceiplist-example
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 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. Achten Sie darauf, dass die Sicherheitsrichtlinie an das richtige Back-End angehängt ist Dienst:

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

    Die obige Sicherheitsrichtlinie enthält drei Regeln: eine Standard-Ablehnungsregel, eine Regel zum Zulassen der IP-Adressen von Fastly und eine Ablehnungsregel für einen Referrer, der altostrat 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. Informationen zum Logging finden Sie unter Log-Explorer verwenden.

    Das folgende Beispiel zeigt ein Protokoll:

     httpRequest: {
    referer: "http://www.altostrat.com/"
    remoteIp: "23.230.32.10"
    requestMethod: "HEAD"
    requestSize: "79"
    requestUrl: "http://www.example.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 altostrat enthält. Da die Anfrage den Referrer http://www.altostrat.com/ enthält, funktioniert die Erzwingung der Sicherheitsregel ordnungsgemäß.

Probleme mit Ergebnissen im Security Command Center

Dieser Abschnitt enthält Informationen zu Problemen mit Security Command Center-Ergebnissen.

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.

Probleme mit Google Cloud Armor Adaptive Protection

Folgen Sie dieser Anleitung, um Probleme mit Adaptive Protection zu beheben.

Adaptive Protection ist für eine Sicherheitsrichtlinie aktiviert, aber es sind keine Logs in Cloud Logging vorhanden

Adaptive Protection-Logs werden getrennt von Google Cloud Armor-Anfragelogs generiert und unter einer anderen Ressource in Cloud Logging angezeigt. Adaptive Protection-Logs und -Ereignisse befinden sich in Cloud Logging unter der Ressource Netzwerksicherheitsrichtlinie. Nach der Aktivierung von Adaptive Protection in einer Sicherheitsrichtlinie gilt ein Trainingszeitraum von mindestens einer Stunde, bevor Adaptive Protection mit dem Generieren von Benachrichtigungen zu mutmaßlichen Angriffen beginnt. Währenddessen während der Trainingsphase, lernt Adaptive Protection aus der eingehenden Anfrage Traffic und entwickelt separate Referenzen für jeden Back-End-Dienst, durch diese Sicherheitsrichtlinie geschützt sind. Adaptive Protection kann dann verdächtige Aktivitäten identifizieren.

Wenn Sie Adaptive Protection für eine Sicherheitsrichtlinie aktivieren und nach einer einstündigen Trainingsphase noch Benachrichtigungen erhalten, deutet dies darauf hin, keine Aktivitäten, die als potenziell bösartiges Targeting auf eine der die mit dieser Sicherheitsrichtlinie verknüpften Back-End-Dienste.

Wenn der potenzielle Angriff oder ungewöhnliche Traffic mehrere Stunden andauert, betrachtet Adaptive Protection das Verhalten als Referenzverhalten und sendet keine Benachrichtigungen mehr zu ähnlichen Trafficmustern. Nachdem die potenzielle Angriff abgeklungen ist und Trafficmuster auf das ursprüngliche Referenzverhalten zurückgesetzt wurden, entweder weil der Angriff beendet wurde oder Sie ihn mit den entsprechenden Google Cloud Armor-Regeln blockiert haben, sendet Adaptive Protection Benachrichtigungen über künftiges Trafficverhalten, dass als Abweichung vom Referenzverhalten betrachtet wird.

Adaptive Protection analysiert Traffic, der normalerweise über eine Google Cloud Armor-Sicherheitsrichtlinie zugelassen werden würde. Wenn Sie die Standardregel so festlegen, dass der Zugriff mit einer eingeschränkten Zulassungsliste verhindert wird, erkennt Adaptive Protection nur schädliche Aktivitäten in Bezug auf den Traffic, der die Evaluierung dann an die Zulassungsliste übergibt.

In Cloud Logging gibt es zu viele Benachrichtigungen oder Logs von Adaptive Protection

Eine Adaptive Protection-Benachrichtigung liefert einen Konfidenzwert. Dieser gibt an, wie stark Adaptive Protection-Modelle die erkannte Aktivität als ungewöhnlich und potenziellen Angriff erkennt. Sie können mit Cloud Logging nach dem spezifischen Eintrag des Logs filtern, um nur Benachrichtigungen mit einem Konfidenzwert anzuzeigen, der über einem bestimmten Schwellenwert liegt.

Adaptive Protection bietet einen Mechanismus, mit dem Sie Benachrichtigungen als falsch-positiv melden können. Dies wird im Abschnitt Monitoring, Feedback und Meldung von Ereignisfehlern beschrieben. Hinweis: Falsch-positive Meldungen führen nicht unbedingt sofort zu Änderungen beim Senden von Benachrichtigungen durch Adaptive Protection. Mit der Zeit lernen Adaptive Protection-Modelle, dass derartige Zugriffsmuster normal und akzeptabel sind. Adaptive Protection sendet dann keine Benachrichtigungen mehr zu diesen Mustern.

Wenn Adaptive Protection zu häufig Benachrichtigungen für eine Teilmenge von Back-End-Diensten in einer Sicherheitsrichtlinie ausgibt, kann es sein, dass der normale Traffic dieser Back-End-Dienste erhebliche Schwankungen aufweist, die von Adaptive Protection als ungewöhnliches Verhalten identifiziert werden. Sie können eine separate Sicherheitsrichtlinie erstellen, ohne Adaptive Protection zu aktivieren, und diese Back-End-Dienste mit der neuen Sicherheitsrichtlinie verknüpfen.

Ein bestimmter von Adaptive Protection gemeldeter Vorfall gilt als falsch-positiv oder nicht relevant

Adaptive Protection bietet einen Mechanismus, um falsch-positive Meldungen zu melden. Folgen Sie der Anleitung im Abschnitt Monitoring, Feedback und Meldung von Ereignisfehlern. Hinweis: Falsch-positive Meldungen führen nicht unbedingt sofort zu Änderungen beim Senden von Benachrichtigungen durch Adaptive Protection. Mit der Zeit lernen Adaptive Protection-Modelle, dass derartige Zugriffsmuster normal und akzeptabel sind. Adaptive Protection sendet dann keine Benachrichtigungen mehr zu diesen Mustern.

Wie stelle ich fest, dass meine Edge-Sicherheitsrichtlinien erzwungen werden?

Die Aktionen, die entlang Ihrer Edge-Sicherheitsrichtlinien ausgeführt werden, können Sie in den Monitoring-Dashboards, Monitoring-Messwerten oder dem anfragespezifischen Logging einsehen.

Monitoring-Dashboards

Cloud Monitoring ist auf der Seite Netzwerksicherheitsrichtlinien unter Monitoring verfügbar. Sie können anhand der Aufschlüsselung nach Sicherheitsrichtlinien auf der Seite die Anzahl der Anfragen ermitteln, die von der konfigurierten Edge-Sicherheitsrichtlinie zugelassen und abgelehnt werden. Sie können auch mithilfe der Aufschlüsselung nach Back-End-Diensten Fehler bei einem bestimmten Back-End-Dienst beheben. Weitere Informationen zum Cloud Monitoring-Dashboard finden Sie unter Google Cloud Armor-Sicherheitsrichtlinien überwachen.

Messwerte überwachen

Für Edge-Sicherheitsrichtlinien sind unverarbeitete Messwerte verfügbar, die die zulässigen und abgelehnten Anfragen ermitteln. Weitere Informationen finden Sie unter Messwerte für Sicherheitsrichtlinien überwachen.

Anfragespezifisches Logging

Die Festlegung der Edge-Sicherheitsrichtlinie wird in den Anfragelogs für das Load-Balancing unter enforcedEdgeSecurityPolicy protokolliert. Dies ist unabhängig von der enforcedSecurityPolicy, die die Festlegung der Back-End-Sicherheitsrichtlinie erfasst.

Bot-Verwaltung

Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei der Bot-Verwaltung.

Für die Nutzer gilt keine Ausnahme, wie erwartet

Angenommen, Sie haben Sicherheitsrichtlinienregeln mit der Weiterleitungsaktion für die reCAPTCHA-Prüfung konfiguriert und festgestellt, dass einige Nutzer, die Ihrer Meinung nach berechtigt sind, nicht wie erwartet ausgenommen werden. Zur Fehlerbehebung führen Sie die im Folgenden aufgeführten Schritte aus.

Prüfen Sie zuerst die Logs der Anfrage, um festzustellen, ob es eine Sicherheitsrichtlinienregel mit einer höheren Priorität gibt, die für den Traffic gilt und bei der sich die Aktion unterscheidet. Achten Sie insbesondere auf die Felder configured_action und outcome. Beachten Sie, dass mindestens zwei Anfragen erforderlich sind, damit ein Nutzer ausgenommen wird. Die erste Anfrage enthält kein Ausnahme-Cookie. Die nachfolgenden Anfragen beinhalten ein Ausnahme-Cookie, wenn der Nutzer die reCAPTCHA-Prüfung besteht. Daher werden mindestens zwei Logeinträge erwartet.

  • Wenn GOOGLE_RECAPTCHA als konfigurierte Aktion und REDIRECT als die konfigurierte Aktion angezeigt wird wurde die Anfrage zur reCAPTCHA-Bewertung weitergeleitet.
  • Wenn Sie GOOGLE_RECAPTCHA als konfigurierte Aktion und ACCEPT als Ergebnis sehen, wurde die Anfrage von der Weiterleitung zur reCAPTCHA-Prüfung ausgenommen.
  • Wenn in den obigen Feldern unterschiedliche Werte angezeigt werden, wurde eine Regel mit einer anderen Aktion zugeordnet. In diesem Fall wird erwartet, dass der Nutzer nicht weitergeleitet oder ausgenommen wird.

Außerdem müssen Nutzer gewisse Merkmale haben, damit sie von der Weiterleitung zur reCAPTCHA-Prüfung ausgenommen werden können.

  1. Die Nutzer müssen einen Browser verwenden.
  2. Im Browser muss JavaScript aktiviert sein, damit die Weiterleitung richtig geladen werden kann Seite mit eingebettetem reCAPTCHA-JavaScript.
  3. Im Browser müssen Cookies aktiviert sein, damit das Ausnahme-Cookie gesetzt und automatisch angehängt werden kann.
  4. Der Nutzer muss die reCAPTCHA-Bewertung bestehen. Dazu muss er beispielsweise Pop-up-Herausforderungen lösen.

Erwarten Sie, dass Nutzer, die keine der oben genannten Anforderungen nicht erfüllen, Ausnahmeregelung erhalten, selbst wenn eine Regel mit der Weiterleitungsaktion für reCAPTCHA-Bewertung wurde abgeglichen.

Drittens wird die reCAPTCHA-Prüfung nur ausgeführt, wenn die Weiterleitungsseite mit dem eingebetteten reCAPTCHA-JavaScript-Code gerendert ist. Dafür Grund dafür, dass nur eine Weiterleitung zur reCAPTCHA-Bewertung möglich ist für Anfragen, die eine Antwort erwarten, die zu einem ganzseitigen Rendering führt. Sonstiges wie Assets, die auf einer Seite geladen werden, oder Anfragen aus einem eingebettetes Script, die keine Rendering-Antwort erwarten, nicht erwartet werden, um eine reCAPTCHA-Bewertung zu erhalten. Daher empfehlen wir, diese Aktion mit einer Abgleichbedingung für URL-Pfade anzuwenden, die diese Bedingung erfüllen.

Angenommen, Sie haben eine Webseite, die eingebettete Elemente wie Bilder, Links zu anderen Webseiten und Skripts enthält. Sie möchten nun die Weiterleitungsaktion für die reCAPTCHA-Prüfung nicht auf URL-Pfade anwenden, die Bilder hosten oder auf die von Skripts zugegriffen werden soll, bei denen kein Rendering der kompletten Seite erwartet wird. Stattdessen können Sie die Weiterleitungsaktion reCAPTCHA-Bewertung für URL-Pfade, die Webseiten hosten, z. B. den Haupt-Webseite oder andere verlinkte Webseiten ein.

Wenn die Weiterleitungsseite erfolgreich gerendert wurde, prüfen Sie schließlich im Entwicklertool des Browsers, ob ein Ausnahme-Cookie gesetzt wurde und ob es in den nachfolgenden Anfragen für dieselbe Website angehängt ist. Weitere Unterstützung erhalten Sie beim Cloud-Supportteam.

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:

  1. Ä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.
  2. 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