469,626 Members | 1,421 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,626 developers. It's quick & easy.

connecting to seperate mySQL server through PHP

We currently have our mySQL server on the same box as the Apache
server.
For security and load balancing, we're going to be moving the mySQL
server to another box.
We're already using a single included connection file in all of our PHP
pages that has the server, username, password line that connects to the
database.

Aside from changing "localhost" to the IP/port number of the new
server, what else should be done, especially in the security sense?
If someone were to hack and be able to get access to view files, they
could open that file and see the username/password. Is there some way
to encrypt it or something?
So far the only thing I can think of to help limit that file's exposure
is to place it outside the /var/www/htdocs folder region. And of course
make sure the mySQL account it's connecting to has only the mySQL
permissions it needs.

Thanks for any advice!
Liam

Nov 8 '05 #1
2 1597
>We currently have our mySQL server on the same box as the Apache
server.
For security and load balancing, we're going to be moving the mySQL
server to another box.
We're already using a single included connection file in all of our PHP
pages that has the server, username, password line that connects to the
database.
For security purposes, this file should be *OUTSIDE* the document
root. If PHP is broken (say, during an upgrade if you didn't shut
down Apache, or if filesystem damage during a power failure screws
up one of the libraries), it's outside the document tree, so Apache
won't display it. If PHP is not broken, it will run it, not display
it.

The file needs to be readable by the user Apache and PHP run as,
but should not be readable by others who can log in to the box,
except admins.

I suggest the possibility of multiple logins with different privileges,
although this doesn't directly help your concern. In particular,
probably a lot of your web pages can function with read-only access
to the database.
Aside from changing "localhost" to the IP/port number of the new
server, what else should be done, especially in the security sense?
You need to GRANT privileges so your web server can access the database.

It would be a good idea to firewall the DB server so the whole world
can't get to the MySQL port, if only to load it down trying a futile
dictionary attack. And no, I'm not talking about MySQL permissions
here, although you set those carefully also.
If someone were to hack and be able to get access to view files, they
could open that file and see the username/password. Is there some way
to encrypt it or something?
You need the real password to access the database. If an encrypted
password works to access the database, then it *IS* the real password.
So far the only thing I can think of to help limit that file's exposure
is to place it outside the /var/www/htdocs folder region. And of course
make sure the mySQL account it's connecting to has only the mySQL
permissions it needs.


It's very difficult to deal with this if you are on a shared server
with people you don't trust (your competitors who are also customers
of your host).

Gordon L. Burditt
Nov 8 '05 #2
ne**@celticbear.com wrote:
Aside from changing "localhost" to the IP/port number of the new
server, what else should be done, especially in the security sense?
If someone were to hack and be able to get access to view files, they
could open that file and see the username/password. Is there some way
to encrypt it or something?


You could store the username/password as environment variables in
httpd.conf, then chmod the file so only root can read it.

Nov 8 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by kamilla | last post: by
4 posts views Thread by CodeImp | last post: by
7 posts views Thread by Frances | last post: by
6 posts views Thread by Todd Brewer | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.