symbulos partners wrote:
What we would like to achieve?
If a malicious user finds a way of entering of accessing the docroot (rwx)
of a website with CMS (PHP + MySQL), we would like to have further barrier
to him accessing the Mysql database.
We had some problem with one hacker using the database of a website with
PhpBB launching an e-mail based DDoS (this is what they said at the
provider hosting our server).
We are trying to introduce as as many obstacles as possible.
Excellent!
Encoding the password in that config file won't help you meet your goal in
the least. If they can read it, they can read it, and they are reading
the same thing PHP uses to access the database, so they can access the
database. You can't make it something they can't use to access the
database, but that PHP *can* use to access the database.
Making it difficult for somebody to physically *read* that password will
help, however.
Alas, you can't make it *too* difficult, or PHP also can't read it, and
then your site has no database access at all.
Standard procedures include:
Moving config files with passwords out of Apache's DocumentRoot and using
PHP's include_path setting to make them readable by PHP.
Some people recommend making the .inc and files be parsed by PHP or not
served up by Apache by tweaking Apache settings, or tacking .php onto the
end of all .inc files. The problem there is that you *still* have files
that the Programmer never intended to be accessed as a web page, available
for hackers to access as a web page. IE, they can surf directly to
http://example.com/someBB.config.inc.php and they are executing PHP code
in a context never really designed, considered, and certainly not tested
by the majority of Programmers out there whose code you acquire. So,
despite strong opposition on this list, I must continue to advise you to
*MOVE* any PHP/.inc file that is not an actual page people are supposed to
surf to, *out* of DocumentRoot, and use include_path to make PHP find
them.
But the goal here is to make it IMPOSSIBLE for the General Public to
*surf* to your config.inc.php script, and read the password, or otherwise
abuse the PHP source code within it to cause mayhem.
You've narrowed your potential attackers down from The Planet (billions
of users) to Shell Users (hundreds++, at most). That's a Big
Difference, imho.
Now, anybody with a shell account (or who breaks into a shell account) can
still use PHP to read your PHP config.inc.php script, and still get ahold
of the password -- Or run that PHP script out of context to cause
problems.
Your options for guarding against that include:
+++
Traditional Answer:
Guard shell access very carefully.
Downside: Not real practical in a shared-host environment, with hundred++
users.
Upside: You should be doing this anyway on a dedicated server, so the risk
is minimal. In fact, if a user you don't want to have shell, has shell,
then they MySQL password is probably *not* your most critical problem at
that point. Way too many nasty things they can do with a shell account
that supersede your MySQL password access.
+++
Low-volume Server Possibility w/ Apache 1.x:
Use PHP as a CGI, and suexec PHP-CGI to a specific user, and make the
config.inc.php file readable only by that specific user.
Downsides:
suexec is a pain to get right, and if you get it wrong, you open up way
more security holes than the MySQL passwword problem in the first place.
CGI is slower than Module, and is missing a few (four?) features.
CGI *might* not be *that* much slower if all your PHP scripts and PHP and
Apache children can fit into RAM.
It *might* also not really matter if CGI is slower for a low-volume server
-- Only you can make the performance/security decision for your needs.
MOST people seem to opt for PHP as Module performance over the security
risks of a compromised shell account. But, hey, it's your server. You
make the choice.
One feature I can recall that CGI won't support: HTTP Authentication, as
it would transmit HTTP password in the clear between processes (Apache and
PHP CGI). If you NEED HTTP Authentication (in PHP, not in .htaccess or
mod_auth_mysql or whatever) then you don't want PHP as CGI.
There are a few other features, mostly minor features that I never wanted
anyway, as I recall... You can probably read up on PHP CGI page to find
the other features you'll be missing.
+++
With Apache 2.x, I've been told that you can run PHP Module as a specific
user, independent of the Apache user, for each site. This means that in a
shared host environment, every host can run PHP as a Module under a
*different* under-powered shell user, with only that ONE user able to read
the PHP files. This protects your MySQL password from all other users on
the system, which is not possible in 1.x, as I understand it, on shared
servers using VirtualHost. One could run a different Apache 1.x process
for each user, of course, but that's problematic from a limited resources
