Egress control & DNS

Default-deny outbound, Cloud NAT, DNS filtering.

Inbound filtering is everywhere; outbound is usually wide open — yet exfiltration and command-and-control both leave through egress. On GCP you have layered egress controls, and using them turns a silent breach into a blocked, logged event.

Constrain and inspect outbound

Write egress firewall rules that deny by default and allow only the destinations a workload legitimately needs, route all outbound through Cloud NAT so there is a single controlled path, and use Cloud DNS policies / DNS Firewall to block resolution of unapproved or known-malicious domains while logging every lookup. For deeper inspection, Secure Web Proxy and Cloud NGFW add TLS-aware egress filtering and IDS/IPS at the boundary.

# Deny all egress by default (high priority number = low precedence)...
gcloud compute firewall-rules create deny-all-egress \
  --network=prod-vpc --direction=EGRESS --action=DENY --rules=all \
  --destination-ranges=0.0.0.0/0 --priority=65534
 
# ...then allow only the approved destination range at higher precedence.
gcloud compute firewall-rules create allow-egress-apis \
  --network=prod-vpc --direction=EGRESS --action=ALLOW --rules=tcp:443 \
  --destination-ranges=199.36.153.8/30 --priority=1000   # restricted.googleapis.com

Detect what tries to leave

Under the controls, turn on VPC Flow Logs to reconstruct who talked to what during an incident, and DNS query logging to catch tunnelling — long, high-entropy subdomains and abnormal query volume to a single domain are how data escapes networks that block ordinary egress. Cloud IDS mirrors traffic to a Google-managed intrusion detection engine for signature-based detection of exfil and C2 patterns.