DMZ Basics

Lately I made the change from deep technical consultant to a more high-level architect like kind of consultant. I now do my work on the turning point between business and technique. One of my first jobs is to make my customer ready for an audit to use the dutch official authentication method, which is called DigID.

There are several requirements, which have to be fulfilled before the customer can make use of the DigID authentication method. One of these requirements is that all the internet facing systems are placed in a DMZ. I tried to explain the importance of a well functioning DMZ. For us as network specialists this fact is obvious, but a lot of people don’t understand the meaning and working of a DMZ. This blog is about the essentials of which a DMZ has to consist.

First we need to understand what we are trying to achieve with a DMZ
• Separation and identification of network areas
• Separation and isolation of internet facing systems
• Separation of routing and security policies

After understanding the achievements, there is another point of interest. Are you gonna build your DMZ with dedicated switches, firewall’s and ESX hosts (physical) or do u use a separate vlan (virtual). There is no clear answer; fact is that bigger organizations build physical DMZ’s more often than smaller ones. Besides the technical aspect, there is off course a financial aspect. Resulting out of the physical/virtual debate comes the debate whether to use two physical firewalls or one physical firewall with several logical interfaces. Equally to the physical/virtual debate there is not just one answer.

For me personally one physical firewall with several logical interfaces with tight configured ACL’s is as good as two physical firewalls. One could dispute this with the argument that if a hacker gains access to one firewall he gains access to the whole network. Personally I don’t think this isn’t a valid argument, because when two physical firewalls are used they are often from the same vendor and use the same firmware with the same bugs and exploits. So if the hacker’s trick works on one firewall, it will often also work on the second one.

Some images to make the above a little more concrete.

A single firewall DMZ:

A multiple firewall DMZ:

As can be read in this article there is just not one definite answer to which DMZ solution to use. This depends on multiple factors. My personal opinion is that you have to build the best solution, which fits the customers needs. In my specific case I use just one firewall with really tight set ACL’s.

Then there is the question of how to configure the security level in Cisco ASA firewalls. In Cisco firewalls the rule is that the higher security level is more trusted than a lower security level. Clients in a zone with a higher security level are granted access to a lower configured security level automatically. That’s not always workable, so I often tend to configure an explicit deny on the end of all ACL’s. Just to make sure I’m in full control of granting access. So traditionally the inside zone is configured with a value of 100 and the outside (internet facing interface) is configured with the value of 0. A DMZ is always between 100 and 5. I often start at 50.

There is another reason why I configure explicit deny’s on the end of every ACL, because what if you have more than one DMZ? You could give them the same security level, but that brings a lot of other problems. So I give my DMZ’s always different security levels and because of the explicit deny’s I’m still in full control of granting access. Another point of interest which I often encounter, and which is not good for security. Everybody knows that the ACL’s from the outside (internet) to the DMZ servers have to be as tight as possible, but often access from the Inside network to the DMZ network is totally open.

I don’t think I have to point out that the biggest threat in a network is the internal user. So keep you’re security between the inside network and the DMZ as tight as possible to!

So if you are going to built a DMZ keep in mind the following points:
• Built the DMZ which fits the customers needs best
• Think about you’re security level settings
• Make your identity NAT as specific as possible
• Make you’re ACL as tight and specific as possible in both ways!
• Keep the configuration manageable not only for you but also for the network administrator
• Make use of the comment line’s in your firewall
• Keep your documentation up to date

Although it seems an abc to use a DMZ for internet facing systems, it’s not that obvious for everyone. I often discuss the use of DMZ’s with my fellow colleagues, which are no network specialists. They often ask me if it’s not secure enough to just NAT/PAT the servers, I tell them that NAT/PAT is not security but just a tool to make communication with the internet (or other networks) possible. So I think it is very important to convince your colleagues of the usefulness of a correct configured DMZ, but also make sure there is a well-written DMZ (and overall network) architecture.

One last tip, it’s better to open a port than realize that a port is open to be hacked