encrypting site.ini

Author Message

Mirko Battisti

Monday 13 December 2010 7:58:01 am

Hello everybody.
I recently had a talk with an Internet security expert. The issue was security of an ezPublish website we've developed. He spotted some minor issues that we fixed (regarding parameters passed to flash objects). Then he pointed out it's not good to have config parameters (i.e. database password) readable in the file site.ini.append.php. He told me that for example in .Net there's a way to encrypt the parameters.

I know that if someone can read your site.ini you probably have bigger problems at system level, and maybe he got me a bit paranoid, but I wondered if there's actually a way to do that in eZPublish.
The only way I can think of is modifyng the kernel (once you've encrypted parameters in site.ini, you need to decrypt them everytime they get accessed).

Has anyone ever think about it, or should I just shut up and stop being paranoid :-)?

Thanks,
Mirko.

Gaetano Giunta

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

André R.

Tuesday 14 December 2010 12:38:04 am

Also remember to secure your var/cache/ini (ini cache) folder if your afraid of other people that have access to your server, Apache needs to be able to change these though & the user you use for cli scripts.

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Mirko Battisti

Tuesday 14 December 2010 1:21:30 am

Thanks Gaetano, thanks Andrè.
I thought it was paranoia, but the guy got me thinking.
It's good to come here and get reassured.

Thank you!

Mirko.

Gaetano Giunta

Tuesday 14 December 2010 1:56:17 am

Excellent catch, André. Care to list all of the settings that can be set to limit the permissions on cache files generated by eZP?

As for cli scripts (including cronjobs): my advice is: always run them as apache user (www-data or whatever it is called)

Principal Consultant International Business
Member of the Community Project Board

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.