What is a DMZ, and how would you design one for a public web application?
Show the answer
Say this first
A DMZ is a separate network segment for servers that must be reachable from the internet, so that compromising one of them does not put the attacker on the internal network. Internet users can reach only the published services in the DMZ, for example TCP 443 to a reverse proxy. DMZ hosts can reach the inside only on specific ports to specific servers, such as the application tier to the database port, and the inside never trusts the DMZ by default. It is built with one firewall and three legs, or with two firewalls back to back.
Go deeper
Rule pattern
| From | To | Allowed |
|---|---|---|
| Internet | DMZ | only published services: TCP 443 to the reverse proxy |
| DMZ | Inside | only named flows: app servers to the database port, nothing else |
| Inside | DMZ | administration from a jump host on the management network |
| DMZ | Internet | deny by default; updates through a proxy or named repositories |
| Anything | Firewall itself | management only from the management network |
Single firewall or two
- Three-legged: one firewall with inside, outside and DMZ interfaces. Cheaper and simpler, but one device and one policy hold everything.
- Back to back: an outer firewall between internet and DMZ, an inner firewall between DMZ and inside. Two layers to break through, sometimes from two vendors so one vulnerability does not open both. More cost and more rules to keep consistent.
Details that separate good from average
- Separate DMZ segments per service type (web, mail, partner), so one breach does not reach the others.
- Private VLANs or host firewalls inside a DMZ, because web servers rarely need to talk to each other.
- Keep application and data tiers on the inside or in their own zones; only the reverse proxy or load balancer sits in the DMZ.
- A WAF or CDN in front of public web apps.
- Logs from DMZ hosts and from the firewall go to a SIEM, since the DMZ is where attacks start. In the cloud the same idea is a public subnet holding only the load balancer, with the application in private subnets.
They will ask next
Why private VLANs in a DMZ?
If one web server is compromised, isolated ports stop it from attacking the others in the same subnet directly. Everything has to go through the firewall, where it is filtered and logged.
The app team says the DMZ web server needs to reach ten internal systems. What do you do?
Challenge the design first: move the logic to an application tier on the inside and let only the proxy call it. If flows are truly needed, allow each one by port and destination, and log them.
Traps
- Allowing broad DMZ to inside access "because the application needs it". That defeats the DMZ.