"Hardening" a Vanilla Installation
R_J
Admin
What could be done to harden a Vanilla installation? That's what I can think of:
- File access rights
- File ownership
- Upload restrictions
- .htaccess restrictions
- ...?
With the recent upgrade, I started to mess around with file access rights and started searching for what the correct file access rights might be. I found that:
Files: 644
Folders: 755/cache, /conf/config.php, /uploads 775
My web server process is running as www-data and so I made that small chmod/chown script for points 1 and 2:
find ./ -type d -exec chmod 755 {} +
find ./ -type f -exec chmod 644 {} +
chmod -R 775 cache/
chmod -R 775 uploads
chmod 775 conf/config.php
chown -R root:root ./
chown -R www-data:www-data cache/
chown -R www-data:www-data uploads/
chown www-data:www-data conf/
chown www-data:www-data conf/config.php
Adding $Configuration['Garden'][' Upload '][' AllowedFileExtensions '] = array('txt','jpg','gif','png'); to /conf/config.php (add file extensions as needed) should be good for 3.
I'd like to achieve a basic authentication for /dashboard links but I haven't managed to do so by now. I'm also not sure if everything will work correctly because dashboard also contains all user controllers...
What else could you think of?
Comments
Adding
$Configuration['Garden']['Forms']['HoneypotName'] = 'hpt';to /conf/config.php and changing the "hpt" to something other might also help.I tend not to use root, for my web files use some other user an group unless there is a particular reason to use root. Just not the web process user. Also check the php process user isn't different than static content. It is on some set-ups.
It makes you more discerning about file management, IMO.
Generally I like the idea of restricting all direct access to php except index.php
<FilesMatch "\.php$"> Order Allow,Deny Deny from all </FilesMatch> <FilesMatch "index\.php$"> Order Allow,Deny Allow from all </FilesMatch>Granted most of the core file already restrict this.
in the uploads folder you could put a .htaccess
grep is your friend.
More "Hiding" than "Hardening":
Increase the version number in index.php: e.g.
define('APPLICATION_VERSION', '2.9');. That will not prevent you from being attacked when someone wants to, but you might not be found if someone scans for vulnerable versions.Staying up to date with the most stable version is still a must!
I'm always changing `$Configuration['Database']['DatabasePrefix'] = 'GDN_'; in config-defaults.php to something like 'VT_' before I install Vanilla, but that might be useless. I guess if someone is able to alter your tables, he will also be able to get their names, but you never know...
Thanx, great topic i'll follow that close.
I was going to suggest this as well. I know our cloud does this.
If you do that, it's imperative you increment after upgrades to break browser caches. You can't just make it 2.9 every version from then on or you'll start getting problems.
I guess it also will be a problem with some plugins, so it might not be the best hint...![:\](https://open.vanillaforums.com/plugins/emojiextender/emoji/little/confused.png ":\")
I don't think this is the best way to achieve what you want.
Instead you could predefine
AssetanSmartAsset(I suggest creating a version salt then hashing and then truncating) and something likepublic function Gdn_Dispatcher_AfterControllerInit_Handler($Sender, $Args){ $VerHash = substr(md5(C('Garden.VersionSalt').APPLICATION_VERSION),0,6); $Args['Controller']->SetHeader('X-Garden-Version',$VerHash); }grep is your friend.
A version-obscuring plugin would be cool. Could use the Installation Secret as the salt.
sounds good.
grep is your friend.
yes, but then we try to help people troubleshoot their forum, we wouldn't know whats going on
obscuring the version to me would be more of a hinderance, then a real benefit. Unless someone is knowingly running an old version that is insecure, and wants to to obscure it.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Of course you will! It's the latest!
My shop | About Me
I tend to agree with that peregrine it isn't really much of a barrier really.
Also naive "hardening" may sometimes in fact weaken. Not in this case but others.
Doing something needs to be balanced objectively with not doing something.
grep is your friend.
My general position is that any "hardening" should be done at the server/ops level.
Anything worth doing to Vanilla should be done in core.
I don't give any attention to stuff like "WordPress Extra Security LockDown Spectacular 5000" addons or whatever. The core team over there knows what it's doing. If it needed more, they'd do more.
Haha I worked with those, they normally require access to write to your server rules which defeat the whole purpose of server security.
grep is your friend.
There is specific hardening, such as entry hardening where you are using SSO. Or temporary hardening, where a vulnerability fix in the pipeline.
grep is your friend.
The problem with security in wordpress is often the addons, which can be the case here.
So there is some scope for some intelligent hardening, this cannot prevent everything though, and many of such plugin are pure bloat or constant false positives.
Another problem with wordpress is there is no single dispatcher. this make the possible entry points multiple.
edit Well there is sort of is a general dispatcher, but still multiple entry points for various things.
grep is your friend.