DMZ Topology
A dmz topology is a network zone that sits between the public web and private systems. You set up this zone by placing public servers between outer and inner firewall rules. Teams often build this layout to protect internal databases from public web traffic. When teams grant broad firewall rules, attackers can move from public apps into private data stores. Broad network rules also let engineers reach every internal service once they enter the private zone. How to set up a dmz topology in your
Topology: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A dmz topology is a network zone that sits between the public web and private systems. You set up this zone by placing public servers between outer and inner firewall rules. Teams often build this layout to protect internal databases from public web traffic. When teams grant broad firewall rules, attackers can move from public apps into private data stores. Broad network rules also let engineers reach every internal service once they enter the private zone.
How to set up a dmz topology in your network
First, you divide your network into three distinct zones: public, perimeter, and private. Your public web servers and mail relays live inside the middle perimeter zone. Your core databases and internal apps stay inside the private zone. You can build this layout with either one firewall or two separate firewalls.
In a single firewall design, one device uses three or more network ports. One port faces the public internet, one holds the perimeter zone, and one guards the private network. This setup costs less to run, but one broken device can expose the whole network.
In a dual firewall design, two separate firewalls guard the middle zone. The outer firewall checks public packets and sends allowed traffic to the middle zone. The inner firewall checks requests moving from the middle zone to the private zone. Teams often pick two vendors so one software bug does not break both walls.
Next, you write strict routing rules for every single network path. Public users can send requests to web servers inside the middle perimeter zone. Those web servers can open ports to specific database hosts in the private zone. Public users can never send direct packets to the private zone at all.
What perimeter zones solve and what they leave open
A perimeter network zone stops outsiders from scanning or hitting your private servers. If an attacker takes over a web server, the inner firewall blocks broad lateral movement. Network rules check source addresses, target addresses, and ports before packets can pass. This layout works well for blocking unauthorized hosts at the network edge.
Still, network firewalls only decide which hosts or users can open a path. Once a session starts, the firewall does not inspect individual SQL queries or shell commands. An engineer or app with an open route can still run a destructive drop table command. They can also pull large tables filled with raw emails, phone numbers, or card numbers.
Topology: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared database roles make this gap much worse for engineering teams. Multiple apps and engineers often log in with the same broad database role. Network logs only show packet counts and IP addresses, not who ran a specific query. To control live sessions, teams need controls that check each command and mask sensitive results.
Managing engineer access across segmented network zones
Engineers still need a safe way to fix servers and query databases across zones. Many teams place a dedicated entry server inside the middle zone for admin tasks. Engineers log in to that host first and then reach private servers inside the core network.
This manual setup adds extra keys, host rules, and firewall ports to maintain. If an engineer leaves the company, you must rotate keys across many hosts right away. Leaving static keys on perimeter hosts creates a major risk if a server gets breached. Teams need a simpler way to verify identity and inspect commands in flight.
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
What is the difference between a single and dual firewall dmz topology?
A single firewall uses one device with three network ports to separate traffic zones. A dual firewall uses two separate devices placed in front of and behind the perimeter zone. The dual layout costs more, but it prevents a single point of failure.
Should database servers ever sit inside the perimeter zone?
No, database servers should always stay inside the private internal network zone. Only public web servers, load balancers, and mail relays belong in the perimeter zone. The web server talks to the private database through a strict inner firewall rule.
Do cloud networks still need a perimeter zone layout?
Yes, cloud networks use public and private subnets to build the exact same zone model. Teams put load balancers in public subnets and keep apps and databases in private subnets. Security groups and route tables act as the outer and inner firewalls.