פתרון בעיות ב-Cloud Armor

ההוראות האלה יעזרו לכם לפתור בעיות שקשורות לכללי מדיניות האבטחה של Google Cloud Armor.

בעיות כלליות

בקטע הזה מפורטות בעיות נפוצות שנתקלים בהן במהלך השימוש ב-Cloud Armor.

ניפוי באגים במדיניות אבטחה

אם אתם צריכים מידע נוסף על מה שמפעיל אירוע מסוים בכללים שהוגדרו מראש, כדאי לקרוא את המאמר שימוש ברישום ביומן של בקשות, ואז להפעיל רישום ביומן מפורט. ב-Cloud Logging נרשמים ביומנים פרטים ברמה גבוהה יותר, שאפשר להשתמש בהם כדי לנתח ולנפות באגים במדיניות ובכללים.

התעבורה מורשית למרות שמוגדר כלל דחייה במדיניות האבטחה של Cloud Armor

כדי לפתור את הבעיה, פועלים לפי השלבים הבאים:

  1. מוודאים שמדיניות האבטחה של Cloud Armor מצורפת לשירות קצה עורפי של יעד. לדוגמה, הפקודה הבאה מתארת את כל הנתונים שמשויכים לשירות לקצה העורפי BACKEND. התוצאות שמוחזרות חייבות לכלול את השם של כללי מדיניות האבטחה של Cloud Armor שמשויכים לשירות הקצה העורפי הזה.

    gcloud compute backend-services describe BACKEND

    מחליפים את BACKEND בשם של השירות לקצה העורפי.

  2. בודקים את יומני הרישום של HTTP(S) כדי לראות לאיזו מדיניות ולאיזה כלל התאימה התנועה שלכם, ומה הייתה הפעולה שבוצעה. כדי לראות את היומנים, משתמשים ב-Cloud Logging.

    זוהי דוגמה ליומן של בקשה שאושרה, עם הדגשה של השדות הרלוונטיים. בודקים את השדות הבאים ומוודאים שהם תואמים לכלל שהגדרתם כדי לחסום את התנועה:

    • הערך של configuredAction צריך להיות זהה לפעולה שהוגדרה בכלל.
    • הערך של name צריך להיות זהה לשם של כללי מדיניות האבטחה של Cloud Armor שמצורפים לשירות לקצה העורפי הזה.
    • הערך של outcome צריך להיות זהה לערך של configuredAction.
    • הערך של priority צריך להיות זהה למספר העדיפות של הכלל.
     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'

    הפלט הזה כולל את הערכים הבאים:

    • ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי
    • ‫FORWARDING_RULE_NAME: השם של כלל ההעברה
    • ‫PROJECT_ID: מזהה הפרויקט
    • ‫TARGET_HTTP_PROXY_NAME: השם של ה-proxy ל-HTTP עם יעד
    • ‫URL_MAP_NAME: השם של מפת URL

  3. בודקים את היררכיית הכללים כדי לוודא שהכלל הנכון הותאם. יכול להיות שכלל בעדיפות גבוהה יותר עם פעולת אישור מתאים לתנועה שלכם. משתמשים בפקודה describe ב-security-policies ב-Google Cloud CLI כדי לראות את התוכן של מדיניות האבטחה של Cloud Armor.

    לדוגמה, בדוגמה הבאה אפשר לראות איך כלל הרשאה בעדיפות גבוהה יותר (בעדיפות 100) תואם לתנועה שמגיעה מכתובת ה-IP‏ 1.2.3.4, ומונע את ההפעלה של כלל הדחייה בעדיפות נמוכה יותר (בעדיפות 200) וחסימה של התנועה.

    gcloud compute security-policies describe POLICY_NAME

    מחליפים את POLICY_NAME בשם של מדיניות האבטחה.

    הפלט אמור להיראות כך:

    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

כלל שהוגדר מראש מחזיר תוצאות חיוביות כוזבות

הזיהוי של XSS ו-SQLi מבוסס על התאמה של חתימות סטטיות בכותרות של בקשות HTTP ובפרמטרים אחרים בשכבה 7. תבניות הביטויים הרגולריים האלה נוטות להחזיר תוצאות חיוביות שגויות. אפשר להשתמש בכלל שהוגדר מראש לזיהוי XSS ו-SQLi במצב תצוגה מקדימה, ואז לבדוק ביומן אם יש תוצאות חיוביות שגויות.

