פתרון בעיות ב-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 הזו. בודקים ביומנים אם הופעל כלל ALLOW לכתובת ה-IP. זה יכול להיות כלל ALLOW בפני עצמו, או כלל THROTTLE או RATE_BASED_BAN אחר.

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

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

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

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

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

• קבלת תמיכה