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 point of view. PS You may want to dig into what happened with phpBB to understand exactly how they broke in and did whatever they did. It's possible that you are installing more dead-bolts on the door, while the real problem is a wide-open window with no lock on it. Not saying that more dead-bolts on a door ain't good; Just that it ain't gonna keep you safe from the same Bad Guy coming back to wreak havoc again the same way as last time. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
