|
Monday 13 December 2010 10:12:33 am
My 2c: it's just useless paranoia. And dangerous paranoia: one that many "experts" claim again and again. A one liner that will do the trick:
chown -R www-data:www-data settings/ && chmod -R 400 settings Now nobody on the server except Apache and Root can read those values. And Apache cannot change them. If an attacker has got root access, little use trying to protect your precious inis or your precious php code or your precious socket connections. If an attacker can run code as Apache, he can get access to your db anyway by making use of your very own php functions that access the db after having decrypted the password. About real protection: your database should only be listening on the strict minimum number of IP addresses - if it's the same server as Apache this means no TCP at all, only pipes, and if it's a different server that means firewalling off port 3306 from anything but the webserver(s). Plus, with mysql, you can set a different pwd for the same user, based on their source IP - this is also a good protection measure in case your db password is stolen. So, who are you protecting your settings from with this extra encryption? Only from a malevolent sysadmin. But witholding the db password from the sysadmin is not a brilliant idea: how is he supposed to check db health, use monitoring tools, do backups, restores etc? Personally, I had very bad experience with servers using encrypted wallets. We used to have a server holding all the ssl private keys for the company websites (an https-terminator appliance). With a password set on each key. Whenever there was a power outage or a reboot forced by a security update, the app would not start any https vhost AT ALL if it did not receive passwords for all the keys. Needless to say, each project manager only knew the password to his own key, and there was at least one of them on holiday at any given time... Care to guess how much downtime we avoided because of not getting hacked vs. how much we lost waiting for the app to start? Last bit of advice: protect your user's passwords, not your db password; that's what hackers want - see eg what happened to gawker yesterday. This means eg. to switch to HashType=md5_site and set a random value to SiteName, so that those hashes are properly salted. And enforcing minimum password length etc... ciao!
Principal Consultant International Business
Member of the Community Project Board
|