אם מצאתם תוצאת חיובית שגויה, אתם יכולים להשוות את תוכן התנועה עם הכללים של OWASP CRS. אם אתם מבצעים מיגרציה מגרסה ישנה יותר של CRS, תוכלו לעיין בהשוואה בין גרסאות של כללי WAF כדי לראות רשימה של שינויים ושינויי שמות בכללים. אם הכלל לא תקין או לא רלוונטי, משביתים אותו באמצעות הביטוי evaluatePreconfiguredWaf ומציינים את מזהה הכלל בארגומנט exclude ID list.

אחרי שבודקים את היומנים ומסירים את כל התוצאות החיוביות הכוזבות, משביתים את מצב התצוגה המקדימה.

כדי להוסיף כלל שהוגדר מראש במצב תצוגה מקדימה:

  1. יוצרים מדיניות אבטחה עם קבוצת הביטויים שהוגדרה מראש במצב תצוגה מקדימה:

     gcloud compute security-policies rules create 1000
     --security-policy POLICY_NAME
     --expression "evaluatePreconfiguredWaf('xss-stable')"
     --action deny-403
     --preview

    מחליפים את POLICY_NAME בשם של מדיניות האבטחה.

  2. בודקים את היומנים של HTTP(S) כדי לראות את השדות של בקשת ה-HTTP, כמו url ו-cookie. לדוגמה, requestUrl הוא חיובי בהשוואה למזהה הכלל 941180 של OWASP CRS:

    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'

    היומן הזה כולל את הערכים הבאים:

    • ‫POLICY_NAME: השם של מדיניות האבטחה
    • ‫BACKEND_SERVICE: השם של שירות הקצה העורפי

  3. כדי להחריג את מזהה הכלל 941180 של OWASP CRS, צריך לעדכן את הכלל במדיניות האבטחה של Cloud Armor:

     gcloud compute security-policies rules update 1000 \
     --security-policy POLICY_NAME \
     --expression "evaluatePreconfiguredWaf('xss-v422-stable', ['owasp-crs-v042200-id941180-xss'])" \
     --action deny-403 \
     --preview

    מחליפים את POLICY_NAME בשם של מדיניות האבטחה.

  4. בודקים שוב את היומנים ומשביתים את מצב התצוגה המקדימה כדי להטמיע את הכלל.

לקוחות עם חתימות שנדחו לא נחסמים ולא נדחים

אם אתם משתמשים ב-Cloud Armor עם Cloud CDN, מדיניות האבטחה נאכפת רק על בקשות לתוכן דינמי, על בקשות שגורמות לפספוס במטמון או על בקשות אחרות שמיועדות לשרת המקור של ה-CDN. התגובות שמוחזרות מהמטמון מוגשות גם אם מדיניות האבטחה של Cloud Armor במורד הזרם יכולה למנוע מהבקשה להגיע לשרת המקור של ה-CDN.

בעיות ברשימות של כתובות IP עם שמות

בקטע הזה מוסבר איך לפתור בעיות שקשורות לרשימות של כתובות IP עם שמות.

כתובות IP ברשימה של כתובות IP עם שם

כתובות ה-IP ברשימות תמיד תואמות לכתובות ה-IP באתרי הספקים שמפורטים במדריך לרשימות כתובות IP עם שמות ב-Cloud Armor. אם יש לכם שאלות לגבי הרשימות, אתם יכולים לפנות לצוות התמיכה ב-Cloud.

כתובות IP ברשימת כתובות IP עם שם לא עדכניות ב-Cloud Armor

מערכת Cloud Armor מסנכרנת את הרשימות שלה עם ספקי רשימות של כתובות IP מדי יום. יכול להיות שיהיו נתונים לא עדכניים, שיהיה עיכוב של כמה שעות או יום בהצגתם בהשוואה לנתונים אצל הספק. עם זאת, אם לדעתכם הנתונים המיושנים מפגרים יותר מהצפוי, למשל יותר משבוע, פנו לצוות התמיכה של Cloud.

בעיה ביצירת מדיניות אבטחה שמפנה לרשימה של כתובות IP עם שמות

