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?
Thanks!
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.
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.
