Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

It seems like life would be simple to run the database server on the same machine as the web server, but are we taking a big secuirty risk by doing this?

The environment will be Windows 2008 server, Postgresql (latest version, possibly 9.0 when it comes out) and Apache 2.

share|improve this question
    
It depends. Can you give more details about the specific scenario you're considering? –  K. Brian Kelley Jul 21 '10 at 20:09

5 Answers 5

up vote 6 down vote accepted

Not necessarily.

Assuming your web server gets compromised the attacker will still gain the credential to access the same databases, no matter what server they run on. After all, the database server will still need to be configured to allow legitimate request from the web server.

(Assuming sensible security measures such at mysqld not accepting password-less root login from localhost.)

That being said, you might still want to run a separate database server. The reason for that being related to performance, scalability, etc.

share|improve this answer
3  
I'd agree that a bigger problem would be the performance hit you get running both on the same machine. –  ChrisF Jul 21 '10 at 20:17

It would really depend on the security model of your Web and DB servers (that is, the software), as well as the degree of firewalling/access control/IDP you'd enforce on the two were they on separate servers.

All else being equal, it is probably the case that it's better to separate the two. Practically, however, at least in a LAMP environment, so long as you're using privsep Apache (if you aren't sure, don't worry, you are) and aren't using the root login to MySQL in your webapp, and you don't have tcp/3306 exposed to the outside world, you're not really gaining much security by moving one or the other onto a different piece of silicon. You do gain performance and debug-ability benefits, though.

Your question is in the style that appears to require an absolute answer, but without more information (at minimum, what OS and web/DB server flavors we're talking about), it's hard to even give an informative one.

share|improve this answer
1  
+1 Basic security and best practices are enough for most data. –  Chris S Jul 21 '10 at 18:20
    
We are going to be running: Windows Server 2008 and Postgresql 8.4 (or 9.0 when it comes out), Apache 2 –  CLJ Jul 21 '10 at 18:33

I don't see much additional security risk putting the database and web servers on the same hardware. If the web server is breached the data is accessible anyway. Security is not the typical reason for segregating tiers.

In either case you want to make sure that the database server is listening on non-standard ports, will only respond to requests from the web server, and that the firewall only allows http/s requests to the web server and no other ports or addresses.

Nonetheless, separating them is good practice .. each server is easier to manage and configure, and you can deal with failures, problems, rebuilds, performance issues, etc. more easily moving forward. So, you might consider two virtual servers on the same hardware, which can then be separated when performance or capacity requires it.

share|improve this answer

I wouldn't - but that's me.

It depends on what's in front of your box (i.e. firewalls, load-balancers etc.) and how 'tight' they are, what the actual data is (i.e. now-impact publically available data at one end, national secrets at the other), whether there's any performance impact on combining them, the strength of the network between them both (i.e. inter-tier firewalls) and the quality of OS/app hardening that will be applied.

If you're not expecting this system to have to deal with too much load one thing you could consider would be to virtualise the system into two separate VMs; one per function - possibly with a third software-only firewall VM between them even. This would mean that even if someone cracked your web server they'd have to then crack the database server and, if included, an intermediatary firewall VM. Of course this would reduce the overall system performance but would be at least to some degree more secure and could also help if your load ever grew to requiring a two server design as you could simply move one VM over to the second machine. VMWare's free ESXi product could do this all pretty easily and there are already free firewall VMs prepackaged ready for implementation if you wanted.

share|improve this answer

I disagree with the posters stating that this isn't a security concern, and here's why:

  • Your front-facing service should have the smallest attack surface possible. This is the primary reason for using reverse proxies and firewalls, and for keeping unnecessary services and programs away from servers that don't require them to operate. This is why web servers are the most common targets for security hardening passes.
  • Your web server should not have god rights to your database system. Therefore compromising the web server does not compromise the database server, as well. For starters, the account the web server uses to access the database shouldn't have local administrative rights to the SQL box, its rights should be confined purely to database permissions. Second, within those SQL permissions it should be operating under the principle of least privilege. Your web box shouldn't be able to instantiate new databases within the instance, for example. Ideally, your web box won't have the ability to drop tables, or delete rows from any tables that it doesn't absolutely have to. So in the event of a compromise in a properly configured 2-tier setup, the impact of an attacker using the SQL credentials is limited in scope.
share|improve this answer
1  
I don't think anyone's saying that a two-box solution isn't safer. However, the question was whether that risk was, to quote the question, "big". The answer is obviously going to depend on circumstances--I wouldn't run an Internet-facing banking site on a single machine, for example. But a properly-locked down Web server, once compromised, should have no more or less access to its database server than it did before being compromised, and that principle is independent of whether the solution is on two machines or one. If that's not true, it's time to re-architect the system. –  BMDan Jul 30 '10 at 18:44
    
I'm not following your logic. If you compromise a web server and gain root to that machine, you've got everything that's on that machine. If that includes your entire database with all its data, then everything is compromised. But if you have a 2 separate servers, then fully compromising the web server, to any degree, would only get you data-level access to the data that was accessible to the web server itself. –  Chris Thorpe Aug 1 '10 at 8:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.