Demilitarised Zone DMZ
You set up a demilitarised zone dmz by placing a buffer subnet between public traffic and private systems. Firewalls on both sides filter packets so public requests never reach your core databases directly. Teams often build this zone to host web servers and public APIs. When teams grant broad network rules across the zone, one breached host exposes internal data. Attackers can use open ports to move from the public subnet into private servers. How a demilitarised zone dmz works in network arc
Zone DMZ: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a demilitarised zone dmz by placing a buffer subnet between public traffic and private systems. Firewalls on both sides filter packets so public requests never reach your core databases directly. Teams often build this zone to host web servers and public APIs. When teams grant broad network rules across the zone, one breached host exposes internal data. Attackers can use open ports to move from the public subnet into private servers.
How a demilitarised zone dmz works in network architecture
A demilitarised zone dmz uses two firewall tiers to separate public services from private networks. The outer firewall accepts inbound requests from the public internet and routes them to zone hosts. Web servers, mail relays, and DNS nodes sit inside this middle subnet. These hosts handle external traffic without holding raw customer records on local disks. The inner firewall sits between the buffer zone and the private internal network. It blocks direct public packets and only allows specific traffic from approved zone servers.
Network admins set up strict IP and port rules on both firewall tiers. An outer rule lets public users reach the configured port on a web server. An inner rule lets that web server talk to a database port inside the private zone. Cloud teams build the same layout with public and private virtual subnets. Route tables and network security groups act as the inner and outer walls. Each subnet boundary checks the source IP, destination IP, and port before forwarding packets.
Why teams pair subnet walls with host access controls
Engineers still need a way to log in and maintain servers inside both zones. Teams often place an entry host in the outer subnet for admin tasks. Admins connect to this outer host first and then reach private servers inside the core network. They manage SSH keys, user roles, and firewall allowlists for every engineer on the team. When new developers join, admins update network rules and copy public keys to target machines.
Over time, static firewall rules and shared keys pile up across both subnets. A developer might need quick database access to fix a bug during an outage. Admins open a port between the zone and the private database to save time. That temporary rule often keeps the session active long after the team fixes the bug. Shared admin roles also make it hard to tell which person ran a specific command.
Zone DMZ: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network zones solve and what they leave open
A network buffer stops random internet scanners from reaching your private databases and internal apps. It contains public server breaches so attackers cannot scan your core subnet with ease. Packet filters and subnet walls are great at deciding which machine can reach another port. They block bad traffic at the network edge before it hits private workloads.
Still, network zones only check IP addresses and ports during the initial connection. Once a session passes the inner firewall, the network wall cannot read the commands inside. It does not know if an approved user runs a safe read query or drops a table. It also cannot rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs in results. Subnet rules decide which host connects, not what individual statements or commands do in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What services belong inside a demilitarised zone dmz?
Public web servers, load balancers, mail relays, and DNS servers belong in this outer zone. Databases and internal business apps should stay inside the private network behind the inner firewall.
Do cloud networks still need a buffer subnet?
Yes, cloud teams split virtual networks into public and private subnets using route tables. Load balancers sit in the public subnet while app servers and databases run in private subnets.
Can a dual firewall setup stop a stolen admin credential?
No, firewalls only verify IP addresses and ports when a session starts. If an attacker steals a valid key from an allowed IP, the firewall lets the traffic pass.