2 Answers
2

privilege escalation on the same machine is easy. On separate locked-down machines it's harder. If you've got a presentation-tier at the front (i.e. apache) which get compromised but has a sql account with only limited privileges and the sql server has no services exposed to it (i.e. no reachable ssh) it makes it potentially a lot harder to do as much damage.

As one example, if an attacker gets root on the webserver machine they could reset the sql server root password etc, access tables on disk the webserver account may not be able to see etc; they can't do that as easily without local access to the database machine.

WAF's the way I see it aren't all that great - at best they can be reasonable for blocking spacific patterns when you make a rule to stop a problem, but you can't expect them to secure things for you; they're only as good as their rules, and it's typically easier/faster to do proper input sanitation in your code than have the extra overhead of making heaps of specific (and slow) rules in your WAF... which would also take huge amounts of work to do. The exception to this is when you have unmaintained code WAF might be the only way to get things done, but again, don't underestimate how difficult it is making fules and verifying they work correctly without affecting business.

Without rules WAFs protect nothing. In practice nobody has very good rules. Cost to fix the code is often lower than cost to make rules to match the code completely, but cost to implement a tactical-fix WAF rule when you have one specific issue can easier than fixing the code. (Cost here can mean any of money/time/complexity).

If your webserver and database are on the same server, and someone gets root, they also get your entire database. If they're on separate servers, they can (ideally) only access whatever the web apps could. (Also, splitting thing up can be useful when scaling up capacity.)