SY0-701Chapter 104 of 212Objective 3.1

DMZ Architecture and Design

This chapter covers DMZ (Demilitarized Zone) architecture and design, a core component of network security for the Security+ SY0-701 exam under Objective 3.1: Security Architecture. Understanding DMZ is critical because it is the most common method for securely exposing internal services to external networks while protecting the internal LAN. You will learn the logical and physical placement of DMZ components, traffic flow rules, and how to design for defense in depth. This knowledge directly applies to scenario questions about network segmentation and firewall rules.

25 min read
Intermediate
Updated May 31, 2026

The Castle's Outer Bailey Defense

Imagine a medieval castle with two concentric walls. The outer wall encloses a large area called the outer bailey, where merchants, stables, and supply stores are located. This area is accessible to the public through a heavily guarded main gate. The inner wall, taller and stronger, encloses the inner bailey, where the lord's keep, treasury, and armory reside. Between the two walls is a killing field—a wide, open space with no cover, overlooked by archers on both walls. A drawbridge and portcullis control access from the outer bailey to the inner bailey. In this design, if attackers breach the outer wall, they are trapped in the killing field, exposed to fire from both walls, and cannot easily reach the inner treasures. The outer bailey provides services (like a market) to outsiders without exposing the inner bailey. This is exactly how a DMZ works: the outer wall is the firewall facing the internet, the outer bailey is the DMZ network hosting public servers (web, email, DNS), and the inner wall is the firewall facing the private LAN. The killing field is the DMZ itself—a buffer zone where traffic is inspected and limited. Attackers who compromise a DMZ server are contained; they cannot directly access the internal network because the inner firewall blocks unauthorized traffic. Just as the castle's design forces attackers into a kill zone, the DMZ forces malicious traffic to be isolated and inspected.

How It Actually Works

What is a DMZ and Why Do We Need It?

A Demilitarized Zone (DMZ) is a physical or logical subnetwork that separates an internal local-area network (LAN) from other untrusted networks, usually the internet. The term comes from military geography—a buffer zone between two hostile forces. In networking, the DMZ hosts external-facing services such as web servers, mail servers, DNS servers, and VPN endpoints. The core principle is that if an attacker compromises a server in the DMZ, they should not automatically gain access to the internal network. This containment is achieved through strict firewall rules and network segmentation.

The threat addressed by a DMZ is the need to provide public access to certain services while minimizing risk to internal assets. Without a DMZ, an organization might place a web server directly on the internal LAN, exposing all internal hosts to potential compromise if the web server is hacked. With a DMZ, the web server sits in an isolated network, and the firewall enforces separate policies for traffic between internet and DMZ, DMZ and internal, and internal and internet.

How DMZ Architecture Works Mechanically

A typical DMZ architecture involves at least one firewall with three interfaces: one connected to the internet (untrusted), one to the DMZ (semi-trusted), and one to the internal network (trusted). This is called a three-legged firewall. Alternative designs use two firewalls in series: an outer firewall facing the internet and an inner firewall facing the internal network, with the DMZ between them.

Traffic flow rules are as follows:

Inbound traffic from the internet to the DMZ: Allowed only for specific services (e.g., HTTP/HTTPS to web server, SMTP to mail server). The firewall performs stateful inspection and may include an intrusion prevention system (IPS).

Outbound traffic from the DMZ to the internet: Typically allowed as needed (e.g., web server fetching updates), but often restricted to specific destinations and protocols.

Traffic from the DMZ to the internal network: Strictly prohibited by default. Exceptions are rare and tightly controlled (e.g., a web server connecting to an internal database via a specific port).

Traffic from the internal network to the DMZ: Allowed for specific management purposes (e.g., IT staff SSH to DMZ servers) and for accessing DMZ-hosted services (e.g., internal users checking email).

Traffic from the internal network to the internet: Usually allowed with NAT and firewall inspection.

Traffic from the internet to the internal network: Blocked unless part of an established session (e.g., a response to an internal request) or via a VPN.

Key Components and Variants

