6.1 Network Boundary: Traffic Inventory, Segmentation, and Egress Control
Firewall rules aren't the starting point of network security. First, you must understand what assets exist, which entities access which services, and why. Only then can you determine whether a given traffic flow represents legitimate business dependency or lateral movement. Without a traffic inventory, the default "deny all" policy often ends up becoming a permanent allow any.
Describe Allowed Paths Using Communication Contracts
source identity / segment
→ destination service
→ protocol + port
→ purpose + data class
→ owner + expiryIP addresses and ports are signals for execution, not necessarily stable identities. Cloud instances, containers, and mobile device addresses can change over time. Policy systems should derive network rules as much as possible from controlled workload or device identities, while still maintaining strict data-plane IP/port boundaries.
Rules must include an owner, justification, and expiration review. Temporary troubleshooting openings (without automatic expiration) can become permanent entry points.
Stateful Firewall Remembers Connections, Not Business Logic
A stateful firewall tracks connection state and can permit return traffic according to its rules. Removing an allow rule for new connections may leave existing conntrack/session state active; urgent revocation must also address established connections. It does not automatically recognize whether traffic on TCP port 443 represents a legitimate API call, data exfiltration, or a tunnel, nor can it substitute for application-level user authorization.
Internet → public gateway:443 allow
gateway → application:8080 allow
application → database:5432 allow
Internet → database:any deny
application → arbitrary Internet deny by defaultSegmentation should be centered on fault domains and trust boundaries: the public internet ingress, application layer, data layer, management plane, build system, and security control plane should not reside in a single broadcast domain. Over-segmentation risks rule explosion, so design must start with high-value boundaries and actual attack paths.
NAT Is Not Equal to Access Control
NAT modifies addresses and hides portions of the internal topology, but mechanisms like connection tracking, port mapping, UPnP, reverse connections, and established outbound traffic can still pass through it. Security conclusions must come from explicit firewall policies and endpoint authentication, not from the assumption that "nothing visible outside the private network."
Similarly, a DMZ is a segmentation strategy, not an inherently trusted zone. If a reverse proxy within the DMZ is compromised, it should only be able to access explicitly defined backend ports. It should not be permitted to read databases or access management interfaces simply because it "resides inside the internal network."
Egress Control Limits Attackers' Next Moves
Controlling only ingress leaves compromised processes free to download tools, access command-and-control (C2) servers, scan internal networks, and exfiltrate data. An egress policy should permit required DNS, identity, telemetry, and external APIs while denying metadata, management networks, and unknown destinations by default. A workload that needs instance identity from metadata requires a narrow identity-retrieval exception; arbitrary URL fetchers must not share that permission.
Domain-based rules require a trusted DNS path, synchronized resolution results, and redirect handling. CDNs and dynamic addresses make static IP allowlists brittle. An egress proxy can centralize domain and identity policy, but distinguish TLS tunneling from TLS termination. Allowing a CONNECT host does not inspect every HTTP request inside the tunnel; a decrypting proxy creates a new plaintext and trust boundary.
DNS is part of the control plane
DNS hijacking, cache poisoning, malicious search domains, and dangling records can all divert traffic to attackers. Enterprise resolvers should restrict recursive sources, protect the management plane, log critical changes, and establish detection for anomalous new domains and high-entropy queries.
DNSSEC authenticates DNS data and protects its integrity when the trust chain validates; it does not establish the domain operator's trustworthiness or hide queries. DoH/DoT protects transport to the selected resolver, which still sees the queries. Unmanaged endpoints can bypass enterprise resolver policy. Choosing the right approach requires distinguishing between client privacy, malware evasion, and internal domain resolution needs.
Separation of Management and Data Plane
Management interfaces need distinct management identities and access paths. Permission to make a business query to a database should not also grant permission to change security groups, read backup credentials, or administer build runners.
Design an out-of-band recovery path as well. In the event of failure in the identity system or network control plane, break-glass access should require dual control, short-lived credentials, and full audit logging, never a set of permanently valid shared administrator passwords.
Validate Network Policies
- Perform connectivity tests from both allowed and disallowed source addresses;
- Simultaneously verify IPv4, IPv6, and availability zone-specific paths;
- Check for outbound redirect rules, DNS changes, and metadata blocking;
- Validate the behavior of rule deletion, temporary exceptions expiring, and controller failures;
- Identify the actual consumers of each long-standing allow rule using flow logs;
- Simulate a compromised application host to confirm no lateral movement into the management plane or adjacent services.
The next lesson examines VPNs and zero-trust access for remote principals across untrusted networks.