Should a webserver in the DMZ be allowed to access MSSQL in the LAN?

This should be a very basic question and I tried to research it and couldn't find a solid answer.

Say you have a web server in the DMZ and a MSSQL server in the LAN. IMO, and what I've always assumed to be correct, is that the web server in the DMZ should be able to access the MSSQL server in the LAN (maybe you'd have to open a port in the firewall, that'd be ok IMO).

Our networking guys are now telling us that we can't have any access to the MSSQL server in the LAN from the DMZ. They say that anything in the DMZ should only be accessible FROM the LAN (and web), and that the DMZ should not have access TO the LAN, just as the web does not have access to the LAN.

So my question is, who is right? Should the DMZ have access to/from the LAN? Or, should access to the LAN from the DMZ be strictly forbidden. All this assumes a typical DMZ configuration.

Solution 1:

Proper network security states that DMZ servers shouldn't have any access into the 'Trusted' network. The Trusted network can get to the DMZ, but not the other way around. For DB backed web-servers like yours this can be a problem, which is why database servers end up in DMZs. Just because it is in a DMZ doesn't mean it HAS to have public access, your external firewall can still prevent all access to it. However, the DB server itself doesn't have access to inside the network.

For MSSQL servers, you probably need a 2nd DMZ due to the need to talk to AD DC's as part of its normal functioning (unless you're using SQL accounts rather than domain-integrated, at which point this is moot). That second DMZ would be home to Windows servers that need public access of some kind, even if it is proxied through a web-server first. Network Security people get squinty when they consider domained machines experiencing public access getting access to DCs, which can be a hard sell. However, Microsoft doesn't leave much choice in this matter.

Solution 2:

I'm with your networking guys, in theory. Any other arrangement means that when somebody compromises the web server they have a door into your LAN.

Of course, reality has to play a part - if you need live data accessible from both the DMZ and the LAN then you really have few options. I'd probably suggest that a good compromise would be a "dirty" internal subnet that servers like the MSSQL server could live. That subnet would be accessible from both the DMZ and the LAN but firewalled off from being able to initiate connections to either the LAN and DMZ.

Solution 3:

If all you are letting through the firewall are SQL connections from the DMZ server to the MS-SQL server, then it shouldn't be an issue.