Jump to content

Invision Community Blog


Managing successful online communities

Matt
 

How to keep your community secure

Security should never be an afterthought. Don't wait until an attack has compromised your site before you take action.

All too often, site owners consider increasing their security only when it's too late, and their community has already been compromised.

Taking some time now to check and improve the security of your community and server will pay dividends.

In this blog, we run down 8 ways that you can protect your community with Invision Community. We go through the security features you may not know about to best practices all communities should be following.

1. Set up Two Factor Authentication

Invision Community supports Two Factor Authentication (2FA for short), and we highly recommend making use of this feature for your users, but especially for your administrative staff.

2FA is a system that requires both a user's password and a special code (displayed by a phone app) that changes every few seconds. The idea is simple: if a user's password is somehow compromised, a hacker still wouldn't be able to log in to the account without the current code number.

You may already be familiar with 2FA from other services you use. Apple's iCloud, Facebook and Google all offer it, as do thousands of banks and other security-conscious businesses.

Invision Community supports 2FA via the Google Authenticator app (available for iOS and Android) or the Authy service, which can send codes to users via text message or phone call. You can also fall back to security questions instead of codes.

You can configure which members groups can use 2FA, as well as requiring certain groups to use it. 

Recommendation: Require any staff with access to the Admin Control Panel or moderation functions to use 2FA. This will ensure that no damage will occur should their account passwords be discovered. Allow members to use 2FA at their discretion.

2. Configure password requirements

The password strength feature displays a strength meter to users as they type a new password. The meter shows them approximately how secure it is, as well as some tips for choosing a good password.

While you can leave this feature as a simple recommendation for users, it's also possible to require them to choose a password that reaches a certain strength on the meter. 

Recommendation: Require users to choose at least a 'Strong' password.

wonky_screenshot.png

3. Be selective when adding administrators

Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Giving access to the AdminCP is like handing someone the keys to your house. Before doing so, be sure you trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).

Recommendation: Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have Administrative access by clicking the Administrators button under staff on the Members tab.

4. Utilize Admin Restrictions

In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. 

Invision Community allows you to limit administrator access to particular areas of the AdminCP with the Admin Restrictions feature, and even limit what can is done within those areas.

This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.

Recommendation: Review the restrictions your admins currently have. 

5. Choose good passwords

This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.

We recommend using a password manager application, such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.

Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for other sites too.

Recommendation: Reset your password regularly and ensure you do not use the same password elsewhere.

security.png

6. Stay up to date

It's a fact of software development that from time to time, new security issues are reported and promptly fixed.

But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.

When we release new updates - especially if they're marked as a security release in our release notes - be sure to update promptly.

Invision Community allows you to update to the latest version via the AdminCP. You no longer need to download a thing!

Recommendation: Update to the latest version whenever possible. Remember, with Invision Community's theme and hook systems, upgrades to minor point releases should be very straight forward.

7. Restrict your AdminCP to an IP range where possible

If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist.

This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment.

Recommendation: Consider IP restriction as an additional security layer when you are not able or willing to use 2FA.

8. Properly secure your PHP installation

Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We, therefore, recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:

disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system

Another critical PHP configuration setting you need to check is that open_basedir is enabled. Especially if you're hosted on a server that also hosts other websites (known as shared hosting), if another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.

Naturally, Cloud customers needn't worry about this, we've already ensured our cloud infrastructure is impervious to this kind of attack.

Recommendation: Review your PHP version and settings, or choose one of our cloud plans where we take care of this for you.

So there we go - a brief overview of 8 common-sense ways you can better protect your community and its users.

As software developers, we're constantly working to improve the behind-the-scenes security of our software. As an administrator, there's also a number of steps you should take to keep your community safe on the web.

If you have any tips related to security, be sure to share them in the comments!

 

Edited by Matt


Comments

Recommended Comments

41 minutes ago, Adlago said:

What does  IPS provide for security headers? 😉

security_h.thumb.png.ab05c23ef9a16fb39338e07d51eca250.png

 

Strict Transport Security should be set up at the server level, and only if you are using SSL (https).

You can enable a Content Security Policy right from the AdminCP should you wish, but it's not something we can automate. You may have needs that the software can't know about (such as showing a Pages widget on an external domain), which is why you should configure it yourself if you wish to use it.

We do output the Content Type Options header when sending a file to the browser. There's little to no benefit using it just on every single page, but we do see value in attachment and file handlers to prevent browsers trying to guess what the file is even after we've supplied a mime type.

We enable a Referrer Policy when visiting external links.