Screened Subnet: Another name for DMZ. The term emphasizes that the subnet is screened (filtered) by firewalls.

Three-Legged Firewall: A single firewall with three interfaces. This is simpler and cheaper but creates a single point of failure. If the firewall is compromised, all segments are at risk.

Dual Firewall (Back-to-Back DMZ): Two firewalls—one external, one internal—with the DMZ between them. This provides defense in depth. The external firewall protects the DMZ from the internet; the internal firewall protects the internal network from the DMZ. If one firewall is breached, the other still provides protection. This is the recommended architecture for high-security environments.

Virtual DMZ: A DMZ implemented using VLANs and virtual firewalls within a hypervisor. This is common in cloud and virtualized environments (e.g., AWS VPC with public subnets acting as DMZ).

Port Forwarding vs. DMZ: Some small office/home office (SOHO) routers have a feature called "DMZ host" that forwards all incoming traffic to a single internal IP. This is NOT a true DMZ—it completely exposes that host without isolation. The exam distinguishes between "DMZ host" (dangerous) and "DMZ network" (secure).

How Attackers Exploit DMZ Misconfigurations

Attackers target DMZ servers because they are internet-facing and often run outdated software. Common attacks include: - Web Application Attacks: SQL injection, cross-site scripting, or exploiting vulnerabilities like CVE-2017-5638 (Apache Struts) to gain remote code execution on the web server. - Pivoting: Once a DMZ server is compromised, the attacker uses it as a launch point to attack the internal network. This is why DMZ-to-internal traffic must be tightly controlled. Without proper segmentation, an attacker can use the compromised server to scan internal hosts. - DNS Tunneling: Using DNS queries to exfiltrate data from a DMZ DNS server to an external attacker-controlled server. - Mail Server Exploitation: Exploiting vulnerabilities in SMTP services (e.g., CVE-2019-11043) to execute commands.

Defensive Deployment: Best Practices

Default Deny: Firewall rules should explicitly allow only necessary traffic. All other traffic is denied.

Principle of Least Privilege: DMZ servers should have minimal permissions and only necessary services enabled.

Separation of Management Traffic: Use out-of-band management or dedicated management VLANs for DMZ servers. Never allow management from the internet.

Monitoring and Logging: Enable logging on firewalls and DMZ servers. Use a SIEM to correlate events. Look for outbound connections from DMZ to internal IPs—this is a red flag.

Regular Patching: DMZ servers are high-value targets; patch critical vulnerabilities promptly.

Network Segmentation: Use separate VLANs for different DMZ services (e.g., web DMZ, mail DMZ) to limit lateral movement.

Real Command/Tool Examples

Firewall Rule Example (iptables on Linux):

# Allow incoming HTTP from any to DMZ web server (10.0.1.10)
iptables -A FORWARD -i eth0 -o eth1 -d 10.0.1.10 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
# Block all other incoming traffic from internet to DMZ
iptables -A FORWARD -i eth0 -o eth1 -j DROP
# Block all traffic from DMZ to internal network (10.0.2.0/24)
iptables -A FORWARD -i eth1 -o eth2 -d 10.0.2.0/24 -j DROP

Cisco ASA Configuration Snippet:

! Define interfaces
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 203.0.113.1 255.255.255.0
!
interface GigabitEthernet0/1
 nameif dmz
 security-level 50
 ip address 10.0.1.1 255.255.255.0
!
interface GigabitEthernet0/2
 nameif inside
 security-level 100
 ip address 10.0.2.1 255.255.255.0
!
! Allow HTTP from outside to DMZ web server
access-list outside-in extended permit tcp any host 10.0.1.10 eq www
access-group outside-in in interface outside
! Deny all other inbound traffic
access-list outside-in extended deny ip any any
! Allow DMZ to reach internet for updates
access-list dmz-out extended permit tcp host 10.0.1.10 any eq 443
access-group dmz-out in interface dmz
! Deny DMZ to inside
access-list dmz-in extended deny ip any 10.0.2.0 255.255.255.0
access-group dmz-in in interface dmz

