The DMZ is the airlock between the hostile internet and the trusted internal network. Its architectural design dictates how well your organization can absorb external attacks without compromising internal data.
A single-homed DMZ uses one firewall with three interfaces (WAN, LAN, DMZ). A dual-homed (or back-to-back) design uses two separate firewalls, creating a true screened subnet where traffic must pass through two distinct security engines.
💡 Pro-tip: For high-security environments, use two firewalls from different vendors (e.g., Palo Alto and Fortinet) in a dual-homed DMZ. This prevents a single vendor zero-day from compromising the entire perimeter.
# Dual-Homed DMZ Policy Example
- name: Internet to DMZ
src: untrust
dst: dmz
app: web-browsing
action: allow
- name: DMZ to Internal LAN
src: dmz
dst: trust
app: sql-server
action: deny # Force via API GatewayThis policy enforces that the DMZ cannot initiate direct SQL connections to the internal LAN, requiring all database queries to pass through an internal application tier.
Modern DMZs are multi-tiered. The outer tier hosts the Web Application Firewall (WAF) and load balancers. The inner tier hosts the actual web servers. This ensures that application-layer attacks are stopped before they reach the backend logic.
⚠️ Never place internal Active Directory domain controllers in the DMZ. If the DMZ is breached, the attacker gains immediate control over identity and authentication for the entire enterprise.
| Design | Cost | Security Level |
|---|---|---|
| Single-Homed | Low | Medium (Single point of failure) |
| Dual-Homed | High | High (Redundant inspection) |
| Multi-Tier | Very High | Maximum (Defense in depth) |
Verify exercises to earn ★ 200 XP and unlock next lab level.