אפשר לנסות ליצור מדיניות אבטחה שמפנה לרשימת כתובות IP עם שם, באמצעות פקודה כמו זו:

gcloud compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredWaf('sourceiplist-example')" \
    --action "allow"

אם הפקודה נכשלת, השגיאה שמופיעה נראית בערך כך:

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.

חשוב לוודא שהספק הספציפי נתמך, וששם רשימת כתובות ה-IP ניתן בצורה נכונה. כדי לבדוק את זה, אפשר להשתמש בפקודה gcloud הבאה כדי להציג את קבוצות הביטויים שהוגדרו מראש:

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

תנועת הגולשים נחסמת למרות שמוגדר מראש כלל לרשימת היתרים של כתובות IP עם שם

יכול להיות שתגלו שתנועה נחסמת מכתובת IP שנמצאת ברשימה של כתובות IP עם שם:

  1. מוודאים שהתנועה מגיעה מכתובת IP שנמצאת ברשימת כתובות IP מותרות עם שם.

  2. בודקים אם יש כללי אבטחה אחרים עם עדיפות גבוהה יותר שיכולים לחסום את התנועה. אם הבעיה נמשכת, אפשר לפנות לצוות התמיכה של Cloud.

  3. מוודאים שמדיניות האבטחה מצורפת לשירות הנכון בקצה העורפי:

    gcloud compute backend-services describe BACKEND_SERVICE

  4. בודקים את הכללים שמופיעים במדיניות האבטחה. לדוגמה:

    gcloud compute security-policies describe POLICY_NAME

    הפקודה מחזירה מידע שדומה לזה:

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

    מדיניות האבטחה שלמעלה מכילה שלושה כללים: כלל דחייה שמוגדר כברירת מחדל, כלל הרשאה עבור כתובות ה-IP של Fastly וכלל דחייה עבור הפניה שמכילה altostrat. גם העדיפויות שלהם מפורטות.

  5. בודקים את היומנים כדי לראות לאיזה כלל התנועה תואמת ולאיזו פעולה היא משויכת. מידע על רישום ביומנים זמין במאמר שימוש ב-Logs Explorer.

    דוגמה ליומן:

    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"
 }
 …

    מהיומן הקודם, אפשר לראות שהבקשה מגיעה מ-23.230.32.10, שכלולה ברשימת כתובות ה-IP הציבוריות של Fastly. עם זאת, הבקשה תואמת לכלל דחייה בעדיפות גבוהה יותר של 50. אם משווים את זה למה שמופיע במדיניות האבטחה, הכלל תואם לכלל הדחייה של מקור ההפניה (referer) שמכיל altostrat. מכיוון שבבקשה יש הפניה אל http://www.altostrat.com/, אכיפת כלל האבטחה פועלת בצורה תקינה.

בעיות בממצאים של Security Command Center

בקטע הזה מפורטות בעיות שקשורות לממצאים של Security Command Center.

הכרטיס Cloud Armor לא מופיע ב-Security Command Center

הפעלת הממצאים של Cloud Armor בממשק של Security Command Center.

תוצאות מ-Cloud Armor לא מופיעות ב-Security Command Center

אם הממצאים מ-Cloud Armor לא מופיעים ב-Security Command Center, יכול להיות שהתנועה לשירותי הקצה העורפי לא עומדת בקריטריונים להעלאת ממצא.

אם יש לכם שאלות לגבי נפח התנועה לשרתי הקצה, תוכלו לבדוק את נתוני הבקשות בלוחות הבקרה של Cloud Monitoring בקטע Network Security Policies (מדיניות אבטחת רשת).

התוצאות רועשות מדי

כדי לקבל עזרה בפתרון הבעיה הזו, אפשר לפנות לצוות התמיכה של Cloud.

בעיות ב-Adaptive Protection ב-Google Cloud Armor

ההוראות האלה יעזרו לכם לפתור בעיות שקשורות להגנה דינמית.

ההגנה הדינמית מופעלת במדיניות אבטחה, אבל אין יומנים ב-Cloud Logging

