Cloud NGFW & L7 Inspection — Beyond IP/Port Firewall Rules

Executive Summary

Cloud NGFW = Next-Generation Firewall cho GCP VPC.

Standard firewall: Layer 4 (TCP/UDP, port-based) Cloud NGFW: Layer 7 (HTTP/HTTPS, DNS, custom protocols)

Key capabilities:

• ✅ FQDN filtering (allow/deny by domain name)
• ✅ HTTP/HTTPS inspection (without client TLS proxy)
• ✅ IDS/IPS integration (intrusion detection)
• ✅ Custom protocol support
• ❌ Latency overhead (~1-2ms per packet)
• ❌ Costs ($0.50-2.00 per endpoint per month)

What is Layer 7 Inspection?

Layers Recap

Layer 7 (Application): HTTP, HTTPS, DNS, SMTP, FTP
Layer 4 (Transport): TCP, UDP (ports)
Layer 3 (Network): IP addresses, CIDR blocks

Standard VPC firewall (Layer 4):
  Rule: allow tcp:443 from 0.0.0.0/0
  Matches: Any HTTPS traffic to port 443
  Cannot distinguish: api.example.com vs malware.example.com

Cloud NGFW (Layer 7):
  Rule: allow https to api.example.com
  Matches: HTTPS traffic where SNI/Host header = api.example.com
  Cannot reach: malware.example.com (even though both are HTTPS on 443)

FQDN-based Filtering

DNS Names Instead of IPs

Traditional approach:
  - Know IP address 203.0.113.5 is dangerous
  - Add firewall rule: DENY 203.0.113.5

Problem: Domain -> IP mapping changes
  - 203.0.113.5 might resolve to api.example.com next week
  - Or IP rotates every hour (CDN)
  - Rules become outdated

FQDN-based filtering:
  - Rule: DENY *.malware-domain.com
  - Real-time DNS resolution
  - Matches regardless of IP changes
  - Works with CDN/load balancers

Creating FQDN Rules

gcloud compute firewall-policies rules create \
  --firewall-policy=ngfw-policy \
  --priority=100 \
  --direction=EGRESS \
  --action=allow \
  --match="{'fqdnMatch': ['api.stripe.com', 'cdn.jsdelivr.net']}"

# Effect: Egress to Stripe API and jsDelivr CDN allowed
#         All other destinations denied (unless another rule allows)

FQDN Resolution Mechanics

VM makes DNS query: api.stripe.com → 1.2.3.4 (CNAME chain)
  → gcloud dns interceptor captures query
  → IP 1.2.3.4 marked as "api.stripe.com"
  
Packet to 1.2.3.4:tcp:443:
  → Firewall checks: Is 1.2.3.4 associated with api.stripe.com?
  → YES (from DNS cache)
  → FQDN rule applies
  → ALLOWED or DENIED based on rule

Problem: DNS cache expiration
  TTL: 300 seconds (5 min)
  After 5 min, 1.2.3.4 loses "api.stripe.com" association
  → Firewall cannot identify IP as api.stripe.com
  → Packet may be DENIED (not matching any FQDN rule)
  → Connection hangs
  
Solution: Use short-lived DNS queries (getaddrinfo before each connection)

HTTP/HTTPS Inspection

TLS Decryption (Optional)

Two modes:

Mode 1: Without TLS decryption
  HTTPS packet: encrypted payload
  Firewall inspection: SNI header only (unencrypted)
  Can match FQDN from SNI
  Cannot inspect HTTP body (encrypted)

Mode 2: With TLS interception (requires setup)
  HTTPS packet: encrypted with client → NGFW certificate
  NGFW decrypts, inspects body, re-encrypts to server
  Can inspect HTTP headers, URL path, body content
  
  Requires: Client trusts NGFW CA certificate
           (Enterprise scenario only)

URL Path Filtering

Without TLS interception:
  Firewall sees: GET /api/v1/users/... HTTPS
  Cannot identify path (encrypted)
  
  Rule: allow https to api.example.com
  Result: ALL paths to api.example.com allowed

