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

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

בעיות כלליות

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

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

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

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

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

    gcloud compute backend-services describe 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'

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

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

    gcloud compute security-policies describe 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. אם הכלל לא תקין או לא רלוונטי, משביתים אותו באמצעות הביטוי evaluatePreconfiguredWaf ומציינים את מזהה הכלל בארגומנט exclude ID list.

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

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

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

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

  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-v030001-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'

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

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

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

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

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

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

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

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

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

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

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

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

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

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