How to verify HSTS is running on NetBackup servers

Problem

HSTS (HTTP Strict Transport Security) is enabled by default in NetBackup 9.0 and higher versions. However, security scans indicate that it is not enabled.

Cause

For NetBackup 9.0 and later, or earlier versions where HSTS was manually enabled, this issue is a false positive from the scan application.

Solution

Verify the false positive and that HSTS is enabled with the following curl command:

1. Open up the NetBackup web console
2. Open a cmd prompt.
3. Navigate to the path:

• Unix/Linux: /usr/openv/netbackup/bin
• Windows: x:\Program Files\Veritas\NetBackup\bin

4. Run the command:

• Unix/Linux:  curl -v -k https://2016-master.vlab.lab/netbackup/ping 2>&1 | grep -i Strict
• Windows:    curl -v -k https://2016-master.vlab.lab/netbackup/ping 2>&1 | findstr /i Strict

Note: Replace 2016-master.vlab.lab with the local master server name (the name of the system where the command is being run from).

5. The command output will include the following line indicating HSTS is enabled:

Additional information:

Some scanners will continue to report this vulnerability even though HSTS has been enabled, because they are testing paths that are not in use by NetBackup. This may occur in any version. To attempt to mitigate these false positives in all 8.1.2 - 10.x.x.x versions:

1. Create empty “ROOT” folders under the existing webapps and webapps_api directories.

Linux: 

• /usr/openv/wmc/webserver/webapps_api/ROOT 
•  /usr/openv/wmc/webserver/webapps/ROOT 

Windows: 

• x:\Program Files\Veritas\NetBackup\wmc\webserver\webapps_api\ROOT
• x:\Program Files\Veritas\NetBackup\wmc\webserver\webapps\ROOT     

After creating these empty directories, the NetBackup Web Management Console service should be restarted.

2. If the folders are already present or if the issue is still not resolved, the scanner may continue to report the issue due to a name mismatch between the name the scan is directed at and the name present on the NetBackup certificates (the primary server name). This most often occurs because:

• one is the short name vs. the long name / FQDN
• one is a virtual name / cluster name vs. the individual node names
• aliasing

Try directing the scan to the name displayed on the NetBackup issued certificates to rule out this possible cause and resolve the scan warning.