What is the best practice for placing database servers in secure network topologies

Question

I have a classic DMZ architecture:

My webserver is placed in the DMZ. The webserver needs to communicate with a database server. This database server is the most critical component of my network as it contains confidential data.

Where should I place the DB server and why? Should I add a second firewall and create another DMZ?

Answer 1

• The best placement is to put the database servers in a trusted zone of their own.
• They should allow inbound connections from the web servers only, and that should be enforced at a firewall and on the machines. Reality usually dictates a few more machines (db admin, etc). Obey reality as needed, of course.
• They should only be making outbound connections if you're updating software on them.

Answer 2

Agree with Jeff Ferland, database servers should be on their own: you should have a clean network for replication & backup.

Pardon my ASCII art, a quick overview of a reasonable ideal:

      [internet]
          |
    outer-firewall--- [proxy-zone]
          |      
          +---- [app-zone]
          |
    inner-firewall 
       |        |
[lan]--+        +-- [database-zone]

1. Run a reverse-proxy, Apache+mod_security/varnish/nginx/WAF/whatever, in the proxy zone. Add load-balancing/failover here if needed too. Also add proxy/relay servers for outbound connections (DNS, SMTP, HTTP proxy), if required.
2. When application logic runs on a web server (Java/PHP/ASP), I prefer to call it an application server.
3. When you need to scale you can scale horizontally, load balancers make this easier. You may also consider replicating static and/or unauthenticated content to the front-end proxies (advance thinking about URL paths, hostnames and cookies pays off here)
4. you might want to add one or more zones of type: IDS, management, backup, remote access, outbound proxy

You're trying to mitigate, so:

• inter-zone communication must be limited to the minimum required for services, administration and monitoring purposes.
• a reverse-proxy accepts untrusted connections from the internet, and can only initiate connections to services on application servers, no outbound internet connections. If you want to classify (color) your zones by nature/traffic you need to consider carefully termination of HTTPs, and if you want to create new HTTPs connections to the app servers (update: you probably do, but you can configure a small set of fast ciphers, and omit CA bundles to keep overheads low).
• application zone accepts semi-trusted connections from proxies, and can initiate connections only to databases. You can trust your application servers a little bit more when you know they're not talking directly to the internet.
• database servers accept connections only from application servers, the database zone should be your "cleanest" network
• consider using different firewalls (vendor/product) for the outer- and inner-firewalls
• for required outbound services (DNS, SMTP or patching/updates) these should go via a distinct server (e.g. on the proxy-zone, or seperate outbound-proxy-zone).
• same goes any outbound CC validation HTTPS connections. (If you're unlucky enough to have some vendor or services black box for validation, these ought go on a dedicated zone too, IMHO.)
• use public IP addressing only in the proxy zone, private addressing elsewhere. No server outside the proxy zone(s) need have a public IP, NAT, or even a default route to the internet.

Separate zones makes your IDS's job easier, and logging more effective. Zones should be layer 2 (switching) and layer 3 (IP) isolated. If you have the resources, add a management-zone, separate management NICs for each server (protected ports if you can). Service monitoring is best done over the operational network.

In reality you may end up compacting the "ideal" network to a single firewall and VLANs. Any dev/preprod environments should copy the operational network as closely as possible (especially if you don't want to chase your tail debugging issues introduced, like dropped idle connections). If you consider your options now with the above in mind it should be easier to migrate in future, i.e. shortly after the next visit from your friendly neighborhood PCI-DSS auditor ;-)

Answer 3

The following is quite a common setup for DMZ architecutre:

Internet

^

Firewall1

^

DMZ (Host your dmz servers here only allowing specific ports through the firewall)

^

Firewall2

^

Database Network (only allow specific ports and protocol from firewall2 to this network)

As you mention the database contains credit card (sensitive) data then even on the innerside of firewall2 the database network should be segregated from the corporate and user networks. So many times I see the crown jewels of a company wide open on the internal network for all users to probe and access. Going a step further you could have a database admin VLAN only only allow systems within this VLAN permission to access the databases (apart from the application that needs to access it from the DMZ of course).

Hope this helps.

Answer 4

3-Tier Architecture is the most secure and scalable solution. As client traffic is increased we can add up as many middle tiers needed to ensure performance. Three Tier architecture is also more secure because the middle layer is protecting the database tier. We need to protect database tier from direct access and need to be placed it in trusted zone and it should be only accept connections from application servers.

Answer 5

As you will need to comply with PCI-DSS you will also need to ensure that you have firewalls at each internet connection and between DMZ and internal networks. Theres some good pointers in the self asssessment questionnaires.

Also dont make the database server if a wintel box a member of the domain etc

Answer 6

I would prefer an architecture where the DB server is protected by more than just a firewall. That is, I would assume the webserver gets compromised - but instead of being able to do arbitrary DB operations, it can only fetch extremely limited data from an intermediary server. A DB enthusiast would assert that any DB will have sufficient privilege-checking builtin. But well, defense in depth.