היומנים של Adaptive Protection נוצרים בנפרד מיומני הבקשות של Cloud Armor, ומופיעים תחת משאב אחר ב-Cloud Logging. היומנים והאירועים של Adaptive Protection נמצאים במשאב Network Security Policy ב-Cloud Logging. אחרי שמפעילים את ההגנה הדינמית במדיניות אבטחה, יש תקופת אימון של שעה לפחות לפני שההגנה הדינמית מתחילה ליצור התראות על מתקפות חשודות. במהלך תקופת הלמידה, Adaptive Protection לומד מתנועת הבקשות הנכנסות ומפתח קווי בסיס נפרדים לכל שירות קצה עורפי שמוגן על ידי מדיניות האבטחה הזו. לאחר מכן, התכונה 'הגנה דינמית' יכולה לזהות פעילות חשודה.

אם מפעילים הגנה דינמית למדיניות אבטחה ולא מקבלים התראות אחרי תקופת האימון של שעה, זה מצביע על כך שאין פעילות שאפשר לזהות כפעילות זדונית פוטנציאלית שמכוונת לשירותי הקצה העורפי שמשויכים למדיניות האבטחה הזו.

אם התנועה החריגה או המתקפה הפוטנציאלית נמשכות לאורך תקופות ארוכות יותר, מעבר לכמה שעות, אז Adaptive Protection מתחיל להתייחס להתנהגות הזו כהתנהגות בסיסית ולא ממשיך להציג התראות על דפוסי תנועה דומים. אחרי שהמתקפה הפוטנציאלית נחלשת ודפוסי התנועה חוזרים לבסיס המקורי, כי המתקפה הסתיימה או כי חסמתם אותה באמצעות הכללים המתאימים של Cloud Armor, ההגנה האדפטיבית מתריעה על התנהגויות עתידיות של תנועה שנחשבות חריגות מהבסיס.

ההגנה האדפטיבית מנתחת תנועה שאחרת הייתה יכולה לעבור דרך כללי מדיניות האבטחה של Cloud Armor. אם מגדירים את כלל ברירת המחדל כך שיחסום גישה עם רשימת היתרים מוגבלת של תנועה, אז Adaptive Protection יזהה רק פעילות זדונית בתנועה שעוברת את ההערכה בהתאם לרשימת ההיתרים.

יש יותר מדי התראות או יותר מדי יומנים ב-Cloud Logging מ-Adaptive Protection

התראה של Adaptive Protection כוללת ציון מהימנות, שמציין עד כמה המודלים של Adaptive Protection מזהים את הפעילות שזוהתה כחריגה ופוטנציאלית כמתקפה. אתם יכולים לסנן את הרשומה הספציפית ביומן באמצעות Cloud Logging כדי להציג רק את ההתראות עם ציון רמת סמך מעל סף מסוים (או להעביר אותן למערכת במורד הזרם).

ההגנה הדינמית מספקת מנגנון לדיווח על התראות כחיוביות כוזבות, כפי שמתואר בקטע ניטור, משוב ודיווח על שגיאות באירועים. חשוב לדעת שדיווח על תוצאות חיוביות כוזבות לא בהכרח יוביל לשינויים מיידיים בהתראות של ההגנה הדינמית. עם הזמן, מודלים של הגנה דינמית לומדים שדפוסי תנועה כאלה הם נורמליים ומקובלים, וההגנה הדינמית מפסיקה להציג התראות לגבי הדפוסים האלה.

אם ההתראות של Adaptive Protection מופיעות לעיתים קרובות מדי בקבוצת משנה של שירותי קצה עורפי במדיניות אבטחה, יכול להיות שהתנועה הרגילה של שירותי הקצה העורפי האלה כוללת תנודות משמעותיות שמזוהות כל הזמן על ידי Adaptive Protection כהתנהגויות חריגות. אפשר ליצור מדיניות אבטחה נפרדת בלי להפעיל את ההגנה הדינמית, ולשייך את שירותי ה-Backend האלה למדיניות האבטחה החדשה.

אירוע מסוים שדווח על ידי Adaptive Protection נחשב לחיובי כוזב או לא רלוונטי

