HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

"Hardening" a Vanilla Installation

R_JR_J Ex-FanboyMunich Admin

What could be done to harden a Vanilla installation? That's what I can think of:

  1. File access rights
  2. File ownership
  3. Upload restrictions
  4. .htaccess restrictions
  5. ...?

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

  • R_JR_J Ex-Fanboy Munich Admin

    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

    AddType text/plain .html .htm .shtml .php
    

    grep is your friend.

  • R_JR_J Ex-Fanboy Munich Admin

    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...

  • phreakphreak Vanilla*APP (White Label) & Vanilla*Skins Shop MVP

    Thanx, great topic i'll follow that close.

    • VanillaAPP | iOS & Android App for Vanilla - White label app for Vanilla Forums OS
    • VanillaSkins | Plugins, Themes, Graphics and Custom Development for Vanilla
  • LincLinc Detroit Admin

    @x00 said:
    Generally I like the idea of restricting all direct access to php except index.php

    I was going to suggest this as well. I know our cloud does this.

  • LincLinc Detroit Admin

    @R_J said:
    Increase the version number in index.php: e.g. define('APPLICATION_VERSION', '2.9');.

    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.

  • R_JR_J Ex-Fanboy Munich Admin

    I guess it also will be a problem with some plugins, so it might not be the best hint... :\

  • x00x00 MVP
    edited September 2014

    I don't think this is the best way to achieve what you want.

    Instead you could predefine Asset an SmartAsset (I suggest creating a version salt then hashing and then truncating) and something like

    public 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.

  • LincLinc Detroit Admin

    A version-obscuring plugin would be cool. Could use the Installation Secret as the salt.

  • sounds good.

    grep is your friend.

  • @Linc said:
    A version-obscuring plugin would be cool. Could use the Installation Secret as the salt.

    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.

  • businessdadbusinessdad Stealth contributor MVP

    @peregrine said:
    yes, but then we try to help people troubleshoot their forum, we wouldn't know whats going on :)

    Of course you will! It's the latest! :D

  • x00x00 MVP
    edited September 2014

    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.

  • LincLinc Detroit Admin
    edited September 2014

    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.

  • 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.

  • x00x00 MVP
    edited September 2014

    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.

Sign In or Register to comment.