Sonatype FAQs

Note: This information is now maintained on the Sonatype Help site. To view the most recent list of available formats for Repository Manager 3, please see formats.

When the Nexus CLM Plugin sends a health check request to Sonatype servers, it uses a unique ID to identify your Nexus instance. You may be asked for this Nexus ID from Sonatype Support staff in case you are experiencing problems with the plugin.

Nexus Professional

Refer to the screenshot to find out where this ID value is visible in the Nexus Pro user interface (note: In some versions this plugin is called the "Nexus Health Check (Pro) Plugin" or "Nexus IQ Plugin"):

Nexus OSS

Nexus OSS requires a more involved process to find the ID.

1) Edit sonatype-work/nexus/conf/logback-nexus.xml and add the following line after the other loggers:

<logger name="com.sonatype.nexus.plugins.healthcheck.service" level="DEBUG" />

2) After the change takes effect ( 60 seconds ), and an analysis is performed on a repository, look for lines like the following:

2013-07-05 09:48:03 DEBUG [pxpool-1-thread-1] admin com.sonatype.nexus.plugins.healthcheck.service.impl.InsightServiceImpl - Calling into server (https://rhc.sonatype.com/rest/rhc/scan/2425fdaabcb641068bd0f69466712345/central?timestamp=2013-07-05_12:48:03) with PUT

The2425fdaabcb641068bd0f69466712345 is the Nexus ID in this case.

Application Components that are similar, but not identical to known/catalogued components can produce "similar" matches in an Application Report, which usually result in a "Component-Similar" policy violation. Such policy violationsare caused by a component with a " Similar Match ". Unexplained similar matches should be treated as a serious problem by the development team, because it could mean the application is using a maliciously altered copy of a component.

Checksum Sanity-check:

If the reason for a similar match is not immediately obvious, start by manually downloading the component in question, and then comparing the sha1 hash of the manually downloaded file to that of the similar-matched component file. The "Occurrences" tab in the CIP will help you locate the similar matched file in your build. If the checksums are different, the component is indeed different from the "official" version. The challenge now is to explain why they differ.

Common causes:

New component version / Missing component version -One indicator that a Similar match is due to a "new component version" is the version graph in the CIP shows no (or very few) version(s) newer than the detected similar version. Typically the new version of a component is very similar to previously cataloged versions, but is not identical to any version we've cataloged before. New component versions are automatically identified, but it is possible some could get missed. Reporting such an issue to product support is the best way to ensure it is corrected.

Repackaging / Signing of the component - If your build is repackaging (e.g. unpack, tweak stuff, repack) the component, this would result in a similar match because the end component is different. Jar signing is an example of such an alteration. The solution here could beto evaluate your application before such alterations are made. It is also possible your build has downloaded an already altered component from someplace else. If so, the source of the component should be verified, and possibly changed to use an "official"/"unmodified" component.

Similar match components can also affect policy violation notifications. Policy Violation notifications are only sent when "new" violations occur. Since "similar" matches are different from the official component, they are treated as "new" components, and as such will trigger new policy violations. This can be confusing ifa build alters a component every time the build is run, resulting in a new policy violation notification that looks identical to prior notices. The policy violated column in the email list of violations (the first column) will likely showthe"Component-Similar" policy.

Docker Repository + Reverse Proxy Intended Use Case

Using a reverse proxy in front of Nexus for Docker repositories is an option to consider for the following use cases:

multiple connectors inside of Eclipse Jetty/Nexus would cause performance issues

the number of open ports needs to be limited for infrastructure or security reasons

managing secure connectors/ports/hosts inside an external reverse proxy aligns with organizational goals and infrastructure

isolating private docker images from other parties is a requirement

Implementation Overview

Nexus would be listening at a non-https connector such as the default 8081.

Docker repositories are added into Nexus as normal but would NOT be configured with any connector port values.

In the simple case there would be the following docker repository hierarchy inside Nexus per project team:

docker-group-project

docker-hosted-project

docker-hub

Based on the host name or port of the request to a reverse proxy, the reverse proxy decides where to reverse proxy the request into Nexus.

Docker Push Port Mapping Example

docker login project.example.com:8086

docker push project.example.com:8086

The reverse proxy would direct docker push commands received at

https://project.example.com:8086

to

http://locahost:8081/repository/docker-hosted-project

Docker Push Host Mapping Example

docker login project-push.example.com

docker push project-push.example.com

The reverse proxy would direct docker push commands received at

https://project-push.example.com

to

http://locahost:8081/repository/docker-hosted-project

Docker Pull Port Mapping Example:

docker login project.example.com:8087

docker pull project.example.com:8087

The reverse proxy would direct docker pull commands received at

https://project.example.com:8087

to

http://locahost:8081/repository/docker-group-project

Docker Pull Host Mapping Example:

docker login project.example.com

docker pull project.example.com

The reverse proxy would direct docker pull commands received at

https://project.example.com

to

http://locahost:8081/repository/docker-group-project

Limitations

Nexus does not support using thedocker pushcommand against group Docker repositories until something like NEXUS-10471 is implemented. Therefore docker push commands must refer to a URL that is mapped to a hosted docker repository, while docker pull commands should point to a URL that maps to a Docker group repository containing that hosted repository.

A wildcard TLS certificate is needed for the host name mapping scenario, if you intend to have more than one project team specific host name.

Shut down nexus, and backup your < Nexus Data Directory >/db

Access the OrientDB console using these instructions.

Run the following command:

connect plocal:../sonatype-work/nexus3/db/security admin admin

You may need to adjust the path used in the connect statement depending on the location of your nexus data directory. It should be the path to the "db/security" directory in your data directory. An absolute path may be used.

After the connect command succeeds, checkthat the admin user exists:

select * from user where id = "admin"

If the admin user does exist, issue this command in the console to update the admin user password to the default value:

update user SET password="$shiro1$SHA-512$1024$NE+wqQq/TmjZMvfI7ENh/g==$V4yPw8T64UQ6GfJfxYq2hLsVrBY8D1v+bktfOxGdt4b/9BthpWPNUy/CBk6V9iA0nHpzYzJFWO8v/tZFtES8CA==" UPSERT WHERE id="admin"

If the admin user does not exist, then issue the following two INSERT commands in the console to insert the admin user and roll mapping:

INSERT INTO user (status, id, firstName, lastName, email, password) VALUES ('active', 'admin', 'admin', 'admin', '[email protected]', '$shiro1$SHA-512$1024$NE+wqQq/TmjZMvfI7ENh/g==$V4yPw8T64UQ6GfJfxYq2hLsVrBY8D1v+bktfOxGdt4b/9BthpWPNUy/CBk6V9iA0nHpzYzJFWO8v/tZFtES8CA==')

INSERT INTO user_role_mapping (userId, source, roles) VALUES ('admin', 'default', 'nx-admin')

The query language is sql-like, but it is not SQL. See the OrientDB Command Reference.

At this point, the admin user should be able to authenticate if the default security realms are in still in place. Verify you can login as the admin user using your web browser.

Optional, if the admin user still fails to authenticate: If the default security realms were removed from the active list, the default admin user will still not be able to authenticate, despite resetting the password. To reset the default security realms, enter this command at the karaf prompt:

delete from realm

After this command succeeds and Nexus is restarted, the default security realms will be activated and any custom activated realms will have been removed. An admin user will then have to add back in any other security realms they had previously ( such as LDAP) using the Realms UI, to allow other users to authenticate.

Optional, if the admin user is missing the "nx-admin" role:

Check to see what roles the "admin" user has assigned to them:

select * from user_role_mapping where userID = "admin"

If they are missing "nx-admin" use this command at the karaf prompt to fix:

update user_role_mapping set roles = ["nx-admin"] where userID = "admin"

Optional, check to see if the admin user is active:

Check to see if the "admin" user is active:

select status from user where id = "admin"

If they are not active, use this to make them active:

update user set status="active" upsert where id="admin"

To end the console session gracefully type "exit".

Start Nexus again using ./bin/nexus start or your regular service control command.

What is the OrientDB Console

Nexus 3 uses several OrientDB databases. In very specific circumstances, these databases can be manipulated as advised by Sonatype support.

This article describes how to openaspecial command-line interface for connecting to and working with the databases used by Nexus. This interface is known as the OrientDB Console.

Caution: Using the console incorrectly can cause irreparable harm to the databases.

Launching the OrientDB Console on Nexus 3.2.1 andNewer

Nexus 3.2.1+ includes a single jar executable which can launch the OrientDB console.

As the operating system useraccount that typically owns the Nexus Repository Manager process, starta terminal session on the host where Nexus is installed.

Change directories to your application directory.

Launch the console using the same version of Java executable that Nexus is using :

Unix

java -jar ./lib/support/nexus-orient-console.jar

Windows

java -jar lib\support\nexus-orient-console.jar

Mac

.install4j/jre.bundle/Contents/Home/jre/bin/java -jar ./lib/support/nexus-orient-console.jar

You should be presented with a command-line interface such as this, ready to accept your commands:

OrientDB console v.2.2.16 www.orientdb.com

Type 'help' to display all the supported commands.

orientdb>

When you are done your commands, type exit to quit the console.

The nexus-orient-console.jar sets up the correct classpath to successfully launch the console. Launching the jar from another location is not supported.

Accessing the OrientDB Console in a DockerContainer

If you normally run Nexus in a Docker container with something like the following:

docker run -d -p 8081:8081 --name nexus -v /some/dir/nexus-data:/nexus-data sonatype/nexus3

Then you should be able to get access to the shell as follows:

docker run -it -p 8081:8081 --name nexus -v /some/dir/nexus-data:/nexus-data sonatype/nexus3 /bin/bash

This is basically just running the same container with the same volume arguments but in interactive mode and telling it to start the shell instead of Nexus. Once in the shell, then follow the regular instructions to run the OrientDB console.

What is HTTP Strict Transport Security (HSTS)?

HSTS is a standard intended to encourage web browsers to only transmit requests securely using https to a given host name. This feature can prevent accidental transmission of sensitive data to a plain http endpoint at the same host name by web browsers which support it.

Build tools do not typically support HSTS, however they will not break either if the server sends indication that the server supports it.

Enabling HSTS in NXRM 3.20.0 or Newer

When TLS connections are terminated by NXRM directly through Eclipse Jetty configuration, HSTS is already enabled by default.

If you are terminating HTTPS connections to NXRM using a reverse proxy, you must configure your reverse proxy to enable or disable HSTS. Instructions for doing that are beyond the scope of this article.

How to Disable HSTS in NXRM 3.20.0 or Newer

Edit${karaf.data}/etc/nexus.properties

Add a line containing

jetty.https.stsMaxAge=-1

Save the file and restart NXRM.

How To Enable HSTS in NXRM 3.19.1 or Older

Edit${jetty.etc}/jetty-https.xml.

Change the section that looks like this:

<New id="httpsConfig" class="org.eclipse.jetty.server.HttpConfiguration"> <Arg><Ref refid="httpConfig"/></Arg> <Call name="addCustomizer"> <Arg><New class="org.eclipse.jetty.server.SecureRequestCustomizer"/></Arg> </Call> </New>

To this:

<New id="httpsConfig" class="org.eclipse.jetty.server.HttpConfiguration"> <Arg><Ref refid="httpConfig"/></Arg> <Call name="addCustomizer"> <Arg> <New id="secureRequestCustomizer" class="org.eclipse.jetty.server.SecureRequestCustomizer"> <!-- 7776000 seconds = 90 days --> <Set name="stsMaxAge"><Property name="jetty.https.stsMaxAge" default="7776000"/></Set> <Set name="stsIncludeSubDomains"><Property name="jetty.https.stsIncludeSubDomains" default="false"/></Set> <Set name="sniHostCheck"><Property name="jetty.https.sniHostCheck" default="false"/></Set> </New> </Arg> </Call> </New>

For justification of 90 day max age default, see https://letsencrypt.org/2015/11/09/why-90-days.html.

Save the file and restart NXRM.

See this issue https://issues.sonatype.org/browse/NEXUS-20268

Repository Manager Does Not Start if Referencing jetty-http-redirect-to-https.xml

On upgrade, it may be noticed that NXRM will not start if the file jetty-http-redirect-to-https.xml is referenced. Logs will contain a message including text such as:

ERROR *SYSTEM org.sonatype.nexus.bootstrap.jetty.JettyServer - Start failedjava.io.FileNotFoundException: etc/jetty/jetty-http-redirect-to-https.xml (No such file or directory)

Cause

As of Repository Manager 3.20.0, this file has been removed from our distribution.

Solution

Evaluate if you need the unsafe feature exposed by this file.

If not, edit your nexus.args property value defined in your nexus.properties file, and remove the reference to jetty-http-redirect-to-https.xml.

If you still need this feature despite the risk of use, follow the instructions in this article to configure it.

Use Case for Redirecting HTTP Requests to HTTPS

Nexus Repository Manager has historically included example Eclipse Jetty configuration files for redirecting inbound plain HTTP requests to a configured secure HTTPS connector. The file to enable this was included at this path:

NXRM 3: <install-dir> /etc/jetty/jetty-http-redirect-to-https.xml

The aim of this feature was to ease HTTP clients and build tools to transition from using insecure URLs to more secure URLs.

Is it Safe?

Noit is not a safe practice because it can imply a false sense of security to the client.

If any plain HTTP connector is exposed to a server, a connection to it will permit the insecure transmit of sensitive information such as usernames and passwords. Essentially there is no way to prevent this transmission on the server side when using a redirect mechanism.

Follow Best Practices Instead: Use HSTS

To encourage security best practices, Nexus Repository Manager 3.20.0 and newer will no longer include a example configuration file that enables direct http to https redirects. Should you still want to use it, instructions how are included below.

As an added security measure for human web browsers, consider using HSTS instead.

How to Redirect All Plain HTTP Requests to HTTPS in NXRM 3.20.0 or Newer (Not Recommended)

Follow all the steps under How to Enable the HTTPS Connector. Make sure the nexus-args property value also includes the reference to${jetty.etc}/jetty-http.xml

Edit$data-dir/etc/nexus.properties. Change the nexus-args property comma delimited value to include${jetty.etc}/jetty-http-redirect-to-https.xml. Save the file.

Download jetty-http-redirect-to-https.xml and save it next to your existing jetty-https.xml file with identical file permissions.

Restart the repository manager. Verify all plain HTTP requests ( except TRACE as intended ) get redirected to the equivalent HTTPS URL.

When working with Repositories and Blobstores, you may want to have some insight intohow the storage space is being used.

This article provides you with a few different ways to find out where repository and blobstore space is being consumed.

Listing the Size of File-based Repositories and Blobstores

For file-based blobstores (not AWS S3), it is possible to run a script that will provide some information regarding the disk space that it being used by each Blobstore and Repository.

The groovy script to run this report can be found here: nx-blob-repo-space-report.groovy

The script can be executed as a task in Nexus Repository Manager. In the Administration pane select System > Tasks. Create a new Execute Script task. Set the Language to groovy and task frequency to Manual, copying the Source from the above link and pasting it into the provided textbox.

When you execute the task, the output within nexus.log will look similar to the following (the directories scanned will differ):

*SYSTEM Script47 - Blob Storage scan STARTED.*SYSTEM Script47 - Scanning /home/nexus/sonatype-work/nexus3/blobs/default*SYSTEM Script47 - Scanning /opt/nexus/test2*SYSTEM Script47 - Scanning /home/nexus/sonatype-work/nexus3/blobs/test1*SYSTEM Script47 - Blob Storage scan ENDED. Report at /home/nexus/sonatype-work/nexus3/tmp/repoSizes-20181213-104154.json

You should be able to find the generated JSON report at the location provided in the log:

Report at /home/nexus/sonatype-work/nexus3/tmp/repoSizes-20181213-104154.json

(The actual location will vary according to your nexus configuration)

Within the JSON report, there are details of each Blobstore and each Repository that uses the Blobstore. For example, the output below shows two Blobstores, each having a single Repository:

{ "blobstore1": { "repositories": { "repositoryA": { "reclaimableBytes": 0, "totalBytes": 4173387 } }, "totalBlobStoreBytes": 4173387, "totalReclaimableBytes": 0, "totalRepoNameMissingCount": 0 }, "blobstore2": { "repositories": { "repositoryB": { "reclaimableBytes": 0, "totalBytes": 1397598 } }, "totalBlobStoreBytes": 1397598, "totalReclaimableBytes": 0, "totalRepoNameMissingCount": 0 }}

For each Repository, totalbytes indicates how much space is being used and reclaimableBytes indicates how much space may be reclaimed by running the Compact Blob Store maintenance task.

For each Blobstore, all of the Repository entries are aggregated. totalRepoNameMissingCount will display how many assets within the Blobstore are associated with a Repository that no longer exists.

The report will also include Repositories that are empty.

Finding the Largest Blobs Within a Blobstore

1. Using a groovy script from the command line.

The groovyscript below will find the largest blobs inside a blobstore directory. Execute the script from the command line making sure dir_name points to the correct path for your sonatype-work directory. The output contains a list of blobslarger than 100M sorted by size.

long min_size = 100000000

String dir_name = '/opt/Nexus/sonatype-work/nexus3'

def ant = new AntBuilder()

def scanner = ant.fileScanner {

fileset(dir: dir_name) {

include(name: '**/blobs/**/*.properties')

exclude(name: '**/metadata.properties')

exclude(name: '**/*metrics.properties')

exclude(name: '**/tmp')

}

}

def results = [:].withDefault { 0 }

scanner.each { File file ->

def properties = new Properties()

file.withInputStream { is ->

properties.load(is)

}

long prop_size = properties.size as long;

if (prop_size > min_size) {

results.put(properties['@BlobStore.blob-name'], prop_size)

}

}

def sorted = results.sort { a, b -> b.value <=> a.value }

sorted.each{ k, v -> println "${k}:${v}" }

2. Running a repository manager task.

The groovy script below can be executed as a task in Nexus Repository Manager. In the Administration pane select System > Tasks. Create a new Execute Script task. Set the Language to groovy and task frequency to Manual, using the Source below. When you execute the task the output logged to the nexus.log will list assets larger than min_size in descending size order for each repository.

import org.sonatype.nexus.repository.storage.StorageFacet

import org.sonatype.nexus.repository.Repository

import org.sonatype.nexus.repository.storage.Asset

import groovy.json.JsonOutput

long min_size = 100000000

repository.repositoryManager.browse().each { Repository repo ->

StorageFacet storageFacet = repo.facet(StorageFacet)

def tx = storageFacet.txSupplier().get()

def results = [:].withDefault { 0 }

try {

tx.begin()

tx.browseAssets(tx.findBucket(repo)).each { Asset asset ->

if (asset.size() > min_size) {

results.put(asset.name(),asset.size())

}

}

} finally {

tx.close()

}

def sorted = results.sort { a, b -> b.value <=> a.value }

log.info(JsonOutput.prettyPrint(JsonOutput.toJson(sorted)))

}

Sonatype Nexus Security Advisory

Date: October 15th, 2019

Affected Versions: All previous Nexus Repository Manager OSS/Pro versions up to and including 2.14.14

Fixed in Version: Nexus Repository Manager OSS/Pro version 2.14.15

Summary:

An OS command injection vulnerability has been discovered in Nexus Repository Manager requiring immediate action. The vulnerability allows for an attacker with administrative access to nxrm to execute arbitrary commands on the system. We have mitigated the issue by not allowing the server to do this. This advisory provides the pertinent information needed to properly address this vulnerability, along with the details on how to reach us if you have any further questions or concerns.

This vulnerability was identified by an external researcher and has been verified by our security team. We are not aware of any active exploits taking advantage of this issue.However, we strongly encourage all users of Nexus to immediately take the steps outlined in this advisory.

The identified vulnerability can allow for the server to execute anything on the system, that the user running the server has privileges to. We are highly recommending all instances of Nexus be upgraded to Nexus 2.14.15 or later.The latest version can be downloaded from:

https://help.sonatype.com/repomanager2/download

For detailed information on upgrade compatibility, please see:

https://support.sonatype.com/entries/21701998-Sonatype-Nexus-Upgrade-and-Compatibility-Notes

Credit:

Sonatype thanksChristian August Holm Hansen @ Binary Security and Badcode & Longofo of Knownsec 404 Team forresponsibly reporting the identified issue.

Support:

If you run into any problems, or have any questions/concerns, please contact us by filing a ticket at https://support.sonatype.com.

Frequently Asked Questions:

Q: What is the risk associated with this vulnerability?

A: Nexus can be compromised, allowing an authenticated attacker to use the flaw to execute files outside the scope of the nxrm server.

Q: What preconditions must be met in order to be vulnerable?

A: An attacker must have network access to the Repository Manager instance, as well as administrative access to the Repository Manager.

Q: Are there implications associated with this advisory itself?

A: Disclosure unfortunately means bad actors may try to take advantage. While we have initially limited the information to the minimum details necessary for users to affect an appropriate fix, this merely slows down a would be attacker. As such, we are advising all organizations utilizing Nexus Repository Manager to immediately assess their individual impact and take appropriate action in response.

Q: Where can I obtain more information associated with the vulnerability?

A: At this time, and in the interest of best protecting our user community, we are limiting the information released to that absolutely required in order to assess impact and affect remediation. Please contact support for more information.

Q: Why is Sonatype making this information available?

A:This is part of a responsible disclosure process. Given NXRM is an open source project with widespread usage, notifying the user base will invariably lead to broad dissemination. We are taking a concerted and proactive approach in our outreach activities and an effort to achieve the most rapid remediation possible.

This instructions are applicable if you are already running Nexus Repository Manager 3.1.0 or newer installed or upgraded using specific instructions.If you are upgrading from a version earlier than 3.1.0, please use the alternate instructions for upgrade.

Before Upgrading

Become familiar with the basic directory structure of a Nexus Repository Manager installation. You are encouraged to stick with the standard installation layoutto make future upgrades as simpleas possible.

You will have to determine your existinginstallation data directory location. Record this value for later use.

Download the Latest Installer Archive

Download the latest installer archive for your platform from the official downloads.

Extract the newest downloaded distribution archive using the standard approach.

Preparing thenew Install

The archive distribution offers the familiarprocess of downloading and simply extracting the install archive in place. There is no graphical or automatedprocess and all commands are done inside a terminal console.

These examples use 3.2.0-01 as the new version.

tar xzvfnexus-3.2.0-01-mac.tgz

tar xzvf nexus-3.2.0-01-unix.tar.gz

7za.exe nexus-3.2.0-01-win64.zip

Comparethe nexus-3.2.0-01/bin/nexus.vmoptions file with your existingversion.

If you changed the default location of the Data Directory, then edit ./bin/nexus.vmoptions and changethe line -Dkaraf.data=../sonatype-work/nexus3to point to your existing data directory. Example: -Dkaraf.data=/app/nexus3/data

If you changed the default location of the temporary directory, thenedit ./bin/nexus.vmoptions and replace the line -Djava.io.tmpdir=../sonatype-work/nexus3/tmpto point to your preferred temporary directory.

If you adjusted the default Java virtual machine max heap memory, thenedit ./bin/nexus.vmoptions and edit the line-Xmx1200M accordingly.

If you have enabled jetty HTTPS access, make sure your etc/jetty/jetty-https.xml SSL keystore location is still available to the new install.

If you manually adjusted any other install files under ./etcyou will need to manually perform a diff between the old files and the new files and apply your changes if applicable to the new version.

Perform the Upgrade

Ensure you have taken recent backups of the existing Data Directory and any custom blobstore locations according to our recommended practices. Because of involved Upgrade steps, downgrading a NXRM version isnot supportedand will almost always result in failures. If you have issues, restore from this backup instead.

Stop your existing installusing the scripts under./bin or your operating system service.Make sure it stops completely.

Start the new installation using the scripts under./binor adjust your operating system service to use these scripts.

Review the log files for any possible issues and sign-in to the server to confirm things are working as expected.

In the case of connecting the Nexus IQ Server to a secure LDAP Server using SSL ( ldaps:// ), it is common for the LDAP server to be using a self-signed certificate that the JVM running CLM server does not yet trust. A common error message in this case is:

javax.naming.CommunicationException: your.ldaps.host:XXXX [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

In order to establish trust of this self-signed certificate, you have to import the LDAP SSL certificate into a keystore file and feed this file as the truststore to the Nexus IQ Server.

Here are the basic steps:

Determine the Java install that IQ Server is using and locate the default truststore file included with java. See our guide for how to determine the truststore file being used. Make a copy of that cacerts file to the same directory where nexus-iq-server-<version>.jar is located. Name the copy nexus-iq-server-outbound.jksso that the purpose of this file is very clear.

Get the LDAPS server certificate and save it to a PEM encoded format text file - here is one way to do this using openssl:

echo -n | openssl s_client -showcerts -connect ldaphost:636 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ldaps.pem

Import the LDAPS server PEM encoded certificate into the truststore that IQ Server will use:

keytool -importcert -file ldaps.pem -alias nexus-iq-server-ldaps-cert -trustcacerts -keystore nexus-iq-server-outbound.jks -storepass changeit

Change the command used to launch IQ Server so that the new truststore is used, as specified by additional java command line system properties:

-Djavax.net.ssl.trustStore=/<replace_with_absolute_full_path>/nexus-iq-server-outbound.jks -Djavax.net.ssl.trustStorePassword=changeit

Q. If you receive a policy violation on a component and you've determined you want to clear it from the report, is it better to mark it as not applicable, waive the violation, resolve it by changing the status.

A. If you are trying to clear a single security violation from a report then the best course of action is to change it's status. For example, for a security violation you can mark it as "not applicable" in the details view.

If you want to disable all future violations of the policy for a component then you should either waive or claim.

To disable a specific policy for a component for all current and future violations, make sure the component match is either exact or similar and then waive the violation.

To disable all policy violations for a component (current and future) you should claim it. Claiming is intended to be used in cases where a component isn't in our data and you know the component is your own. If you claim a component you won't get any further information on it from our data, because you are saying you know what it is, and you are the source of information for that component.

If the component match is "unkown" and you've determined that you have the best source of information for it then you should claim it. Once you've claimed a component you own it, and you're responsible for maintaining the information on it.

Status changes, waivers and claims apply only to the exact policy and component (as matched by checksum) where they are applied.

There are options to apply a policy waiver to "All components" or "All applications" in an organization, but these options are not encouraged. When you want to use these options, it usually means that adjusting your policy rules are a better option.

Update - Nexus IQ Server Versions 53 and Later

Nexus IQ Server version 53 introduced fine grained waivers. Fine grained waivers allow you to waive a specific violation for a component.Other violations of the same policy for a component will remain, and new violations of the policy for the component will show up in the future.

However, note that marking a vulnerability as "not applicable" silences it regardless of any change to itsseverity. A waiver on the other hand will stop only the specific violation. So if you waive a "security medium", for example, you can get a new violation if the vulnerabilities score later changes so it violates "security high".

The Nexus IQ Server requires HTTP access to Sonatype Hosted Data Services. Sometimes these outbound requests fail and examining the HTTP headers of the requests can help determine why.

Enabling Outbound HTTP Headers Debugging in the Nexus IQ Server

Caution: This configuration change may log to the application log HTTP Authorization related headers containing base64 encoded username and passwords. ( HTTP proxy credentials, Jira integration credentials, webhook credentials, etc.)

Edit config.yml. Change

"org.apache.http": INFO

to

"org.apache.http": DEBUG

"org.apache.http.wire": ERROR

Restart the Nexus IQ Server to pick up the configuration changes.

Perform a scan to trigger an outbound HTTP request to data services.

Examine the clm-server.log for the outbound HTTP request and response headers.

When you are done examining the HTTP outbound requests, change the logger back to the default levels and restart the Nexus IQ server to pick up the changes.

"org.apache.http": INFO "org.apache.http.wire": ERROR

Organizations hosting a Nexus Repository Manager instance may have firewalls or HTTP Proxy Servers which must explicitly allow access to external hosts from internal networks.

Public registries such as the Docker Hub use multiple hosts and Content Delivery Networks (CDN) to serve content and scale requests.

In order for Nexus Repository Manager to have a Docker Hub proxy repository which works correctly, repository manager must be able to have full HTTP access to the following hosts:

https://auth.docker.io

https://registry-1.docker.io

https://index.docker.io/

https://dseasb33srnrn.cloudfront.net/

https://production.cloudflare.docker.com/

This list is subject to change at the whim of Docker Inc. and is not in control of Sonatype.

If your Docker Hub proxy repository is not working correctly, you can enable outbound HTTP request DEBUG level logging to examine the requests being made from repository manager to verify that outbound requests are reaching their intended endpoint.

Symptom

Customers upgrading Sonatype Docker images or images based on them may discover that outbound TLS connections from Sonatype server products no longer work.

Sonatype server product application logs report TLS related exceptions complaining about constraints being violated.

A non-exhaustive list of examples of the messages that may be noticed are:

javax.net.ssl.SSLHandshakeException: DHPublicKey does not comply to algorithm constraints

java.security.cert.CertificateException: Certificates do not conform to algorithm constraints

Cause

Official Sonatype Docker Images are continually reviewed and updated to reflect industry best practice for security.

This can mean that image dependencies like the OS used, patch levels, and Java runtime will be updated and inherit recommended security constraints.

In the case of TLS connections failing with noted symptoms, the TLS connection being attempted are failing because the remote party does not conform to the industry best practices for secure connections.

Major Base Image Changes 2019

To improve our default docker image container security, we made changes from using CentOS to instead using the Red Hat Universal Base Image (UBI).

This change was made starting in these versions:

Nexus Repository Manager 2.14.14

Nexus Repository Manager 3.18.0

Nexus IQ Server release 69

Resolution

A serious attempt should be made to correct the remote side of the TLS connection to conform to security standards rather than weakening the minimum security requirements in general.

Workaround: Weakening Java Cryptographic Security Requirements

We realize in some cases a short term workaround may be needed until the remote side can correct its security policies.

The underlying Sonatype docker images pick up security policy enforcements of the Fedora project ( and consequently either CentOS or Red Hat Universal Base Image (UBI) ).

Fedora project sets a consistent security level for all applications, including Java based ones, using a system level java security policy file as described in this document:

https://fedoraproject.org/wiki/Changes/JavaCryptoPolicies

In the case of Java applications like those offered by Sonatype docker images, the system level file is located at:

/etc/crypto-policies/back-ends/java.config

This overriding OS level policy file may benews if you are used to adjusting java runtimesecurity policy using a JRE specific file at<java-home>/lib/security/java.security .

Adjust Java cryptographic requirements as needed using the following document, replacing mention of lib/security/java.security with/etc/crypto-policies/back-ends/java.config :

https://www.java.com/en/configure_crypto.html

This document and plugin is no longer maintained.

Problems with this article or the original plugin it refers to will no longer be addressed. This article remains only for historical purposes.

Please use the latest Jenkins server integration that Sonatype provides:

Latest Sonatype Nexus Platform Plugin for Jenkins

If you want a more recent version of this support article instead, see:

[Deprecated] Nexus IQ Plugin for Jenkins 1.x

First Setup

Plugin Installation

Before you get started, you must first download and install the Nexus Jenkins Plugin from Sonatype Downloads. Then from the Jenkins dashboard, navigate toManage Jenkins -> Plugin Manager, proceed to theAdvanced tab,and upload the downloaded HPI using the Upload Plugin form shown below.

https://github.com/jenkinsci/jenkins.git'

Configure System

Once you have the plugin installed, the next thing you need to do is configure a Nexus Repository Manager to be able to upload your build artifacts. Once again click on theManage Jenkins link from the dashboardand then theConfigure Systemlink. Under theSonatype Nexus heading selectNexus Repository Manager 2.x Server from the Add Nexus Repository Manager Serverdropdown.

Display Name is the name of the server you would like shown when selecting Nexus Repository Manager instances for build jobs. Server ID is a unique ID which is used to reference the Repository Manager in Build Pipeline scripts, it should be alphanumeric without spaces. The Nexus Jenkins Plugin uses Jenkins credentials provider to manage server credentials. To authenticate the connection, use the Add dropdown to create a credentials entry and then select it from the Credentials dropdown. After entering the information for your Nexus Repository Manager, and click theTest Connectionbutton to ensure connectivity to your Nexus Repository Manager installation.

Tool Configuration (Optional)

For the following example you'll use Maven to build in your project. In order to do so, you need to ensure that you have a Maven installation configured in Jenkins. To do so, navigate to theManage Jenkins -> Global Tool Configurationand configure a Maven installation as shown below.

Freestyle Build

Freestyle Build Step Configuration

The Nexus Jenkins plugin supports traditional Freestyle jobs. For this example we will build Jenkins within Jenkins (inception!) and publish it to our local Nexus instance setup in the previous steps. To start, create aFreestyle Project by clicking on theNew Item link on the Dashboard. Give the project a name and clickOK to continue with the configuration.

Setup the Freestyle project as you would normally, in this example we will use Git as our SCM.

Add a build step forInvoke top-level Maven targets and configure maven to build Jenkins as the first step.

Nexus Repository Manager PublisherConfiguration

Using the Add build step dropdown, selectNexus Repository Manager Publisher to add a step to publish your artifacts. This step should occur after the build so that the binaries are available for upload. Once adding the step, configure the Nexus Instance by selecting the Display Name configured in the first steps. Once the instance is selected, you should see a list of all repositories your authenticated user has access to in theNexus Repositories dropdown. Select a repository which has Release Repository Policy and allows for Artifact Uploads.

Once a repository is selected, you can select Packages to publish to Nexus Repository Manager during your Freestyle build. Packages are synonymous to Maven artifacts, a group of binaries (jar, -sources.jar) which are described by a component identifier (GAV).

For this example, use theAdd Package dropdown to select aMaven Package. Fill in the Group, Artifact, and Version fields. You will notice the Packaging field is freeform but will provide autocomplete for traditional Maven packages. In this example we will want to publish the Jenkins war and will select war for the package. Lastly, use theAdd Artifact Path dropdown and selectMaven Artifact. This allows you to select the artifacts to upload for this particular GAV. Jenkins builds the war to war/target/jenkins.war which we will use for theFile Path.

Finally save the changes and launch a build for your project. Once the build has finished you should be presented with output similar to what's shown below.

Returning to our Nexus instance, we can see the Jenkins war is now available in the Releases repository.

Pipeline Build

Pipeline Build Step Configuration

Jenkins Pipeline builds allow for precise control and configuration over your build process. In this example we will, again, build Jenkins within Jenkins and publish to our local Nexus Repository Manager instance. Some of the configuration steps will be repeated from theFreestyle build instructions, so feel free to skim over parts that you have already read. To start, create aPipeline job by clicking on theNew Item link on the Dashboard. Give the project a name and clickOK to continue with the configuration.

Pipeline jobs allow you to configure the job via a Groovy script. The script is editable in the section with the Pipeline header.In this example we will use the sampleGithub + Maven script by selecting this option fromthe dropdown that readstry sample Pipeline...

Once the sample script is selected, the text area will be populated with the Preparation, Build and Results stages. Note that the Preparation stage makes reference to the M3 Maven tool which we setup in the Tool Configuration (Optional) step of this documentation. Below is the script with the Jenkins GitHub repository substituted for the sample repository.

node {

def mvnHome

stage('Preparation') {

git ' https://github.com/jenkinsci/jenkins.git'

mvnHome = tool 'M3'

}

stage('Build') {

if (isUnix()) {

sh "'${mvnHome}/bin/mvn' -Dmaven.test.failure.ignore clean package"

} else {

bat(/"${mvnHome}\bin\mvn" -Dmaven.test.failure.ignore clean package/)

}

}

stage('Results') {

junit '**/target/surefire-reports/TEST-*.xml'

archive 'target/*.jar'

}

}

Nexus Repository Manager PublisherConfiguration

Now, we will add aNexus Repository Manager Publisher step to the build pipeline script.This step should occur after the build so that the binaries are available for upload. For best reporting during the build process, the publish step should exist in its own stage. Below the Results stage, add a new Publish stage to the script.

stage('Publish') {

}

Jenkins Pipeline makes getting started with their scripting easy using the Pipeline Syntax wizard to generate the necessary Groovy code to publish your artifact. Click thePipeline Syntax link in thePipeline section to open the wizard in a new window. UnderSteps open theSample Step dropdown and find the nexusPublisher: Nexus Repository Manager Publisher step in the dropdown. Selecting this step will bring up a configuration section that will look familiar to those who completed theFreestyle Build tutorial in this documentation. We will repeat the process here, firstconfigure the Nexus Instance by selecting the Display Name configured in the first steps. Once the instance is selected, you should see a list of all repositories your authenticated user has access to in theNexus Repositoriesdropdown. Select a repository which has Release Repository Policy and allows for Artifact Uploads.

Once a repository is selected, you can select Packages to publish to Nexus Repository Manager during your Freestyle build. Packages are synonymous to Maven artifacts, a group of binaries (jar, -sources.jar) which are described by a component identifier (GAV).

For this example, use theAdd Packagedropdown to select aMaven Package. Fill in the Group, Artifact, and Version fields. You will notice the Packaging field is freeform but will provide autocomplete for traditional Maven packages. In this example we will want to publish the Jenkins war and will select war for the package. Lastly, use theAdd Artifact Pathdropdown and selectMaven Artifact. This allows you to select the artifacts to upload for this particular GAV. Jenkins builds the war to war/target/jenkins.war which we will use for theFile Path.

Clicking theGenerate Groovy button below the step configuration will generate the configured pipeline script. Copy the generated script and return to the Pipeline job configuration.

Nexus Publisher Script

nexusPublisher nexusInstanceId: 'localNexus', nexusRepositoryId: 'releases', packages: [[$class: 'MavenPackage', mavenAssetList: [[classifier: '', extension: '', filePath: 'war/target/jenkins.war']], mavenCoordinate: [artifactId: 'jenkins-war', groupId: 'org.jenkins-ci.main', packaging: 'war', version: '2.23']]]

After copying the script, paste it into the previously added Publish stage. Once completed, your entire script should look like the following.

Example Pipeline Build Script

node {

def mvnHome

stage('Preparation') {

git '

mvnHome = tool 'M3'

}

stage('Build') {

if (isUnix()) {

sh "'${mvnHome}/bin/mvn' -Dmaven.test.failure.ignore clean package"

} else {

bat(/"${mvnHome}\bin\mvn" -Dmaven.test.failure.ignore clean package/)

}

}

stage('Results') {

junit '**/target/surefire-reports/TEST-*.xml'

archive 'target/*.jar'

}

stage('Publish') {

nexusPublisher nexusInstanceId: 'localNexus', nexusRepositoryId: 'releases', packages: [[$class: 'MavenPackage', mavenAssetList: [[classifier: '', extension: '', filePath: 'war/target/jenkins.war']], mavenCoordinate: [artifactId: 'jenkins-war', groupId: 'org.jenkins-ci.main', packaging: 'war', version: '2.23']]]

}

}

Save the configuration and run the build. Once completed, you should be presented with a successful build similar to what's shown below.

Returning to our Nexus instance, we can see the Jenkins war is now available in the Releases repository.

Date:October 15th, 2019

Affected Versions:

Nexus Repository Manager 2 versions up to and including 2.14.14

Nexus Repository Manager 3 versions up to and including 3.18.1

Nexus IQ Server versions up to and including 72

Fixed in Version:

Nexus Repository Manager 2 version 2.14.15 and later

Nexus Repository Manager 3 version 3.19.0 and later

Nexus IQ Server version 73 and later

Summary:

A remote code execution (RCE) vulnerability has been discovered in Nexus Repository Manager 2, Nexus Repository Manager 3, and Nexus IQ Server.

An attacker with elevated privileges can upload a specially crafted file. That file can contain commands that will beexecuted on the system, with the same privileges as the user running the server.We have fixed the issueby ensuring the values are properly verified. This advisory provides the pertinent information needed to properly address this vulnerability, along with the details on how to reach us if you have any further questions or concerns.

We are not aware of any active exploits taking advantage of this issue.However, we strongly encourage all users of NXRM and IQ Server to immediately take the steps outlined in this advisory. We are highly recommending all instances of NXRM 3 be upgraded to 3.19.1 or later, all instances of NXRM 2 be upgraded to 2.14.15 or later, and all instances of IQ Server upgrade to 74 and later. The latest versions can be downloaded from:

Nexus Repository Manager 2 Download

Nexus Repository Manager 3 Download

Nexus IQ Server Download

For detailed information on upgrading, please see:

Nexus Repository Manager 2 Upgrade and Compatibility Notes

Upgrading Nexus Repository Manager 3.1.0 and Newer

Upgrading the IQ Server

Support:

If you run into any problems, or have any questions/concerns, please contact us by filing a ticket at https://support.sonatype.com.

Frequently Asked Questions:

Q: What is the risk associated with this vulnerability?

A:An attacker withelevated priveledges can upload a specially crafted file. That file can contain commands that will be run on the underlying systems as the user who owns the server process.

Q: What preconditions must be met in order to be vulnerable?

A:An attacker must have network access to the Repository Manager instance, as well as administrative access to the Repository Manager.

Q: Are there implications associated with this advisory itself?

A: Unfortunately, disclosure means bad actors may try to take advantage. While we have initially limited the information to the minimum details necessary for users to affect an appropriate fix, this merely slows down a would be attacker. As such, we are advising all organizations utilizing NXRM and IQ Server to immediately assess their individual impact and take appropriate action in response.

Q: Where can I obtain more information associated with the vulnerability?

A: At this time, and in the interest of best protecting our user community, we are limiting the information released to that absolutely required in order to assess impact and affect remediation. Please contact support for more information.

Q: Why is Sonatype making this information available?

A: This is part of a responsible disclosure process. We are taking a concerted and proactive approach in our outreach activities and an effort to achieve the most rapid remediation possible.

Symptoms

When the blobstore runs out of disk space you will notice errors in the nexus.log similar to the following, depending on the repository format:

npm ERR! javax.servlet.ServletException: org.sonatype.nexus.blobstore.api.BlobStoreException: BlobId: tmp$eb796cb8-7fe6-4306-83ac-3143ced2eb38, java.io.IOException: No space left on device

Recommendations

1. Schedule a Compact Blobstore task to run to remove items from blob storage that have previously been deleted. Many tasks which purge old content from the blobstore mark the content for deletion but do not clean up physical disk space. To remove content from disk you need to run Compact Blobstore.

2. Shutdown Nexus Repository Manager 3 and allocate more storage to the mount point where the blobstores are located.

3. If you need to move the blobstore to a different location with greater capacity, you can follow the steps in this article:

Relocating Blobstores

Sonatype Nexus Security Advisory

Date: October 15th, 2019

Affected Versions: All previous Nexus Repository Manager OSS/Pro versions up to and including 2.14.14

Fixed in Version: Nexus Repository Manager OSS/Pro version 2.14.15

Summary:

A Remote Code Execution vulnerability has been discovered in Nexus Repository Managerrequiring immediate action. The vulnerability allows for an attacker with administrative access to NXRM to create repostories that can grant access to read/execute system data outside the scope of NXRM. We have mitigated the issue by not allowing NXRM to do this unless explicitly requested by system administrators. This advisory provides the pertinent information needed to properly address this vulnerability, along with the details on how to reach us if you have any further questions or concerns.

This vulnerability was identified by an external researcher and has been verified by our security team. We are not aware of any active exploits taking advantage of this issue.However, we strongly encourage all users of Nexus to immediately take the steps outlined in this advisory.

The identified vulnerability can allow for the server to execute anything on the system, that the user running the server has privileges to. We are highly recommending all instances of Nexus be upgraded to Nexus 2.14.15 or later.The latest version can be downloaded from:

https://help.sonatype.com/repomanager2/download

For detailed information on upgrade compatibility, please see:

https://support.sonatype.com/entries/21701998-Sonatype-Nexus-Upgrade-and-Compatibility-Notes

Credit:

Sonatype thanks Christian Hland@ Binary Security forresponsibly reporting the identified issue.

Support:

If you run into any problems, or have any questions/concerns, please contact us by filing a ticket at https://support.sonatype.com.

Frequently Asked Questions:

Q: What is the risk associated with this vulnerability?

A: Nexus storage can be compromised, allowing an attacker to use the flaw to read or execute files outside the scope of the nxrm server.

Q: What preconditions must be met in order to be vulnerable?

A: An attacker must have network access to the Repository Manager instance, as well as administrative access to the Repository Manager to apply the required storage configurations.

Q: Are there implications associated with this advisory itself?

A: Disclosure unfortunately means bad actors may try to take advantage. While we have initially limited the information to the minimum details necessary for users to affect an appropriate fix, this merely slows down a would be attacker. As such, we are advising all organizations utilizing Nexus Repository Manager to immediately assess their individual impact and take appropriate action in response.

Q: Where can I obtain more information associated with the vulnerability?

A: At this time, and in the interest of best protecting our user community, we are limiting the information released to that absolutely required in order to assess impact and affect remediation. Please contact support for more information.

Q: Why is Sonatype making this information available?

A:This is part of a responsible disclosure process. Given NXRM is an open source project with widespread usage, notifying the user base will invariably lead to broad dissemination. We are taking a concerted and proactive approach in our outreach activities and an effort to achieve the most rapid remediation possible.

Problem

It may be noticed that some blobs marked soft deleted ( deleted=true inside the blob properties file ) in a file based blobstore may not be hard deleted after repeated runs of the Admin - Compact blobstore task.

S3 based blobstores are not affected by the Admin - Compact blobstore task and this article does not apply to those types of blobstores.

Diagnosis

The Admin - Compact Blob store task relies on a deletions index file to know which blobs should be hard-deleted.

Although each soft-deleted blob has a property within the associated .properties file that flags it as such, the deletions index file is the only thing that the Compact Blobstore task will use for performance reasons.

It is possible for the deletions index to be missing blobs, perhaps due to errors when they are deleted such that their IDs do not get added to the index. In this case, the blobs are effectively orphaned and will not be picked up during compaction.

How to rebuild a file based blobstore deletions index file

Locate the file based blobstore containing the soft-deleted blobs which were not deleted by the Admin - Compact blobstore task.

Add the following line to the metadata.properties file in the root directory of the blobstore.

rebuildDeletedBlobIndex=true

For example, the default file based blobstore metadata properties file is relative to the install dir at ../sonatype-work/nexus3/blobs/default/metadata.properties

The next time that the Admin - Compact Blobstore task is run, it will iterate over all of the properties files in the blobstore, looking for the deleted=true attribute and rebuild the index file.

The task will run longer than usual, depending on the size of the blobstore and I/O performance.

Once the task has successfully completed, the property will be automatically be removed from metadata.properties and so that the index will not rebuild again on the next run of the task.

This knowledge base article provides instructions for running the Nexus IQ Server as a service under Windows using a free edition of Java Service Wrapper. If you want to run the Nexus IQ Server as a service on Linux please see our installation guide.

New Nexus IQ Server Install as a Windows Service

Ensure you have already installed the latest JDK from Oracle on the target system and the system meets our other system requirements.

Download and extract the clm-jsw.zip file attached to this article into a directory path that does not contain spaces.

Replace the extracted conf/config.yml with the config.yml file from current Nexus IQ server installation (be sure to check the "sonatypeWork" property in the copied version to make sure it is correct).

Copy the nexus-iq-server-<version>.jar file from your installation into the "lib" directory.

Note: Do not copy the nexus-iq-cli-<version>.jar file into that directory. That is the command line scanner, and it cannot be on the class path of IQ Server.

The service will run as the SYSTEM user. IQ server requires use of a temporary directory to perform some work. The SYSTEM user will use "%systemroot%\System32\config\systemprofile\Temp" as it's temporary directory. On some versions of Windows this directory does not exist by default. Make sure that this directory exists. Create it manually if it does not.

Using an administrative user, run ".\bin\clm install".

Using an administrative user, run ".\bin\clm start" to start the windows service, or start it through the services UI.

Verify that on restarting the host, that the application will successfully restart itself.

Editing Java Program Arguments Used to Lauch IQ Server

You may want to edit the Java.exe arguments used when IQ Server is launched. These are not parameters to IQ Server, but rather parameters for the Java Virtual Machine.

To change arguments passed to the java.exe program launching IQ Server:

Edit ./bin/jsw/conf/wrapper.conf

Find the references to wrapper.java.additional.<n> properties - add or remove lines with new properties according to the java service wrapper documentation.

Example: Configure a custom outbound truststore

In order to override the default Java truststore IQ Server uses:

Edit ./bin/jsw/conf/wrapper.conf

Specify wrapper.java.additional.<n> properties defining the trustStore and its password. Make sure all paths specified use forward slashes, even on windows and if the value requires a space, then the entire value must be in quotes.

# MaxPermmSize not needed on JDK 8+, so comment it out# wrapper.java.additional.1=-XX:MaxPermSize=256mwrapper.java.additional.1=-Djavax.net.ssl.trustStore=/<replace_with_absolute_full_path>/nexus-iq-server-outbound.jkswrapper.java.additional.2=-Djavax.net.ssl.trustStorePassword=changeit

To identify which java install is being used by a running IQ Server:

Signin to IQ Server UI as an admin user and then change the open browser window location URL path to download a support zip: /rest/supportAlternately: Use the REST API to download a support zip

Save the support zip to disk and open it.

Inside the support zip, open the ./info/sysinfo.json file. Locate the following java system properties ( example values ):

"java.endorsed.dirs" : "/usr/java/jdk1.8.0_212-amd64/jre/lib/endorsed",

"java.ext.dirs" : "/usr/java/jdk1.8.0_212-amd64/jre/lib/ext:/usr/java/packages/lib/ext",

"java.home" : "/usr/java/jdk1.8.0_212-amd64/jre",

"java.io.tmpdir" : "/tmp",

"java.library.path" : "/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib",

"java.runtime.name" : "Java(TM) SE Runtime Environment",

"java.runtime.version" : "1.8.0_212-b10",

"java.specification.name" : "Java Platform API Specification",

"java.specification.vendor" : "Oracle Corporation",

"java.specification.version" : "1.8",

"java.vendor" : "Oracle Corporation",

"java.vendor.url" : "http://java.oracle.com/",

"java.vendor.url.bug" : "http://bugreport.sun.com/bugreport/",

"java.version" : "1.8.0_212",

"java.vm.info" : "mixed mode",

"java.vm.name" : "Java HotSpot(TM) 64-Bit Server VM",

"java.vm.specification.name" : "Java Virtual Machine Specification",

"java.vm.specification.vendor" : "Oracle Corporation",

"java.vm.specification.version" : "1.8",

"java.vm.vendor" : "Oracle Corporation",

"java.vm.version" : "25.212-b10"

To identify which outbound TLS connection truststore is being used by a running IQ Server:

Signin to IQ Server UI as an admin user and then change the open browser window location URL path to download a support zip: /rest/supportAlternately: Use the REST API to download a support zip

Save the support zip to disk and open it.

Inside the support zip, open the ./info/sysinfo.json file. Look for these java system properties:

javax.net.ssl.trustStore

javax.net.ssl.trustStorePassword

If the properties are present, the truststore being used is at the path specified by the value of the javax.net.ssl.trustStore property.

If the properties are not present, then inside./info/sysinfo.json look for the line that contains

java.home

The value of this property should contain a path to the Java runtime home being used by IQ server.

From the java.home path, you can deduce which of these currently apply to IQ server:

if java-home /lib/security/jssecacertsis a valid file, trusted certificates for outbound connections IQ Server makes are loaded from here. This file does not exist by default but can be created by a user using keytool.

java-home /lib/security/cacertsexists by default. It is pre-loaded with well known public certificate authority root certificates that allow a client program to trust sites which have certificates signed by them. If for some reason it is missing, there will be no trusted certificates loaded for IQ Server.

See our guide for instructions on How to Configure a Custom Truststore for IQ Server.

To make a proxy repository act like a hosted repo and continue to serve already cached artifacts:

Nexus Repository Manager 3

Select the proxy repository in the UI Repositories list. On the Settings tab, check theBlock outbound connections on the repositorycheckbox and Save the settings.

Nexus Repository Manager 2

For each repository, edit the Configuration tab. Change Automatically Block to False. Save.

Immediately right-click the repository in the repositories list and choose Block proxy. This manually blocks outbound connections from the proxy and now Nexus will no longer keep trying to unblock these invalid repositories.

Nexus uses the Jetty container and Jetty provides a handler that can be used to restrict access by IP addresses and subnets.

Attached is a sample jetty config file that allows you to configure the IP Access Handler using Nexus 2.8+.

To configure it:

Download and store the file at NEXUS_HOME/conf/jetty-ipaccess.xml, with the same permissions as the other jetty files

Edit NEXUS_HOME/conf/jetty-ipaccess.xml, add white listed and blacklisted addresses using the syntax as documented in the javadoc. By default, all access is allowed

Edit NEXUS_HOME/bin/jsw/conf/wrapper.conf, and reference the new jetty file as an app parameter iewrapper.app.parameter.3=./conf/jetty-ipaccess.xml( 3 by default, however the next available number must be used )

restart Nexus

Warn: This is unsupported functionality. The export method described is not intended to manage policy, but rather to seed policy in an organization for a test IQ Server.

How to Export Policy from IQ Server

The steps below detail how to export policy from the Nexus IQ server.

In a terminal, issue the following command: curl -u username:password -o policy.jsonhttp://<iq-server-url>/rest/policy/organization/ROOT_ORGANIZATION_ID/export

username and password are the credentials used to log into the IQ server.

policy.json is the file name to write the response into

Step 1 will produce a policy.json file in your current working directory. This file can be imported via the IQ Server using actions drop down menu in the upper right hand corner of the Root Organization view.

Warn: When importing a new policy, all trending information associated to that organization or application(s) will be lost. This method is not intended to manage policy, but rather to seed policy in an organization.The "/rest/" endpoints are used by the UI and we may change them to support the needs of the UI. The officially supported API is at "/api/v2/" and is documented in the IQ Server Help.

Prior to Aug 3, 2014, secure access to the Central Repository was limited to Nexus Professional licensees using the Nexus Pro Secure Central plugin and those who obtained a special Auth Token from Sonatype after making a Apache Software Foundation donation. Going forward, Sonatype offers SSL access to Central for everyone free of charge. If you want to switch to using the now free secure central, see our guide to doing this.

Nexus Professional versions earlier than 2.9.xinclude a now legacy Secure Central Plugin which supported an HTTPS Maven 2 Proxy Repository connection to Maven Central. The remote URL was configured by default as https://secure.central.sonatype.com/maven2.

This article describes how to completely disable or replace this secure connection and optionally replace it with the standard Maven Central remote URL.

Completely Deleting Secure Central Proxy Repository

You can completely delete the legacy Nexus Pro Secure Central repository. Choose this option if:

you plan to replace it and start a new Central repository

its local storage contains very little or is empty or you don't care if Nexus will need to re-download indexes or already cached artifacts from somewhere else

you prefer not to use a secure connection to Central

Steps:

Delete any dependent repositories on Central. By default, Nexus ships with a Central M1 Shadow repository that needs to be removed before deleting Central.Open Repositories tab. Select the "Central M1 Shadow" repository.Click theDeletebutton in the toolbar and confirm the deletion.

Delete Central. Open Repositories tab. Select the "Central" Repository. Click the Delete button in the toolbar and confirm the deletion.

Disable the secure central capability. Open Administration -> Capabilities tab. Select Secure Central capability. View its Settings. Make sure the Enabled checkbox is not checked. Save the capability.

Blocking Secure Central Proxy Repository

You can choose to keep the existing secure central proxy and it's already cached artifacts in local storage, but prevent it from trying to fetch new artifacts remotely. Choose this option if:

you want the option to enable it again later

you've already cached artifacts locally and do not want to incur the time to fetch these artifacts again

Steps:

Block Central from going remote for new artifacts. Open Repositories tab. Right-click the secure "Central" Repository. Choose the Block Proxy option.

Disable the secure central capability. Open Administration -> Capabilities tab. Select Secure Central capability. View its Settings. Make sure the Enabled checkbox is not checked. Save the capability.

Replacing Secure Central with Standard Central

Simply changing the remote URL of the secure Central proxy repository may seem appealing, however changing the remote url of existing repository may have ill effects and is generally not recommended. It is usually better to simply add a new repo and delete or block the old one.

You may still want to fetch artifacts from central, but using the standard http/https free URLs.

Steps:

Follow the steps for Blocking or Deleting Secure Central Proxy Repository

Add a new Maven 2 Proxy repository with the remote url of https://repo1.maven.org/maven2/ or http://repo1.maven.org/maven2

Add the new Maven 2 Proxy Repository to any groups that contained the legacy secure central Proxy repository.

To move a Nexus Repo 3 server to a new location you'll need to move three things:

The application directory (e.g. nexus-3.13.0-01)

The data directory

Blob storage

The application directory of a Nexus Repo 3 installation is portable*, and can simply be copied to the new location. Be sure to preserve operating system file permissions when doing this.

The data directory ( commonly referred to as $data-dir or ${karaf.data} ) of a Nexus Repo 3 installation is portable*, and can just be copied to a new location. If you're not sure where the data directory of your installation is located, we have an article that can help you.

Blob stores are also portable, and can be copied to a new location. To find the location of your blob stores go to "repository --> blob stores" in the Nexus Repo 3 administration UI. If the path shown for a blob store is not an absolute path, that means it is located at a relative directory under $data-dir/blobs/, and it will be copied when you copy the entire data directory.

Note that the directories above must be copied when Nexus Repo is not running. But to minimize downtime, consider using a backup tool that can perform incremental file system backups. One commonly used tool which can do this is the "rsync" program that can be found in Linux distributions.

When using a backup tool that can perform incremental backups an initial copy of the directories can be done while the original Nexus Repo 3 is still running. If you're using rsync, this can be done with "rsync -avP <source> <dest>". Once this completes, shut down Nexus Repository Manager, and run a second copy using "rsync -avP --del <source> <dest>". This second copy should run quite quickly, since rsync will only be handling the delta of files between the first and second copy.

If your original system has a slow disk consider running the first rsync with "ionice -c3 rsync". This will prevent rsync from consuming all disk bandwidth.

If your blob stores are not going to be in the same location as they were in the original system running Nexus Repo you'll need to update their locations in the database. See here for information on how to do this:

Relocating Blob Stores

* Note: If you've made customizations to the files in the "etc" directory in either the install or work directories be sure to check and see if any absolute paths have been used. These may need to be adjusted in the new installation.

To downgrade a Nexus Repository Manager (NXRM) 3 PRO instance to OSS:

Gracefully stop NXRM.

Open the file <data-dir> /etc/nexus.properties in a text editor.

Add a new line to the file containing:

nexus.loadAsOSS=true

Save the file with read permissions and ownership of the user owning the NXRM process.

Required for versions 3.10.0 to 3.14.0 only:

This step is not needed for versions 3.9.0 or earlier or 3.15.0 and later.

You will need to modify the DB paths in the script before executing it.

Download the attached downgrade.osql script to your <app-dir>.

Open the downgrade.osql script in a text editor and modify the path references inside the script to refer to the correct locations.

In a terminal session, change directories to the <app-dir> and execute the script using a java command:

java -jar ./lib/support/nexus-orient-console.jar downgrade.osql

Start NXRM

Problem

Upgrading directly to IQ Server release 73 from a previous release may fail.

The server will not start and the clm-server.log will contain log messages which include text similar to:

*SYSTEM com.sonatype.insight.brain.db.OperationalDataStoreProvider - Initializing the insight_brain_ods data store.

java.lang.IllegalStateException: Fatal error trying to start server

at com.sonatype.insight.brain.service.InsightBrainService$2.onError(InsightBrainService.java:156)

at io.dropwizard.cli.Cli.run(Cli.java:82)

at com.sonatype.insight.brain.service.InsightBrainService.run(InsightBrainService.java:172)

at com.sonatype.insight.brain.service.InsightBrainService.main(InsightBrainService.java:100)

Caused by: com.sonatype.insight.db.DatabaseException: java.sql.SQLException: Cannot create PoolableConnectionFactory (Allgemeiner Fehler: "java.lang.IllegalArgumentException: timeNanos out of range 86400998000000"

General error: "java.lang.IllegalArgumentException: timeNanos out of range 86400998000000" [50000-196])

Cause

The database records from an earlier version contains policy evaluations and related violations with local timestamps greater than23:59:59.499. This is rare and only affects a small subset of customers, however will fail upgrade and force the customer to roll back to the previous IQ Server release.

The bug in reading these timestamps was introduced by upgrading the version of the third-party database that IQ server uses.

Resolution

Release 74 and newer will not encounter this problem.

First rollback to the backup of the sonatype-work/clm-server directory taken before the upgrade to IQ Server 73 was attempted. Then choose one of these options:

Start the previous IQ Server release that was being used prior to the upgrade attempt.

Start IQ Server release 72 and upgrade to it.

Start IQ Server release 74 or newer and upgrade to it.

Starting any version of IQ Server against the databases that release 73 was started against is not supported.

Problem

Your Nexus instance is configured to use an HTTP proxy server that rewrites SSL certificates for secure ( HTTPS ) remote hosts.

The identity ofeach host certificate remains unique, but yourHTTP proxy server modifies the certificate chain of the remote certificate such that your HTTP proxy server acts like an internal certificate authority.

Since Nexus by default only knows about certificate authorities in the JVM cacerts file, Nexus will not implicitly trust certificates issued by your proxy server. This can result in connection errors to remote hosts that include messages similar to:

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target > PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target > unable to find valid certification path to requested target

Resolution

When you first encounter these errors, you may be inclined to start adding each certificate your proxy server generates to your Nexus Professional trust store. This can work, but is not ideal for several reasons.

this is potentially a lot of work if you have many repositories.

when new repositories get added, it is easy to forget to explicitly trust the remote certificate, especially if you have multiple users maintaining your Nexus instance

not all outbound HTTPS connections are for repositories, therefore some problems may not be noticeable unless you closely examine the nexus log for errors and research what host certificates to trust

HTTP proxy servers can generate new certificates for the same remote on a configured schedule - a policy enforced by your proxy server administrators and beyond the control of a Nexus Administrator

A more reliable solution is to trust the proxy server certificate once, essentially treating it as an authority for every certificate it issues.

To do this, execute a command to get the PEM formatted certificate of your proxy server. For example:

keytool -J-Dhttps.proxyHost=<proxy_hostname> -J-Dhttps.proxyPort=<proxy_port> -printcert -rfc -sslserver <remote_host_name:remote_ssl_port>

Replace <proxy_hostname> and <proxy_port> with the HTTP proxy server that Nexus is configured with under Administration -> Server. Replace <remote_host_name:remote_ssl_port> with one of the remote host and port having the certification problem. You can omit the port if it is the default 443.

You should see at least two entries printed by the above command. Take thelastcertificate content printed and copy it entirely to your clipboard. This should be your proxy server's certificate, added to the end of the certificate chain.

The copied certificate content should start with-----BEGIN CERTIFICATE-----and end with-----END CERTIFICATE-----.

Then in the Nexus UI, go to Administration ->SSL Certificatesand clickAdd...and choosePaste PEM. Paste the certificate contents to the dialog that opens.

ClickLoad Certificate. Verify the certificate contents in the next window. Verify the Issuer details listed are from your proxy server certificate. When you are satisfied clickAdd Certificate.

If you have previously added host specific certificates to the Nexus trust store that have an Issuer of your proxy server, you can optionally delete those explicit certificate entries.

Certain features such as proxy repositories, require an explicit declaration that they consult the Nexus Trust Store to verify a remote certificate chain. For example, proxy repositories must still have the Use Nexus SSL trust store checked on the SSL tab.

Note: Nexus OSS users need to import the certificate manually into the trust store used by the Nexus JVM. The SSL certificates feature is available for Nexus Pro only.

Sonatype Support's hours of operation are from 8a.m. to 8.p.m Eastern time. Support outside of those hours is done on a best effort basis.

However, if you have purchased 24x7 support you can obtain round the clock support for critical system failures. To obtain out of hours support you must file a support ticket at https://support.sonatype.com using one of your designated support accounts, and select "critical production system outage" as the issue type. The ticket must be filed by a registered support contact in order for the pager alert to be raised.

Overview

Nexus request headerauthentication allows you to use an external system to validate the login credentials of users accessing Nexus Repository Manager or Nexus IQ Server. The validated user ID is sent to Nexus via an HTTP request header. Request header authenticationis useful to implement single sign on (SSO), and is also useful for using authentication schemes which Nexus does not currently support, such as Kerberos or SAML.

This article will walk you through the steps needed to set up request headerauthentication for Nexus Repository Manager using the Apache web server.

Configuration for Nexus IQ Server (CLM) is almost identical, except that the method used to configure the request headeris different. See here for details:

Nexus Lifecycle Advanced Configuration

It is recommended that you follow the steps in this guide and get everything working as described here before attempting to configure Apache for more advanced types of authentication. It is also recommended that you test each step after completing it before proceeding to the next step.

Step 1 - Configure Nexus for Security Authentication and Authorization via LDAP or Crowd

An HTTP request headercan only be used for authentication(validation of login credentials) in Nexus. Authorization (mapping of users to Nexus roles and privileges) needs to be done via another mechanism. This will allow you to map groups defined in external servers such as Active Directory to sets of roles and privileges in Nexus. Instructions for configuring external user management systems in Nexus can be found here:

Integrating LDAP or Active Directory with Nexus

Integrating Atlassian Crowd with Nexus

Once you have the integration with the external user management system working then you need to grant users in your external systems access to Nexus. There are two mechanisms available to do this:

External User Mapping

External Role Mapping

For large numbers of users it is highly recommended to use external role mappings. It's far easier to manage users in a system such as Active Directory which has been specifically designed for the task.

Once you have your user mappings configured be sure to test it. Make sure the end users you've mapped in from the external authentication system can log into nexus and access the resources you've granted the access to.

Step 2 - Configure a Request Header Authenticationin Nexus Repository Manager

The Nexus side of request header authenticationis quite simple, we just need to let Nexus know what HTTPheader is going to contain the authenticated user ID.

To set this up:

Go to "administration/capabilities" in the UI

Click on "new" to add a new capability

Select the "Rut Auth" capability

Fill in the header name. This article assumes you will use "X-Proxy-REMOTE-USER" as the header name.

Save

When the capability is first created and marked Enabled, the RUT Auth Realm will automatically get added to the Selected Realms list under Administration -> Server -> Security Settings -> Selected Realms.

Make sure that this realm is added later manually if you initially add the capability but do not enable it.

For more information see here:

Authentication via Remote User Token

Step 3 - Configure Apache

Next we need to configure fourthings in Apache:

Load the modules needed for this setup

Configure basic authentication

Set the X-Proxy-REMOTE-USER header

Configure Apache as reverse proxy in front of Nexus

Step 3a - Load Modules

The following Apache modules will be needed in order to run the configuration below:

mod_proxy

mod_proxy_http

mod_headers

mod_rewrite

These can be loaded via LoadModule directives in httpd.conf. But different distributions of Apache will have modules loaded in different ways. It's best that you consult the documentation for your Apache distribution to find the recommended mechanisme for loading modules.

Step 3b - Configure Apache HTTP Basic Authentication

For the purpose of this article we are going set up simple authentication in Apache. You will need to replace this later with a more secure authentication system. That is not covered in this article, you'll need to consult the Apache documentation for information about other authentication systems.

Full instructions for setting up simple authentication in Apache can be found here:

Apache Authentication and Authorization

Basically, you just need to run:

htpasswd -c /home/test/passwd username

The "htpasswd" command comes as part of your Apache distribuion:

Running the above command will prompt you for a password for user "username", and then write out a password file at the specified location. Additional users can be added with:

htpasswd /home/test/passwd <user-id>

Next, add a location directive into the http.conf file, and configure Apache for basic authentication using the password file you created previously:

<Location /nexus>

#Configure basic authentication (for testing purposes)

AuthType Basic

AuthName "Sonatype Nexus"

AuthBasicProvider file

AuthUserFile /home/test/passwd

Require valid-user</Location>

You can test the above by visiting http://localhost/nexus in a browser. You should be prompted for authentication by the browser. Entering the credentials of one of the users you configured above should work.

Note: Web browsers will cache credentials entered for HTTP basic authentication until they are restarted. So you'll need to restart your browser to get the loging prompt again. Using HTTP basic browser authentication is only shown here for testing purposes, you should replace this with a more robust authentication mechanism for production purposes.

Step 3c - Set the Authenticated User ID in aRequest Header

Authenticated users in Apache are made available via the REMOTE_USER server variable. Unfortunately there doesn't appear to be a way to make server variablesdirectly available for setting in request header, so we need a bit of trickery:

# Make REMOTE_USER set by authentication available as environment variable

RewriteEngine on

RewriteCond %{REMOTE_USER} (.*)

RewriteRule .* - [E=ENV_REMOTE_USER:%1]

RequestHeader set X-Proxy-REMOTE-USER %{ENV_REMOTE_USER}e

The RewriteRule rule above fires for every request and sets the environment variable ENV_REMOTE_USER equal to the value of REMOTE_USER, which is itself set by the apache authorization module. The RequestHeader sets a request header named X-Proxy-REMOTE_USER with the value of ENV_REMOTE_USER in the request sent to Nexus.

Additionally, we need to unset any authorization headers being sent from the original request, these aren't needed, and should not be sent to Nexus. This is accomplished with:

# Remove incoming authorization headers, Nexus users are authenticated by HTTP header

RequestHeader unset Authorization

Step 3d - Configure Apache as a Reverse Proxy

Next we need to configure Apache as a reverse proxy in front of Nexus. For testing purposes this will work:

# Configure apache as a reverse proxy for Nexus

ProxyPreserveHost on

ProxyPass http://localhost:8081/nexus

ProxyPassReverse http://localhost:8081/nexus

Additional configuration will likely be needed for production, particularly if you are using Apache to serve SSL (http) pages. You can find full documentation for configuring Apache as a reverse proxy for Nexus here:

Running Nexus Behind a Reverse Proxy

Step 3e - Completed Configuration

For reference, here is the full configuration from above:

<Location /nexus>

#Configure basic authentication (for testing purposes)

AuthType Basic

AuthName "Sonatype Nexus"

AuthBasicProvider file

AuthUserFile /home/test/passwd

Require valid-user

# Make REMOTE_USER set by authentication available as environment variable

RewriteEngine on

RewriteCond %{REMOTE_USER} (.*)

RewriteRule .* - [E=ENV_REMOTE_USER:%1]

RequestHeader set X-Proxy-REMOTE-USER %{ENV_REMOTE_USER}e

# Remove incoming authorization headers, Nexus users are authenticated by HTTP header

RequestHeader unset Authorization

# Configure apache as a reverse proxy for Nexus

ProxyPreserveHost on

ProxyPass http://localhost:8081/nexus

ProxyPassReverse http://localhost:8081/nexus

</Location>

Step 4- Restrict the IP subnet for Nexus

In order to make the above configuration secure you must restrict access to Nexus by subnet or IP address. Without this restriction a user could bypass the Apache instance and log directly into Nexus, or worse, they could craft a malicious request with the remote user header set and gain access to resources they should not normally be able to see.

There are two ways you can restrict access, by subnet, or by IP address. Restriction by subnet is easiest, and is usually sufficient, particularly if Apache and Nexus are running on the same machine.

To restrict by subnet edit $NEXUS_HOME/conf/nexus.properties and look for this line:

application-host=0.0.0.0

This line is telling Nexus to listen for connections on all network interfaces. To restrict this, simply replace "0.0.0.0" with the IP address of the network interface which is on a restricted subnet. For example, if both Nexus and Apache are on the same machine then you can tell Nexus to only listen on the loopback network:

application-host=127.0.0.1

Restriction by IP address is a bit more complex, see here for details:

How to Restrict Access to Nexus by IP Address

Step 5- Replace Basic Authentication with a More Robust Security Mechanism

It is beyond the scope of this article to cover more advanced authorization schemes such as Kerberos, this is left as an exercise to the reader. Apache supports a wide variety of authorization schemes, a web search will turn up lots of information on how to get these working.

Here are a few resources for Kerberos that you may find useful:

Apache Kerberos User Guide

Configure Apache to use Kerberos Authentication

Apache supports many other authentication systems, such as Oath, SAML, etc. There are lots of tutorials and examples available on the web for these.

Nexus is licensed by user count, not the number of server instances. As long as the number of users accessing all Nexus instances per organization doesn't exceed the number in your written license agreement you are in compliance. Note that this is not a concurrent user count, it is a total user count.

For reference, the definition of "user" in the license agreement is:

"User" means an individual who is authorized by Company to use a Product for the benefit of Company's internal business purposes and for whom a Subscription to the Product has been purchased. Users must include, without limitation, all of Company's employees (including managers, Contributing Developers and administrators), consultants, contractors and agents. For purposes of this definition, "Contributing Developer" means a User who produces or consumes software artifacts managed and/or scanned by the Product.

Q. I want to set up a test Nexus instance. Do the number of licensed users apply to this test instance.

A. Yes.

Q. Does a user token for the same physical user as a username identifier equate to a single licensed user?

A. Yes. We treat these as multiple ids for the same licensed user.

Q.Does anonymous access to Nexus count as one user, or as many users that may be accessing Nexus anonymously?

A.If you are exposing your Nexus instances publicly (outside your organization), then the anonymous access counts as one user. If the anonymous access is within your organization, then each individual user as defined by the license agreement applies, despite the access not requiring a login.

Q.How can I verify if I am in compliance with the number of licensed users?

A. In Nexus Repository Manager you can access the "System -> Licensing -> Recent Connections" UI. You will then have access to a report of all the unique IP addresses accessing nexus within the last 7 days. This information is intended as an approximation tool only. In many situations ( eg. reverse proxy fronting Nexus ), the number of unique IPs accessing Nexus will be skewed.

Another approach is to examine the request.log files. The IP address and user ID associated with each inbound request will be in columns 1 and 3 respectively. Again, this information should only be used as a guide, you can't count on accuracy due to the often complex network setups at many organizations.

If you have any questions or concerns about Nexus licensing please contact us at [email protected]

Problem:

You've restricted read access to a repository by using a repository target with a regular expression that matches a group ID, such as "/com/mycompany/team-a/.*". This works, but now users with this privilege can't use the "Browse Storage" tab in the UI.

Solution:

This is happening because the folders "/", "/com/", etc. do not match your regular expressions.

To fix this you also need to grant read access to the paths in the tree, so use a regular expression like this one:

/|/com/|/com/mycompany/|/com/mycompany/team-a/.*

Alternatively, you can grant access to all directory listings regardless of where they are in the hierarchy:

.*/

This will grant access to all directory listings, but will not grant any access to artifacts within a directory.

Date: July 26, 2019

Affected Versions:Nexus Repository Manager 3 versions starting in 3.14.0 up to and including 3.17.0

Fixed in Version:Nexus Repository Manager Pro version 3.18.0

Summary:

A cross-site scripting(XSS) vulnerability have been discovered in Nexus Repository Manager 3.

An attacker with elevated privileges can create entities with specially crafted properties which when viewed by another user can execute arbitrary JavaScript in the context oftheNXRMapplication.We have fixed the issueby ensuring the values are properly encoded. This advisory provides the pertinent information needed to properly address this vulnerability, along with the details on how to reach us if you have any further questions or concerns.

We are not aware of any active exploits taking advantage of this issue.However, we strongly encourage all users of NXRM to immediately take the steps outlined in this advisory.

The identified vulnerability allows arbitrary JavaScript to run in an NXRM user's browserin the context ofthe application. In regards to XSS, it is common that the injected JavaScript could forge requests on behalf of the user, redirect the user to another site or modify the page content. We are highly recommending all instances of NXRM be upgraded to 3.18.0 or later. The latest version can be downloaded from:

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

For detailed information on upgrade, please see:

Upgrading Nexus Repository Manager 3.1.0 and Newer

Discoverer:

Thank you to 1jesper1 for reporting the vulnerability.

Support:

If you run into any problems, or have any questions/concerns, please contact us by filing a ticket at https://support.sonatype.com.

Frequently Asked Questions:

Q: What is the risk associated with this vulnerability?

A: An attacker with elevated privileges can create entities with specially crafted properties which when viewed would execute arbitrary JavaScript within the context of the application leading to the compromise of the confidentiality and integrity of data.

Q: What preconditions must be met in order to be vulnerable?

A:An attacker must have elevated privileges and another user must view malicious entities.

Q: Are there implications associated with this advisory itself?

A: Disclosure unfortunately means bad actors may try to take advantage. While we have initially limited the information to the minimum details necessary for users to affect an appropriate fix, this merely slows down a would be attacker. As such, we are advising all organizations utilizing NXRM to immediately assess their individual impact and take appropriate action in response.

Q: Where can I obtain more information associated with the vulnerability?

A: At this time, and in the interest of best protecting our user community, we are limiting the information released to that absolutely required in order to assess impact and affect remediation. Please contact support for more information.

Q: Why is Sonatype making this information available?

A: This is part of a responsible disclosure process. Given NXRM is an open source project with widespread usage, notifying the user base will invariably lead to broad dissemination. We are taking a concerted and proactive approach in our outreach activities and an effort to achieve the most rapid remediation possible.

When submitting a support request to Sonatype it is tremendously helpful if you supply us with diagnostic information from the affected product. We ask that you supply the following information with your support ticket:

Diagnostic and log files from the affected server

Build logs or screenshots of the client side issue

Failure to supply the needed information often results in unnecessary delays in ticket resolution times.

Getting the us the information we needis easy, see below for instructions for Nexus Repository Manager and Nexus IQ Server.

Nexus Repository Manager 3

Nexus Repository Manager 2

NexusIQ Server

Nexus Repository Manager 3.x

Create a Support Zip Using the UI

Go to the administration UI. Then click on "Support ZIP", and "Create support ZIP":

Create a Support Zip Using REST API

Use this method when:

repository manager version is 3.13.0 or newer

the server is started but the UI may not reachable

the blob store is corrupt, preventing the support zip from being saved there as it normally would

a load balancer needs to be bypassed to request support zips from specific nodes

How to create a support zip using REST API:

Open a command prompt / terminal on a host that has curl installed and can reach your IQ server host.

Execute the following command (adjust 'localhost:8081' to your hostname[:port] and admin:admin123 to your real Administrator user username and password ):

curl -u admin:admin123 -O -J -X POST http://localhost:8081/service/rest/v1/support/supportzip -H "Content-Type: application/json" --data '{"systemInformation": true, "threadDump": true, "metrics": true, "configuration": true, "security": true, "log": true, "taskLog": true, "jmx": true, "limitFileSizes": true, "limitZipSize": true}'

Locate the support zip file saved into the current directory automatically and attach it to your support ticket.

Note: The REST API method WILL NOT attempt to save the generated support zip on the server in the downloads directory or in the blob store.

Nexus Repository Manager 2.x

Go to Administration/Support Tools/Support Zip" in the UI and create a support zip:

Nexus IQ Server

Nexus IQ Server Version 1.27 and Newer

Create a Support zip Using The UI

Signin tothe IQ Server as a user with the System Administrator role ( ie. example: default admin user ).

Open a new browser tab and enter one of the following URLs with options as described below: Basic support zip: enter this URL (adjust 'localhost:8070' to your IQ Server hostname[:port]):

http://localhost:8070/rest/support

Adding org, app, and policy info: IQ Server version 1.35+, enter a URL plus additional parameter as below:

http://localhost:8070/rest/support?includeDb=true

The "?includeDb=true" parameter will allow us to recreate your unique policy configuration to aid in troubleshooting policy issues. If you use this option the support zip will include the names of your organizations and applications, andalso your policy configuration. Avoiding file truncation: For IQ Server version 1.43+, you can also add the URL parameter below:

http://localhost:8070/rest/support?noLimit=true

Support zip files may become truncated to keep the overall support zip size under 20MB. The "noLimit =true" parameter will prevent truncating large files, which is useful to include entire log files when requested. Combining all parameters:

http://localhost:8070/rest/support?includeDb=true&noLimit=true

Save the generated zip file and attach it to your support ticket.

Create a Support Zip Using curl

Open a command prompt / terminal on a host that has curl installed and can reach your IQ server host.

Execute the following command (adjust 'localhost:8070' to your IQ Server hostname[:port] and admin:admin123 to your real Administrator user username and password ):

curl -u admin:admin123 -O -J http://localhost:8070/rest/support

or to include additional debugging information for IQ Server version 1.35+, add the URL parameter below:

curl -u admin:admin123 -O -J http://localhost:8070/rest/support?includeDb=true

Locate the support zip file saved into the current directory and attach it to your support ticket.

Nexus IQ Server Version1.26 and Older

Please compress(zip)the following files from the server installation and submit as a ticket attachment:

config.yml ( obfuscate any passwords contained in this file before submittal )

log/clm-server.log

log/request.log

Nexus 3 has metrics information available in the administration support UI.

Additionally, Nexus 3.0.1 exposes the following RESTendpointsfor monitoring:

{host:port}/service/metrics/healthcheck

{host:port}/service/metrics/data

{host:port}/service/metrics/ping

{host:port}/service/metrics/threads

These require authentication, and the user must either be an administrator, or have the "nx-metrics-all" privilege.

curl -u admin:admin123 http://localhost:8081/service/metrics/pingpong

curl -u admin:admin123http://localhost:8081/service/metrics/healthcheck{"deadlocks":{"healthy":true}}

Also note that in version 3.16.0 new health check endpoints were added, which can be used to determine if Nexus Repo is able to service read and write requests respectively:

Name

URL

ReadableHealth Check

http://<hostname>:<port>/service/rest/v1/status

Writable Health Check

http://<hostname>:<port>/service/rest/v1/status/writable

For both status endpoints, Success is represented as HTTP 200 OK. Failure is represented as HTTP 503 SERVICE UNAVAILABLE. The nexus.log file for the node should be inspected for further details.

If you have configured Nexus to authenticate using Active Directory, and you are making use of the User Token feature in Nexus professional you will find that users will still be able to access the server using their user tokens even if you have disabled their Active Directory accounts.

Of course you can work around this by editing the user in Nexus and clicking on "reset token". However, there is a better way to prevent this.

Go to "security/ldap", click on the "user & group settings" tab.Then set the "user filter" field as follows:

(!(UserAccountControl:1.2.840.113556.1.4.803:=2))

This will prevent disabled users from showing up in LDAP search results. And user tokens will not work for users that cannot be found in any configured security realm.

Note that the above configuration will only work for Active Directory.For reference: http://support.microsoft.com/kb/269181

Developing extensions or clients for Nexus Repository Manager Professional may require access to Sonatype's private Nexus development repository.

Before you begin, you need:

A valid Nexus Professional license

Sonatype support account credentials. These are the credentials you use to login to https://support.sonatype.com and https://issues.sonatype.org and they must be associated with your Sonatype license

What can I access?

Closed source binary/runtime jar and javadoc files will be downloadable, primarily those under a com.sonatype group id. Source jars remain unavailable.

Configure Access to the Sonatype Nexus Private Development Repository

There is a repository which can be added to your Nexus instance that will allow you to create plugins that interact with Nexus Repository Manager Pro or OSS. The repository URL is:

https://repository.sonatype.org/content/groups/private-nexus-dev/

Here's what you'll need to do:

Create a Maven 2 releases proxy repository in your nexus instance for the above URL. Be sure to put your support account credentials into the "authentication (optional)" part of the proxy repository's configuration - credentials are necessary to access this repository.

Add this proxy repository to your "public" group repository.

How to Install a NXRM Pro 2.x License

To install a binary Nexus Professional 2.x license bring up the UI in a web browser. The default URL for Nexus is:

http://localhost:8081/nexus

You'll see the trial activation screen below:

Nexus 3 License Installation

Click on the "Already have a license?" link. This will take you to the license installation screen:

Now click on the "Already have a license file?" link:

Click on "browse...", locate your license file, then click "Install". You'll be presented with the EULA dialog:

Click on "I Agree", and your license will be installed. You'll be taken to the home page of the server. You can log in with the default username and password, "admin/admin123".

After logging in you can verify your license by clicking on the "Licensing" link under "Administration" in the left hand navigation:

Problems?

In some rare cases you may experience problems installing your license via the UI. You can also try a more advanced command line alternative.

Looking for NXRM 3.x License Install Instructions?

Nexus 3 ships as a single binary which contains both free and pro customers. To activate the licensedfeatures in Nexus 3 followthese instructions:

This article applies to Nexus Repository Manager 3.1 and greater only.

Install a License Using the User Interface ( recommended )

Installing your product license file using the user interface is the standard method to install your license.

How to Install a License Using a System Property

Supported in Nexus 3.6.1 and newer.

This method is mainly intended to assist licensing a brand new setup of a high-availability master node repository manager instance that is unlicensed. If a license is already installed, installing a license using this method will not work.

Locate your repository manager installation <data-directory>. By default this is ./sonatype-work/nexus3 relative to the <app-directory>.

Create a new file, or edit the existing file at path <data-directory>/etc/nexus.properties .

Add the following property in that file:

nexus.licenseFile=/absolute/path/to/your/nexus/repository/manager/license.lic

The referenced license.lic file should be the license file you were provided by Sonatype and readable by the user owning the repository manager process.

Start Nexus. The nexus.log will contain messages indicating success or failure of reading the license file using this method. Examples:

2017-10-23 14:40:19,654-0500 INFO [jetty-main-1] *SYSTEM com.sonatype.nexus.licensing.ext.internal.NexusLicenseInstaller - Installing license from property nexus.licenseFile=/absolute/path/to/your/nexus/repository/manager/license.lic

2017-10-23 14:40:19,654-0500 INFO [jetty-main-1] *SYSTEM com.sonatype.nexus.licensing.ext.internal.NexusLicenseInstaller -Ignoring property nexus.licenseFile=/absolute/path/to/your/nexus/repository/manager/license.lic. A license is already installed.

How to Override the Installed License File Location

Linux and OSX Only. Windows not applicable.

You can override the default location of the Java user prefsusing a system property, which can change the location where the license will be stored or read from.

Find and edit the file <app_dir>/bin/nexus.vmoptions

At the end of the file, add a new line like this:

-Djava.util.prefs.userRoot=/absolute/path/to/already/created/directory

The absolute path should point to an already created directory readable by the user account owning the repository manager process. Under this new directory, Nexus will expect to find the license file at a pathcom/sonatype/nexus/professional/prefs.xml This is also the directory where the product license will be written too when installed by a supported method.

How to Copy an Installed License from Another NXRM

Linux and OSX Only. Windows not applicable.

Once installed, the Nexus Repository Managerlicense is stored in the Java user preferences store directory for the user which owns the NXRM process. It is technically possible to move an already installed license file from a licensed NXRM server instance to another unlicensed NXRM server instance, since licenses can be installed in multiple servers.

By default. the product license can be found in the home directory of the user running Nexus at this location:

~/.java/.userPrefs/com/sonatype/nexus/professional/prefs.xml

This means you can install the license using a supported method first for one process user, then just copy that file over to a new host or different user accountand you'll have an installed license for that process user account as well.

How to Install a License Using the Karaf Console

Stop Nexus gracefully

Enable the Apache Karaf console interface. Edit the file bin/nexus.vmoptions and change this line from "false" to "true":

-Dkaraf.startLocalConsole=true

Start Nexus in console mode using the run command:

./bin/nexus run

./bin/nexus /run (on Windows)

Pressenter to drop to the Apache Karaf console prompt, then run the following command:

nexus:license -m install -f /absolute/path/to/license/file/license.lic

In IQ Server, there is a list of repository names and a repository manager column showing an opaqueID value. The ID may look similar to this:

104EFEB3-C814DA61-B552CB41-AD6442A0-C579CFA8

In the case where there are multiple repository manager instances using the same IQ server and similar repository names, determining which NXRM instance is being referred may be unknown.

The repository ID shown in IQ Server is the node-id value in repository manager 3x.

You can get the node-id from a repository manager REST resource when authenticating as an administrator user: NXRM version 3.8.0 and newer: http://localhost:8081/service/rest/atlas/system-information

NXRM version 3.0.0 to 3.7.1:http://localhost:8081/service/siesta/atlas/system-information Example:

curl -u admin:admin123 http://localhost:8081/service/rest/atlas/system-information -s | jq | grep node-id "node-id": "104EFEB3-C814DA61-B552CB41-AD6442A0-C579CFA8"

There is also a UI showing this value and button to download the JSON in the UI as well under Administration -> Support -> System information.

This information is now maintained at https://help.sonatype.com/iqserver/installing/upgrading-the-iq-server.

Note: This article applies to Nexus Repo versions3.3.0 to 3.6.0. The issue that causes this was fixed in version 3.6.1.

If you see the following error in the Nexus logs when running the task "Purge unused docker manifests and images", then you have hit a bug where a docker blob has been misidentified as a manifest.

2017-07-05 06:06:35,729+0000 ERROR [quartz-1-thread-1] *SYSTEM org.sonatype.nexus.repository.docker.internal.DockerGCTask - Failed to run task 'Purge unused docker manifests and images' on repository 'Docker'org.sonatype.nexus.repository.docker.internal.V2Exception$ManifestInvalid: manifest invalid

See the following jira for more details.

https://issues.sonatype.org/browse/NEXUS-12962

Below are the recovery steps:

Shutdown Nexus

Make a backup of "sonatype-work/nexus3/db/component".

Then open a command prompt and run:

java -jar <nrexus-install>/lib/support/nexus-orient-console.jar

This will open a prompt. At that prompt execute the following commands (you may need to change depending on your sonatype work location):

connect plocal:sonatype-work/nexus3/db/component admin admin

update asset set attributes.docker.asset_kind='BLOB' where format='docker' and name like '%/blobs/%' and attributes.docker.asset_kind='MANIFEST'

exit

This will convert this blobstore file back into an asset of type "BLOB" which is what is should be.

After executing the above commands restart the server.

Symptom

You are trying to push a docker image to Nexus and Docker complains with a message similar to:

Error pushing to registry: Put /v2/ubuntu/blobs/uploads/81ad3e90-544a-4bf6-88bf-acd92b479f69?digest=sha256%3Aa3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4: unsupported protocol scheme ""

Cause

This is a known issue that occurs when using Docker 1.7.1 (and probably earlier) with Nexus 3.

Solution

Upgrade to Docker 1.8.0 or later to solve this, version 1.8.0 is the minimum version supported by Nexus Repo.

The information on this page is now available in the documentation pages.

Nexus Repository OSS Download Archives

It is not possible to enable anonymous access to the IQ Server component details in Nexus Repository Manager.This is an intentional design decision, the data is considered sensitive, and so a login is required.To enable viewing this information for a logged in user, give them a role with the following privileges:

nx-healthcheck-alerts-read

nx-repository-view---read

nx-repository-view---browse

Published:2019-02-05

Revisions: 2019-06-12,2019-03-04, 2019-02-28

Affected Versions: Nexus Repository Manager 3.x OSS/Pro versions up to and including 3.14.0

Fixed in Version:Nexus Repository Manager OSS/Pro version 3.15.0

Risk: Critical - 10 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Summary

Insufficient access controls have been discovered in Nexus Repository Manager 3 which allow remote code execution.

An unauthenticated user can craft requests in a manner that can execute arbitrary code and programs on the host system. We have mitigated the issue by adding the necessary access controls as well as disabling the ability to execute arbitrary java code via this path. This advisory provides the pertinent information needed to properly address this vulnerability, along with the details on how to reach us if you have any further questions or concerns.

This vulnerability was identified by external researchers and has been verified by our security team. As of February 28, 2019 Sonatype has become aware that exploit instructions are being published by third-parties. Additionally, as of June 12, 2019 Sonatype has also become aware that an exploit for this vulnerability has been added to the arsenal of a botnet.We are not aware of any active exploits taking advantage of this issue.We strongly encourage all users of NXRM to immediately take the steps outlined in this advisory.

As the identified vulnerability allows an unauthenticated attacker to run arbitrary code or programs on the host system,we are highly recommending all instances of NXRM be upgraded to3.15or later.

The vulnerability associated with this advisory is fixed in NXRM 3.15 and above. The latest version of NXRM 3.x can be downloaded from:

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

For detailed information on upgrade compatibility, please see:

https://support.sonatype.com/hc/en-us/articles/115000350007

Credit:

Sonatype thanks Rico @ Tencent Security Yunding Lab and voidfyoo @ Chaitin Techfor responsibly reporting the identified issues and working with us as we addressed them.

Support:

If you run into any problems, or have any questions/concerns, please contact us by filing a ticket at https://support.sonatype.com.

Frequently Asked Questions:

Q: What is the risk associated with this vulnerability?

A: An unauthenticated attacker can inject and execute code on the server potentially affecting confidentiality, integrity, and availability.

Q: What preconditions must be met in order to be vulnerable?

A: The attacker would need to send specially crafted requests to NXRM.

Q: Are there implications associated with this advisory itself?

A: Disclosure unfortunately means bad actors may try to take advantage. While we have initially limited the information to the minimum details necessary for users to affect an appropriate fix, this merely slows down a would be attacker. As such, we are advising all organizations utilizing Nexus Repository Manager to immediately assess their individual impact and take appropriate action in response.

Q: Where can I obtain more information associated with the vulnerability?

A: At this time, and in the interest of best protecting our user community, we are limiting the information released to that absolutely required in order to assess impact and affect remediation. Please contact support for more information.

Q: Why is Sonatype making this information available?

A: This is part of a responsible disclosure process. Given Nexus Repository Manager is an open source project with over 150,000 active server installations, notifying the user base will invariably lead to broad dissemination. We are taking a concerted and proactive approach in our outreach activities and an effort to achieve the most rapid remediation possible.