Sonatype Nexus Security Best Practices

Sonatype Nexus Repository Manager eliminates friction between DevOps teams and allows them to ship secure software faster while increasing efficiency and quality. While this open-source repository comes with extensive capabilities such as role-based access control and caching, it is essential to make your instance of Nexus Repository Manager (NXRM) secure to prevent your software from security attacks.

Here are some of the security best practices you should follow to protect your mission-critical artifacts from attacks.

Host Operating System

Your NXRM instance works on any Windows, Linux, or Macintosh operating system that can run a supported Sun/Oracle Java version. However, the best-tested system that works well with Nexus is Linux. For the latest Nexus version (2.4.11+), Sonatype recommends the latest Java 8 version.

When installing and running the repository manager, provide a dedicated user account specific to the operating system. The NXRM process user must have the permissions to create a valid shell. Also, prevent running the Nexus as a root user as it poses security risks to the host OS. Instead, create a service-specific user and provide only the rights required for that user.

It is also vital that you increase the available file handle limits to 65536 or higher than the default value provided by your operating system. This avoids potential errors at the runtime. The file handle limit adjustments are only required for Linux and macOS. Find out how you can increase the limit through the NXRM documentation.

Also, your NXRM instance requires Java Cryptography Extension (JCE) to run features like Secure Central and Smart Proxy. JCE installation ensures stronger encryption algorithms. If you see the following in your log, it indicates that Nexus requires the JCE.

java.security.InvalidKeyException: Illegal key size

Download the JCE here.

Installation Dependencies

Installation methods

You can install NXRM instance either through a distribution archive or through a Docker container. Installing and running the NXRM with container reduces the surface attack area. Without containerization, a successful malicious attempt to exploit the service can damage other services running on the host. With containerizing, this attack restricts to the container running that service. You can access NXRM docker images here.

Running NXRM as a service

For production use, the Nexus Repository Manager must be configured to run as a service. As a security measure, always run that nexus service or daemon as a specific user that has only the rights that are actually required. If you are installing the NXRM instance with a docker container, you need not require a service configuration. However, if you are using a distribution archive, you will have to configure the service manually. Find out the configuration procedure for Linux, Mac OS, and Windows here.

Application

Change password

Once the installation is complete, the very first step is to change the default admin password to ensure that your instance begins with a secure state. NXRM generates a unique random password during the initial setup process and stores it in a file called admin.password located in the data directory.

Configure anonymous access

At this stage, it is also essential to configure access for anonymous users. Without configuring this setting, NXRM allows all unauthenticated users to read the contents of repositories. As a security best practice, uncheck the Allow anonymous users to access the server checkbox during the initial setup.

Set up an SMTP server

It is a good practice to configure an SMTP server to receive emails from Nexus. You can do this by opening SMTP settings under the Email Server menu and adding details such as host, port, username, and password.

Set up routing rules

Create routing rules to prevent your NXRM instance from making specific requests to upstream repositories. For example, you can prevent leaking names of internal projects or external registries so that malicious users cannot perform name hijacking attacks.

Configure backup

Develop a backup and restore procedure to store your NXRM databases and system configurations securely. The system allows you to perform backup for data stored in Blob Store as well as a database backup. Detailed steps to back up your NXRM are available on the Nexus documentation.

Use SSL communication

Using SSL for inbound and outbound communication with NXRM is one of the vital security best practices. For inbound communication, SSL integration may include HTTPS access to the user interface, tool access to repository content as well as usage of REST APIs.

For outbound communication, SSL can be integrated with a remote proxy repository over HTTPS, SSL/TLS serves for email servers, and LDAP servers configured to use LDAPS.

Refer to the Nexus Repository Manager documentation to know how to configure SSL with your instance.

Permissions

NXRM uses role-based access control to help administrators gain control over user rights through three security concepts: Privileges, Roles, and Users. As a security best practice, specify roles for each user and avoid giving all privileges to all the users. The following are the default roles you can assign to users.

• Anonymous role: with read privilege
• Developer role: Anonymous role + upload privilege
• Team Lead role: Developer role + create and upload privilege
• Build machine role: Developer role + read privilege + read to QA repository privilege

In addition to the standard roles, you can even take advantage of Content Selectors, which is another security feature that allows giving specific users the privilege to access different pieces of repository. Along with Content Selectors, you can also use Realms to bind NXRM to LDAP and allow the users to authenticate their credentials using their corporate ID and password.

Monitoring

One of the best ways you can monitor your NXRM instance for performance, anomalies, and security risks through the Repository Health Check feature. Use the tool to identify which components in your repository manager need an upgrade or replacement. Find and prioritize vulnerable components by severity and impact through details on the number of times the component was downloaded from the repository.

Known Vulnerabilities

The following are some of the known vulnerabilities in NXRM versions. Get the complete list here.

• CVE-2019-16530 – Nexus Repository Manager 2 & 3 – Remote Code Execution
• CVE-2019-15893 Nexus Repository Manager 2 – Remote Code Execution
• CVE-2019-5475 Nexus Repository Manager 2 – OS Command Injection
• CVE-2019-14469 Nexus Repository Manager 3 – Cross Site Scripting XSS
• CVE-2019-7238 Nexus Repository Manager 3 – Missing Access Controls and Remote Code Execution
• CVE-2018-16621 Nexus Repository Manager 3 – Java Injection

References:

https://help.sonatype.com/repomanager3/security

https://help.sonatype.com/repomanager2/repository-manager-best-practices

https://blog.sonatype.com/how-to-use-the-new-repository-health-check-2.0

https://support.sonatype.com/hc/en-us/sections/203012668-Security-Advisories