Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have a classic DMZ architecture:

enter image description here

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?

share|improve this question
2  
Why does the database server need to communicate with the web server? I would think that it would be the other way around(the web server that needs to communicate with the db server, and the db server just needs to return the results). The db server should not be permitted to initiate communication with the web server; it has no need to. –  Kevin M Nov 14 '11 at 15:28
    
Correct. I updated the question accordingly :) –  lisa17 Nov 14 '11 at 16:15
    
What assets does the database contain? –  this.josh Nov 15 '11 at 9:11
    
@this.josh credit cards details –  lisa17 Nov 15 '11 at 11:00
add comment

5 Answers

up vote 14 down vote accepted
  • 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.
share|improve this answer
    
so I should add another leg to the firewall for a DB DMZ, correct? –  lisa17 Nov 14 '11 at 20:20
2  
@lisa1987 Yes. You may be able to accomplish it via VLANs rather than hardware. –  Jeff Ferland Nov 14 '11 at 20:27
    
putting a sensor on the segment will allow you to monitor it easily plus the log will be clearer. The syslog server could be on a different segment and valuable information could be associated with debugging. –  happy Jan 9 '13 at 6:25
    
Be especially careful to mitigate VLAN Hopping en.wikipedia.org/wiki/VLAN_hopping when depending on VLANs for security. –  mgjk Jan 9 '13 at 17:24
add comment

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 proxy/relay server 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 unauthenticated content to the front-end proxies.
  4. you might want to add one or more of zones: IDS, management, backup, remote access, outbound proxy

You're trying mitigate, so:

  • inter-zone communication must be limited to the minimum required for service and monitoring purposes.
  • reverse-proxy accepts untrusted connections from the internet, can only connect to services on application servers. If you want to classify your zones by traffic you need to consider carefully termination of HTTPs, and if you want to create new HTTPs connections to the app servers.
  • application zone accepts semi-trusted connections from proxies, can connect 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 accepts 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 outbound-proxy-zone).
  • same goes any outbound CC validation HTTPS connections. (If you're unlucky enough to have some vendor-provided black box for validation, that ought go on a dedicated zone too, IMHO.)
  • use public IP addressing only in the proxy zone, private addressing elsewhere. No server outside proxy zone need have a public IP, NAT, or a default route to the internet.

Separate zones makes your IDS's job easier, and logging more effective. If you have the resources, add a management-zone, separate management NICs for each server (protected ports if you can).

In reality you may end up compacting the "ideal network" to a single firewall and VLANs, but 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 ;-)

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
Could you expand on not adding the database server to the domain? I disagree with you but keen to hear your view. –  fixulate Jan 9 '13 at 12:38
    
well in my experience it adds a lot more risk to internal system compromise if the server is a domain member and therefore will be subjected to domain accounts for administration –  Matthew Jan 14 '13 at 16:44
1  
But with being part of the domain you get all the security benefits that you lose by being standlone? GPO, centralised management, password policy, account auditing, etc. Curious to know if anybody else thinks removing servers from the domain increases their security posture? –  fixulate Jan 23 '13 at 13:10
add comment

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.

3 Tier Architecture

share|improve this answer
add comment

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.