DMZ Screened Subnet
You set up a dmz screened subnet by placing public servers between two firewalls. An outer firewall filters web traffic, and an inner firewall protects private systems. Engineering teams use this layout to keep public apps away from core databases. Still, broad firewall rules or shared admin keys can still expose internal networks. How a dmz screened subnet works A dmz screened subnet acts as a buffer zone for your network. It sits between the public internet and your private internal network
Screened Subnet: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a dmz screened subnet by placing public servers between two firewalls. An outer firewall filters web traffic, and an inner firewall protects private systems. Engineering teams use this layout to keep public apps away from core databases. Still, broad firewall rules or shared admin keys can still expose internal networks.
How a dmz screened subnet works
A dmz screened subnet acts as a buffer zone for your network. It sits between the public internet and your private internal network. The first firewall faces the internet and blocks bad traffic right away. It only lets approved web requests reach the servers in the buffer zone.
Servers in this middle zone run public services like web apps and mail relays. These hosts never hold sensitive customer records or core business logic. If an attacker compromises a web host, they remain trapped in the middle zone.
A second firewall sits behind the buffer zone to guard the private network. This inner firewall checks every packet that moves from the buffer to private hosts. Teams set up strict rules here so web servers only talk to specific ports. Direct traffic from the public internet to the private network hits a block.
Network admins often use two different firewall vendors for the inner and outer walls. If one vendor has a software bug, the second firewall still stops the attack. Routing tables in the middle zone also drop any unknown network paths. Every packet must match an explicit allow rule on both walls to pass through.
What the network setup solves and what it misses
This two-firewall design stops direct scans against your private databases and internal servers. It gives security teams a clear place to watch incoming web traffic. It also limits network movement if a public server gets compromised during an attack. You gain strong network borders and clear routing paths between public and private zones.
Still, network borders only check IP addresses and port numbers during transit. A firewall decides which host can open a session, not what happens inside. Once an engineer or app logs in through an open port, the firewall steps back. It cannot read individual database queries, shell commands, or API calls in flight.
Screened Subnet: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Teams still need a way to manage human and automated sessions to internal hosts. Admins must update firewall rules by hand when server addresses change. Broad roles on backend databases let valid users run risky commands over approved ports. If a query returns sensitive emails, phone numbers, or card numbers, the firewall passes them. Network rules alone cannot rewrite matched fields in results or approve single commands.
Managing admin sessions across network zones
Engineers often need to reach hosts inside the buffer zone and the private network. Opening admin ports across both firewalls creates a path that attackers can abuse. Teams often share static keys or keep wide network paths open for daily work. Over time, these temporary firewall rules pile up and weaken the boundary.
Good network hygiene requires teams to lock down both network paths and user sessions. You should restrict outbound traffic from the buffer zone to the bare minimum. You should also audit every command and query that crosses into the private zone. Pairing network isolation with query-level checks keeps both your borders and data safe.
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 is the difference between a screened host and a screened subnet?
A screened host uses one firewall and puts one server on the internal network. A screened subnet uses two firewalls to isolate a whole group of public servers.
Can a single firewall create a dmz screened subnet?
Yes, one firewall with three network ports can separate public, middle, and private zones. Still, using two separate firewalls prevents a single device failure from exposing internal systems.
Which servers belong inside the buffer subnet?
Place any host that accepts direct requests from the internet inside the middle subnet. Common examples include web servers, DNS servers, mail relays, and public API endpoints.