Cloud NGFW — L7 Inspection, FQDN Filtering & TLS Interception

Tại sao quan trọng trong production

VPC firewall rules và Hierarchical Firewall Policies chỉ operate ở L3/L4: IP address, protocol, port. Đây là giới hạn cơ bản của stateful packet filtering. Chúng hoàn toàn mù trước:

• curl https://malicious.com/c2 gửi từ một VM — là outbound port 443, không khác gì request đến api.stripe.com
• Exploit payload được encode trong HTTP body — layer 4 không thể đọc được
• C2 (Command & Control) traffic chạy qua domain generation algorithms (DGA), generate domain mới mỗi ngày
• Lateral movement trong VPC dùng legitimate ports (443, 8443)

Cloud NGFW Enterprise giải quyết những vấn đề này bằng cách add L7 application-layer inspection: đọc nội dung packet, kiểm tra signature, đánh giá URL, và — với TLS inspection — decrypt traffic để kiểm tra payload trước khi re-encrypt và forward.

Đây là sự khác biệt kiến trúc cơ bản: VPC firewall rules enforce ở hypervisor của VM đích/nguồn mà không cần thay đổi data path. Cloud NGFW Enterprise yêu cầu một Firewall Endpoint — một GCE VM managed by Google đứng ở giữa data path để inspect traffic.

---

Ba Tiers của Cloud NGFW

Cloud NGFW tổ chức capabilities theo ba tiers với mức chi phí và functionality khác nhau:

Tier 1: Essentials (Miễn phí)

Essentials là baseline firewall service, thực chất là VPC firewall rules và hierarchical policies với packaging mới:

• Firewall rules dựa trên IP ranges, ports, protocols
• Secure Tags cho micro-segmentation (targeting theo attribute thay vì tag string)
• Address Groups: nhóm nhiều IP ranges thành một object có thể reuse
• Không có L7 capability

Tại sao tồn tại tier này: Google muốn migration từ VPC firewall rules sang Network Firewall Policy API là free. Essentials là functional equivalent của VPC firewall rules nhưng trong model mới hơn.

Tier 2: Standard

Standard thêm hai tính năng quan trọng vẫn operate ở L4 nhưng với context awareness:

FQDN Objects: thay vì hardcode IP ranges, rule có thể dùng domain names. Khi rule evaluate, GCP resolve domain và so sánh IP từ DNS response với destination IP của packet.

# Network Firewall Policy rule với FQDN
- direction: EGRESS
  priority: 100
  targetTags: ["backend-vm"]
  action: ALLOW
  match:
    destFqdns:
    - "api.stripe.com"
    - "hooks.slack.com"
    layer4Configs:
    - ipProtocol: tcp
      ports: ["443"]

Cơ chế FQDN resolution: FQDN filtering không phải DNS-based enforcement. GCP không intercept DNS queries. Thay vào đó, hệ thống pre-resolve FQDN thành IP list và lưu trong firewall rule. Khi packet đến, so sánh destination IP với list IP đã pre-resolved. DNS TTL được tôn trọng — IP list được refresh khi TTL hết hạn.

Giới hạn quan trọng của FQDN filtering: nếu attacker dùng IP address trực tiếp (không qua DNS), FQDN rule không catch được. FQDN filtering bảo vệ chống lại DNS-based egress mà không thêm IP vào allowlist.

Google Threat Intelligence: Standard tier cũng bao gồm Threat Intelligence feeds — IP ranges được Google identify là known malicious (tor exit nodes, known C2 IPs, scanners). Có thể dùng trong rules:

- action: DENY
  match:
    srcThreatIntelligences:
    - "iplist-tor-exit-nodes"
    - "iplist-known-malicious-ips"

Geolocation Objects: block/allow traffic theo quốc gia của source IP. Dùng cho compliance (chỉ cho phép traffic từ specific countries) hoặc DDoS mitigation.

Tier 3: Enterprise

Enterprise là tier duy nhất có thực sự L7 inspection. Yêu cầu deploy Firewall Endpoints — khác hoàn toàn về mặt kiến trúc so với Essentials và Standard.

Capabilities chính:

• URL Filtering: kiểm tra full URL path (không chỉ domain), block specific pages
• Intrusion Prevention System (IPS): signature-based detection và prevention
• TLS Inspection: decrypt, inspect, re-encrypt traffic

---

Firewall Endpoint — Data Path Insertion

Đây là phần quan trọng nhất và thường bị hiểu sai nhất về Cloud NGFW Enterprise.

