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.

We're deploying a simple newsletter webapp on a stand-alone LAMP platform in the company DMZ. There is some discussion as to whether the MySQL server should be removed from the DMZ and put in the internal network.

The server is behind a firewall with only port 80 open and MySql will be attached to a non-standard port. The database contains customer email addresses.

Is this a secure setup (or secure enough)? How much more secure would it be by placing the data behind a second firewall? (I'm more of a developer so I'm not really aware of all the security aspects here - can someone enlighten me!)

Update Just for clarification and to attact more comment here is our current setup:

internet - firewall1 - http server - firewall2 - appserver - firewall3 - enterprise resources

This new application was supposed to go completely within the DMZ between firewalls 1 and 2. We're currently discussing pulling the MySQL server in behind the 2nd firewall.

share|improve this question

7 Answers 7

To allow connections from the DMZ to the internal LAN is breaking with the concept of a DMZ.

Binding MySQL to localhost is going to be no less secure than placing MySQL elsewhere. If data theft is your concern, you should assume that were the two machines split apart and the Apache portion was compromised, then MySQL connection details stored on the compromised machine could simply be re-utilised by an attacker to read the data out anyway.

Edit to add:

Even with a double-hop DMZ as you describe, you're not purchasing yourself any real security benefit from separating the services, whilst at the same time making the setup more complicated. You're possibly even increasing the attack surface by having more machines and sending data over the wire that would otherwise be on loopback.

share|improve this answer
    
I find your comments interesting especially considering they go against all the advice we've had in the past (from our app server supplier!) Can you point me to any security primers so I can read up a bit on this subject? (I would also vote you up but my rep is too low here :( - vote me up someone!!) –  paul Jul 7 '09 at 9:38
    
I can't think of any primers that would cover it to hand. I can say however that a lot of vendors, consultants and indeed auditors are quick to make suggestions without thinking through or understanding the permutations. Certainly there are good uses for a double-hop DMZ but they don't gel with what you're trying to prevent. List out all of the possible attack vectors that you can imagine, think of solutions to each one and then think of technicalities that you could use to circumvent the solution. It's a bit corny - but think like an attacker. And sometimes, the simplest solution is the best. –  Dan Carley Jul 7 '09 at 9:58
    
I'm a programmer and therefore an optimist when it comes to security ;-) Thanks for your comments. Agree with the 'simple is often best' point. –  paul Jul 7 '09 at 10:04

I would put the DB in the internal network (behind a second firewall).

This vastly reduces the attack surface of the DB because you set the firewall rules for the second firewall (DMZ to Internal) to ONLY allow connections on port XXXX (the DB port) from the webserver.

So even if your DMZ is compromized there is still protection for your DB.

share|improve this answer
    
You seem to be outnumbered here! Do you have any further comments to back up/ refine what you're saying? –  paul Jul 7 '09 at 10:02

I think the MySQL part has been adequately covered and I certainly agree with what has already been said. I would just like to point out that as a first step you should find out what the legal requirements are in your part of the world, as they vary considerably. Quite possibly that will determine your configuration.

share|improve this answer
    
Fair point. Those PCI people have a mind of their own. –  Dan Carley Jul 7 '09 at 9:32

The DB server should be firewalled from any outside internet connections so only the app server (plus anything needed for administration) can connect to the database. If it is separate from the app server - there are various reasons for doing this - then set up firewalling and security appropriately.

Compromising the application server is likely to make the application's login credentials available to the DB attacker, so some level of DB or application level security may help. For example, you could do some sort of separation of responsibilities along the lines of:

Set up DB object ownership so the application cannot directly read customer data but must go through a stored procedure. Full credit card numbers could be write only - a sproc could allow them to be updated but only read the last 4 digits for the 'update details' screen. Anything that needed the CC number might live on a different server and connect through a different account.

If the financials are managed on a physically different server (perhaps firewalled off from the public internet) then you could at best issue bogus orders or similar without actually compromising the server. Obtaining credit card information would require compromising two machines (the app server and either the DB server or financials server). You would also have to launch the attack from the compromised web server. This gives you a longer window to detect activity as the attacker cannot compromise both machines simultaneously.

The DB and financials server machines also have a very specific set of interactions with the web server. This allows you to assume that most if not all non app-related activity is suspicious and set up an IDS on these machines with an ultra-paranoid configuration.

share|improve this answer

Let us evaluate the two scenarios and see which one is better. I suppose you have configured the MySQL account to have only READ/WRITE access to the tables specific to the application.

I will attack the webserver using a zeroday exploit. I now have administrator access to the web server and can fully access the local filesystem. I can also send network communication originating from this webserver. I have gained access to the credentials required to access the application database.

If the database server is on the same machine, I now also have direct and full access to the database. I can read and write to all tables in the database, create new ones and listen in on all other communication with this database server. Evaluation: This is the worst scenario. The application database and all other databases are now impacted.

If the database server is on a different machine in the same DMZ, I can fully communicate with the database server. I can now use an exploit in the Windows File Sharing service to gain administrator access to this server. Evaluation: I can access the database server using the web application account, but this may only give me limited rights. I need a different exploit to gain full access to the database server. I can exploit any service available on the database server.

If the database server is in an entirely different network, I can only access the database port. Any other communication is filtered by a firewall. This means I can only use an exploit in the database program to gain administrator access. If I gain administrator access, the full internal network is compromised. Evaluation: I can access the database server using the web application account, but this may only give me limited rights. I can only exploit the database port to gain full access. If I do this, the network of the database sever is compromised.

share|improve this answer

If the machine is compromised then it wouldn't matter if the MySQL server were in the DMZ or not. The credentials for accessing the MySQL database will be in the web app code somewhere and the machine in the DMZ will have to have access to it so firewalls won't keep your data safe in this instance.

A better design may be to have the web app write a queue which is then pulled into a MySQL database inside your protected network. This would limit the exposure of customer data to what's in the queue. Just thinking out loud here. This may not work or be practical for your particular app.

share|improve this answer

You shall not allow any traffic from DMZ into the internal network. It is a really bad idea! If someone may gain control over your web app the dmz, then it will be possible to open a connection to a server inside your internal network and gain full controll over your entire network. If you want to separate the Web app from your network i suggest you create another DMZ and place your DB there. The only traffic allowed to the other DMZ i from your web server. I have seen some terrible firewall designs, and this is one of them.

Håkan Winther Senior DBA and former owner of a security company.

share|improve this answer
    
+1 for the second DMZ - this is what I have been forced to do by our security team serverfault.com/questions/35334/… –  Sergei Jul 7 '09 at 7:22

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.