התכונה 'הגנה דינמית' מספקת מנגנון לדיווח על התראות שגויות. פועלים לפי ההליך שמתואר בקטע מעקב, משוב ודיווח על שגיאות באירועים. שימו לב: יכול להיות שדיווח על תוצאות חיוביות שגויות לא יוביל לשינויים מיידיים בהתראות של Adaptive Protection. עם הזמן, מודלים של Adaptive Protection לומדים שדפוסי תנועה כאלה הם נורמליים ומקובלים, והמערכת מפסיקה לשלוח התראות לגבי הדפוסים האלה.

איך אפשר לדעת שמדיניות האבטחה שלכם נאכפת?

כדי לבדוק את הפעולות שבוצעו במדיניות האבטחה שלכם ב-Edge, אפשר לעיין בלוחות הבקרה של המעקב, במדדי המעקב או ברישום ביומן לכל בקשה.

לוחות בקרה של Monitoring

‫Cloud Monitoring זמין בדף Network Security Policies בקטע Monitoring. אפשר להשתמש בפירוט לפי מדיניות אבטחה בדף כדי למדוד את מספר הבקשות שאושרו ונדחו על ידי מדיניות האבטחה שהוגדרה. אפשר גם לבדוק את הפירוט לפי שירות לקצה העורפי כדי לנפות באגים בשירות לקצה העורפי מסוים. פרטים על לוח הבקרה של Cloud Monitoring זמינים במאמר מעקב אחרי מדיניות האבטחה של Cloud Armor.

מדדי מעקב

מדדים גולמיים שמודדים את הבקשות שאושרו ואת הבקשות שנדחו זמינים למדיניות אבטחה של Edge. מידע נוסף זמין במאמר בנושא מעקב אחרי מדדים של מדיניות אבטחה.

רישום ביומן לכל בקשה

ההחלטה של מדיניות האבטחה ב-Edge נרשמת ביומני הבקשות של איזון העומסים בקטע enforcedEdgeSecurityPolicy. ההחלטה הזו שונה מההחלטה שמופיעה בenforcedSecurityPolicy, שמתייחסת להחלטה בנושא מדיניות האבטחה של הקצה העורפי.

ניהול בוטים

בקטע הזה מוסבר איך לפתור בעיות שקשורות לניהול בוטים.

המשתמשים לא פטורים כמו שמצופה

יכול להיות שהגדרתם כללים של מדיניות אבטחה עם פעולת ההפניה לבדיקת reCAPTCHA, וגיליתם שחלק מהמשתמשים שלדעתכם הם לגיטימיים לא קיבלו פטור כמו שציפיתם. כדי לפתור את הבעיה, מבצעים את השלבים הבאים.

קודם כל, בודקים ביומני הרישום של כל בקשה אם יש כלל מדיניות אבטחה עם עדיפות גבוהה יותר שתואם לתנועת הגולשים, שבו הפעולה שונה. חשוב במיוחד לבדוק את השדות configured_action ו-outcome. שימו לב: כדי שמשתמש יהיה פטור, צריך להיות מעורבות לפחות שתי בקשות. הבקשה הראשונית מגיעה ללא קובץ Cookie של פטור, והבקשות הבאות מגיעות עם קובץ Cookie של פטור אם המשתמש עובר את ההערכה של reCAPTCHA. לכן צפויות לפחות שתי רשומות ביומן.

  • אם הפעולה שהוגדרה היא GOOGLE_RECAPTCHA והתוצאה היא REDIRECT, הבקשה הופנתה לבדיקת reCAPTCHA.
  • אם הפעולה שהוגדרה היא GOOGLE_RECAPTCHA והתוצאה היא ACCEPT, הבקשה לא הופנתה לבדיקת reCAPTCHA.
  • אם אתם רואים ערכים שונים בשדות הקודמים, סימן שהייתה התאמה לכלל עם פעולה שונה. במקרה כזה, המשתמש לא אמור להיות מופנה אוטומטית או להיות פטור.

בנוסף, יש כמה דרישות שצריך לעמוד בהן בצד המשתמש כדי שלא יופנה לבדיקת reCAPTCHA.

  1. המשתמש צריך להשתמש בדפדפן.
  2. כדי שהדף להפניה אוטומטית ייטען בצורה תקינה עם JavaScript של reCAPTCHA מוטמע, צריך להפעיל JavaScript בדפדפן.
  3. כדי להגדיר את קובץ ה-Cookie של הפטור ולצרף אותו באופן אוטומטי, צריך להפעיל קובצי Cookie בדפדפן.
  4. המשתמש צריך לעבור את בדיקת reCAPTCHA – לדוגמה, אם יש אתגרים בתיבת הדו-שיח, הוא צריך לפתור אותם.