I'm not really sure I'd group a Feature Policy in with security related headers...it's intended to indicate to the user agent which features (like location) the site may need. Trying to do this automatically also means third parties in the future may run into trouble if they try to leverage a new feature that we didn't outright allow initially. Either way, I'd say it's at least debatable if this should be lumped in as a security concern (Google's writeup even says "It's like CSP, except it controls features instead of security").

Share this comment


Link to comment
Share on other sites
Quote

Recommendation: Reset your password regularly and ensure you do not use the same password elsewhere.

This is not necessarily true. (And using a different password everywhere could drive a person crazy in this day and age.) Changing your password more often - especially when forced -, leads to lazy, insecure passwords.

Microsoft actually talked about how it's a dated practice. Better security and things like 2FA go much farther, especially when you already are using a good password. Avoid using common passwords that are very easy to guess, which includes names and birthdates.

Share this comment


Link to comment
Share on other sites
18 minutes ago, Tarun said:

This is not necessarily true. (And using a different password everywhere could drive a person crazy in this day and age.) Changing your password more often - especially when forced -, leads to lazy, insecure passwords.

Well, if we are already nitpicking: Your response asserts that changing passwords leads to “insecure passwords”, but this is only true if one creates passwords meant to remember. But the article doesn’t say that. One could use a password manager with stronger passwords, but the the recommendation of changing even stronger passwords is still valid, since they too could be compromised. 

Share this comment


Link to comment
Share on other sites
2 hours ago, Tarun said:

This is not necessarily true. (And using a different password everywhere could drive a person crazy in this day and age.) Changing your password more often - especially when forced -, leads to lazy, insecure passwords.

Microsoft actually talked about how it's a dated practice. Better security and things like 2FA go much farther, especially when you already are using a good password. Avoid using common passwords that are very easy to guess, which includes names and birthdates.

My personal recommendation is use a password manager, preferably one that stores the encrypted passwords on your own storage (e.g. your own cloud account) rather than a central server. That way you can generate extremely good passwords and maintain a different one for every site without any hassle.

Share this comment


Link to comment
Share on other sites

Most password managers (such as LastPass and 1Pass) can generate random passwords with mixes of characters at variable lengths). Most of my passwords on any given site are random, not reused anywhere else, and 32+ characters with a mix of letters (upper and lower), numbers and special characters. I could never remember any of these passwords, even if I were only tasked with remembering one, however I don't need to - I only need to remember one password (to access the app I use) and that's it.

Bonus: the password managers have apps for ios which has native support for this sort of thing. If I register on a site on my laptop and store the password in the password manager, when I visit it on my iPhone I can log in using the password manager.

Share this comment


Link to comment
Share on other sites

Nice blog article. This is a really good example of a useful, general best practice blog article which is great in particular for newbies, but can serve as a reminder in terms of more experienced admins, to perform a quick review as well. Things are always changing.

In fact I'd say IMHO its a little break from the trend of marketing/PR technobabble, although elements of that too are of course genuinely useful and sometimes food for thought.

One thing I've found in running a VPS using CentOS and WHM  in terms of point 8 and disabling dangerous functions is that disabling popen and proc_open can prevent server side software updates (like PHP Pecl/Perl/Pear extensions) from successfully updating. I find it handy to have 2 of 3 lines in my WHM > Software > MultiPHP INI > Editor config which can be quickly uncommented/commented out again when necessary (say updating an extension that requires proc_open), it saves on a lot of typing and remembering the list of functions especially when using a mobile device.

; This directive allows you to disable certain functions for security reasons.
; It receives a comma-delimited list of function names.
; http://php.net/disable-functions
disable_functions = "show_source, system, shell_exec, passthru, exec, pcntl_exec, proc_open, popen"
# disable_functions = "show_source, system, shell_exec, passthru, exec, pcntl_exec"
# disable_functions = "show_source, system, passthru, pcntl_exec"

 (My list here is probably different to the one in the Blog article.)

Re perhaps increasing the HTTP Content Type options in IPS, they could be useful but if you've set them server-wide already, I'd be wary in case its possible that you could be overwriting the http.conf server level config.

Edited by The Old Man

Share this comment


Link to comment
Share on other sites
1 hour ago, The Old Man said:

Nice blog article. This is a really good example of a useful, general best practice blog article which is great in particular for newbies, but can serve as a reminder in terms of more experienced admins, to perform a quick review as well. Things are always changing.

In fact I'd say IMHO its a little break from the trend of marketing/PR technobabble ...

Agreed. The rest of what you wrote (the code, etc.) is out if my skillset.

Share this comment


Link to comment
Share on other sites

The disabling PHP functions bit is pure security theater and does not increase the security of your site. If an attacker is capable of running arbitrary PHP code on your server due to some vulnerability, it's already game over. Restricting those functions does not in any way, shape, or form prevent them from doing whatever it is they want to do. Using functions that are required to be enabled just to make pieces of Invision Community function, an attacker can read/write files, read/write the database, and open sockets (network connections). The combination of these is plenty to establish a persistent backdoor and/or gain a foothold into your network to launch attacks elsewhere.

open_basedir is potentially a good idea though, depending on your setup. In places where you can safely enable it and enabling it won't break anything, it's a good idea to do so.

A better setup for securing PHP would be ensuring that the user account PHP is running as for your Invision Community install is unprivileged (i.e. not root) and is dedicated to your site (i.e. not a shared apache user). If you have multiple sites, run each site under a separate user account. Then, set up file permissions appropriately so that the user accounts have read-only access to their own files and no access to the files of other users. Directories that must be writeable, such as cache and uploads, should have script execution disabled via server config. This ensures that a compromise is unable to write backdoor scripts to your filesystem (although they can still manipulate the database), which will limit the damage an attacker can do. By manipulating the database, an attacker can still establish persistent backdoors into your site with certain configurations (for example, by manipulating cache entries if they're stored in the db or by creating a new admin account), so this is not foolproof. As I wrote above, if an attacker is able to execute arbitrary PHP, it's game over. The setup I described in this paragraph blocks some of the ways they can do that, but not all of them.

Share this comment


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...