If you have a DMZ with one or more servers/services (maybe FTP, HTTP en SMTP). And you have a LAN with typical serversservices (like file sharing, Active Directory, database server).

Depending on the integration of services and resources, the firewall between the DMZ and LAN could have a lot of open ports. At what point would you consider not using a DMZ?



There is no realistic measurement in which I would consider not using a DMZ. With security, every extra bit you can get helps. The idea is, to limit the amount of attacks possible attacks. As admins, we often have to fight for the security we are allowed to implement, so take whatever you can get. Even if you have to completely open a host in your lan to the DMZ, one host is a lot better than every host.

A realistic example from what you said is putting a front-end exchange server in the DMZ, and a the back-end and active directory in the LAN. Even though these can still be reached from the DMZ, at least you have limited the possible ways to get through. You can then put your efforts into watching for any security notices related to these particular services.

  • Honestly I feel that DMZ sounds good in theory, but is not that straight forward in practice. Almost any typical service in the DMZ would need access to the server in the LAN, just for authentication. Anyway, thanks! – Michiel van Oosterhout Sep 10 '09 at 18:00
  • Depends on what the company does. If you run websites, they probably would not need to contact that LAN for any reason. Same goes with FTP sites. – Kyle Brandt Sep 10 '09 at 23:19
  • 2
    Every time I hear the words "With security, every extra bit you can get helps." I cringe. Adding layers to security for the sake of security usually causes more complexity for the admins and users. With more complexity comes the chance of misconfiguration by admins and bypass measures by the users. Security is always a balance between 'secure enough' and inconvenience. – Dscoduc Sep 11 '09 at 17:11
  • Dscoduc: Good point, I guess it depends on where you are. If you have to fight to just get the most basic measures implemented, then every bit helps from that view. If you you work in a more enterprisey place were all sort of layers of security get in the way, then you are right, then complexity becomes the trade off. – Kyle Brandt Mar 8 '10 at 13:12

The goal of a DMZ is usually to separate the untrusted network from the trusted network. Depending on the level of firewalls you can control many aspects of the connection besides just opening up ports.

My experience has been that companies put in place a policy that prevents any untrusted connections from communicating directly with trusted resources, with exceptions being carefully reviewed. For example, reverse proxy servers in the DMZ can provide pre-authentication for untrusted connections before they are served up data from trusted resources.

Another point worth considering is that even with opening up ports, it is possible to control which devices can communicate over those ports. For example, it might be necessary to open up a port to allow SQL communication between a web server in the DMZ and a SQL server in the trusted newtwork, but you could restrict the traffic flowing through that port to only the Web server and the SQL server.

Utimately it's up to you to craft a boundary policy that will provide the minimal level of access to satisfy your application requirements.


I dislike the term "DMZ" because it implies that there is a single zone into which you toss things you don't really specifically trust. Lots of places in fact will just have some random switch or hub connected to another interface on their firewall, and call that their "DMZ".

I much prefer to segregate individual services into individual zones (typically a mixture of interfaces on the firewall and vlans on a switch connected to the firewall). From there I'll do a mixture of symmetric natting or direct routing with ACLs / firewall rules on a per service / per server basis. If you're an FTP server, you get ftp related access; DNS server? You get port 53, etc. But I never put the ftp server and the DNS server on the same broadcast domain.

For me the point of a "DMZ" is mostly to act as a single point to monitor and regulate traffic, it isn't just to block traffic. You setup policies based on the service and you have a single chokepoint to setup your logging, monitoring, and filtering.

Of course, if you do wind up having to nat directly into your corporate network for whatever reason, at least you can still monitor the logs for that specific rule that brings the traffic in, and monitor that specific host a bit more closely than the others. Ideally though, you can just move that server into the DMZ as well and just allow more access from inside the corporate zone into that service zone than would be allowed from outside; this gives you 100% visibility on the traffic generated by that host so that if it is compromised by the internet facing service, you quickly see that it is from the traffic logs.


Shouldn't you move some of the services to the DMZ? Try to keep the LAN unreachable from anywhere. Then, manage the security in the DMZ area.

  • 1
    or, add a second DMZ, with internal services. – Cian Sep 9 '09 at 11:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.