JIRA and Confluence are important tools for managing projects and exchanging knowledge in many companies. Since they contain sensitive information, operating them as securely as possible is a must. In this two-part series about the security in Atlassian products we explain general principles of safeguarding JIRA and Confluence and give advice based on best practices. The first part focuses on network and server security and security aspects concerning the installation and basic configuration.
In this article we look at the configuring and running a system with multiple Atlassian products as securely as possible. As a common scenario found in many companies, we assume that you operate two Atlassian systems in your Intranet:
Confluence for project documentation and collaboration and
JIRA Software for project management and issue tracking.
This infrastructure has grown incrementally (it usually does) and is customised to the needs of the enterprise.
In this assumed primary use case you likely have a closed set of users, meaning all users are your colleagues and have to be registered to use the systems. However, certain projects require the participation of external users, e.g. external employees or users working for cross-enterprise projects.
As the most likely scenario, we presume that Confluence and JIRA systems hold a lot of sensitive internal information, but no secrets that would require very strict protection. The detailed definition of protection needs is an important task which goes beyond the aspects mentioned here and has to be done individually for each system.
Based on these considerations, our goal is to configure and run the entire system to be as secure as possible.
Describing an elaborate threat model for the scenario introduced above is out of scope of this article. However, in order to harden the overall system, a rough general conception of likely attacker types can be helpful.
The complete outsider
In case one of the systems is accessible from the internet, everybody can try to attack it. In a worst-case scenario, an outsider gains access (with user or even administrative privileges), which can be seen as a complete security breach. An attacker might also try to target individual users (steal sessions, information, etc) or gather general information (internal data about people, projects, etc.).
The external user
External users are registered in the system and have (restricted) access to parts of it. Since no bonds tie them to the organisation, they might be more likely to attack the system than internal employees. External users might profit from internal information and could therefore explicitly scan the system for sensitive information or even try to attack internal users or administrators.
The internal user
Internal employees are usually considered to be loyal to the company and hence less likely to conduct harmful actions. However, especially in large enterprises, individual employees may be disappointed or have other motives to harm the system. These people may try to gather sensitive information, attack other users or administrators, or try to escalate their privileges to access administrator functionality, for instance.
The administrator
Atlassian products consider administrators to be trustworthy by definition.
In our general strive to harden the systems, a first and primary goal must be to reduce the attack surface for external attacks to a minimum. Most of the essential steps to accomplish this goal have to be addressed when setting up and configuring the system (network, server, webserver, etc). The subsequent sections give insights into relevant tasks, share informative links and provide hints about further configuration tweaks.
Once the general system is set up robustly, the Atlassian products themselves have to be configured and run securely. Amongst other things, topics related to user management, rights and roles and safe defaults have to be addressed. In the remainder, this blog will explain general principles and give advice based on best practice.
Architecture and other fundamental considerations
As stated before, we address a scenario where two Atlassian products are used on the system. Manuals and documentation of Confluence or JIRA already give instructions on how to set up your system. We will refer to these guides throughout this section while giving some additional recommendations and discussing important steps. Since we do not want to linger too much over technical details, we point out important aspects and provide links to more detailed documentation pages.
Conceptual considerations: External access
One fundamental architectural decision to make is whether your Confluence or JIRA instances have to be accessible over the internet. This decision depends primarily on your business needs but has significant impacts on the architectural setup of the entire system. Aside from the obvious black and white solutions, several shades can be configured.
If your systems only need to be reachable inside the company, the systems can be routed solely on the intranet without exposing them to the world wide web. This of course reduces the attack surface to attacks from the outside greatly.
In case certain or all employees need to be able to access the systems from anywhere, a VPN solution may help. If users can open a VPN tunnel to the intranet, Confluence or JIRA access is ensured, too. Unfortunately, however, VPN connections are not always a very fast and user-friendly solution. Another flexible and mighty solution for restrictive access control is the use of client certificates. But since this solution requires a public key infrastructure which entails some non-trivial challenges, it is rarely seen in practice.
In contrast, our exemplary scenario introduced above presumes the existence of external users and thus needs to provide access over the internet. However, even in this use case we try to keep the attack surface as small as possible. It is often not necessary to expose all functionality to the outside world. A reasonable compromise, for instance, would be to require administrators to log in from the intranet (or VPN) while all other users can access the systems via internet.INFO: Further Information: The page “Using Apache to limit access to the Confluence administration interface” describes how to restrict administrative access to a configurable range of IP addresses.
Technical setup (network / host configuration)
Host security is of paramount importance for every IT system. We expect you or your colleagues from the IT infrastructure department to be competent experts who know their job. Hence this section only gives an overview of necessary tasks while mentioning some additional tweaks which may enhance security.
Encrypted communication
Using Confluence or JIRA Software in a productive environment always requires to enforce encrypted communication between client and server. This prevents attackers on the network level from wiretapping or manipulating confidential communication. Consequently, a vital but non-trivial task is to obtain a strong, valid TLS certificate and to configure TLS appropriately (avoid old libraries, deprecated protocols, weak cipher suites and other pitfalls).
INFO: Further Information: Atlassian’s recommendations on how to set up connection over HTTPS can be found here:
for Confluence
for JIRA
Recommended architecture: Use a reverse proxy
As basic architecture, we suggest the various Atlassian products to be routed through a reverse proxy which serves as a single interface to the systems. This allows to configure certain issues centrally for all systems. The following article “Proxying Atlassian server applications with Apache HTTP Server” gives further insights into Atlassian applications in a reverse proxy setup.
Reverse proxy / web server configuration: Many configuration issues can be addressed on various levels: inside the administrative interface of Confluence / JIRA, on web server level or centrally on the reverse proxy. Aside from other aspects, the following topics have to be considered:
Logging: What information needs to be logged (assess your protection needs!)? Where to do logging? How verbose should it be? Are the capabilities provided by Confluence / JIRA sufficient? Web server / reverse proxy can write very detailed and technical logs. The reverse proxy allows to centralize logging.
IP restrictions: Are IP restrictions (or similar protection mechanisms) for certain functionalities (e.g. admin UI) necessary?
Advanced protection mechanisms: In case of particularly high protection needs or other strict security necessities the reverse proxy can be configured to serve as a powerful additional layer of defence. A web application firewall like ModSecurity can do a good job here.
Avoiding the exposure of system information:
The system should not needlessly expose internal information which might help attackers to identify weaknesses like old software or plugin versions. Examples of what to look out for:
/server-status → This is just one example of a standard Apache monitoring page which reveals very detailed information about the server. It should never be exposed to the internet.
Confluence, JIRA Software and some plugins tend to print error pages which contain entire stack traces. Adversaries may draw conclusions about old or vulnerable plugins or implementation details. Hence HTTP status 500 error messages should be replaced by a custom page which does not reveal stack traces or similar verbose error messages.
HTTP headers: For some extra security in certain situations we recommend to set two additional HTTP headers. Setting “X-Xss-Protection” to “1; mode=block” provides some additional protection against cross-site scripting. The header “X-Frame-Options” can protect against a called clickjacking. The page “Enable X-FRAME-Options header to implement clickjacking protection” describes this issue.
Maintenance
Like for all systems, operators / administrators should have a clear plan about how to maintain their Confluence and JIRA Software instances. On a regular basis, security-relevant bugs are discovered and then fixed by the vendor. Hence it is of paramount importance to stay informed about new releases and security patches and update affected systems before the vulnerabilities are exploited in the wild. As a minimum, we recommend to care about the following aspects:
Stay informed about Atlassian Security Advisories; hint: subscribe to the mailing list)!
If vulnerabilities in Atlassian products become known (e.g. via an official advisory), update as quickly as possible!
Generally, keep your systems up to date! Try to avoid old versions as they are likely to contain, potentially even unknown, security vulnerabilities. Do not forget to keep the entire software stack (server, web server etc.) up to date, too. We presume your IT infrastructure team knows how to do the job.
Confluence and JIRA offer a functionality to check if you can update your application by checking the compatibility of each installed add-on.
Confluence and JIRA will detect available updates for your add-ons automatically if they have access to the Atlassian Marketplace.
Prepare a plan about how to handle all updates. For instance, a monthly patch day could be implemented, on which you and your team assess whether or which components need to be updated.
Keep a careful eye on your Confluence and JIRA Software plugins. Vulnerable plugins are a likely and major security risk for the entire platform. Try to stay informed about potential vulnerabilities in plugins, even though this task may be more tedious as plugin providers rarely offer mailing lists or the like. If you have implemented a patch day, this would be a good opportunity to re-assess the security of your plugins regularly.
For all considerations, ponder your protection needs. While security issues in systems exposed to the internet need to be addressed immediately, certain risks might be deliberately accepted for exclusively internal systems with a very limited number of users. However, never forget about potentially malicious insiders or the possibility of an outside attacker penetrating into the intranet.
Security Features of Atlassian Tools
Atlassian mentions some security features at least for Confluence in the chapter “Configuring Confluence Security” within the Confluence documentation. For JIRA Software you will not find such a chapter. In the following, we will sum up the most important topics for you and give you additional information. However, we recommend that you read the chapter within the latest documentation anyway, so you will be up to date about the latest changes on this topic.
The security features officially listed within the documentation are:
Password Storage – All passwords are hashed and salted if you use internal accounts. No passwords will be stored if you use delegated authentication.
Buffer Overflows – As Confluence is a 100% Java application it is highly resistant to buffer overflows.
SQL Injection – Database queries are generated using standard APIs, so Confluence is highly resistant to SQL injections.
Script Injection – Confluence is a self-contained Java application and does not launch external processes. As such, it is highly resistant to script injection attacks.
Cross-Site Scripting – In default configuration Cross-Site Scripting is barely possible. Depending on your configuration you can increase the risk here.
Transport Layer Security – Confluence is able to use TLS, so your administrator can run the application safely.
Session Management – The session management is handled in the given Java application server. Up to now, no vulnerabilities are known.
Plugin Security – As Atlassian will not guarantee anything for 3rd party plugins each administrator should be aware of the source of the used plugins and decide whether they trust those or not.
Administrator Trust Model – Atlassian Tools are written under the assumption that you can trust your administrators. Each system administrator is able to access any kind of content either directly or via installing plugins or granting himself the necessary permission.
Stack Traces – The systems will provide stack traces through the web interface for each occurring error. Those stack traces could be used for support purposes. From a security point of view, however, we recommend to configure the system in a way that it does not expose stack traces.
Based on those topics we will start to give you some advice about how to run your system as safely as possible. We will start with general advice and get into specific details later on. In the same way we will move from the outside of the system to its core – from how to secure the network access to how to permit users and how to configure specific features.
Be aware of the Administrator Trust Model
Within the Atlassian tools your administrators can do almost everything, so you should consider some organisational ideas here.
Try to have around three employees with system administration access to all of your tools.
If you have less, it could be that there are times in which no employee with admin-access is at work – one is sick, the other one is on vacation.
If you have more, you run into the problem of getting a planless configuration, as everybody changes the configuration as his or her team needs it at this moment without documentation and discussion with others. If you have e.g. 160 employees and 16 system administrators it could happen that one day a custom-field will disappear as one admin doesn’t need it for his projects. So he will simply delete it without thinking about the fact that this field could be used by other teams. The problem here is: The field and all data are lost.
Another outcome could be that you have multiple configurations of the same kind, 10 similar bug issue types with the same fields, 20 similar custom fields with slightly different naming and content configurations. Those redundant configurations can sum up and cause some performance problems for e.g. indexing, searching and stuff like this.
Make sure your administrators know what they do. Let them make the certificate for JIRA Administrator and/or Confluence Administrator provided by Atlassian or an Expert Partner.
If you store highly confidential information and data in your systems, you can even think about a separate obligation to confidentiality for each of your administrators.
Use external user management if possible and connect it via TLS
Even as the passwords are hashed if you use the internal user directory, we recommend to connect an external user management with delegated authentication. In this way no passwords will be stored in your system at all. As mentioned above, use a TLS connection were possible.
INFO: More security for Internal Directories: If an external user management is not possible for any reason, there are ways to secure the usage of internal user management. The easiest way is to enable CAPTCHA for failed logins.
If this is not secure enough, you can also implement Fail2Ban to limit login attempts. Fail2Ban is a Python application which can be used to limit the rate at which a given machine hits login URLs for Confluence.
Link via TLS
If you run more than one Atlassian product and you like to use the trusted-application-links, connect them also via TLS. If you use more than one Atlassian product it is great if you have connected them with the trusted application link. In this way you can create issues or link issues directly out of Confluence or search and link to pages out of JIRA. Also you can include different gadgets on your confluence page, or you can use Confluence as knowledge base for your JIRA ServiceDesk and you will get many more options with all the other products from Atlassian.
As Atlassian themselves mention that a trusted application link is a potential security risk, you should also use a TLS connection here to limit this risk.
Don’t permit anonymous users in any level of permission
If you run your system in the internet it is highly recommended to not permit anonymous user to your system to perform any action. But even if you run your system just in your company’s network you should think twice before you permit anonymous user. Here you have to think at least about two layers:
Anonymous access to your system → managed by a system administrator
Anonymous access to a JIRA project or Confluence space → managed by a system administrator or a project / space administrator.
Your system administrator can define if only known users or also anonymous users can see content on your system. If you like to use the anonymous access to be able to guarantee access for everybody to specific content you have to make sure that your project or space administrators will know this and which risks will be involved. The risk here is that a project or space administrator accidentally can permit access to restricted information in the project or space he is responsible for. Apart from access permission, permissions for different actions can be assigned to anonymous users by project or space administrators. This results in a higher risk as information can be manipulated and deleted.
But even if the system administrator has denied anonymous access of unknown users for the whole system, the project and space administrators have to be careful in permitting users.
In JIRA you can only assign users with a specific user-account to the given roles. So here you will have no problem if you are a project administrator. As a system administrator you have to have some more topics in mind. We will handle those topics below when we talk about specific permissions you have to be aware of in your configuration.
WARNING: Anonymous access on space level: In Confluence you can permit anonymous access on space level even if anonymous access on the system-level is not set. The result here will be that all users who are able to login to the system in the first place will have access to your space.
Validate the source of your plugins
If you use JIRA Software or Confluence you will know that you have to install one or another plugin very soon to get functionalities that the base system does not offer. With a marketplace containing over 2,000 plugins you will find nearly everything you can imagine. You get everything from free plugins to plugins which cost as much as your base system. This variety results in some topics you have to be aware of:
For all plugins independently:
Are they developed professionally or are they some kind of “side-project” with a bunch of problems and bugs you have to discover by yourself?
Does the plugin extend the REST API or does it offer any other interface you have to be aware of?
How does the plugin affect the performance of your system?
Does the vendor offer regular updates for the plugin and how long does the vendor need to verify his plugin for new major versions of the base system?
Does the vendor offer professional support and how long does it take to fix bugs reported by users?
If you use more than one plugin:
Do they work together without any problem?
Do they support each other’s functionality?
How do the plugins together affect the performance of your system?
These are just some major topics to give you a first idea of what you should be aware of if you search and install plugins.
Don’t enable “Lab-Features” or “Darkfeatures”
If you are using Atlassian products already for a while, you may have stumbled across the term “darkfeature” or “lab-feature”. Those features are new features in beta-status that could be enabled via a hidden configuration. Darkfeatures become new features in one of the next versions of the product. But as long as they are not officially introduced they are not finally developed and therefore are not secure to use.
At this place we will neither describe in detail how to enable specific darkfeatures nor will we give you a list of darkfeatures for any tool of Atlassian as Atlassian themselves do not provide such a list.
Our recommendation for this topic is simply: Don’t use darkfeatures in your productive system.
Conclusion
In this blog post we have handled the topics:
Network and Server Security
Installation and Configuration Security
As you have seen, the Atlassian tools are quite secure if you follow the recommended guidelines and best practices. If you have a basic security awareness and no special risk scenarios you will probably be on the safe side. However, we pointed out some tweaks to optimise your system security. You should be aware of all the issues and, together with your protection needs, you can configure your system as securely as required.
In the next blog post you will learn which specific topics you should be aware of when you configure your JIRA and Confluence instances. We will have a closer look at user and permission management, shared filters and dashboards in JIRA for example and the problems that could occur with space and page restrictions in Confluence.
(c) 2017 mgm technology partners. This posting "Network and Server Security for JIRA and Confluence - Security around Atlassian Systems, Part 1" is part of the mgm technology blog. The author of the posting is
Benjamin Weinheimer and Björn Kirschner.
We are hiring! mgm technology partners is looking for good software engineers for all our offices. Check out www.mgm-tp.com/karriere.