views:

70

answers:

4

An auditor reviewing our system was suggesting that our data should be stored on a separate physical server from the web server. We're running SQL 2008 on a Windows 2003 machine with IIS as the web server running ASP.NET 3.5 applications.

I can't think of any significant reason that there would more security by having SQL on a separate box. The website still accesses SQL so there's no reduction of SQL injection possibility (we protect against that of course), and we would use RPD to admin the SQL machine just like the web server.

Can anyone with more security knowledge give some insight as to why it would be better, or if in fact it's not any more secure?

+1  A: 

The main benefit of having the DB server on a different box is to minimize Operating System level threads. Say if you web server some how compromised you would be minimizing the impact on your database.

Maxwell Troy Milton King
+3  A: 

A box that is only running SQL Server can:

  • Have anything extraneous to the dbms removed. Since IIS is an obvious entry point into the overall system, by not having IIS on the same box, some possible problems are avoided. -- I'm not referring to a sql-injection attack since obviously, they flow from the web server through to the dbms. I'm referring to unpatched IIS problems, poorly configured IIS accounts, etc.
  • Can also remove any OS-level logins, etc -- OS level attacks
  • Can move the SQL server to a different network (eg behind a firewall)
  • Can apply more resources to monitoring the high value target. Eg tripwire type systems
  • Can apply better hw/sw (raid, more frequent backups) if the cost of the hw on the IIS machine/farm would be too great.

ps. Even running as a separate virtual instance (but same hw) would be better than having everything on one OS instance.

Larry K
Is there a best practices guide for setting this type of configuration up?
Jeff S
Right. With webserver and SQL server on same box, if attacker is able compromise webserver host via webapp/IIS (although configuration can prevent some of this), they can copy/overwrite the database files without even hacking the SQL server. Also some SQL server vulnerabilities may require exploitation from local host and so using a separate box and restricting access to the SQL box will help.
mar
A: 

This should be on serverfault. However, since you're here.

A web server can be compromised in a number of different ways. Maybe someone left an FTP service running, maybe one of those apps allows you to upload files, etc. If at any time the web server is compromised then they can gain file system level access.

When they can get to the file system then they can copy your database files wholesale off of the machine. Further, with file system access they can get to your encryption keys.. Which would bypass any type of data at rest encryption you have. In other words, if the web server is cracked all of your valuable data can easily walk out the door without anyone the wiser.

By putting the database on a different server and limiting access to only the specified port AND limiting user access of the account allowed to log on to the server to only view data and only make modifications to data through controlled stored procedures then you limit exposure drastically. In other words, even if they cracked the web server they couldn't execute "drop ;" or, just as bad, "truncate ;"

Take this a step further and ONLY allow very specific ports on that box to be open. And even then, only allow them to be open to the machines that actually need to access them. For example, NEVER allow the outside world to RDP to your database server.

Defense in depth is your priority. You can't always prevent them from cracking the web box; but you can limit what they can do with that connection once there. Or at least raise the difficulty level to the point that they'll stop at just defacing the site.

Another thing: sql server is much happier on its own machine and will run faster.

Chris Lively
Sorry, I'm a coder not a networking guy so I wasn't familiar with serverfault. I'll use that next time.
Jeff S
A: 

Keep in mind that audits are all about CYA (cover your ass.) When you have a breach, you can say you were audited. The auditor can say he followed the audit procedure. Your boss can say he has an auditor's signature.

I can't think of any significant reason that there would more security by having SQL on a separate box.

Probably, neither can the auditor. It's just his job to come up with an improvement. If you are on friendly terms with the auditor, they can be very open to negotiation.

A separate database server is a very reasonable suggestion to make. An auditor can also recommend a firewall that only allows a message queuing system with predefined message formats to talk the database. Ouch!

Andomar