Codelab של כללי WAF ב-Cloud Armor מוגדר מראש

1. מבוא

שלום! ברוכים הבאים ל-codelab בנושא כללי WAF שהוגדרו מראש ב-Cloud Armor!

‫Google Cloud Armor הוא פתרון אבטחה לרשת קצה ארגונית של Google, שמספק הגנה מפני מתקפות DDoS, אכיפה של כללי WAF ויכולת ניהול אדפטיבית בהיקף נרחב.

ב-Cloud Armor הרחבנו את קבוצות הכללים של WAF שהוגדרו מראש כדי לצמצם את הסיכון לפרצות אבטחה באפליקציות אינטרנט שמופיעות ברשימת 10 פרצות האבטחה המובילות של OWASP. קבוצות הכללים מבוססות על קבוצת כללי ליבה (CRS) של OWASP Modsecurity בגרסה 3.0.2, כדי להגן מפני חלק מסיכוני האבטחה הנפוצים ביותר באפליקציות אינטרנט, כולל הכללת קובץ מקומי (lfi), הכללת קובץ מרוחק (rfi), הפעלת קוד מרוחק (rce) ועוד.

בשיעור Codelab הזה תלמדו איך לצמצם חלק מהפגיעויות הנפוצות באמצעות כללי WAF של Google Cloud Armor.

מה תלמדו

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

מה תצטרכו

• ידע בסיסי ב-Google Compute Engine ( codelab)
• ידע בסיסי ברישות וב-TCP/IP
• ידע בסיסי בשורת הפקודה של Unix/Linux
• מומלץ להשלים סיור מודרך ברשת ב-GCP באמצעות Networking in the Google Cloud
• (אופציונלי) כדאי להשלים את השיעור Lab בנושא Cloudnet20 Cloud Armor כדי ללמוד איך להגן על עומסי עבודה באמצעות כללים שמבוססים על הזרקת SQL, כתובות IP ומיקום גיאוגרפי.

טופולוגיה ותרחיש שימוש של Codelab

איור 1 – טופולוגיה של Codelab בנושא כללי WAF ב-Cloud Armor

האפליקציה OWASP Juice Shop שימושית להדרכה בנושא אבטחה ולהעלאת המודעות, כי היא מכילה מקרים של כל אחת מ-10 נקודות החולשה באבטחה של OWASP – בכוונה. תוקף יכול לנצל את הפגיעות הזו למטרות בדיקה. ב-Codelab הזה נשתמש בו כדי להדגים כמה מתקפות על אפליקציות, ולאחר מכן נגן על האפליקציה באמצעות כללי WAF של Cloud Armor. האפליקציה תהיה מול מאזן עומסים של Google Cloud, שיוחלו עליו כללי מדיניות האבטחה והכללים של Cloud Armor. הוא יוגש באינטרנט הציבורי, כך שניתן יהיה להגיע אליו כמעט מכל מקום, והוא יהיה מוגן באמצעות Cloud Armor וכללי חומת אש של VPC.

2. הגדרה ודרישות

הגדרת סביבה בקצב אישי

1. נכנסים אל Cloud Console ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

הערה: אפשר לגשת בקלות ל-Cloud Console אם זוכרים את כתובת ה-URL שלו, שהיא console.cloud.google.com.

חשוב לזכור את מזהה הפרויקט, שהוא שם ייחודי בכל הפרויקטים ב-Google Cloud (השם שלמעלה כבר תפוס ולא יתאים לכם, מצטערים!). בהמשך ה-codelab הזה נתייחס אליו כאל PROJECT_ID.

הערה: אם אתם משתמשים בחשבון Gmail, אתם יכולים להשאיר את מיקום ברירת המחדל כללא ארגון. אם אתם משתמשים בחשבון Google Workspace, אתם צריכים לבחור מיקום שמתאים לארגון שלכם.

2. לאחר מכן, תצטרכו להפעיל את החיוב ב-Cloud Console כדי להשתמש במשאבים של Google Cloud.

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

מפעילים את Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.

ב-GCP Console, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

הקצאת המשאבים והחיבור לסביבה יימשכו רק כמה רגעים. בסיום התהליך, אמור להופיע משהו כזה:

המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות ברשת. אפשר לבצע את כל העבודה ב-Lab הזה רק באמצעות דפדפן.

לפני שמתחילים

ב-Cloud Shell, מוודאים שמזהה הפרויקט מוגדר

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
PROJECT_ID=[YOUR-PROJECT-NAME]
echo $PROJECT_ID