חשוב לזכור שמשתמשים שלא עומדים באף אחת מהדרישות שלמעלה לא יקבלו פטור, גם אם הם תואמים לכלל עם פעולת ההפניה לבדיקת reCAPTCHA.

שלישית, בדיקת reCAPTCHA מופעלת רק כשדף ההפניה שמטמיע את ה-JavaScript של reCAPTCHA מוצג. לכן, ההפניה להערכת reCAPTCHA רלוונטית רק לבקשות שצפויות להניב תגובה שתוביל לעיבוד של דף מלא. בקשות אחרות, כמו טעינת נכסים בדף או בקשות שנובעות מסקריפט מוטמע שלא מצפה שהתגובה תוצג, לא צפויות לקבל בדיקת reCAPTCHA. לכן, מומלץ להחיל את הפעולה הזו עם תנאי התאמה לנתיבי כתובות URL שעומדים בתנאי הזה.

לדוגמה, נניח שיש לכם דף אינטרנט שמכיל רכיבים מוטמעים כמו תמונות, קישורים לדפי אינטרנט אחרים וסקריפטים. לא רוצים להחיל את פעולת ההפניה האוטומטית לבדיקת reCAPTCHA על נתיבי כתובות URL שמארחים תמונות, או שאמורים להיות נגישים על ידי סקריפטים שבהם לא צפוי עיבוד מלא של הדף. במקום זאת, אפשר להחיל את פעולת ההפניה האוטומטית לבדיקת reCAPTCHA על נתיבי כתובות URL שמארחים דפי אינטרנט, כמו דף האינטרנט הראשי או דפי אינטרנט מקושרים אחרים.

לבסוף, אם דף ההפניה מוצג בהצלחה, בודקים בכלי למפתחים שמסופק על ידי הדפדפן אם מוגדר קובץ Cookie של פטור ואם הוא מצורף לבקשות הבאות לאותו אתר. לקבלת עזרה נוספת, אפשר לפנות לצוות התמיכה ב-Cloud.

בעיות בהגבלת קצב של יצירת בקשות

בקטע הזה מוסבר איך לפתור בעיות נפוצות שקשורות להגבלת קצב הבקשות.

הגבלת התנועה לא מתבצעת כמצופה

יכול להיות שתגלו שכתובת IP של לקוח שולחת רמות גבוהות של תנועה לאפליקציה בקצב שעולה על הסף שהגדרתם, אבל התנועה לא מוגבלת כמו שציפיתם. כדי לבדוק את הבעיה, פועלים לפי השלבים הבאים.

קודם כול, צריך לוודא שכלל עם עדיפות גבוהה יותר מאפשר תעבורת נתונים מכתובת ה-IP הזו. בודקים ביומנים אם הופעל כלל ALLOW עבור כתובת ה-IP. יכול להיות שזה כלל ALLOW בפני עצמו, או כלל THROTTLE או RATE_BASED_BAN אחר.

אם מצאתם כלל עם עדיפות גבוהה יותר, אתם יכולים לבצע אחת מהפעולות הבאות:

  1. משנים את העדיפויות כדי לוודא שלכלל הגבלת הקצב יש עדיפות גבוהה יותר, על ידי הקצאת ערך מספרי נמוך יותר.
  2. מגדירים את כתובת ה-IP כך שלא תיכלל בביטוי התואם בכלל עם עדיפות גבוהה יותר.

יכול להיות גם שהסף מוגדר בצורה שגויה. אם זה המצב, הבקשות מותאמות בצורה מדויקת, אבל מופעלת פעולת התאמה. בודקים את היומנים כדי לוודא שזה המצב, ואז מקטינים את ערך הסף בכלל.

לבסוף, יכול להיות שכתובת ה-IP לא תתאים לכלל של ויסות נתונים או של חסימה שמבוססת על קצב. כדי לפתור את הבעיה, צריך לבדוק אם יש טעות בתנאי ההתאמה, ואז לשנות את תנאי ההתאמה של הכלל לערך הנכון.

המאמרים הבאים