Server Separation to avoid attacks?

Question

I currently have 1 server with a full LAMP stack on it as well as Mongo DB.

Is there any benefit to spliting up these services onto different servers in regards to redundancies?

For example:

Server 1 -> Apache/PHP
Server 2 -> mySQL
Server 3 -> Mongo

The reason why I am thinking this may be of benefit is that in the case of being hacked or a software failure, it would be easier to reload software. Also in the future it would allow me to have clusters instead of 1 server for each element.

Is this normal? Or is it better to have 3 servers all with a full stack on it?

Answer 1

Service Separation can help if your servers themselves go down, in that if your backups are recent you will be able to restore individual services faster, or so you can have a failover environment (only applies if you duplicate the entire environment a second time so you end up with 6 servers, as each server must have a failover), but it in no significant way helps against active network threats and does not increase your security.

These kinds of questions arise:

1. How are you protecting against hacker threats with this setup? If a hacker gets into your web server and installs malicious scripts to get data from your database or some other action your separation of services won't help.
2. What do you have in place to fight against intrusions and malicious acts, to mitigate them at all? Typically you will have an IDS/IPS at the border of your net, as well as firewalls, to protect against some network threats so they don't actually become a problem.
3. You don't protect against DoS or DDoS with service separation. This will take down your sites whether you have one server or ten.
4. You still have the risk of the services on each system getting hijacked having malicious scripts. An FTP area can get malware which then attacks the other servers, or can run a malicious script to help distribute malware to others, or can hijack your systems to DDoS and attack other systems. A PHP server can get code injection which can then have attacks against other systems. Your database server could get malicious code added to it. These kinds of things are items which server separation won't help with.

Ultimately, while this may provide a benefit for failover and faster restore if your servers explode, assuming you take good backups, there's not that much additional benefits. No real additional security benefits come from service separation. Sure, you get services separated from each other, but that adds no additional protections from the (literally) thousands of vectors of attack.

---

Amendments:

After poking the Information Security SE site, I am amending my statements here:

1. Any web-facing zones are open to risks of attack. In the ideal world, your PHP application(s) will not be able to execute anything that they aren't supposed to. In the real world, this isn't the case, and there are numerous avenues of attack against PHP sites and services.
2. I do not know your network structure. I do not know if these are all VPSes, or are all servers (virtual or otherwise) behind an Enterprise-grade firewall where you can segregate internal communications and restrict your Apache/PHP server so that it is accessible from the internet, but it can only communicate to your databases over specific ports and such. If you have such an environment, and it is all in-house and not VPSes and you can do firewall segregation, I would go the separation-of-services route, and have good backup management for all servers. From there, put the Apache/MySQL into a DMZ which is accessible from both inside and outside over the web ports, and then allow communication in restricted fashion between the database servers and Apache/MySQL.
3. I'm making assumptions as to what exactly you're trying to protect against. If your servers aren't in an Enterprise-class environment, you'll have to set up each server to be restricted in terms of communicating with each other. If they are all on VPSes and not all on the same network, this detracts from Security because your databases will have to have web-facing listeners even if you restrict which IPs can reach it. That makes it more sane to just keep everything on one server, and use localhost-specific listeners for the database servers.
4. There are literally hundreds of thousands of threats that can be an issue. If you are talking about threats in general, there's no real difference in security if you're all on the same subnet behind an Enterprise-grade firewall. If these are VPSes, service separation can actually detract from your security.

Ultimately your failover capability is dependent on having good backups and having a backup server which you can very quickly deploy to take the place of the malfunctioning server. Security is another matter entirely and without specifics on what threats you are trying to counter, there's no real way to provide a fully-complete answer. Service separation is a start, but it doesn't really provide that much additional security, and you should never rely on the security of service separation to protect you.