הפעלת ממשקי API

הפעלת כל השירותים הנדרשים

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com        
gcloud services enable monitoring.googleapis.com 

3. יצירת רשת VPC

יצירת רשת VPC

מ-Cloud Shell

gcloud compute networks create ca-lab-vpc --subnet-mode custom

פלט

Created
NAME        SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
ca-lab-vpc  CUSTOM       REGIONAL

יצירת תת-רשת

מ-Cloud Shell

gcloud compute networks subnets create ca-lab-subnet \
        --network ca-lab-vpc --range 10.0.0.0/24 --region us-central1

פלט

Created 
NAME           REGION       NETWORK       RANGE
ca-lab-subnet  us-central1  ca-lab-vpc    10.0.0.0/24

יצירת כללים לחומת האש ב-VPC

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

מ-Cloud Shell

gcloud compute firewall-rules create allow-js-site --allow tcp:3000 --network ca-lab-vpc

פלט

Creating firewall...done.
NAME           NETWORK     DIRECTION  PRIORITY  ALLOW     DENY  DISABLED
allow-js-site  ca-lab-vpc  INGRESS    1000      tcp:3000        False

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

מ-Cloud Shell

gcloud compute firewall-rules create allow-health-check \
    --network=ca-lab-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-healthcheck \
    --rules=tcp

פלט

Creating firewall...done.
NAME                NETWORK     DIRECTION  PRIORITY  ALLOW  DENY  DISABLED
allow-health-check  ca-lab-vpc  INGRESS    1000      tcp          False

4. הגדרת אפליקציית הבדיקה

השלב הבא הוא ליצור את אפליקציית הבדיקה, במקרה הזה שרת האינטרנט OWASP Juice Shop.

כשיוצרים את מופע המחשוב, משתמשים בקובץ אימג' של קונטיינר כדי לוודא שהשרת כולל את השירותים המתאימים. השרת הזה יופעל ב-us-central1-c ויהיה לו תג רשת שיאפשר בדיקות תקינות.

יצירת אפליקציית OWASP Juice Shop

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

מ-Cloud Shell

gcloud compute instances create-with-container owasp-juice-shop-app --container-image bkimminich/juice-shop \
     --network ca-lab-vpc \
     --subnet ca-lab-subnet \
     --private-network-ip=10.0.0.3 \
     --machine-type n1-standard-2 \
     --zone us-central1-c \
     --tags allow-healthcheck

פלט

NAME                  ZONE           MACHINE_TYPE   PREEMPTIBLE  
owasp-juice-shop-app  us-central1-c  n1-standard-2               

INTERNAL_IP  EXTERNAL_IP     STATUS
10.0.0.3     <public IP>     RUNNING

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

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

מ-Cloud Shell

gcloud compute instance-groups unmanaged create juice-shop-group \
    --zone=us-central1-c

פלט

NAME              LOCATION       SCOPE  NETWORK  MANAGED  INSTANCES
juice-shop-group  us-central1-c  zone                     0

מוסיפים את מופע Juice Shop GCE לקבוצת המופעים הלא מנוהלת.

מ-Cloud Shell

gcloud compute instance-groups unmanaged add-instances juice-shop-group \
    --zone=us-central1-c \
    --instances=owasp-juice-shop-app

פלט

Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].

מגדירים את היציאה עם השם ליציאה של אפליקציית Juice Shop.

מ-Cloud Shell

gcloud compute instance-groups unmanaged set-named-ports \
juice-shop-group \
   --named-ports=http:3000 \
   --zone=us-central1-c

פלט

Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].

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

הגדרת הרכיב של מאזן העומסים ב-Cloud: בדיקת תקינות

יוצרים את בדיקת התקינות של יציאת השירות Juice Shop.

מ-Cloud Shell

gcloud compute health-checks create tcp tcp-port-3000 \
        --port 3000

פלט

Created 
NAME           PROTOCOL
tcp-port-3000  TCP

הגדרת הרכיב של מאזן העומסים ב-Cloud: שירות קצה עורפי

יוצרים את הפרמטרים של שירות הקצה העורפי.

מ-Cloud Shell

gcloud compute backend-services create juice-shop-backend \
        --protocol HTTP \
        --port-name http \
        --health-checks tcp-port-3000 \
        --enable-logging \
        --global 

פלט

NAME                BACKENDS  PROTOCOL
juice-shop-backend            HTTP

