So far we have been talking about permissions and restrictions, which are of course a huge part of how to keep your data secure. But there are a few best practices and features in place to reduce the risk of your Confluence installation being corrupted and prevent the wrong people from getting access.
Confluence protects access to its administrative functions by a special administrator session. When a user attempts to access the Administration Console or space administration, they are prompted to log in again. This logs the administrator into a temporary secure session that grants access to those administration screens. In other parts of the documentation this feature is also referred to as WebSudo.
The administrator session has a rolling timeout of 10 minutes (default). This means that if there is no activity in the Confluence or space administration for 10 minutes, the user will be logged out of the administrator session. If the user does click on any administrative function, the timeout will be reset.
To configure the secure administrator sessions:
- Browse to the Administration Console (Administration | Confluence Admin).
- Choose Security Configuration in the left-hand menu.
- Edit the settings:
- To disable secure administrator sessions, uncheck the Enable checkbox next to Secure administrator sessions.
- To change the timeout of the sessions, update the value next to minutes before automatic invalidation.
- Click on Save.
If your Confluence instance uses a custom build authentication mechanism, the extra login might cause problems as it checks the authentication against Confluence instead your own custom authentication server. Disabling password confirmation would be a valid solution.
An administrator can always manually end the secure session by clicking on Drop access in the banner displayed at the top of their screen as shown in the following screenshot:
Software such as Confluence is not flawless and every now and then a vulnerability is discovered. When such a vulnerability is discovered, Atlassian will calculate its severity based on the industry-standard Common Vulnerability Scoring System (CVSS).
Note
For more information about CVSS, visit http://www.first.org/cvss/cvss-guide.html.
Based upon the CVSS scores, the severity will be mapped according to the following guidelines:
|
CVSS score range |
Severity in advisory |
|---|---|
|
0 – 2.9 |
Low |
|
3 – 5.9 |
Medium |
|
6 – 7.9 |
High |
|
8 – 10 |
Critical |
The following is a summary of the factors usually resulting in a specific severity. These ratings don't take your personal installation details into account, but are based upon an average installation.
- Critical: This means the information required in order to exploit the vulnerability is widely available to attackers.
The exploitation is usually straightforward, meaning that the attackers don't need any special credentials or knowledge about individuals in your installation.
The exploitation of the vulnerability results in root-level compromise of your servers or other infrastructure devices.
- High: Here, the exploitation doesn't result in elevated privileges.
The exploitation doesn't result in significant data loss or corruption.
And, the vulnerability is difficult to exploit.
- Medium: The denial-of-service vulnerabilities are difficult to set up.
These vulnerabilities affect only nonstandard configurations or obscure applications.
This includes exploits that require an attacker to reside on the same local network as the victim.
This includes vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.
This includes vulnerabilities where exploitation provides only very limited access.
- Low: Vulnerabilities in the low range normally have very little impact on an organization's business. Exploitation of such vulnerabilities usually requires local or physical system access.
When a critical severity vulnerability is discovered, and resolved, Atlassian will inform their customers using the following channels:
- Atlassian will post a security advisory in the latest documentation of Confluence at the same time as a fix for the vulnerability is released. Check the following link:
https://confluence.atlassian.com/display/DOC/Confluence+Security+Overview+and+Advisories
- Atlassian will send a copy of the security advisory to the "Technical Alerts" mailing list.
If you want to track noncritical vulnerabilities, you can monitor the issue trackers for Confluence at https://jira.atlassian.com/browse/CONF. Security issues will be marked with a "security" label.
The Confluence Administration Console plays a vital role in keeping your Confluence installation running and making sure your users have the permissions they should have.
One way of further securing the Administration Console is limiting its access to certain machines on your network or on the Internet. If you are using an Apache web server in front of your Confluence installation, this would work as follows:
- The first step is to create a file in a common location on your server. We will use this file to include the Apache configuration needed, making sure we only have one location to change instead of many. We can do that in the following manner:
- Create a file called
local_machines_only.confin your apache configuration directory. - In this file add the following lines (only the bold part):
- Order Deny, Allow: Look for the Deny rules first, then the Allow
- Deny from All: Deny access for everybody
- Allow from 192.168.1.5 #Arthurs machine: Allow access from Arthur's machine based upon IP
Note
More on access control with Apache at http://httpd.apache.org/docs/2.2/howto/access.html.
- Create a file called
- The next step is to add a long list of locations to your Apache Virtual Host configurations. The following configuration assumes you've installed Confluence under the context path
/confluence, that is,http://mycompany.com/confluence. If this is not true for your installation, change the locations in the following configuration accordingly:<Location /confluence/admin> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/oauth/consumers/list> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/oauth/view-consumer-info> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/oauth/service-providers/list> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/oauth/service-providers/add> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/oauth/consumers/add> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/oauth/consumers/add-manually> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/oauth/update-consumer-info> Include local_machines_only.conf </Location> <Location /confluence/pages/templates/listpagetemplates.action> Include local_machines_only.conf </Location> <Location /confluence/pages/templates/createpagetemplate.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/spacepermissions.action> Include local_machines_only.conf </Location> <Location /confluence/pages/listpermissionpages.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/removespace.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/importmbox.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/viewmailaccounts.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/addmailaccount.action?> Include local_machines_only.conf </Location> <Location /confluence/spaces/importpages.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/flyingpdf/flyingpdf.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/exportspacehtml.action> Include local_machines_only.conf </Location> <Location /confluence/spaces/exportspacexml.action> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/embedded-crowd> Include local_machines_only.conf </Location> <Location /confluence/plugins/servlet/upm> Include local_machines_only.conf </Location>
This will make sure the administrative functions can only be accessed by the specified machines and IPs.
How you set up your Confluence roles, permissions, and internal processes makes a big difference in keeping your Confluence installation secure. The following are some tips you could consider. None of these make your installation a full 100 percent secure, but they slow down or turn around any attacker.
In general you could say, "Don't put convenience go before security."
- Keep the number of Confluence administrators as low as possible, but having just one is also not without risks.
- Restrict the number of users with powerful roles or group memberships. If only one group of users should have access to some particular data, restrict access to the data to those users. Do not give all staff access to sensitive data when there is no need.
- Confluence administrators should have separate accounts for their administrative role and for their day-to-day work.
- Lock down administrative access as much as possible. If there is no reason to perform administrative tasks from outside the office, use the previously mentioned method to restrict access to a known IP address.
- Get documented procedures in place, for when people are leaving departments or the company, so that you can make sure those people cannot access you Confluence anymore.
- The Confluence database user should only have the permissions to read and write to the Confluence database, and should not be allowed to perform administrative database functions.
- Regularly monitor your security requirements as things change over time. Before you know it, you will have 10 administrators instead of three, or your Apache configuration will be modified when upgrading your systems.
Keep in mind that these tips may only be a small part of your entire infrastructure. Apply those that make sense to your company and security requirements.