פתרון בעיות ב-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.

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

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

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

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

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

• קבלת תמיכה