מוסיפים את קבוצת המכונות של Juice Shop לשירות הקצה העורפי.

מ-Cloud Shell

 gcloud compute backend-services add-backend juice-shop-backend \
        --instance-group=juice-shop-group \
        --instance-group-zone=us-central1-c \
        --global

פלט

Updated [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/backendServices/juice-shop-backend].

הגדרת הרכיב Cloud load balancer: מפת URL

יוצרים את מפת ה-URL לשליחה לבק-אנד.

מ-Cloud Shell

gcloud compute url-maps create juice-shop-loadbalancer \
        --default-service juice-shop-backend

פלט

NAME                     DEFAULT_SERVICE
juice-shop-loadbalancer  backendServices/juice-shop-backend

הגדרת הרכיב Cloud load balancer: שרת proxy לחלוקת העומס

יוצרים את שרת ה-proxy ליעד כדי להציג את מיפוי כתובות ה-URL.

מ-Cloud Shell

gcloud compute target-http-proxies create juice-shop-proxy \
        --url-map juice-shop-loadbalancer

פלט

NAME              URL_MAP
juice-shop-proxy  juice-shop-loadbalancer

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

יוצרים את כלל ההעברה למאזן העומסים.

מ-Cloud Shell

gcloud compute forwarding-rules create juice-shop-rule \
        --global \
        --target-http-proxy=juice-shop-proxy \
        --ports=80

פלט

Created [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/forwardingRules/juice-shop-rule].

אימות השירות Juice Shop באינטרנט

מ-Cloud Shell

PUBLIC_SVC_IP="$(gcloud compute forwarding-rules describe juice-shop-rule  --global --format="value(IPAddress)")"

מ-Cloud Shell

echo $PUBLIC_SVC_IP

פלט

<public VIP of service>

צריך להמתין כמה דקות לפני שממשיכים, אחרת יכול להיות שתקבלו תגובה HTTP/1.1 404 Not Found.

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP

פלט

HTTP/1.1 200 OK
<...>

אפשר גם לעבור לדפדפן כדי לראות את Juice Shop.

עכשיו אפשר לבדוק את נקודות החולשה של Juice Shop ואת האופן שבו אפשר להגן מפניהן באמצעות קבוצות של כללי WAF ב-Cloud Armor.

5. הדגמה של נקודות חולשה ידועות

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

התבוננות בפרצת אבטחה מסוג LFI: Path Traversal

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

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp

פלט

HTTP/1.1 200 OK
<...>

כדאי גם לשים לב ש-path traversal עובד גם כן:

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp/../

פלט

HTTP/1.1 200 OK
<...>

התבוננות בפגיעות של RCE

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

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls

פלט

HTTP/1.1 200 OK
<...>

כדי לראות את הפלט המלא, אפשר להסיר את דגלי ה-curl.

מעקב אחרי הגישה של סורק מוכר

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

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"

פלט

HTTP/1.1 200 OK
<...>

התבוננות במתקפת פרוטוקול: פיצול HTTP

חלק מאפליקציות האינטרנט משתמשות בקלט מהמשתמש כדי ליצור את הכותרות בתשובות. אם האפליקציה לא מסננת את הקלט בצורה נכונה, תוקף יכול להרעיל את פרמטר הקלט באמצעות הרצף ‎ %0d%0a (רצף ה-CRLF שמשמש להפרדה בין שורות שונות). כל דבר שמנתח את התגובה, כמו שרת proxy ביניים, יכול לפרש אותה כשתי תגובות, ועלול להציג תוכן שגוי בבקשות הבאות. הוספת הרצף %0d%0a לפרמטר הקלט, מה שעלול להוביל להצגת דף מטעה.

מ-Cloud Shell

curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"

פלט

HTTP/1.1 200 OK
<...>

Observe session fixation

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP -H session_id=X

פלט

HTTP/1.1 200 OK
<...>

6. הגדרת כללי WAF ב-Cloud Armor

מציינים את כללי ה-WAF שהוגדרו מראש:

מ-Cloud Shell

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

פלט

EXPRESSION_SET
Sqli-canary
RULE_ID
    owasp-crs-v030001-id942110-sqli
    owasp-crs-v030001-id942120-sqli
<...>

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

מתוך Cloud Shell:

gcloud compute security-policies create block-with-modsec-crs \
    --description "Block with OWASP ModSecurity CRS"

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

שימו לב שעדיפות כלל ברירת המחדל היא 2147483647