With TLS interception:
  Firewall sees: GET /api/v1/users/search?q=...
  Can match URL patterns
  
  Rule: allow https to api.example.com path /api/v1/users/search
  Result: Only this endpoint allowed
          /api/admin/ denied (even if to api.example.com)

IDS/IPS Integration

Intrusion Detection

IDS (Intrusion Detection System):
  - Passive monitoring
  - Detects suspicious patterns (no blocking)
  - Alerts/logs suspicious packets

Cloud NGFW + IDS:
  - Network traffic analyzed for known attacks
  - CVE signatures, exploit patterns
  - Integrates with Cloud Logging (BigQuery export)
  - Alert on match but allow packet through
  
Use case: See attacks but understand impact
          Before enabling blocking (IPS)

Intrusion Prevention

IPS (Intrusion Prevention System):
  - Active blocking
  - Drops suspicious packets
  - Can halt attacks mid-stream
  
Cloud NGFW + IPS:
  - Enable after tuning detection (avoid false positives)
  - Blocks known malicious traffic
  - Risk: May block legitimate traffic (false positives)
  
Best practice: Start with IDS (log only)
               → Analyze false positive rate
               → Enable IPS when confident

Custom Signatures

Scenario: Malware family "XYZ" uses HTTP header pattern

Custom signature:
  Pattern: HTTP header "X-Malware-C2: true"
  Action: DROP (block)
  Logging: Alert to security team

Result: Any packet with this header = blocked
        False positives: Rare (if tuned correctly)

Performance Implications

Latency Overhead

Benchmark (simplified):

Standard firewall:
  Packet → Match IP/port → ALLOW/DENY
  Latency: <100 µs (microseconds)

Cloud NGFW (FQDN):
  Packet → DNS cache lookup → FQDN match → ALLOW/DENY
  Latency: 1-2 ms (milliseconds) added

Cloud NGFW (TLS inspection):
  Packet → Decrypt → Inspect body → Re-encrypt → ALLOW/DENY
  Latency: 2-5 ms added

Total latency per packet: +1-5ms
  
Impact: 
  - Single packet: Negligible
  - 1M packets/sec: 1000-5000 ms cumulative delay
  - Real applications: Noticeable if TLS inspection enabled

Throughput Ceiling

Cloud NGFW throughput per endpoint:
  - Balanced mode: ~10 Gbps
  - High performance mode: ~50 Gbps
  
Implication:
  - 100+ VM clusters: Need multiple NGFW endpoints (load balance)
  - Single NGFW can bottleneck network
  - Cost scales with throughput

Deployment Models

Centralized NGFW

Architecture:

All VPCs + On-premises
        ↓ (all traffic)
    Central NGFW
        ↓ (filtered)
    Internet

Advantages:
  - Single policy point
  - Centralized logging
  - Cost efficient (shared capacity)

Disadvantages:
  - Bottleneck (single point)
  - Latency for all traffic
  - Blast radius if NGFW fails

Distributed NGFW

Architecture:

VPC A → NGFW A → Internet
VPC B → NGFW B → Internet

Advantages:
  - No bottleneck (parallel filtering)
  - Lower latency (local NGFW)
  - Better availability (independent)

Disadvantages:
  - Policy management complex (per VPC)
  - Higher cost (multiple endpoints)
  - Inconsistent logging (per VPC)

Common Rules

Rule 1: Block Malware Domains

Direction: EGRESS
Priority: 100
Action: DENY

Match:
  fqdnMatch: [
    '*.malware-family-a.com',
    '*.c2-server.top',
    'phishing-domain.net'
  ]

Effect: Outbound attempts to malware blocked
        Ransomware cannot call home

Rule 2: Allow Corporate SaaS

Direction: EGRESS
Priority: 200
Action: ALLOW

