How to seperate the mysql database from the apache host.
 

Hi All,

I apologize ahead of time if this is in the wrong place, yet I am quite a newbie.

Basically I am doing a school project where I create my own ecommerce website and launch it, using all free software. This is why I love you people!

My professor is highly concerned with security. Of course being an ecommerce site, by nature, will need to store private business and customer data, as well as perform credit transactions. So confidentiality, integrity, authentication, yadda yadda.. The professor wants this to be relatively high-end in terms of the systems capability (not like amazon.com, but maybe something along the lines of a small retail business entering into the e-world).

So I am learning my way through Linux via command prompt because GNOME is for uber noobs and I like doing things the hard way. My team that I am doing this with would like to take our lamp server (on vmware), configured by yours truly, and break it up to run the database on a second machine. It made sense to us because the webserver was going to placed in the DMZ of our network and somehow we would then sync a foreign database located in a private zone on the network. So in other words the database is not accessible by the cloud in any way other than through our webserver. I read somewhere about how that can help dodge sql injection attacks.

I am very new to some of this so if the above design sounds really flawed, it probably is. I was just hoping for maybe some links that you think would help us, or some general insight! Perhaps even a better network topology we could use. I have read through quite a few other forums and the best answer I could find was here: http://www.ehow.com/how_5132804_conn...erver-php.html
I understand the syntax but I'm not sure how to go about implementing that code, or if it is even what I need.

Any advice here is greatly appreciated and I promise that contributing to my 'A' this semester will in some way get you free cookies.

-microwave

The answer is very simple -- unless you are an expert in Website design, do not put sensitive data into an online database. Period. There are any number of ways by which a hacker can compromise all but the most robustly designed online databases, and new vulnerabilities are uncovered every day.

I can't believe that databases with potentially sensitive information are to be made part of student's Website design project.

Fairly easy.
Install mySQL on another machine, place it in the Private zone, enable networking on mySQL.
Then iptables steps in.
Let's say your webservers IP is, 192.168.10.10 and your mySQL servers IP is 192.168.20.10
Now you need to add a iptables rule to the mySQL server as:
iptables -A INPUT -s 192.168.10.10 -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT
Which means:
Accept TCP port 3306 only when source IP of connection is 192.168.10.10, meaning only the webserver will be allowed to go through port 3306, which is the port mySQL listens on by default.
Then on your PHP code, you need to alter your mysql_connect() to read:
mysql_connect("192.168.20.10", "mysql_username", "mysql_password");

If you wish to configure mySQL to listen on another port, then you must change the PHP command a little bit more further:
mysql_connect("192.168.20.10:PORTNUMBER", "mysql_username", "mysql_password");

Hope I understood your question.

Good boy only hard learned lessons are lessons well learned ;) No realy i think myself that this is the best way to learn about things.

Generely its always a good thing to follow one machine - one service practice. If one service is vulnerable only one machine goes down.
As Tux-Slack pointed it out use a decent iptables setup to protect the SQL-Server.
I just like to flaten this out a bit.
machine: webserver --- sql-server
service: apache:80 --- mysql:3306

You have to make sure within the config of mysql that it listens on an ip that can be reached from outside. Most distros deliver mysql listening on localhost only. Look for something like skip-network or bind-adress ip.add.re.ss in the /etc/my.cnf file

Misguided information. No matter where something is it matters who and how you talk to it. As the SQL commands are comming from the webserver wich is in the cloud you have to take caution there.


Just for my peace of mind: Is this setup realy going to go live and be fired on from the cloud? Or just sitting somewhere and looking good?

Cheers Zhjim

Just a couple of thoughts...

Doing things via the command line usually makes thing easier than using a GUI tool. Knowing the ins and outs of arguments, what files need configuring and what to put in them is the hard part. Sometimes DIFFing a config file after using a GUI can be very enlightening.

Moving MySQL to a different machine in this case may or may not be a good way to go. Having to configure a completely separate box opens up a lot of security concerns unless you have an established build policy in place. Separating services us usually done based on the value placed on performance, standardization and security. You might be able to achieve a good level of security by simply binding the MySQL service to localhost rather than a routable address.

Dodging SQL injection attacks is a function of sanitizing user input, not server placement on the network.

One other thing you could do is some "harder" programming.
On the mySQL server, you would need an application that would listen on some port, let's say 1337. In this program you would need to write all those SQL operations that you would need. And also code some TCP Socket comunication in the application.
Then, same deal, use iptables to filter traffic on port 1337 so that only web server is allowed to access it.
Then in the webapplication, instead of connecting to the SQL, use fsockopen() to contact your application, pass it arguments over the TCP socket, and wait back for the response and the returning data(from SELECT statements).
This way, no one and nothing can inject any SQL statement to the DB server because you would handle all SQL statements with your own application and the public doesn't have any direct connection with the database. And plus your DB doesn't accept anything from the network, but only directly from the UNIX socket.

So over the last couple weeks my team and I were able to get the website working. The exact problem I was having was actually due to just lack of proper mysql user/login configuration. Who knew! Thanks again for all the help.

-microwave