Is it sufficient to have single database inside the DMZ which the webservers in the DMZ receives their data from.

Or if setup with two databases is a better solution, that would be to have a database in the internal network which the database in the DMZ receives from?


Your question is a little vague, so I would advise that you consider what threat models you're trying to protect yourselves from.

The first thing to do is to define that a DMZ is a region in your network which is considered wholly or partially untrusted, because it is attached to the Internet (or some other untrusted and hostile network). The DMZ defines a security boundary between that infrastructure and your internal, more trusted environment. That security boundary is usually enforced by a firewall or similar network controls. You might be saying "yeah, I know this", but I've seen people completely misunderstanding the point of a DMZ and I want to make sure we're on solid ground.

My understanding is that you're concerned about keeping your database in the DMZ along with the web server, because you've got internal equipment from your trusted network connecting into that database. This is a common configuration, and many people do indeed get by just fine by allowing connections from the trusted network to the database in the DMZ.

However, one thing to consider is the authentication model. If you're authenticating to an MSSQL server in the DMZ via AD, and your domain controller isn't in your DMZ (I hope it's not!) you'll need to allow that AD traffic through the firewall. This isn't a good idea, really. So, utilising database replication to sync data through the DMZ boundary so that the inner database can be authenticated to via AD, while the outer (i.e. DMZ-based) database doesn't need to speak to the DC, is actually a pretty good solution.

  • You are using a more "forgiving" term of DMZ than I am/was. I use zoning for what you mean, and DMZ for the zone that has NO safeguards. I think he e should utilize zoning instead of just a DMZ, E.a. a controlled environment with Authentication, authorization and Accountability. (the 3 A's). as a side note I would recommend utilizing Secure Shell connections and a DB that only listens on local host as security methods to limit exposures to threats. – LvB Mar 5 '15 at 11:37

It is better to NOT use a DMZ at all.

but if you must, assume everything in the DMZ is compromised and should be distrusted and assumed leaked to others. therefor the best solution would be to move your DB and webservice outside of the DMZ, and employ a reverse proxy inside your dmz. (and make sure the webserver can only talk with the proxy, and the DB only with the webserver) when you do this. and all other standard techniques and safeguards you could be safe from attackers. (you still need to do a security check as is pointed out in a comment by @Polynomial)

--Additional info about DMZ.

DMZ's are systems that are outside of your normal protection and safe-guards (e.a. there without all the things you normally have to protect yourself against misuse). in reality there is no valid reason to have a system in a DMZ apart from honeypots.(a honeypot is a system specifically designed to be an attractor for viruses / attackers so that you can analyse them.) for all other legitimate use you should use multi-layered defenses and just have a clearly defined acces path THROUGH your firewalls (e.a. your firewall allows calls to your webserver on port 80 and 443 but only if there for "your-domain" and only to a specific end-point (like the only webserver or the main load-balancer).

In practice it is sometimes needed to have a system in your DMZ to utilize something because of policy (IMHO a bad policy). if your stuck with that situation,
I would use whats called a reverse-proxy to proxy all valid request from inside the DMZ to inside your safe network where your webserver is. this prevents most of the scipted attacks and keeps your base security intact. it does mean you have to protect your webserver through other means to limit the effect of a compromised webserver (simply because its now inside your network)

  • 1
    It would really help if you even attempted to motivate your statements. "It is better to NOT use a DMZ at all" clearly isn't a self-justifying statement – Stephane Mar 5 '15 at 10:47
  • Sorry, but this is a horrible answer. If you're going to propose something radical like "do away with security boundaries" then you sure as hell better have some strong justification. Also, "you should be safe from attackers" without quantification as to a threat model is very dangerous assurance to give. – Polynomial Mar 5 '15 at 10:54
  • I am not suggesting to get away with the boundaries, I'm suggesting you USE the boundaries. a DMZ is NOT a method to ADD boundaries to a system or network, its a way to place something OUTSIDE of those boundaries. As I mentioned you should ADD additional boundaries to your webserver if you poke a hole though your firewall for it. (this should be done anyway as any server can become compromised.) DMZ has a very narrow use case and its NOT what you are using it for. it is only for systems that you want to have NO security on, or has its own security through other means,that conflict with yours) – LvB Mar 5 '15 at 11:23

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.