Nmap Scan to Verify DMZ Isolation:

# From a DMZ server, try to scan the internal network
nmap -sT 10.0.2.0/24
# If properly configured, all ports should be filtered or no response

Standards and RFCs

RFC 1918: Defines private IP address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). DMZ servers often use public IPs or private IPs with NAT.

RFC 2647: Benchmarking Terminology for Firewall Performance. Relates to firewall testing in DMZ architectures.

NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy. Provides guidance on DMZ design.

Walk-Through

1

Identify Services to Expose

Begin by listing all services that need to be accessible from the internet, such as web (HTTP/HTTPS), email (SMTP, IMAP, POP3), DNS, and VPN. Each service requires a dedicated server or virtual machine placed in the DMZ. For each service, document the protocol, port numbers (e.g., TCP 80/443 for web, TCP 25 for SMTP, UDP 53 for DNS), and the expected traffic volume. This step determines the number of DMZ servers and the firewall rules needed. A common mistake is overloading a single server with multiple services, increasing the attack surface. The SY0-701 exam expects you to identify that each service should ideally be on a separate server to limit blast radius.

2

Design Network Segmentation

Decide on the physical or logical topology. For a small organization, a three-legged firewall with a single DMZ subnet may suffice. For higher security, use a dual firewall design with separate DMZ subnets for different sensitivity levels (e.g., a web DMZ and a mail DMZ). Assign IP addressing—typically using RFC 1918 private addresses for the DMZ subnet, with NAT on the external firewall to map public IPs to DMZ servers. Document the subnet mask, default gateway, and VLAN IDs if using virtual LANs. Ensure the DMZ subnet is not the same as the internal LAN subnet to avoid routing confusion. The exam tests your ability to choose between single and dual firewall based on security requirements.

3

Configure Firewall Rules

Implement access control lists (ACLs) on the firewall(s). For the external firewall (or the internet-facing interface of a three-legged firewall), create rules that allow only necessary inbound traffic to DMZ servers. For example, allow TCP port 80 and 443 to the web server only. Deny all other inbound traffic. For the internal firewall (or the internal interface), create rules that block all traffic from the DMZ to the internal network by default. Then add exceptions only if absolutely required (e.g., a web server needs to query an internal database on a specific port). Use stateful inspection to allow return traffic for established sessions. Log all denied traffic for analysis. A common trap on the exam is allowing DMZ-to-internal traffic that is not explicitly needed.

4

Deploy and Harden DMZ Servers

Install operating systems and applications on DMZ servers with a minimal configuration—disable unnecessary services, remove unused software, and apply the latest patches. Use host-based firewalls (e.g., Windows Firewall, iptables) as an additional layer. Configure logging to send events to a centralized SIEM. Set up intrusion detection (IDS) or prevention (IPS) on the DMZ network segment. Harden the servers according to CIS benchmarks. For example, for a web server, disable directory listing, use secure headers (HSTS, X-Frame-Options), and implement input validation. The exam expects you to know that DMZ servers should be hardened more strictly than internal servers because they are exposed to untrusted networks.

5

Test and Validate Segmentation

After deployment, perform penetration testing and vulnerability scanning from the internet side to verify that only intended services are reachable. Then, simulate a compromise of a DMZ server (e.g., via a web shell) and attempt to access the internal network. Ensure that the internal firewall blocks these attempts. Use tools like Nmap, Metasploit, or commercial scanners. Review firewall logs to confirm that blocked traffic is logged. Also test that legitimate traffic (e.g., internal users accessing the web server) works correctly. Validate that outbound traffic from DMZ servers is restricted (e.g., only to specific update servers). This step is often overlooked in real-world deployments, leading to security gaps. The exam may present a scenario where a misconfiguration allows DMZ-to-internal traffic, and you must identify the fix.

What This Looks Like on the Job