Match:
  fqdnMatch: [
    '*.salesforce.com',
    '*.slack.com',
    '*.github.com',
    '*.google.com'
  ]

Effect: Approved SaaS traffic allowed
        Unapproved SaaS blocked (default deny)

Rule 3: Block Risky Categories

Direction: EGRESS
Priority: 500
Action: DENY

Match:
  threatIntelligence: ['malware', 'botnet', 'c2']
  categoryMatch: ['illegal-content', 'gambling', 'adult']

Effect: Dynamic threat list blocks dangerous categories
        Updated automatically via threat feeds

Rule 4: Inspect Internal APIs

Direction: INGRESS
Priority: 1000
Action: ALLOW

Match:
  destinationIpAddress: ['10.0.1.0/24']  (API subnet)
  protocol: 'tcp'
  ports: [443]
  
With TLS inspection:
  - Inspect X-API-Key header
  - Verify User-Agent
  - Validate URL path

Effect: Only authorized internal clients can call APIs

Troubleshooting

Symptom: FQDN Rule Not Matching

Diagnosis:

1. Check DNS cache:
   (No direct tool, but TCP connection failure indicates DNS miss)

2. Force new DNS resolution:
   VM: nslookup api.example.com  (refresh cache)

3. Check NGFW logs:
   gcloud logging read \
     'resource.type="compute#NGFW" AND 
      severity="WARNING"' \
     --limit=20

4. Verify FQDN in rule:
   gcloud compute firewall-policies rules describe RULE_ID \
     --format="value(match.fqdnMatch)"

5. Check rule priority:
   Is higher-priority rule denying before FQDN rule?

Symptom: TLS Inspection Certificate Error

Client error: "Certificate not trusted"

Cause: Client doesn't trust NGFW CA certificate

Solution:
  1. Import NGFW CA certificate to client OS trust store
  2. Or: Disable TLS inspection (use SNI-only)
  3. Or: Exclude certificate-pinned apps from inspection

Symptom: Performance Degradation

Diagnosis:

1. Check NGFW utilization:
   gcloud monitoring query \
     'resource.type="global" AND 
      metric.type="compute.ngfw.throughput"'

2. If > 80% utilization:
   Add more NGFW endpoints (load balance)

3. Check TLS inspection enabled:
   If yes, latency +3-5ms per packet
   → Disable if not critical

4. Monitor packet drops:
   'compute.ngfw.packets_dropped' metric
   High drops = throughput exceeded

Best Practices

✅ Do:

• Start with IDS (detection only)
• Gradually enable IPS (prevention)
• Centralize NGFW for consistent policy
• Log all traffic for forensics
• Use threat intelligence feeds (auto-update rules)
• Monitor performance metrics

❌ Don't:

• Enable TLS inspection by default (latency + cost)
• Create overly complex FQDN lists (hard to debug)
• Forget to whitelist legitimate traffic first
• Assume NGFW solves all security (defense in depth)
• Enable IPS without tuning (false positives)

Cost Analysis

Cloud NGFW pricing (approximate):

NGFW policy endpoint: $0.15/hour ($108/month)
Per VM per month: $0.50-2.00 (based on tier)
IDS/IPS: Additional cost for advanced signatures

Example: 100 VMs + 1 NGFW endpoint
  Endpoint: $108/month
  VMs: 100 × $1.00 = $100/month
  Total: $208/month (~$6/vm/month)

vs VPC firewall: $0 (included)

ROI: Worth it if:
  - Production environment (security critical)
  - Large cluster (cost amortized)
  - Compliance requirement (required for certification)

Conclusion

Cloud NGFW provides enterprise-grade application-layer security:

• FQDN filtering: Domain-based rules (vs IP-based)
• IDS/IPS: Intrusion detection/prevention
• TLS inspection: Deep packet inspection (optional)
• Centralized control: Organization-wide policies

Best for: Production environments requiring advanced threat prevention and compliance.

Not needed: Simple deployments or cost-sensitive scenarios (use standard VPC firewall).