Verwenden Sie diese Anweisungen zur Fehlerbehebung bei Problemen mit Google Cloud Armor-Sicherheitsrichtlinien.
Allgemeine Probleme
In diesem Abschnitt werden häufige Probleme bei der Verwendung von Cloud Armor behandelt.
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.
Blockierte Anfragen in Logs identifizieren und korrelieren
Wenn Cloud Armor eine Anfrage an einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer blockiert, können Sie eine eindeutige Trace-ID an den Client zurückgeben, indem Sie einen benutzerdefinierten Antwortheader konfigurieren, der die Variable {cloud_trace_id} verwendet.
Anhand dieser Trace-ID können Sie dann den Logeintrag in Logging finden und feststellen, warum die Anfrage blockiert wurde.
So machen Sie die Trace-ID sichtbar und finden eine blockierte Anfrage in Logging:
Konfigurieren Sie einen benutzerdefinierten Antwortheader mit der Variable
{cloud_trace_id}in Ihrem Backend-Dienst. Mit dem folgenden Befehl wird beispielsweise dem Backend-DienstBACKEND_SERVICE_NAMEeinX-Cloud-Trace-Id-Antwortheader hinzugefügt:gcloud compute backend-services update BACKEND_SERVICE_NAME \ --global \ --custom-response-header='X-Cloud-Trace-Id:{cloud_trace_id}'Ersetzen Sie
BACKEND_SERVICE_NAMEdurch den Namen Ihres Backend-Dienstes.Weitere Informationen finden Sie unter Benutzerdefinierte Antwortheader konfigurieren.
Wenn eine Cloud Armor-Sicherheitsrichtlinie eine Anfrage ablehnt, prüfen Sie die HTTP-Antwortheader, die an den Client zurückgegeben werden, um den 32-stelligen Hexadezimalwert des
X-Cloud-Trace-Id-Headers zu erhalten.Fragen Sie auf der Seite Log-Explorer das Feld
tracemit der Trace-ID aus dem Antwortheader ab, um den entsprechenden Logeintrag zu finden:resource.type="http_load_balancer" trace="projects/PROJECT_ID/traces/TRACE_ID"
Ersetzen Sie Folgendes:
PROJECT_ID: die ID des Projekts, das die Weiterleitungsregel und die URL-Zuordnung des Load Balancers enthältTRACE_ID: die 32-stellige hexadezimale Trace-ID, die im benutzerdefinierten Antwortheader zurückgegeben wird
Traffic wird trotz einer in der Cloud Armor-Sicherheitsrichtlinie konfigurierten Ablehnungsregel zugelassen
Führen Sie zur Behebung die folgenden Schritte aus:
Prüfen Sie, ob die Sicherheitsrichtlinie von Cloud Armor an einen Ziel-Backend-Dienst angehängt ist. Der folgende Befehl beschreibt beispielsweise alle Daten, die dem Backend-Dienst
BACKENDzugeordnet 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
BACKENDdurch den Namen des Backend-Dienstes.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 zum Aufrufen der Logs Logging.
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:
configuredActionmuss mit der in der Regel konfigurierten Aktion übereinstimmen.namemuss mit dem Namen der Cloud Armor-Sicherheitsrichtlinie übereinstimmen, die diesem Backend-Dienst zugeordnet ist.outcomemuss mitconfiguredActionübereinstimmen.prioritymuss mit der Prioritätsnummer der Regel übereinstimmen.
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 WeiterleitungsregelPROJECT_ID: die Projekt-IDTARGET_HTTP_PROXY_NAME: der Name des HTTP-ZielproxysURL_MAP_NAME: der Name des URL-Mappings
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
describein densecurity-policiesdes 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_NAMEdurch 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 dem statischen Signaturabgleich von 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 Trafficinhalt mit den OWASP-CRS-Regeln vergleichen.
Wenn Sie von einer älteren CRS-Version migrieren, finden Sie im Vergleich der WAF-Regelversionen 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 ID der Regel 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 --previewErsetzen Sie
POLICY_NAMEdurch den Namen der Sicherheitsrichtlinie.Prüfen Sie die HTTP(S)-Logs auf HTTP-Anfragefelder wie
urlundcookie. Beispielsweise wirdrequestUrlpositiv mit der OWASP-CRS-Regel-ID 941180 verglichen: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 SicherheitsrichtlinieBACKEND_SERVICE: der Name des Backend-Dienstes.
Schließen Sie die OWASP-CRS-Regel-ID 941180 aus, indem Sie die Regel in der Cloud Armor-Sicherheitsrichtlinie aktualisieren:
gcloud compute security-policies rules update 1000 \ --security-policy POLICY_NAME \ --expression "evaluatePreconfiguredWaf('xss-v422-stable', ['owasp-crs-v042200-id941180-xss'])" \ --action deny-403 \ --previewErsetzen Sie
POLICY_NAMEdurch den Namen der Sicherheitsrichtlinie.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-Fehlschläge oder andere Anfragen umgesetzt, die für den CDN-Ursprungsserver bestimmt sind. Cache-Treffer werden auch dann bereitgestellt, wenn die nachgelagerte Cloud Armor-Sicherheitsrichtlinie verhindern kann, dass die Anfrage den CDN-Ursprungsserver erreicht.
Probleme mit der Anfragetextprüfung
Da Cloud Armor Daten schrittweise auswertet, während sie empfangen werden, können Regeln bis zum konfigurierten Prüflimit anhand unvollständiger Textdaten ausgewertet werden. Um potenzielle falsch positive oder unvollständige Ergebnisse zu vermeiden, sollten Sie Regeln schreiben, die auf das Vorhandensein von Daten und nicht auf deren Fehlen abzielen. Weitere Informationen finden Sie unter Beschränkung der Prüfung des Anfragetexts.
Übereinstimmende Unterausdrücke in Logs ansehen
Bei der Fehlerbehebung für Regeln können Sie das ausführliche Logging aktivieren, indem Sie das Flag --log-level auf VERBOSE setzen. Mit Logging können Sie dann sehen, welche Unterausdrücke in einer Regel übereinstimmen. Wenn eine Regel mehrere Unterausdrücke enthält, protokolliert Cloud Armor nur Details zum zuletzt übereinstimmenden Unterausdruck.
Der folgende Beispielausdruck enthält zwei Unterausdrücke:
request.url.contains('__') && request.body.contains('abc')
Wenn Sie eine POST-Anfrage mit dem Text abc an die URL example.com/etc/pass__word senden, stimmt der Ausdruck überein. Da die Unterausdrücke von links nach rechts ausgewertet werden, wird der Unterausdruck request.body.contains('abc') zuletzt ausgewertet. Der folgende Logauszug zeigt die Details für den übereinstimmenden Unterausdruck request.body:
jsonPayload: {
[...]
enforcedSecurityPolicy: {
[...]
matchedFieldType: "request.body",
matchedFieldName: "request.body",
matchedFieldValue: "abc",
matchedFieldLength: 3,
matchedOffset: 0,
matchedLength: 3,
}
[..*]
}
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 auf den aufgeführten Websites der Anbieter im Leitfaden zu benannten IP-Adresslisten in Cloud Armor. Wenn Sie Fragen zu den Listen haben, wenden Sie sich an das Cloud-Supportteam.
IP-Adressen in einer benannten IP-Adressliste sind in Cloud Armor veraltet
Cloud Armor synchronisiert seine Listen täglich mit den IP-Adresslistenanbietern. 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 "evaluatePreconfiguredWaf('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": "evaluatePreconfiguredWaf(\u0027sourceiplist-example\u0027)"}'.
Error parsing Cloud Armor rule matcher expression: sourceiplist-example
isn't 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.
Kontrollieren Sie, ob der Traffic von einer IP-Adresse kommt, die sich auf einer benannten Liste zugelassener IP-Adressen befindet.
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.
Prüfen Sie, ob die Sicherheitsrichtlinie an den richtigen Backend-Dienst angehängt ist:
gcloud compute backend-services describe BACKEND_SERVICE
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: evaluatePreconfiguredWaf('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
altostratenthält. Die jeweiligen Prioritäten sind ebenfalls aufgeführt.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, deraltostratenthält. Da die Anfrage den Refererhttp://www.altostrat.com/hat, 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 Cloud Armor-Karte wird im Security Command Center nicht angezeigt.
Aktivieren Sie Cloud Armor-Ergebnisse in der Security Command Center-Oberfläche.
Ergebnisse von Cloud Armor werden nicht im Security Command Center angezeigt
Wenn Ergebnisse von Cloud Armor nicht im Security Command Center angezeigt werden, erfüllt der Traffic zu den Backend-Diensten möglicherweise nicht die Kriterien für die Erstellung eines Ergebnisses.
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 Logging vorhanden
Adaptive Protection-Logs werden separat von Cloud Armor-Anfrage-Logs generiert und in Logging unter einer anderen Ressource angezeigt. Adaptive Protection-Logs und -Ereignisse befinden sich in Logging unter der Ressource Netzwerksicherheitsrichtlinie. Nachdem Adaptive Protection in einer Sicherheitsrichtlinie aktiviert wurde, dauert es mindestens eine Stunde, bis Adaptive Protection Benachrichtigungen zu mutmaßlichen Angriffen generiert. Während des Trainingszeitraums lernt Adaptive Protection vom eingehenden Anfragetraffic und entwickelt verschiedene Referenzwerte für jeden Backend-Dienst, der durch diese Sicherheitsrichtlinie geschützt ist. Adaptive Protection kann dann verdächtige Aktivitäten identifizieren.
Wenn Sie Adaptive Protection für eine Sicherheitsrichtlinie aktivieren und nach einem einstündigen Trainingszeitraum keine Benachrichtigungen erhalten, bedeutet dies, dass keine Aktivitäten vorliegen, die als potenziell schädliches Targeting von einem der Backend-Dienste erkannt werden, die mit dieser Sicherheitsrichtlinie verknüpft sind.
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 der potenzielle Angriff abgeklungen ist und die Traffic-Muster wieder der ursprünglichen Baseline entsprechen, weil der Angriff beendet wurde oder Sie ihn mit den entsprechenden Cloud Armor-Regeln blockiert haben, sendet Adaptive Protection Benachrichtigungen zu zukünftigen Traffic-Verhaltensweisen, die als Abweichungen von der Baseline gelten.
Adaptive Protection analysiert Traffic, der sonst über eine Cloud Armor-Sicherheitsrichtlinie zugelassen werden kann. Wenn Sie die Standardregel so festlegen, dass der Zugriff mit einer eingeschränkten Zulassungsliste für Traffic verweigert wird, erkennt Adaptive Protection nur schädliche Aktivitäten im Traffic, der die Prüfung im Hinblick auf die Zulassungsliste besteht.
Es gibt zu viele Benachrichtigungen oder zu viele Logs in Logging 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 in Logging nach dem spezifischen Eintrag des Logs filtern, um nur die Benachrichtigungen anzuzeigen (oder an nachgelagerte Systeme weiterzuleiten), die einen Konfidenzwert über einem bestimmten Schwellenwert haben.
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 Backend-Diensten in einer Sicherheitsrichtlinie ausgibt, kann es sein, dass der normale Traffic dieser Backend-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 Backend-Dienste mit der neuen Sicherheitsrichtlinie verknüpfen.
Ein bestimmter von Adaptive Protection gemeldeter Vorfall wird als falsch positiv eingestuft oder ist 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 Backend-Diensten Fehler bei einem bestimmten Backend-Dienst beheben. Weitere Informationen zum Cloud Monitoring-Dashboard finden Sie unter 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.
Nutzer werden nicht wie erwartet ausgenommen
Möglicherweise haben Sie Sicherheitsrichtlinienregeln mit der Weiterleitungsaktion für die reCAPTCHA-Bewertung konfiguriert und stellen fest, dass einige Nutzer, die Sie für legitim halten, nicht wie erwartet ausgenommen wurden. Führe die folgenden Schritte zur Fehlerbehebung 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 enthalten ein Ausnahme-Cookie, wenn der Nutzer die reCAPTCHA-Bewertung besteht. Daher werden mindestens zwei Logeinträge erwartet.
- Wenn Sie
GOOGLE_RECAPTCHAals konfigurierte Aktion undREDIRECTals Ergebnis sehen, wurde die Anfrage zur reCAPTCHA-Bewertung weitergeleitet. - Wenn Sie
GOOGLE_RECAPTCHAals konfigurierte Aktion undACCEPTals Ergebnis sehen, wurde die Anfrage von der Weiterleitung für die reCAPTCHA-Bewertung ausgenommen. - Wenn Sie in den vorherigen Feldern andere Werte sehen, wurde eine Regel mit einer anderen Aktion gefunden. In diesem Fall wird erwartet, dass der Nutzer nicht weitergeleitet oder ausgenommen wird.
Zweitens gibt es mehrere Anforderungen auf Nutzerseite, damit sie von der Weiterleitung zur reCAPTCHA-Bewertung ausgenommen werden.
- Die Nutzer müssen einen Browser verwenden.
- Im Browser muss JavaScript aktiviert sein, damit die Weiterleitungsseite mit eingebettetem reCAPTCHA-JavaScript richtig geladen werden kann.
- Im Browser müssen Cookies aktiviert sein, damit das Ausnahme-Cookie gesetzt und automatisch angehängt werden kann.
- Der Nutzer muss die reCAPTCHA-Bewertung bestehen. Er muss beispielsweise Dialogaufgaben lösen, falls vorhanden.
Nutzer, die keine der oben genannten Anforderungen erfüllen, erhalten keine Ausnahme, auch wenn eine Regel mit der Weiterleitungsaktion für die reCAPTCHA-Bewertung übereinstimmt.
Drittens wird die reCAPTCHA-Bewertung nur ausgeführt, wenn die Weiterleitungsseite, die das reCAPTCHA-JavaScript einbettet, gerendert wird. Aus diesem Grund ist die Weiterleitung für die reCAPTCHA-Bewertung nur für Anfragen anwendbar, die eine Antwort erwarten, die zu einem vollständigen Seitenrendering führt. Für andere Anfragen, z. B. für Ressourcen, die auf einer Seite geladen werden, oder für Anfragen, die aus einem eingebetteten Skript stammen, das nicht erwartet, dass die Antwort gerendert wird, wird keine reCAPTCHA-Bewertung ausgeführt. Daher empfehlen wir, diese Aktion mit einer Abgleichbedingung für URL-Pfade anzuwenden, die diese Bedingung erfüllen.
Angenommen, Sie haben eine Webseite mit eingebetteten Elementen wie Bildern, Links zu anderen Webseiten und Skripts. Sie sollten die Weiterleitungsaktion für die reCAPTCHA-Bewertung nicht auf URL-Pfade anwenden, die Bilder hosten oder auf die über Skripts zugegriffen werden soll, bei denen kein vollständiges Seitenrendering erwartet wird. Stattdessen können Sie die Weiterleitungsaktion für die reCAPTCHA-Bewertung auf URL-Pfade anwenden, die Webseiten hosten, z. B. die Hauptwebseite oder andere verknüpfte Webseiten.
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
In diesem Abschnitt finden Sie Informationen zur Behebung häufiger Probleme mit der Ratenbegrenzung.
Der 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.