Scenario 1: E-commerce Web Server Compromise A mid-sized company hosts its e-commerce website on a single server in a DMZ behind a three-legged firewall. An attacker exploits a SQL injection vulnerability (CVE-2021-22204) in the web application, gaining a reverse shell on the web server. The attacker immediately attempts to scan the internal network (192.168.1.0/24) using Nmap. However, the internal firewall rules block all outbound traffic from the DMZ to the internal network. The attacker's scans time out. The IDS on the DMZ segment detects the scanning activity and alerts the SOC. The SOC analyst reviews the logs, sees the blocked traffic, and confirms the DMZ containment is working. The analyst then coordinates with the web team to patch the vulnerability and rebuild the server from a known good image. Common mistake: If the DMZ-to-internal rule had been too permissive (e.g., allowing TCP 3306 for database access without IP restriction), the attacker could have pivoted to the internal database server and exfiltrated customer data.

Scenario 2: Dual Firewall DMZ with VPN A financial institution uses a dual firewall DMZ architecture. The external firewall allows only HTTPS to the web server and UDP 500/4500 for IPsec VPN. The internal firewall permits only VPN traffic from the DMZ VPN concentrator to the internal authentication server (LDAP on TCP 389) and blocks all other DMZ-to-internal traffic. An attacker attempts a DDoS attack on the web server. The external firewall rate-limits incoming connections, and the web server is behind a load balancer that absorbs the attack. The SOC uses netflow data to identify the attack source and blocks the IP range at the external firewall. The internal network remains unaffected. Common mistake: Some organizations place the VPN concentrator inside the internal network, not in the DMZ, forcing remote users to traverse the internal firewall unnecessarily. The correct design places the VPN concentrator in the DMZ so that remote users authenticate before accessing internal resources.

Scenario 3: Cloud DMZ in AWS A startup uses AWS with a VPC. They create a public subnet as a DMZ for their web servers, and a private subnet for databases. The public subnet has an internet gateway, and security groups allow only HTTP/HTTPS inbound. The private subnet has no direct internet access; it can only be reached from the public subnet via a specific security group rule allowing TCP 3306 for MySQL. An attacker compromises the web server via an unpatched vulnerability. The attacker tries to connect to the database but the security group only allows traffic from the web server's private IP, and the attacker cannot spoof that IP because AWS enforces source/destination checks. The attack is contained. Common mistake: Using a single security group that allows all traffic between subnets, effectively bypassing DMZ isolation.

How SY0-701 Actually Tests This

What SY0-701 Tests on DMZ Architecture The exam focuses on your ability to design and evaluate DMZ architectures in scenario-based questions. Specific sub-objectives under 3.1 include: (1) Explain the importance of network segmentation and DMZ as a security control. (2) Compare and contrast DMZ designs: three-legged firewall vs. dual firewall vs. screened subnet. (3) Understand how placement of services (web, mail, DNS, VPN) affects security. (4) Identify proper firewall rules for DMZ traffic flows. (5) Recognize the difference between a true DMZ network and a SOHO "DMZ host" feature.

Common Wrong Answers and Why Candidates Choose Them 1. "Place the web server inside the internal network for better performance." – Candidates think speed over security. The correct answer is to place it in the DMZ to isolate it. 2. "Use a single firewall with two interfaces (inside/outside) and put the DMZ on the inside interface." – This creates a flat network; the DMZ is not isolated. The correct design uses a third interface or a second firewall. 3. "Allow DMZ servers to initiate connections to internal servers freely for database access." – Candidates forget the principle of least privilege. The correct answer is to allow only specific ports and IPs. 4. "A DMZ host feature on a SOHO router provides the same security as a true DMZ." – This is a trap; the DMZ host feature completely exposes one internal host, not a segmented network.

Specific Terms and Acronyms - DMZ (Demilitarized Zone) - Screened subnet - Three-legged firewall - Back-to-back firewall - Stateful inspection - Default deny - RFC 1918 (private IP ranges) - NAT (Network Address Translation) - Ingress/egress filtering

