Safeguard Your Hub Installation

Documentation is an important part of your security plan. If your Hub administration changes hands, the new administrator shouldn't have to learn how the application is configured through trial and error. As you follow this guide to secure your Hub environment, make a note of each change and explain why you set it up the way you did. When done, collect your notes and add them to your information security policy documentation.

To ensure that your installation includes the most recent security enhancements, make sure you always use the latest version of Hub. To make sure you haven't missed an important update:

• Subscribe to announcements for major releases on the Hub blog.

• Follow Hub on Twitter for minor updates.

To prevent accidental disclosure, we usually restrict the visibility to issues that are classified as a Security Problem to members of the JetBrains team. You may see issues in the Security Problem section of our release notes, but this is by no means a comprehensive list of security-related issues that have been fixed in any given release.

For this reason, we strongly recommend that you update your installation to the latest version as soon as possible.

As a web-based application, registered users can connect to Hub from outside your network. Any server that is exposed to the Internet is vulnerable to hackers who can destroy data, encrypt data and hold it for ransom, or steal your secrets. We recommend that you install Hub in a trusted environment that is protected by a firewall. Your firewall rules should not allow traffic without any business justification.

Follow these guidelines to ensure the security of your installation:

• Restrict access to database files to prevent users or other processes from modifying or deleting your Hub data.

• Install security updates for the operating system as well as third-party software that is connected to your installation.

• Use firewall rules to allow traffic only through ports that are required for inbound network connections.

To secure communication over your network, you should either use built-in TLS or install Hub behind a reverse proxy server that provides SSL encryption. All of your traffic is then encrypted using HTTPS (HTTP over SSL/TLS).

When users log in to Hub with an authentication modules that does not support SSL/TLS encryption (for example, the Hub authentication module), the password is transmitted in plain text. If you don't use HTTPS, a packet sniffer can intercept and log this traffic and compromise your passwords. To protect your accounts, use a reverse proxy to secure all of your connections using HTTPS (HTTP over SSL/TLS).

For detailed information, see Secure the Connections to Your Hub Server.

You should always use a dedicated user account to run Hub on your server.

• For MSI installations, Hub creates a dedicated service user account with the name JetBrainsHub during installation. By default, this account only has access to the Hub installation and home directories.

  If you change the user account that runs the Windows service, this account should have limited access as well.

• For ZIP and JAR installations, the Hub service is run by the user who enters the command to start the application. This should be a user account that was created specifically to run Hub. Limit the access rights that are available to this account at the operating system level to protect critical parts of the system. This should be a non-privileged user that only has access to the Hub installation and home directories.

Hub stores passwords in the database as salted hashes. Each user's password is hashed with a different, randomized salt. The salted passwords are hashed using the SHA-256 cryptographic hash function.

The Hub database, however, is not encrypted. To ensure that your data is secure, we recommend that you apply filesystem-level or full disc encryption to the server that runs Hub. You should apply encryption to any backup copies of the database that are stored on the server as well.

You should not only secure access to Hub over HTTPS, but secure the data that is exchanged between Hub and the web services that are connected to it. Obtain an SSL certificate for each external service and import the certificates into Hub.

• You should import trusted SSL certificates for any external application that is integrated with Hub. For more information, see Trusted SSL Certificates.

• You should also have an SSL keystore that identifies Hub as a client when it tries to connect to a third party. For more information, see SSL Keys.

The following integrations can be configured to establish a secure connection using SSL:

• LDAP Auth Module

• Atlassian Jira Auth Module

You should also use a digital certificate to secure the connection to the SMTP server that sends email notifications from Hub. For more information, see SMTP.

Hub supports two-factor authentication (2FA). Many of the third-party authentication modules that are supported in Hub also support 2FA. Hub lets you require 2FA for every member of your organization. Users can choose to protect their accounts with app-based or token-based 2FA.

• With app-based 2FA, users must use an external app to generate an authentication code, which they must then enter when they log in with their password. This adds an extra layer of security. Even if a password is compromised, the malicious user cannot access the application without the authentication code from the external app.

• With token-based 2FA, users pair their Hub account with a hardware device. Users must have this hardware device in their possession when they log in.

When you require 2FA for one or more groups, the information that is accessible to members of these groups is subject to an additional layer of protection. To learn how to enable this feature, see Require Two-factor Authentication.

If you're using third-party services for authentication and don't require 2FA, you can't guarantee that every user sets it up. Or uses a strong password.

Here's what you do know:

• Many users don't create unique passwords for each of their accounts.

• Most passwords are extremely weak and easy to guess.

• An attacker only has to guess one weak password to gain access to your system.

The Hub authentication module lets you ensure that users create passwords that keep your data safe. If you use this module to manage logins, we recommend that you set the Password Strength to Good or Very Strong. For more information, see Set a Password Policy.

Asking users to verify their email addresses ensures that your users confirm ownership of their accounts. This is especially important when you let users register their own accounts.

For Hub installations that are connected to YouTrack, email verification can be especially important. YouTrack supports features like the Mailbox Integration that creates user accounts from incoming email messages and the Zendesk Integration that can create accounts when importing tickets. The option to require email verification prevents users from registering accounts that can be used to gain unauthorized access to Hub and other applications in your business environment.

The option to require email verification is located on the Auth Modules > Common Settings page in Hub. For more information, see Common Settings for Auth Modules.

