DMZ Network Topology
A dmz network topology places public servers inside an isolated buffer subnet. This setup sits between the open internet and your private internal network. Network teams build this boundary using one or two firewalls to filter packets. Broad firewall rules or shared credentials inside the buffer zone create big risks. An attacker who breaches one web host can move to backend databases. How a dmz network topology works in practice A perimeter subnetwork separates untrusted public traffic from
Network Topology: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A dmz network topology places public servers inside an isolated buffer subnet. This setup sits between the open internet and your private internal network. Network teams build this boundary using one or two firewalls to filter packets. Broad firewall rules or shared credentials inside the buffer zone create big risks. An attacker who breaches one web host can move to backend databases.
How a dmz network topology works in practice
A perimeter subnetwork separates untrusted public traffic from private company databases and hosts. External users send requests to web, mail, or DNS servers inside the buffer. Those public servers never sit on the same local network as private data.
Teams often choose between a single-firewall design and a dual-firewall design. In a single-firewall layout, one appliance uses three separate network interfaces. One interface links to the internet, one feeds the buffer, and one guards internal systems. This setup costs less, but one broken device puts every zone at risk.
A dual-firewall layout places the buffer subnet between two distinct firewall appliances. The outer firewall allows incoming web traffic to reach only the public hosts. The inner firewall checks all traffic moving from the buffer to private servers. Teams often use two different vendors so one software bug cannot break both walls.
Where perimeter network rules fall short for engineers
Network zones and firewall rules do a good job of blocking outside scanners. They control which IP addresses and ports can open a path between subnets. Still, port rules only check where packets start and where they go.
Engineers and support staff still need to log in to fix broken servers. They also query databases inside the private zone during incidents or routine maintenance. Once a firewall opens a port for an engineer, network inspection stops there.
Standard perimeter rules cannot see which person runs a command over an open port. They cannot block a bad query that deletes a table in a database. They also do not mask emails, phone numbers, or card numbers in query results. If a developer account holds broad permissions, one mistake can damage live data. Teams need controls that check identity and inspect commands in flight, not just ports.
Network Topology: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Steps to harden traffic across network zones
Start by denying all traffic between subnets by default on every firewall. Open only the exact ports your public web apps need to serve users. Never allow a public host to open a direct path to every backend machine.
Remove shared admin keys from servers that sit inside the perimeter buffer. If an attacker steals a static key there, they will try it everywhere. Require engineers to log in with their own identity before running any command.
Keep database engines and private state inside the internal zone at all times. Only allow specific app servers to talk to those databases on fixed ports. Log every command and query so auditors can see what ran during a session.
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
What servers belong inside a perimeter buffer subnet?
Put any host that accepts direct requests from the public internet in this zone. Common examples include web servers, mail relays, DNS servers, and file transfer hosts. Never place primary databases or internal domain controllers inside this outer subnet.
Why do teams use two firewalls instead of one?
Two firewalls create two separate barriers that an attacker must cross in order. If the outer firewall fails, the inner firewall still blocks paths to private data. Teams also run different firewall brands to avoid sharing a single software flaw.
Does a perimeter zone protect against stolen engineer credentials?
No, because firewalls only check network addresses and ports when a session starts. If an attacker uses a valid engineer login, the firewall lets the traffic pass. You still need command checks and field masking to protect live backend data.