Kiến trúc cơ bản

Trong VPC firewall rules (Essentials), enforcement xảy ra tại vNIC của VM — không có gì thay đổi trong data path giữa hai VMs.

Với Cloud NGFW Enterprise, một Firewall Endpoint được insert vào data path:

Trước Cloud NGFW Enterprise:
VM A ──────────────────────► VM B
       (VPC network fabric)

Sau Cloud NGFW Enterprise:
VM A ──► [Firewall Endpoint] ──► VM B
                │
         L7 inspection
         TLS decrypt/encrypt
         IPS signature check

Firewall Endpoint là một managed resource (GCE VM được Google quản lý) deploy trong một zone. Nó nhận traffic được redirect từ data path, thực hiện deep inspection, và forward hoặc drop traffic.

Deployment model

Để enable L7 inspection cho một VPC network:

1. Tạo Firewall Endpoint trong một zone:

gcloud network-security firewall-endpoints create my-endpoint \
  --organization=ORG_ID \
  --zone=us-central1-a

2. Associate endpoint với VPC network:

gcloud network-security firewall-endpoint-associations create my-assoc \
  --network=projects/PROJECT/global/networks/my-vpc \
  --firewall-endpoint=organizations/ORG_ID/locations/us-central1-a/firewallEndpoints/my-endpoint

3. Tạo Firewall Policy rules với action apply_security_profile_group:

- action: apply_security_profile_group
  direction: EGRESS
  match:
    destPorts: [{ipProtocol: tcp, ports: ["443"]}]
  securityProfileGroup: PROFILE_GROUP_URL

4. Traffic matching rule sẽ được redirect đến Firewall Endpoint để inspect.

Cơ chế redirect traffic

Việc redirect traffic đến Firewall Endpoint không dùng DNAT hay IP routing thông thường. GCP sử dụng cơ chế trong Andromeda để intercept traffic và đưa vào inspection path. Đối với VM, không có gì thay đổi — IP address đích vẫn là VM B, không phải Firewall Endpoint.

Về mặt network topology: Firewall Endpoint nằm trong một managed VPC được Google sở hữu, peered với VPC của customer. Traffic đi qua peering connection này để inspection rồi quay lại.

Scope: zonal resource

Một Firewall Endpoint là zonal resource. Nó chỉ inspect traffic của VMs trong cùng zone. Để cover một region có nhiều zones, cần deploy endpoint trong mỗi zone.

Ví dụ: VPC có VMs trong us-central1-a, us-central1-b, us-central1-c → cần 3 Firewall Endpoints.

Đây là trade-off quan trọng về cost: mỗi Firewall Endpoint có chi phí cố định (charged per hour), không phụ thuộc vào traffic volume. Việc có nhiều zones = nhiều endpoints = chi phí cao hơn.

---

FQDN Filtering vs URL Filtering — Sự Khác Biệt Cơ Bản

FQDN Filtering (Standard Tier)

FQDN filtering resolve domain → IP list → match at L4 (IP destination). Nó operate mà không cần Firewall Endpoint — không cần L7 inspection.

• Match: toàn bộ domain và mọi subdomain (nếu wildcard)
• Granularity: domain-level, không thể phân biệt example.com/api vs example.com/admin
• Mechanism: so sánh destination IP với pre-resolved IP list
• Limitation: không hoạt động nếu traffic bypass DNS (dùng IP trực tiếp)

URL Filtering (Enterprise Tier)

URL filtering xảy ra ở L7, sau khi packet được forward đến Firewall Endpoint và TLS được decrypt. Hệ thống đọc HTTP/HTTPS request và inspect full URL path.

• Match: full URL path https://example.com/admin/users
• Granularity: per-path, per-query-string, per-HTTP-method
• Mechanism: HTTP header parsing tại application layer
• Requires: Firewall Endpoint + TLS inspection enabled

Điều này là sự khác biệt về chất: FQDN filtering (Standard) không thể phân biệt giữa allowed.com/safe và allowed.com/malware-download. URL filtering (Enterprise) có thể.

---

TLS Inspection — Decrypt để Inspect rồi Re-encrypt

80%+ traffic internet ngày nay là HTTPS/TLS encrypted. Không có TLS inspection, L7 rules chỉ có thể inspect SNI (Server Name Indication trong TLS ClientHello) — là hostname duy nhất visible mà không cần decrypt. Payload, URL path, HTTP headers — tất cả encrypted.

