DMZ

A DMZ (demilitarised zone) is a separate slice of your network for the servers the internet has to reach, such as a website or a public API. It sits between the outside world and your private systems, so that if a public server is broken into, the attacker lands in a small, fenced-off area instead of next to your databases.

Why public servers need their own zone

Every network has two kinds of thing in it. Some systems are private: databases, file shares, internal dashboards, build servers, the payroll app. Nobody outside the organisation should ever talk to them directly. Other systems are public on purpose: a web server, a mail server, a DNS server, an API. Their whole job is to answer requests from strangers.

Public servers are the ones most likely to be attacked. They accept input from anyone, they run a lot of code, and a single bug in that code (an unpatched library, an injection flaw, a weak admin password) can hand an attacker control of the machine. If that machine sits on the same flat network as everything else, the attacker can now reach every private system as if they were an employee.

A DMZ fixes the placement problem. Public servers go in their own zone, and firewalls decide exactly which traffic may cross between the internet, the DMZ and the internal network. Other names for the same idea are 'perimeter network' and 'screened subnet'.

How a DMZ is laid out

There are three zones, each with a different level of trust:

• The internet: untrusted. Anyone can be on the other end.
• The DMZ: semi-trusted. It holds the public-facing servers and nothing else.
• The internal network: trusted. It holds the private systems and the people who use them.

The firewalls between them control the doors. There are two common ways to build it.

Two firewalls

The classic layout puts one firewall between the internet and the DMZ, and a second between the DMZ and the internal network. Traffic from outside has to pass the outer firewall to reach the DMZ, and anything leaving the DMZ for the inside has to pass the inner one as well. Some organisations use firewalls from two different vendors here, so that a flaw in one product doesn't open both doors at once.

One firewall with three interfaces

A cheaper layout uses a single firewall with three network interfaces: one to the internet, one to the DMZ and one to the internal network. It enforces the same rules between each pair of zones. It is simpler to run, but that one device is now a single point of failure, and a mistake in its configuration affects every zone.

The rules that make it work

A DMZ is only as good as the firewall rules around it. Placing servers in a separate subnet does nothing if every port is open between zones. The usual policy is 'deny everything, then allow only what is needed':

The DMZ-to-internal row is the one that matters most. A web server usually needs data from somewhere, so it is allowed to talk to one database on one port, and nothing else. That matches the video: the DMZ can talk to the inside, but only for specific information.

What happens when a DMZ server is breached

The payoff of all this shows up on the day something goes wrong. Here is a normal request, then an attack on the web server:

The breach still matters: the web server has to be rebuilt, and the attacker may have seen whatever that server could see. But the damage has a boundary. That boundary is the whole point of the design.

A worked example: a small online shop

Picture a shop with a website, a mail server, a PostgreSQL database of orders and an office network of staff laptops. Placing them:

• DMZ: the web server and the mail server, because customers and other mail servers must reach them.
• Internal: the database, the file server and the laptops.

The firewall rules might look like this, written in a simple made-up syntax rather than any one product's:

# Outer firewall: internet -> DMZ
allow any      -> web   tcp/443   # HTTPS
allow any      -> mail  tcp/25    # incoming mail
deny  any      -> any             # the rest
 
# Inner firewall: DMZ -> internal
allow web      -> db    tcp/5432  # orders
deny  dmz      -> any             # the rest
 
# Inner firewall: internal -> DMZ
allow admin-pc -> web   tcp/22    # SSH, admins

Three details are worth noticing. The database port is open to one source, the web server, not to the whole DMZ, so a breached mail server can't reach the orders at all. Every list ends in a 'deny the rest' rule, so a forgotten service stays closed rather than open. And administration only goes one way: admins connect from the internal network to the DMZ, never the other way round.

The web server's database account should also have only the permissions the site needs. The firewall allows the SQL connection, so an attacker on the web server can use it. Least privilege on that account limits what they can do with it.

DMZs in the cloud

Cloud networks use the same idea under different names. On AWS, a common layout has public subnets with a route to an internet gateway, holding load balancers or web servers, and private subnets with no route in from the internet, holding databases. Security groups then act as the firewall rules: the database's security group allows its port only from the web servers' security group. Azure calls the same pattern a perimeter network, built from virtual networks, network security groups and Azure Firewall.

The vocabulary changes, but the questions are the same: what is public, what is private, and exactly which connections may cross between them.

Common mistakes

• Allowing the DMZ to reach 'the internal network'. A broad rule such as 'DMZ to internal, any port' undoes the design. Allow single hosts and single ports.
• Putting sensitive data in the DMZ. Keeping a copy of the customer database on the web server to 'make it faster' puts it exactly where an attacker lands first.
• Confusing it with a home router's 'DMZ host'. Many home routers have a setting with that name. It forwards all unsolicited traffic from the internet to one device on your home network, with no second firewall behind it. That is the opposite of a real DMZ: it exposes the device fully, and it still sits next to everything else you own.
• Forgetting outbound rules. If DMZ servers can connect anywhere on the internet, a compromised one can download tools and send stolen data out freely.
• Treating the DMZ as 'done'. Servers in it still need patching, logging and monitoring. The DMZ limits how far a breach spreads; it doesn't stop one happening.

Where it fits

A DMZ is one layer of defence in depth, not the only one. It sits alongside patching, strong authentication, a web application firewall in front of the site, and least-privilege accounts. Many teams now go further with network segmentation inside the internal network too, and with zero-trust approaches where no connection is trusted just because of where it comes from. Those ideas extend the DMZ's thinking rather than replacing it: keep risky things apart, and make every crossing a deliberate, narrow exception.

Key takeaways

• A DMZ is a separate zone for public-facing servers, between the internet and the internal network.
• Firewalls control every crossing: the internet can reach the DMZ, and the DMZ can reach the inside only on specific ports to specific hosts.
• If a public server is breached, the attacker is stuck in the DMZ instead of reaching private systems.
• Tight rules matter more than the layout: deny by default, and allow the fewest connections needed.
• A home router's 'DMZ host' setting is not a real DMZ.