DMZ Zone in Networking
You build a dmz zone in networking by placing public hosts between two firewalls. An outer firewall filters web traffic, while an inner firewall blocks direct local reach. Most teams start by moving web servers and mail relays into this middle subnet. When teams write broad firewall rules for convenience, an attacker can cross into private systems. A single open port to the internal network lets a compromised web server reach databases. How to set up a dmz zone in networking A standard setup
Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build a dmz zone in networking by placing public hosts between two firewalls. An outer firewall filters web traffic, while an inner firewall blocks direct local reach. Most teams start by moving web servers and mail relays into this middle subnet. When teams write broad firewall rules for convenience, an attacker can cross into private systems. A single open port to the internal network lets a compromised web server reach databases.
How to set up a dmz zone in networking
A standard setup uses either one firewall with three network ports or two separate firewalls. In the single firewall design, one port faces the public web. A second port links to the isolated subnet, and the third connects to private hosts. This layout costs less, but one broken device puts every internal subnet at risk.
The dual firewall model offers a stronger wall between outside users and private data. The front firewall permits public web traffic to reach only the hosts in the middle zone. The back firewall sits between that middle zone and your private local network. Teams often use two different firewall vendors so one software bug cannot break both walls.
Next, you assign a dedicated IP range to the middle subnet. You place public web apps, DNS servers, and mail relays inside this range. Databases and internal tools stay behind the back firewall inside the private zone. You then write strict allow rules on the back firewall for required app traffic. All other traffic between the zones gets dropped by default.
Routing traffic and managing firewall rules
Public users need to reach your web app without seeing private network addresses. You set up network address translation on the front firewall to map public IPs to middle hosts. When a packet arrives from the web, the front firewall checks the destination port. It forwards valid web requests to the web server and drops all other port scans.
When the web app needs data, it opens a session through the back firewall. The back firewall checks that the request comes from the exact web server IP. It also checks that the traffic uses the single database port you allowed. Reverse connections from the middle subnet to random private hosts get blocked right away. You also block middle hosts from initiating unapproved outbound sessions to the public internet.
Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What perimeter zones solve and what they miss
Network zones do a great job of blocking random port scans from the public internet. They stop outside attackers from sending packets straight to your private database hosts. If a public web server fails, the back firewall blocks network scans into private subnets. Perimeter rules control which IP address can open a network path to another host.
Still, a firewall rule only decides which machine or engineer can log in. Once an engineer or app opens an allowed port, the firewall stops checking the session. Network rules cannot read the actual database queries or shell commands running inside that tunnel. If an engineer logs in to fix a server, broad role permissions allow risky commands. Packet filters also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Should databases live inside the perimeter subnet?
No, you should keep all databases inside the private internal network behind the back firewall. If a public web server gets breached, local data on that same subnet is easy to steal. Let the web app talk to the private database through one restricted firewall port.
Is one firewall enough for a perimeter subnet?
A single firewall with three network ports works for small setups and test labs. Still, it creates a single point of failure for both performance and security rules. Production systems work best with two separate firewalls dividing the public, middle, and private networks.
How do engineers manage servers inside the isolated zone?
Engineers should never log in to middle servers directly from the public internet. Instead, they initiate sessions from the private internal network through the back firewall. You should restrict these admin sessions to specific source IPs and log every action taken.