The Hub authentication module lets users register their own accounts in Hub. If you allow self-registration and your installation is accessible from outside your network, you should protect your installation from registration bots. These bots can consume resources and claim licenses that are intended for use by humans.

To block registration bots, enable reCAPTCHA in the Hub authentication module. For more information, see Hub Authentication Module.

Throttling or rate limitation helps protect the application from brute-force attacks. The common settings for authentication modules let you apply rate limits to logins and requests to verify credentials.

Rate limits help slow down brute-force attacks by blocking new login requests for a short time following a series of consecutive login failures, so they keep your passwords safe. When used in combination with reCAPTCHA, legitimate users can bypass the throttling by solving a CAPTCHA-based challenge. For more information, see Throttling Settings.

All of the operations in Hub are managed by a permission scheme. Permissions are assigned to a collection of roles, which are then granted to users and groups for a specific project. Users only have permission to perform the operations that are allowed for the role that they are assigned in each project.

If you are overly-generous with granting permissions, you expose your system to high risk from insider threats. It also gives external hackers access to sensitive data as soon as any of your accounts is compromised.

We recommend that you follow the principle of least privilege and only grant access to the information and resources that are absolutely necessary to perform the operations that are required for each user. Start small, then go bigger — but only with good reason. Follow these guidelines to prevent unnecessary access to sensitive data:

• Grant as little access as necessary to new accounts, then add permissions if necessary.

• Revoke access when it is no longer required.

• Delete or ban unnecessary user accounts.

• Avoid the auto-join groups option if user registration is enabled in the Hub authentication module.

• Limit the permissions that are available to the Guest user account.

• Grant roles with very limited permissions to the All Users and Registered Users groups.

• Limit the number of users who are assigned roles in the Global project.

• Use as few accounts with System Admin roles as possible and monitor their activity.

To protect your installation against ransomware and recover from hardware or software failure, make sure your Hub database is included in your backup plan.

• Enable regular backup of your Hub database For more information, see Backup.

• Test backups by restoring your system to make sure the process works. For more information, see a page related to your distribution type:

  • Restore a Docker Installation

  • Restore a ZIP Installation

• Keep copies of recent backups off premises.

• Make sure your backups are secure and encrypted.

You set the username and password for the default administrator account when you install Hub on your server. This account has permission to perform any operation in Hub.

One of the most common problems detected by risk and security audits is an administrator account that is not tied to a specific individual. You might be tempted to create a simple username and password combination and share the default administrator account with more than one administrator. Don't.

• Shared accounts are often used to gain uncontrolled access to systems.

• Audit events and logs are rendered useless when you cannot associate a change with a specific individual.

• Administrator accounts have unlimited access and should use the strongest possible passwords.

Follow these guidelines to secure your default administrator account:

• After initial setup, create personal user accounts for each administrator and grant them the required level of access. Administrators should use their own accounts to perform administrative tasks.

• Limit the number of accounts with administrative access rights to the users who require this level of access.

• Require that users with administrator privileges use strong passwords and change them periodically.

• Revoke administrative access as soon as it is no longer required.

• Manage ownership of the default administrator account carefully. If the user who is responsible for this account leaves your organization or is no longer responsible for the application, select another user to assume ownership and transfer this responsibility. If the previous administrator no longer requires access to Hub:

  • Use the Merge User operation to combine these two user accounts. For more information, see Merge User Accounts.

  • Remove the login credentials for the previous administrator from the merged user account.

  If the previous administrator still requires access to Hub in a non-administrative role:

  • Create a new user account for the previous administrator and grant the appropriate level of access to the account.

  • Use the Merge User operation as described above to transfer ownership of the default administrator account to the new administrator.

Hub provides tools that let you monitor your application for suspicious activity.

• The Audit Events page provides a list of events, targets, and authors for every event that is logged in Hub. These events are recorded every time an operation is applied to a target entity. This includes changes that are applied to users, groups, projects, roles, auth modules, services, and resources, among others. You can filter the list to search for specific types of activity or download the events as a JSON file for further investigation.

• Events that are considered to be security-related are printed to a dedicated security.log file. This file contains a wider range of events and target entities.

• Login events are printed to a dedicated hub-login.log file.

You can browse the audit events and security logs to detect unusual activity or for troubleshooting. However, if your organization uses security information and event management software, a much better solution is to include your Hub log files as a data source. These solutions let you scan and analyze aggregated log files and generate alerts when a suspicious pattern of activity is detected.

Follow these guidelines to secure your log files:

• Ensure that only individuals who have a job-related need have access to the data directory where you store your Hub log files.

• Create backup copies of your Hub log files on a centralized log server.

If you store sensitive information in your issues, take extra efforts to make sure this data is secure.

• Use dedicated projects to store issues that contain information that can be used to identify a person.

• Make sure the users who have access to issues in this project understand the sensitivity of this information.

• Restrict project access to the users who need to view and use this information.

By default, all Hub installations include a dedicated user account for guests. While this account isn't granted any roles in Hub, it can be allowed limited access in connected services like YouTrack. If your installation is accessible from outside your network, anyone who knows your server address can use the guest account to browse issues and code in your projects without having to log in.

If you wish to limit or block anonymous access, you have the following options:

• You can revoke the role that is assigned to the guest account in the Global project. We generally discourage granting roles with update permissions to the guest account, as these actions cannot be associated with an individual.

• You can ban the guest account. All users are required to log in to view issues with a registered account. Access to each project is determined by the roles that are assigned on a per-user or per-group basis.