Egress control, DNS & firewalls

NAT, egress proxies, DNS filtering, and exfiltration defense.

Almost everyone filters inbound traffic and leaves outbound wide open. But exfiltration and command-and-control both leave through egress: a compromised workload with unrestricted outbound can stream your data anywhere and pull down the next stage of an attack. Controlling what can leave, and logging the rest, turns a silent breach into a blocked, alerting event.

Why egress is the neglected half

A default-open outbound policy assumes everything inside the perimeter is trustworthy — the exact assumption modern attacks break. Constrain egress to the specific destinations a workload legitimately needs (a package mirror, an internal API, a payment provider) and deny the rest. For most workloads the legitimate egress list is short and stable, which makes an allowlist practical rather than painful, and makes any attempt to reach an unlisted host an immediate red flag.

# Squid egress proxy: allow only approved destinations, deny + log the rest.
acl approved dstdomain .github.com .amazonaws.com registry.internal
http_access allow approved
http_access deny all                 # everything else is refused and logged
 
# Workloads have NO direct route out; the only path is the proxy:
#   HTTPS_PROXY=http://egress-proxy.internal:3128
# A compromised container trying to reach evil.example is blocked at the proxy
# and the attempt appears in the proxy log as a denied request.

DNS filtering and exfil defense

DNS is both an egress control point and an exfiltration channel. Filtering resolution against threat intelligence blocks known C2 and phishing domains before a connection is even attempted, and logging every lookup gives you a high-value record for hunting. Watch for the telltale signs of DNS tunnelling — long, high-entropy subdomains and abnormal query volume to one domain — which is how data leaves networks that block ordinary egress.