The Security Kitchen

A few days ago someone asked me advice because he was planning to put a web server up in the DMZ, and he wasn’t entirely sure how to go about that. Our conversation ended with him saying that I was probably gonna blog about this in the style of  “Someone was asking stupid questions regarding DMZs …”, so here’s that blog … in a different style.

First up, there are no stupid questions.  Where would I earn the right to feel high and mighty because I know more about networks than you? There’s another million things I don’t know shit about. To go even farther, I probably learned more from this conversation than you

Here’s my view of the (old school) DMZ.

What is a DMZ ?

The name DMZ comes from the military term, Demilitarized Zone, we only wanted to have it’s proper TLA (Three Letter Acronym) so it would sound cooler.  In the military, the DMZ is a pretty dangerous place to be.  Best case you have guns pointing at you from both sides, worst case they’re shooting you to smithereens.

On a network, we create a DMZ to locate components that will interact with users or machines that are in an untrusted zone. Why ? Because the risk that these components are compromised is much bigger and if they would be in our trusted (internal) network, the havoc when it happened would be immense. The DMZ gives us control over the traffic that is allowed to and from the boxes, from both sides.

Option 1 : the multihomed firewall

In my humble opinion, a good SMB or branch office solution.  Assuming you don’t have to much internet-facing services. We set up one interface of the firewall for internet access, one interface connects to our DMZ and the third one connects to our LAN.  The rule of thumb here is to tightly control access from the internet to our (blue) box in the DMZ, make sure no access from the DMZ box to the internal network is allowed and strictly control access from the LAN to the box in the DMZ.

Option 2 : back to back firewalls

You have extensive needs for internet facing services and you have a budget too?  Good ! Back to back firewalls give you a lot more flexibility.  In the drawing I’ve created an internal and an external DMZ.  Your webserver (the blue box) is in the external DMZ and you control access from the internet tightly.  Access to this server from the LAN is extremly limited (ssh only, maybe even from a management LAN?).  You might have noticed the orange server in the internal DMZ.  Imagine that your webserver needs to present data from an internal database?  Your worst decision might be to have the webserver connect directly to your internal database.  So we set up a database server in a seperate subnet and replicate a (read-only) subset of our database, containing only the data we actually need, to this server.  Again, the proof of the pudding is in the tasting.  You are going to limit access between any of the subnets to only that what is strictly needed to get the job done ! And even then you are reviewing this on a periodic basis.

Option 3 : Don’t try this at home

I hope you noticed what is wrong here.  You have put your server in the DMZ but also added a secondary interface that is connected directly to your LAN.  This is a recipe for disaster.  Sure, it’s easy to work with but by doing this you are connecting an untrusted zone with a trusted zone and bypassing your firewall in one go.  Any pwnage of the server will result in pwnage of your entire internal network.  It even hurt my eyes to draw this option.  Let’s move on !

Option 4 : A special case

This is a scenario that is well-suited for a web application firewall (but not the best solution !).  Assume that incoming traffic is encrypted (HTTPS over TCP/443) and traffic to the server behind the WAF is not encrypted.  SSL termination is on the WAF.  If we would implement scenario one, we would have unencrypted traffic travelling over an untrusted network, the same DMZ link.  If someone would breach our DMZ, it would be trivial to snoop in on that traffic.  To avoid this, we create a secondary DMZ. Thus we have an external DMZ where our encrypted traffic flows and another DMZ where the unencrypted traffic flows.

Again, the key is to control access to any machine on any network controlled by you.  And check on it !

Note :

This is a very rudimentary overview of DMZ setups. I’m sure you can find more elaborate versions somewhere on the internet, but I didn’t want to disappoint you The rest of the discussion, we will continue over a few good beers.