DMZ Demilitarized Zone in Computer Networking
A dmz demilitarized zone in computer networking is a buffer subnet between public and private networks. You build it by placing public servers between an outer firewall and an inner firewall. Teams often set up this buffer to host web apps, mail servers, and DNS services. When firewall rules or user roles are too broad, attackers can move into private systems. How a dmz demilitarized zone in computer networking works The main goal of a DMZ is to keep your internal network safe from untrusted
Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A dmz demilitarized zone in computer networking is a buffer subnet between public and private networks. You build it by placing public servers between an outer firewall and an inner firewall. Teams often set up this buffer to host web apps, mail servers, and DNS services. When firewall rules or user roles are too broad, attackers can move into private systems.
How a dmz demilitarized zone in computer networking works
The main goal of a DMZ is to keep your internal network safe from untrusted traffic. External users can reach public servers in the DMZ, but they cannot reach private databases. Teams use two main designs to set up this boundary. The first design uses a single firewall with at least three network ports. One port links to the internet, one holds the DMZ, and one holds the private network. The second design uses two separate firewalls for stronger isolation. The outer firewall filters traffic from the internet into the DMZ subnet. The inner firewall checks all traffic moving from the DMZ to the private network. If an attacker breaks into a web server, the inner firewall blocks further movement. You must write strict rules so only required ports open between these zones.
How to set up your network zones and rules
Start by listing every service that needs to accept requests from the public internet. Move those web, mail, and file servers into the isolated DMZ subnet. Keep all core databases, internal tools, and user records inside the private zone. Next, set up your outer firewall to allow public traffic only on needed ports. Block all other incoming requests at the outer edge by default. Then, set up the inner firewall to deny any traffic starting from the DMZ. If a web app needs data, allow only specific database port traffic between those two hosts. Never place admin keys or raw customer records on a host inside the DMZ. Review your firewall logs every week to spot blocked requests or strange traffic patterns.
What network zones solve and what they leave open
A DMZ does a great job of blocking direct network paths from the outside world. It stops strangers on the internet from scanning your internal database hosts. Still, network firewalls only check packet headers, IP addresses, and port numbers. They decide which host or user can log in over a network path. Once a valid session starts, the firewall does not inspect individual queries or commands. An engineer or compromised app with a valid role can still run a broad query. They might pull thousands of emails, phone numbers, or card numbers over an allowed port. Static firewall rules also grow complex over time as teams add new apps. Old rules often keeps the session active long after a project ends, creating hidden risks. Network zones alone cannot control what commands run or rewrite sensitive fields in results.
Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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 services belong inside a DMZ subnet?
Any server that talks directly to external users belongs inside the DMZ subnet. Common examples include public web servers, email servers, FTP hosts, and DNS servers.
Should I place my main database inside the DMZ?
No, you should always keep your main database inside the private internal network. Public web servers in the DMZ should talk to the database through strict inner firewall rules.
Is a single firewall enough to build a DMZ?
A single firewall with three network ports can build a basic DMZ for small teams. Still, using two separate firewalls removes a single point of failure and boosts security.