Common Trick Questions - A question might describe a "DMZ" with a single firewall and ask if it provides adequate security. The trick: a three-legged firewall is acceptable, but if the firewall is compromised, the DMZ is not isolated. The exam may ask for the best design—dual firewall. - Another trick: "Which device should be placed in the DMZ?" Options: web server, database server, domain controller. The correct answer is web server; database and domain controller should be internal. - A scenario where an organization uses a single public IP and port forwarding to a single internal server—this is NOT a DMZ; it's just port forwarding.

Decision Rule for Eliminating Wrong Answers On scenario questions, first identify where each asset is placed (DMZ vs. internal). Then check firewall rules: (1) Is traffic from internet to DMZ restricted to necessary services? (2) Is traffic from DMZ to internal blocked? (3) Is traffic from internal to DMZ allowed only for management? If any rule violates these, the answer describing that rule is likely incorrect. Also, if the question mentions "DMZ host" or "virtual server" without segmentation, it's probably a distractor.

Key Takeaways

A DMZ is a network segment that isolates external-facing servers from the internal LAN.

The three-legged firewall uses one device with three interfaces; the dual firewall uses two separate firewalls for defense in depth.

Firewall rules should follow default deny: only explicitly allow necessary traffic.

Traffic from the DMZ to the internal network should be blocked by default; exceptions must be minimal and specific.

A SOHO router's 'DMZ host' feature is not a true DMZ—it exposes a single internal host without isolation.

Common DMZ services include web (TCP 80/443), email (TCP 25, 143, 993), DNS (UDP 53), and VPN (UDP 500/4500).

Placement of VPN concentrators should be in the DMZ to authenticate remote users before accessing internal resources.

Logging and monitoring of DMZ traffic is critical; outbound connections from DMZ to internal IPs are suspicious.

DMZ servers must be hardened, patched, and run minimal services to reduce attack surface.

In cloud environments (e.g., AWS), a public subnet with security groups acts as a DMZ; private subnets are internal.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Three-Legged Firewall DMZ

Single device with three interfaces (outside, DMZ, inside)

Lower cost and simpler management

Single point of failure: if firewall compromised, all segments are exposed

Traffic between DMZ and inside passes through same firewall

Suitable for small to medium businesses with moderate security needs

Dual Firewall (Back-to-Back) DMZ

Two separate firewalls: external (internet to DMZ) and internal (DMZ to inside)

Higher cost and more complex configuration

Defense in depth: if one firewall is breached, the other still protects

Traffic between DMZ and inside passes through two firewalls (external and internal)

Recommended for high-security environments like finance or healthcare

DMZ Network (True DMZ)

Isolated subnet with firewall rules controlling traffic

Multiple servers can be placed in the DMZ

Provides containment: compromised server cannot directly access internal network

Requires careful configuration of firewall rules

Industry standard for secure network design

DMZ Host (SOHO Router Feature)

A single internal IP address that receives all forwarded ports

Only one host can be the DMZ host at a time

No isolation: the host is directly on the internal network with all ports exposed

Often misconfigured, leaving the host fully exposed to the internet

Not considered a secure DMZ; should be avoided for production environments

Watch Out for These

Mistake

A DMZ is just a separate VLAN; no firewall rules needed.

Correct

A DMZ requires firewall rules to enforce isolation. A VLAN alone provides no security; it only separates broadcast domains. Without firewall rules, traffic can still route between VLANs if a router or Layer 3 switch is configured to allow it.

Mistake

Placing a server in the DMZ means it is not protected by a firewall.

Correct

DMZ servers are protected by the external firewall from internet threats, but they are more exposed than internal servers. The purpose is to contain a breach, not to leave servers unprotected. DMZ servers should still have host-based firewalls and hardening.

Mistake

A dual firewall DMZ is always better than a three-legged firewall.

Correct

Dual firewall provides defense in depth but increases complexity and cost. For small organizations with limited resources, a properly configured three-legged firewall can be sufficient. The exam expects you to choose based on risk tolerance and budget.

Mistake

DMZ servers can have direct internet access without restrictions.

Correct

Outbound traffic from DMZ servers should be restricted to only what is necessary (e.g., software updates from specific sources). Unrestricted outbound access allows attackers to exfiltrate data or download tools.

