Firewall Architecture: DMZ Design Patterns

The core principle is containment: a host that accepts connections from the internet is assumed to be compromisable. The DMZ's job is to ensure that when it is compromised, the attacker lands in a network segment with no direct path to internal databases, domain controllers, or employee workstations.

This is an application of defense in depth rather than a single control. The DMZ boundary is enforced by firewall policy, but it is reinforced by host hardening, egress filtering, and monitoring on the DMZ hosts themselves — a DMZ is not a substitute for securing the servers that live in it.

The simplest and most budget-friendly design uses one firewall appliance with three interfaces: one facing the internet (untrusted), one facing the DMZ, and one facing the internal LAN (trusted). All inter-zone traffic passes through the same device and rule base.

The advantage is cost and simplicity — one box to manage. The drawback is a single point of failure: a misconfigured rule or a flaw in the firewall software itself can expose all three zones at once, and there's no second layer to catch a mistake in the first.

• •Internet interface: default-deny inbound, allow only ports the DMZ actually serves (typically 443, sometimes 80 redirecting to 443, 25 for a mail relay)
• •DMZ interface: strictly controlled outbound to internal, no unsolicited inbound from internal
• •Internal interface: internal hosts may initiate to DMZ for specific services (e.g., app server to internal DB proxy), never the reverse

A more resilient design places the DMZ between two separate firewalls — ideally from different vendors, though this adds operational overhead in patching and rule-syncing. The external firewall filters internet-to-DMZ traffic; the internal firewall filters DMZ-to-internal traffic. An attacker who compromises a DMZ host still has to defeat a second, independently configured device to reach the internal network.

This is the pattern recommended for environments handling regulated data (cardholder data environments under PCI DSS, for example) because it removes the single point of failure inherent in the three-legged design and makes rule review more tractable — each firewall has a narrower, more auditable job.

The rule set is where DMZ designs succeed or fail in practice. The pattern to enforce, regardless of topology:

• •Internet → DMZ: allow only the specific service ports the DMZ host exposes, nothing else
• •DMZ → Internet: restrict to what the application needs (e.g., outbound HTTPS for license checks or API calls) — do not allow a compromised DMZ host unrestricted outbound access, which is what lets it phone home to command-and-control infrastructure or exfiltrate data
• •DMZ → Internal: allow only specific, documented flows (e.g., web server to a single internal API on one port) — never allow the DMZ to initiate broad connectivity to the internal subnet
• •Internal → DMZ: allow only what's needed for management (SSH/RDP from a jump host, monitoring agents) — never let the DMZ initiate to internal management ports
• •Internal → Internet: filtered separately through the same or a different firewall, not routed through the DMZ

The following illustrates a three-zone nftables policy on a single Linux firewall (eth0 = WAN, eth1 = DMZ, eth2 = LAN). It defaults to drop and explicitly allows only the flows described above.

table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;

    # established/related always allowed back through
    ct state established,related accept

    # Internet -> DMZ: only HTTPS to the web host
    iifname "eth0" oifname "eth1" ip daddr 10.10.20.10 tcp dport 443 accept

    # DMZ -> Internal: web host to internal API, one port only
    iifname "eth1" oifname "eth2" ip saddr 10.10.20.10 ip daddr 10.10.30.5 tcp dport 8443 accept

    # DMZ -> Internet: outbound HTTPS only (e.g. package updates, license checks)
    iifname "eth1" oifname "eth0" tcp dport 443 accept

    # Internal -> DMZ: mgmt SSH from jump host only
    iifname "eth2" oifname "eth1" ip saddr 10.10.30.9 tcp dport 22 accept

    log prefix "DROPPED: " counter drop
  }
}

Most DMZ failures aren't topology mistakes — they're rule-base drift and operational shortcuts that erode the design over months.

• •"Temporary" broad rules (any/any between DMZ and internal) added for troubleshooting and never removed
• •Unrestricted DMZ egress, letting a compromised host reach any destination on any port — this is the single most common finding in DMZ audits
• •Management interfaces (SSH, RDP, database admin ports) reachable from the internet because a rule was scoped to the wrong interface
• •Treating the DMZ as trusted internally — internal hosts opening broad connectivity to "our own" DMZ servers because they're not seen as a threat
• •No logging or alerting on DMZ-to-internal connection attempts, so a pivot attempt looks like normal traffic until it's too late

• •Default-deny on every interface; allow only named, documented flows
• •One service per DMZ host where feasible — a compromised web server shouldn't also be a mail relay
• •Egress-filter the DMZ as strictly as ingress — outbound is where exfiltration and C2 happen
• •Log and alert on any DMZ-initiated connection to internal address space that isn't in the explicit allow list
• •Review and prune firewall rules on a fixed schedule; treat unreviewed "temporary" rules as expired after a set period
• •Segment further within the DMZ itself (a web-tier DMZ separate from a partner-VPN DMZ) rather than one flat zone for every externally facing service