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

כאן מוסבר איך לפתור בעיות במדיניות האבטחה של Google Cloud Armor.

בעיות כלליות

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

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

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

זיהוי בקשות חסומות ביומנים וקישור ביניהן

כש-Cloud Armor חוסם בקשה במאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או במאזן עומסים קלאסי של אפליקציות (ALB), אפשר להחזיר ללקוח מזהה מעקב ייחודי על ידי הגדרה של כותרת תגובה בהתאמה אישית שמשתמשת במשתנה {cloud_trace_id}. אחר כך אפשר להשתמש במזהה המעקב הזה כדי למצוא את רשומת היומן ב-Logging ולהבין למה הבקשה נחסמה.

כדי לחשוף את מזהה המעקב ולמצוא בקשה חסומה ב-Logging:

  1. מגדירים כותרת תגובה בהתאמה אישית עם המשתנה {cloud_trace_id} בשירות לקצה העורפי. לדוגמה, הפקודה הבאה מוסיפה כותרת תגובה של X-Cloud-Trace-Id לשירות לקצה העורפי BACKEND_SERVICE_NAME:

    gcloud compute backend-services update BACKEND_SERVICE_NAME \
   --global \
   --custom-response-header='X-Cloud-Trace-Id:{cloud_trace_id}'

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

    מידע נוסף זמין במאמר הגדרת כותרות תגובה בהתאמה אישית.

  2. כשמדיניות האבטחה של Cloud Armor דוחה בקשה, בודקים את כותרות התגובה של ה-HTTP שמוחזרות ללקוח כדי לקבל את הערך ההקסדצימלי בן 32 התווים של הכותרת X-Cloud-Trace-Id.

  3. בדף Logs Explorer, שולחים שאילתה לשדה trace באמצעות מזהה המעקב מכותרת התגובה כדי למצוא את הרשומה התואמת ביומן:

    resource.type="http_load_balancer"
trace="projects/PROJECT_ID/traces/TRACE_ID"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט שמכיל את כלל ההעברה ואת מפת URL של מאזן העומסים
    • ‫TRACE_ID: מזהה המעקב ההקסדצימלי באורך 32 תווים שמוחזר בכותרת התגובה בהתאמה אישית

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

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

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

    gcloud compute backend-services describe BACKEND

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

  2. בודקים את יומני ה-HTTP(S) כדי לראות איזו מדיניות ואיזה כלל הותאמו לתנועה, ומה הפעולה שמשויכת אליהם. כדי לראות את היומנים, משתמשים ב-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 דומה לכלל OWASP CRS עם המזהה 941180:

    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.

בעיות בבדיקת גוף הבקשה

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

הצגת ביטויי משנה תואמים ביומנים

כדי לפתור בעיות בכללים, אפשר להפעיל רישום מפורט ביומן על ידי הגדרת הדגל --log-level לערך VERBOSE, ולהשתמש ב-Logging כדי לראות אילו ביטויי משנה בכלל תואמים. אם כלל מכיל כמה ביטויי משנה, Cloud Armor מתעד רק פרטים על ביטוי המשנה האחרון שהותאם.

הביטוי לדוגמה הבא מכיל שני ביטויי משנה:

request.url.contains('__') && request.body.contains('abc')

אם שולחים בקשת POST עם גוף הבקשה abc לכתובת ה-URL‏ example.com/etc/pass__word, הביטוי תואם. מכיוון שביטויי המשנה מוערכים משמאל לימין, ביטוי המשנה request.body.contains('abc') מוערך אחרון. בקטע הבא מהיומן מוצגים הפרטים של ביטוי המשנה request.body שתואם:

jsonPayload: {
  [...]
  enforcedSecurityPolicy: {
    [...]
    matchedFieldType: "request.body",
    matchedFieldName: "request.body",
    matchedFieldValue: "abc",
    matchedFieldLength: 3,
    matchedOffset: 0,
    matchedLength: 3,
  }
  [..*]
}

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

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

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

כתובות ה-IP ברשימות תמיד תואמות לכתובות ה-IP באתרי הספקים שמופיעים במדריך של Cloud Armor לרשימות של כתובות IP בעלות שם. אם יש לכם שאלות לגבי הרשימות, פנו לצוות התמיכה של 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. בהשוואה למה שמופיע במדיניות האבטחה, הכלל תואם לכלל הדחייה של מפנה שמכיל את 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.

בעיות בהגנה דינמית של Google Cloud Armor

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

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

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

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

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

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

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

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

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

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

אירוע מסוים שדווח על ידי Adaptive Protection נחשב לתוצאה חיובית מוטעית או שהוא לא רלוונטי

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

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

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

מרכזי בקרה למעקב

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

מדדי מעקב

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

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

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

ניהול בוטים

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

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

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

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

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

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

  1. המשתמש צריך להשתמש בדפדפן.
  2. הדפדפן צריך להפעיל את JavaScript כדי לאפשר טעינה תקינה של דף ההפניה האוטומטית עם JavaScript מוטמע של reCAPTCHA.
  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 לא תואמת לכלל החסימה שמבוסס על הגבלת קצב או על קצב. כדי לפתור את הבעיה, צריך לבדוק אם יש טעות בתנאי ההתאמה, ואז לשנות את תנאי ההתאמה של הכלל לערך הנכון.

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