Mistake

A DMZ is only for web servers.

Correct

DMZs host any service that needs to be accessible from untrusted networks, including email, DNS, VPN, and application gateways. The exam may ask which of these should be in the DMZ.

Frequently Asked Questions

What is the difference between a three-legged firewall and a dual firewall DMZ?

A three-legged firewall uses one firewall with three network interfaces: one for the internet, one for the DMZ, and one for the internal network. It is simpler and cheaper but creates a single point of failure. A dual firewall DMZ uses two separate firewalls: an external firewall between the internet and DMZ, and an internal firewall between the DMZ and internal network. This provides defense in depth—if one firewall is compromised, the other still protects. For the exam, remember that dual firewall is more secure but more expensive and complex. Scenario questions may ask you to choose based on security requirements; if high security is needed, choose dual firewall.

Should a database server be placed in the DMZ?

No, database servers should be placed in the internal network, not the DMZ. The DMZ hosts only servers that need direct access from the internet, such as web and email servers. A database server contains sensitive data and should be isolated. If a web server in the DMZ needs to access a database, it should connect to the internal database through a tightly controlled firewall rule that allows only the specific port (e.g., TCP 3306 for MySQL) and only from the web server's IP. This minimizes exposure. On the exam, if a question asks where to place a database server, the correct answer is the internal network.

What is a screened subnet?

A screened subnet is another term for a DMZ. It refers to a network segment that is 'screened' or filtered by a firewall. The term emphasizes that the subnet is protected by a screening router or firewall. In some contexts, a screened subnet may imply a single router with ACLs instead of a stateful firewall, but for the Security+ exam, treat it as synonymous with DMZ. The key point is that it is a buffer network between the internet and the internal network.

Can a DMZ be implemented in a cloud environment like AWS?

Yes. In AWS, a DMZ is typically implemented using a Virtual Private Cloud (VPC) with public and private subnets. The public subnet acts as the DMZ, and the private subnet acts as the internal network. Security groups and network ACLs control traffic. For example, a web server in the public subnet (DMZ) can have a security group that allows HTTP/HTTPS from the internet, while the database in the private subnet has a security group that allows traffic only from the web server's security group. This mimics a dual firewall design. The exam may present a cloud scenario; remember that the same DMZ principles apply.

What is the purpose of a DMZ?

The primary purpose of a DMZ is to add an additional layer of security to an organization's internal network. By placing external-facing services in a separate network segment, you limit the impact of a potential security breach. If an attacker compromises a server in the DMZ, they do not automatically have access to the internal network because the internal firewall blocks traffic from the DMZ. This containment is crucial for protecting sensitive internal resources. The DMZ also allows organizations to provide services to the public without exposing their internal infrastructure.

How do you configure firewall rules for a DMZ?

Firewall rules should follow the principle of least privilege. For inbound traffic from the internet to the DMZ, allow only the specific ports needed for each service (e.g., TCP 80 for HTTP, TCP 443 for HTTPS). Deny all other inbound traffic. For outbound traffic from the DMZ to the internet, restrict to necessary destinations (e.g., update servers). For traffic from the DMZ to the internal network, block all by default; if needed, allow only specific source IPs, destination IPs, and ports. For traffic from the internal network to the DMZ, allow for management (e.g., SSH from admin IPs) and for internal users accessing DMZ services. Always use stateful inspection to allow return traffic. Log all denied traffic for monitoring.

What is the difference between a DMZ and a VPN?

A DMZ is a network segment that isolates external-facing servers from the internal network. A VPN (Virtual Private Network) is a technology that creates an encrypted tunnel over an untrusted network to allow remote users to securely access the internal network. They serve different purposes but can be used together. For example, a VPN concentrator can be placed in the DMZ so that remote users authenticate before being allowed into the internal network. The exam may ask where to place a VPN server; the correct answer is often the DMZ.

Terms Worth Knowing

Ready to put this to the test?

You've just covered DMZ Architecture and Design — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.

Done with this chapter?