Cơ chế Man-in-the-Middle

Cloud NGFW TLS inspection thực chất là TLS man-in-the-middle được kiểm soát:

1. Client (VM) initiates TLS handshake với destination server
2. Firewall Endpoint intercepts handshake, present certificate của nó (không phải certificate của server thật)
3. Firewall Endpoint establish hai TLS connections riêng biệt:
   • Connection 1: VM ↔ Firewall Endpoint (certificate của endpoint, issued by customer CA)
   • Connection 2: Firewall Endpoint ↔ Real Server (certificate của server thật)
4. Firewall Endpoint decrypt payload từ Connection 1, inspect, re-encrypt và forward qua Connection 2

VM ──[TLS C1: cert by Customer CA]──► Firewall Endpoint ──[TLS C2: real server cert]──► Server
                                           │ (plaintext L7 payload)
                                       IPS/URL inspect

Certificate Authority

Để VM "trust" certificate từ Firewall Endpoint, customer CA certificate phải được distribute đến VMs. Trong môi trường managed:

• Kubernetes/GKE: inject qua ConfigMap hoặc admission controller
• VM fleet: distribute qua startup script hoặc OS config management (Ansible, Chef)
• Browsers: không áp dụng — TLS inspection chỉ phù hợp cho server-to-server hoặc workload-to-service traffic, không phải traffic từ end-user browser

Traffic không nên inspect

Không phải tất cả traffic đều nên bị TLS inspect:

• Certificate pinning: services như mobile banking apps dùng certificate pinning — nếu intercept sẽ break connection
• Mutual TLS (mTLS): nếu client present certificate để authenticate, TLS inspection làm mất client certificate
• Financial/PII data: dù GCP không log payload, một số compliance frameworks yêu cầu end-to-end encryption không có MITM
• Performance-critical paths: mỗi connection cần thêm một TLS handshake với Firewall Endpoint — overhead latency đáng kể

Best practice: chọn lọc traffic nào cần TLS inspection thay vì inspect tất cả.

---

Intrusion Prevention System — Signature-Based Detection

Cloud NGFW Enterprise Enterprise IPS sử dụng threat signatures từ Google để detect:

• Vulnerability exploits: attempts khai thác known CVEs, buffer overflow, code injection
• Command-and-control (C2): traffic đến known C2 infrastructure
• Spyware và malware: signatures của known malicious software communication patterns

Severity levels và actions

Mỗi threat signature có một severity level: CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL.

Trong Security Profile Group, bạn configure action theo severity:

# Security Profile Group example
threatPreventionProfile:
  severityOverrides:
  - severity: CRITICAL
    action: BLOCK
  - severity: HIGH
    action: BLOCK
  - severity: MEDIUM
    action: ALERT
  - severity: LOW
    action: ALERT

• BLOCK: drop packet và log
• ALERT: allow packet nhưng log alert
• ALLOW: allow packet, không log (useful để override specific signatures)

Giới hạn IPS signature approach

Signature-based IPS có một fundamental limitation: nó chỉ detect known threats. Zero-day exploits, custom malware, hay novel attack techniques sẽ không bị catch. IPS complement, không replace:

• IAM least privilege (giảm blast radius nếu bị exploit)
• Patching (reduce exploitable surface)
• Cloud IDS (Palo Alto signatures, separate product) — sẽ được bàn trong file 06

---

Trade-off: Latency và Throughput

Mọi L7 inspection đều có chi phí latency. Khi traffic được redirect qua Firewall Endpoint:

• Thêm network hop: packet phải đi đến endpoint VM và về, thêm ~1-3ms latency trong cùng zone
• TLS handshake thêm: với TLS inspection, thêm một TLS handshake — đáng kể hơn (~5-50ms cho first connection)
• Processing overhead: deep packet inspection ăn CPU

Throughput limits: mỗi Firewall Endpoint có throughput limit. Theo GCP documentation, capacity phụ thuộc vào loại traffic và cấu hình. Khi traffic vượt quá capacity của một endpoint, có thể cần deploy thêm endpoints.

Đây là lý do tại sao quyết định "inspect gì" rất quan trọng. Không nên redirect tất cả traffic qua Enterprise tier — chỉ traffic cần L7 inspection (egress ra internet, lateral movement sensitive paths).

---

Tham khảo

• Cloud NGFW Overview
• Cloud NGFW Tiers
• FQDN Objects
• TLS Inspection
• Firewall Endpoints
• Cloud NGFW Enterprise Blog