Creating a DMZ
Creating a dmz means placing a buffer subnet between the public internet and your private network. You set up firewalls to filter traffic entering and leaving this zone. Teams use this layout to host public web servers while keeping backend databases safe. Still, broad firewall rules or shared keys often give attackers a direct path inside. Core architecture for creating a dmz A demilitarized zone acts as a neutral network segment for your public services. External users can reach servers ins
DMZ: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Creating a dmz means placing a buffer subnet between the public internet and your private network. You set up firewalls to filter traffic entering and leaving this zone. Teams use this layout to host public web servers while keeping backend databases safe. Still, broad firewall rules or shared keys often give attackers a direct path inside.
Core architecture for creating a dmz
A demilitarized zone acts as a neutral network segment for your public services. External users can reach servers inside this zone, such as web or mail hosts. Those users cannot reach your internal private network directly from the outside internet. You build this barrier using either a single firewall or a dual firewall design.
In a single firewall design, one device manages at least three separate network interfaces. The first interface links to the public internet, and the second forms the buffer zone. The third interface links to your private internal network where sensitive data lives. This setup costs less, but it creates a single point of failure for your team.
A dual firewall layout offers stronger isolation by splitting the workload across two devices. The outer firewall sits at the edge and only allows public traffic into the zone. The inner firewall sits behind the buffer zone and guards the private network. An attacker must break through two distinct rule sets to reach your core systems.
Setting up network rules and routing
First, you group all public apps and services that need outside traffic. You assign these hosts to a dedicated subnet with its own IP address range. Next, you set up default deny rules on both the outer and inner firewalls. You then open only the exact ports needed for public web or mail traffic.
Public hosts often need to read or write data in your private backend databases. You allow this by opening narrow pinholes through the inner firewall for specific ports. You also set up network address translation to map public addresses to buffer hosts. Finally, you turn on packet logs at each boundary to track connection attempts.
DMZ: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network perimeters solve and where gaps remain
Network zones do a great job of blocking random scans from the public internet. They keep raw database ports off the public web and stop lateral movement. If a public web server gets hit, the inner firewall blocks broad network scans. This perimeter model gives your team a clear boundary for routing and packet rules.
Yet network firewalls only check IP addresses and ports when a session starts. Once an engineer or app logs in through an open port, the firewall steps back. It cannot read the actual SQL queries or shell commands running inside that session. If someone uses a valid role, the firewall lets every command pass right through.
Shared database passwords and long-lived SSH keys make this blind spot much worse. Teams often open firewall ports so developers can fix production servers from their laptops. A network rule decides which machine can talk, not what a user does next. It cannot rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Should a database ever sit inside a DMZ?
No, you should keep all databases inside the private internal network. Place only the web or app tier in the buffer zone and restrict inner ports.
What is the difference between a single and dual firewall DMZ?
A single firewall uses one device with three network interfaces to split traffic. A dual firewall uses two separate devices to guard the outer and inner boundaries.
How do engineers manage servers inside the buffer zone?
Engineers connect from the internal network or through a hardened remote entry point. You should still log every command and remove standing admin keys on those hosts.