Security Addendum 2010-04-16 - Preventing security attacks
In April 2010, JIRA sites were attacked via security vulnerabilities in JIRA. These vulnerabilities will be fixed in JIRA 4.1.1, and patches are available for earlier versions of JIRA.
For more information:
- about these vulnerabilities and patching your JIRA instance, see JIRA Security Advisory 2010-04-16
- on how to determine whether your public JIRA instance has been compromised please refer to the detection guide.
To the best of our knowledge, the following guidelines will help prevent attacks of the kind recently experienced.
1. Use Strong Passwords
1.1 Administrators should use Strong Passwords
All your JIRA administrators, JIRA system administrators and administrators of all Atlassian products should have strong passwords. Ask your administrators to update their passwords to strong passwords.
Do not use passwords that are dictionary words. Use mixed-case letters, numbers and symbols for your administrator passwords and make sure they are sufficiently long (e.g. 14 characters). We encourage you to refer to the Strong Password Generator for guidelines on selecting passwords.
Using strong passwords greatly increases the time required by an attacker to retrieve your passwords by brute force, making such an attack impractical.
1.2 Administrators should have Different Passwords for Different Systems
As well as choosing a strong password, administrators should have different strong passwords for different systems.
This will reduce the impact the attacker can have if they do manage to obtain administrator credentials on one of your systems.
2. Apply JIRA Security Patches
Apply the patches found in JIRA Security Advisory 2010-04-16 for your version of JIRA.
These patches protect JIRA from recently detected privilege escalation and XSS vulnerabilities.
3. Protect Against Brute Force Attack
You can also actively protect your systems against repeated unsuccessful login attempts, known as "brute force" login attacks.
3.1 Upgrade to JIRA 4.1
JIRA 4.1 contains built-in protection for brute force attacks by displaying a CAPTCHA after a number of failed authentication attempts.
In JIRA 4.1.1 this option is enabled by default. (Please refer to the JIRA 4.1.1 Upgrade Guide for details.) To enable this protection in JIRA 4.1, log in as an administrator and navigate to Administration -> General Configuration and set the "Maximum Authentication Attempts Allowed" to a small number (e.g. 5).
For more details, see Configuring JIRA Options.
3.2 Enable Brute Force Login Protection on your Web Server
It is possible to also enable brute force login protection on your web server by detecting repeated authentication failures in application logs. Once repeated login failures have been detected, you can set up an automated system to ban access to your web server from that particular IP address.
For more information on how to configure an automated approach to this kind of login prevention, refer to Using Fail2Ban to limit login attempts.
4. Restrict Network Access to Administrative Sections of Applications
An Atlassian application's administration interface is a critical part of the application; anyone with access to it can potentially compromise not only the application instance but the entire machine. As well as limiting access to only users who really need it, and using strong passwords, you should consider limiting access to it to certain machines on the network.
For more information on how to implement Apache blocking rules to restrict access to administrative or sensitive actions in:
- JIRA, refer to Using Apache to Limit Access to the JIRA Administration Interface
- Confluence, refer to Using Apache to limit access to the Confluence administration interface
You can use a similar approach to protecting all Atlassian applications.
5. Restrict File System Access by the Application Server
The application server (e.g. Tomcat) runs as a process on the system. This process is run by a particular user and inherits the file system rights of that particular user. By restricting the directories that can be written to by the application server user, you can limit unnecessary exposure of your file system to the application.
For example, ensure that only the following directories can be written to by JIRA's application server:
- The following subdirectories of your JIRA Installation Directory for 'recommended' JIRA distributions (or for JIRA WAR distributions, the installation directory of the Apache Tomcat application running JIRA):
- Your JIRA Home Directory.
For detailed instructions, please see Tomcat security best practices.
6. Disable Jelly
Jelly is disabled in JIRA by default. If you need to use Jelly, you should enable it immediately prior to use and disable it immediately afterwards. See the JIRA Jelly Tags documentation for details.
Was this helpful?
Thanks for your feedback!