2

We are about to release a web application for our users, and are trying to figure out if others put their servers in a DMZ, or just keep it off the domain behind the firewall and greatly restrict access via firewall rules? Has anyone here found any cons to just restricting access via firewall rules and O/S perms?

Note that this site is an ASP.NET MVC front-end with SQL Server back-end.

Also - this is an HR/Finance application, and the database back-end contains our most valuable data. From a security perspective, I'd rather give the world root access to intranet than allow access to the database server. As a result, my original plan was to skip using a DMZ and only opening up port 443 on the firewall to the web server ... this seemed no worse than putting the db server on the DMZ with the web server.

Improve this question
1
  • 2
    Should be on Serverfault, maybe?
    – Nate
    Jun 13, 2011 at 19:32

4 Answers 4

Reset to default
4

Typically, the configuration is like this:

Internet facing servers connected to Firewall's DMZ Port
Trusted servers (SQL, AD, etc) connected to Firewall's Trusted/LAN Port
Internet connected to Firewall's WAN port

Then, the Firewall is configured to route between those subnets, and allow access according to the ACLs you define.

Improve this answer
4
  • 1
    So the database and web server communicate through the firewall? Doesn't that slow things down?
    – Beep beep
    Jun 13, 2011 at 19:46
  • Yes. It does. You need an enterprise grade firewall if you expect to push lots of traffic through.
    – Nate
    Jun 13, 2011 at 21:02
  • That said, you can get a LOT of throughput on a medium size firewall for a few thousand dollars.
    – Nate
    Jun 13, 2011 at 21:04
  • We ended up putting our web server for internal users on the same server as the database, but putting our web server for external users in the DMZ. Makes speed ridiculously fast for internal data entry users, while allowing scalability for the thousands of external users. Thanks for the ideas!
    – Beep beep
    Jun 28, 2011 at 5:29
1

I do usually not use a DMZ, but only a firewall. The account that the IIS application pool is running on is already restricted.

Improve this answer
1

What you're asking is what's the best practice?

It doesn't matter where things are placed it comes down to one thing. i.e. How you've secured it.

One firewall rule could open everything up, or close everything down. Maybe you need to look at it from a different perspective.

Do you trust your employees enough to have direct access to those servers without a firewall restricting access between them. Same goes for internet. If that's the case put them both in a DMZ.

Personally I like them on the same subnet without a firewall between them because it ensures maximum performance. But, if the web server was compromised it leave the DB server more open than if it was on the safe LAN side. Are their other services need to be available on the DB server from the LAN side like RDP? depending on where it sits you might have to open ports up from lan to DMZ to allow access etc.

Improve this answer
0

Golden Rule: If it can be reached from the Internet and there is no practical reason not to do so - put it in the DMZ. The idea being that if the machine is compromised it should not be possible to reach the internal network. In effect, it's kind of like a double firewall.

Improve this answer
8
  • OK, but what about the database? If the database is in the DMZ, we really have very little security benefit vs. just opening a port ... but if it's on the internal network we have a performance hit from all db traffic traveling through the firewall and back.
    – Beep beep
    Jun 14, 2011 at 18:15
  • 1
    Don't worry about performance hit by firewall. Most firewalls are extremely fast. Security is more important at this point.
    – hookenz
    Jun 14, 2011 at 23:09
  • @Jess, Matt's comment is correct and if you ever get to the point of having a detectable performance hit from the firewall it would be cheaper to replace it with a higher performance one that it would be to clean up after an attack. You are also wrong about the security aspect. Having a DMZ is virtually the same as having a separate and isolated network for the server(s) that faces the Internet. It simply comes down to limiting the damage an attacker could do by not allowing them into the LAN.
    – John Gardeniers
    Jun 14, 2011 at 23:44
  • @John - I understand, but the only data we care about is what is sitting on the database server. By putting the web server on the DMZ, we have to create rules that allow database server access across the firewall (in this case, just from the web server) ... particularly since the database server would need to be opened up for write-access from internal clients as well. Even if the db server is on its own dmz, it's the same. In my view, this seems less secure than putting both the web and db servers on the internal network and just opening up port 443 to the web server. What am I missing?
    – Beep beep
    Jun 15, 2011 at 1:17
  • @Jess, without a DMZ, if someone gains control over your server (don't kid yourself that it can't happen) they are inside your network. With the same server in a DMZ they are outside your network and have a whole new system they have to try and penetrate before they can get to the inside.
    – John Gardeniers
    Jun 15, 2011 at 1:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .