the classic 3 leg DMZ firewall design
the hook
you put a web server on the internet and within a week someone's poking at it. that's just tuesday on the internet. the question that actually matters isn't "will my public server get attacked," it's "when it gets popped, what does the attacker actually get." the 3 leg dmz firewall design is the classic answer to that question, and it's been keeping networks sane since before "zero trust" was a marketing term.
what a 3 leg dmz actually is
picture one firewall with three network interfaces instead of two. that's the "3 legs":
leg 1: faces the internet. untrusted, hostile, assume everything coming in is trying something.
leg 2: the dmz. this is where your public facing stuff lives, web servers, mail servers, anything that has to be reachable from the outside world.
leg 3: the inside. your users, your workstations, your database, your file shares, the stuff that actually matters.
the firewall sits in the middle and enforces who can talk to who. it's not just routing packets, it's making decisions.
the traffic rules that make it work
the whole design hinges on directional rules, not just "is this port open." here's the logic:
internet to dmz: allowed, but only on specific ports like 80 and 443. nothing else. no ssh, no rdp, no random high ports because "it might be useful someday."
dmz to internet: usually needed too, for updates, licensing checks, whatever the app requires. but it should be scoped tight, not "allow any."
internet to inside: never. flat out blocked. the internet has zero business talking directly to your workstations or your database.
dmz to inside: this is the rule people mess up most. it should be locked down to only the specific connections the app actually needs, like a web server hitting a database on one specific port. not "dmz can talk to inside freely because it's easier."
inside to dmz and internet: your users need to browse the web and reach internal apps, so this is generally more permissive, but still logged and filtered.
why this actually contains a breach
say your public web server gets popped through some unpatched cms plugin. without a dmz, that box might sit on the same flat network as your database and your domain controller. game over, the attacker just walks sideways.
with a proper 3 leg dmz, the attacker lands in the dmz zone and hits a wall. they can't reach your inside network because the firewall rules simply don't allow dmz to inside traffic except for that one narrow, specific path the app needs. they're stuck in a fenced yard, not the whole property.
this is the entire point of network segmentation: assume compromise, limit blast radius. the dmz isn't there to prevent the initial breach, it's there to make sure one popped box doesn't become the whole network.
where people quietly break this design
the concept is simple but it gets undermined in real deployments constantly. a few common ways people accidentally flatten their own dmz:
using "any any" rules from dmz to inside because a developer needed something to work quickly and nobody went back to tighten it.
putting a domain-joined server in the dmz. the second that box is joined to your internal active directory, it's not really isolated anymore, it has credentials and trust relationships reaching into the inside network.
letting management traffic, like rdp or ssh to the dmz box, originate from anywhere instead of a locked down jump host or vpn.
forgetting logging on the dmz to inside leg, so even if the segmentation holds, you have no visibility if something tries to cross it.
the takeaway
the 3 leg dmz isn't some outdated ccnp exam topic, it's a mindset: never let your public facing stuff share a trust zone with the things that actually matter. if you're running your own network, go audit your firewall rules right now. check what's allowed from dmz to inside, and if you find anything wider than "the one port the app specifically needs," tighten it today. segmentation doesn't stop the first compromise, it stops the second one, the one where they get everything.