מתוך Cloud Shell:

gcloud compute security-policies rules update 2147483647 \
    --security-policy block-with-modsec-crs \
    --action "deny-403"

מכיוון שכלל ברירת המחדל מוגדר עם הפעולה deny (דחייה), אנחנו צריכים לאפשר גישה מכתובת ה-IP שלך. צריך למצוא את כתובת ה-IP הציבורית (באמצעות curl,‏ ipmonkey,‏ whatismyip וכו').

מתוך Cloud Shell:

MY_IP=$(curl ifconfig.me)

מוסיפים את הכלל הראשון כדי לאפשר גישה מכתובת ה-IP שלכם (מזינים את כתובת ה-IP שלכם למטה)

מתוך Cloud Shell:

gcloud compute security-policies rules create 10000 \
    --security-policy  block-with-modsec-crs  \
    --description "allow traffic from my IP" \
    --src-ip-ranges "$MY_IP/32" \
    --action "allow"

עדכון מדיניות האבטחה כדי לחסום מתקפות LFI

החלת קבוצת כללי הליבה (CRS) של OWASP ModSecurity שמונעת Path traversal להכללות של קבצים מקומיים.

מתוך Cloud Shell:

gcloud compute security-policies rules create 9000 \
    --security-policy block-with-modsec-crs  \
    --description "block local file inclusion" \
     --expression "evaluatePreconfiguredExpr('lfi-stable')" \
    --action deny-403

עדכון מדיניות האבטחה כדי לחסום Remote Code Execution (rce)

בהתאם ל-OWASP ModSecurity Core Rule Set, צריך להחיל כללים שמחפשים rce, כולל הזרקת פקודות. פקודות אופייניות למערכת ההפעלה מזוהות ונחסמות.

מתוך Cloud Shell:

gcloud compute security-policies rules create 9001 \
    --security-policy block-with-modsec-crs  \
    --description "block rce attacks" \
     --expression "evaluatePreconfiguredExpr('rce-stable')" \
    --action deny-403

עדכון מדיניות האבטחה כדי לחסום סורקי אבטחה

כדאי להחיל את OWASP ModSecurity Core Rule Set כדי לחסום סורקי אבטחה מוכרים, לקוחות HTTP של סקריפטים וסורקי אינטרנט.

מתוך Cloud Shell:

gcloud compute security-policies rules create 9002 \
    --security-policy block-with-modsec-crs  \
    --description "block scanners" \
     --expression "evaluatePreconfiguredExpr('scannerdetection-stable')" \
    --action deny-403

עדכון מדיניות האבטחה כדי לחסום מתקפות פרוטוקול

בהתאם ל-OWASP ModSecurity Core Rule Set, צריך להחיל כללים שמחפשים את התווים Carriage Return ‏ (CR) ‏%0d ו-Linefeed ‏ (LF) ‏%0a וסוגים אחרים של מתקפות על פרוטוקולים, כמו HTTP Request Smuggling.

מתוך Cloud Shell:

gcloud compute security-policies rules create 9003 \
    --security-policy block-with-modsec-crs  \
    --description "block protocol attacks" \
     --expression "evaluatePreconfiguredExpr('protocolattack-stable')" \
    --action deny-403

עדכון מדיניות האבטחה כדי לחסום קיבוע של סשן

בהתאם ל-OWASP ModSecurity Core Rule Set, צריך להחיל כללים ש…

מתוך Cloud Shell:

gcloud compute security-policies rules create 9004 \
    --security-policy block-with-modsec-crs  \
    --description "block session fixation attacks" \
     --expression "evaluatePreconfiguredExpr('sessionfixation-stable')" \
    --action deny-403

צירוף מדיניות האבטחה לשירות הקצה העורפי

מתוך Cloud Shell:

gcloud compute backend-services update juice-shop-backend \
    --security-policy block-with-modsec-crs \
    --global

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

7. מעקב אחרי ההגנה של Cloud Armor באמצעות OWASP ModSecurity Core Rule Set

אישור שהפגיעות מסוג LFI טופלה

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/?a=../

פלט

HTTP/1.1 403 Forbidden
<...>

מוודאים שמתקפת ה-RCE נחלשה

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls

פלט

HTTP/1.1 403 Forbidden
<..>

אישור זיהוי של סורקים מוכרים

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"

פלט

HTTP/1.1 403 Forbidden
<..>

אישור שמתקפת פרוטוקול נחלשה

לפי OWASP ModSecurity Core Rule Set ver.3.0.2, ההתקפה על הפרוטוקול ממוזערת על ידי

מ-Cloud Shell

curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"

פלט

HTTP/1.1 403 Forbidden
<..>

אישור שנעשים ניסיונות לחסימת קיבוע של סשן

מ-Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/?session_id=a

פלט

HTTP/1.1 403 Forbidden
<..>

8. בדיקת כללי האבטחה של Cloud Armor

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

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

• עדיפות 9000 – חסימת LFI (הכללת קבצים מקומיים)
• עדיפות 9001 – חסימת RCE (הרצת קוד מרחוק/הזרקת פקודות)
• עדיפות 9002 – זוהו סורקים חסומים
• עדיפות 9003 – חסימת מתקפות פרוטוקול כמו פיצול HTTP והברחת HTTP
• עדיפות 9004 – חסימת התקפות מסוג Session Fixation
• עדיפות 10000 – מתן הרשאה לכתובת ה-IP לגשת לאתר
• עדיפות ברירת מחדל – דחייה.

*שימו לב שהכלל 'allow your IP' מוגדר עם מספר העדיפות הכי גבוה כדי לאפשר גישה לאתר, אבל חוסם כל מתקפה.

9. עיון ביומנים של מדיניות האבטחה של Cloud Armor

בדף Cloud Armor Console, אפשר לראות את הפרטים של מדיניות האבטחה וללחוץ על הכרטיסייה Logs ואז על הקישור View policy logs כדי לעבור לדף Cloud Logging. הסינון יתבצע אוטומטית על סמך מדיניות האבטחה הרלוונטית, לדוגמה resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(block-with-modsec-crs). בודקים את קודי התגובה של השגיאה 403 ומרחיבים את פרטי היומן כדי לראות את השם של מדיניות האבטחה שנאכפת, את הערך של השדה שתואם ואת מזהי הביטוי שהוגדרו מראש (או את מזהה החתימה). בצילומי המסך הבאים מוצגות דוגמאות ליומנים של מדיניות האבטחה שנאכפת שהוגדרה ב-codelab הזה.

LFI log

יומן RCE

יומן זיהוי סורקים

יומן של התקפות פרוטוקול

יומן של קיבוע סשן

10. ניקוי נתונים חכם

אחרי שמסיימים את שיעור ה-Lab, צריך למחוק את המשאבים.

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

הסרת כללי מדיניות האבטחה של Cloud Armor משירות לקצה העורפי

gcloud -q compute backend-services update juice-shop-backend --security-policy "" --global

מחיקת מדיניות האבטחה של Cloud Armor

מחיקה של מדיניות האבטחה תגרום למחיקה אוטומטית של הכללים שמשויכים אליה.

gcloud -q compute security-policies delete block-with-modsec-crs

מחיקת משאבי מאזן העומסים

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

gcloud -q compute forwarding-rules delete juice-shop-rule --global

gcloud -q compute target-http-proxies delete juice-shop-proxy

gcloud -q compute url-maps delete juice-shop-loadbalancer

gcloud -q compute backend-services delete juice-shop-backend \
    --global

gcloud -q compute health-checks delete tcp-port-3000

gcloud -q compute instance-groups unmanaged delete juice-shop-group --zone=us-central1-c

מחיקת המכונה

gcloud -q compute instances delete owasp-juice-shop-app --zone us-central1-c

מחיקת הכללים של חומת האש, רשת המשנה וה-VPC

gcloud -q compute firewall-rules delete allow-health-check
gcloud -q compute firewall-rules delete allow-js-site
gcloud -q compute networks subnets delete ca-lab-subnet --region us-central1
gcloud -q compute networks delete ca-lab-vpc

‫11. מעולה!

כל הכבוד על השלמת ה-Codelab בנושא כללי WAF שהוגדרו מראש ב-Cloud Armor!

מה נכלל

• איך מגדירים קבוצת מופעים ומאזן עומסים גלובלי בענן
• איך מגדירים מדיניות אבטחה ב-Cloud Armor עם כללי WAF שהוגדרו מראש כדי להגן מפני lfi,‏ rce,‏ סורקים, מתקפות פרוטוקול וקיבוע סשן
• איך מאמתים באמצעות יומנים ש-Cloud Armor צמצם חלק מהמתקפות שמופיעות ברשימת עשרת המתקפות המובילות של OWASP

השלבים הבאים

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