Managing the Security ConsoleCopy link

Although the default Security Console settings should work for a broad range of network environments, you can change settings to meet specific scanning requirements.

Click Administer next to Console on the Administration > Vulnerability Management > Console Administration page to launch the Security Console Configuration panel.

View general configuration settingsCopy link

On the General page, you can view the version and serial numbers for the instance of the Security Console that you are using.

Change the Security Console Web server default settingsCopy link

The Security Console runs its own Web server, which delivers the user interface.

To change the Security Console web server default settings:

  1. Go to Administration > Vulnerability Management > Console Administration.
  2. Click Console > Web Server.
  3. Enter a new number for the access port.
  4. Enter a new session time-out.This value is the allowed number of seconds of user inactivity after which the Security Console times out, requiring a new logon.
  5. Enter new numbers for initial request and maximum request handler threads, if necessary.It is recommended that you consult Technical Support first. In this context, threads refer to the number of simultaneous connections that the Security Console will allow. Typically a single browser session accounts for one thread. If simultaneous user demand is high, you can raise the thread counts to improve performance. The Security Console will increase the thread count dynamically if required, so manual increases may be unnecessary.
  6. Enter a new number for failed logon threshold if desired.This is the number of failed logon attempts that the Security Console permits before locking out the would-be user.
  7. Click Save.
Use the restart command to apply your changes

To apply the changes, restart the Security Console. You can use the restart command with the Command Console.

Manage the HTTPS certificateCopy link

The application provides a self-signed X.509 certificate, which is created during installation. However, it is recommended that you replace it with a certificate that is signed by a trusted certifying authority (CA).

Use a CA-signed certificate (recommended)Copy link

Complete these steps to use a CA-signed HTTPS certificate.

Create an HTTPS certificate, which then can be signed by a CA.

To create an HTTPS certificate:

  1. Browse to the Manage Certificate window, located in Administration > Vulnerability Management > Console Administration.
  2. Go to Global and Console Settings > Administer > Web Server.
  3. Click the Manage Certificate button.
  4. Select Create New Certificate.
  5. Complete these fields with the required information:
    • Common Name- The hostname that you will access the on-premises console with (for example, mycompany.rapid7console.com). This value must exactly match the server name of theNexpose deployment where the certificate will be installed. Use commonName format (in other words, do not include port numbers or protocols, such as http:// or https://). Rapid7 does not support wildcard certificates.
    • RSA Key Size - The value that the CA will sign the certificate with. To find this value, refer to a certificate that your company previously had signed by this CA.
    • Signature Hash Algorithm - The value that the CA will sign the certificate with. To find this value, refer to a certificate that your company previously had signed by this CA.
    • Valid for (years) - The number of years until the certificate expires.
  6. Complete the remaining fields according to your company's policy.
  7. Click Create. To create a certificate signing request (CSR), click Create CSR Now and proceed to Task 2.

Set a SAN field to indicate which domains are secured by the certificate. You set the SAN field using a local terminal or shell, rather than through the Nexpose UI.

Important

Consoles using CA-signed certificates must have a SAN field. Self-signed certificates do not require a SAN field.

To set the SAN field:

  1. Open a terminal or shell.
  2. In your installation directory, check the keystores folder for a file called nscweb.ks (for example, <install-dir>/nsc/keystores/nscweb.ks).
    • If the file does not exist, complete the steps in Task 1 to generate it.
  3. Before you proceed: Make sure you have execute permission

    In order to complete the next step successfully, make sure you have execute permission on /opt/rapid7/Nexpose/_jvm1.8.0_232/bin/keytool, and verify with your network administrator that assigning execute permissions for this binary is acceptable.

    This can be done by running as administrator on Windows or issuing a chmod +x command on the Linux file from the command line.

    For Linux operating systems, complete these steps. For Windows operating systems, proceed to step 4:

    1. Log in via SSH into the Security Console server, and navigate to this directory: cd [install_dir]/rapid7/nexpose/_jvm1.8.0_232/bin
      • Note: You may have to edit the directory if you did not use the standard install directory. Also, ensure the directory that you've selected is correct, as some installations have a different version of the JVM than 1.8.0_232.
    2. Run the this command as root, replacing the samplehostname.com DNS and 127.0.0.1 IP address with the appropriate values for your console: ./keytool -certreq -alias nscweb -sigalg sha512WithRSA -keystore /opt/rapid7/nexpose/nsc/keystores/nscweb.ks -storepass 'r@p1d7k3y$t0r3' -ext san='dns:samplehostname.com,ip:127.0.0.1' -file filename.csr
      • Note: You may have to edit the directory in the command if you did not use the standard install directory.
  4. For Windows operating systems complete these steps:
    1. Open a PowerShell window as an administrator on the host machine and navigate to this directory: Set-Location "C:\Program Files\Rapid7\Nexpose\_jvm1.8.0_232\bin"
      • Note: You may have to edit the directory if you did not use the standard install directory. Also, ensure the directory that you've selected is correct, as some installations have a different version of the JVM than 1.8.0_232.
    2. Run this command as an admin, replacing the samplehostname.com DNS and 127.0.0.1 IP address with the appropriate values for your console: .\keytool.exe -certreq -alias nscweb -sigalg sha512WithRSA -keystore "c:\Program Files\rapid7\nexpose\nsc\keystores\nscweb.ks" -storepass 'r@p1d7k3y$t0r3' -ext san="dns:samplehostname.com,ip:127.0.0.1" -file filename.csr
      • Note: You may have to edit the directory in the command if you did not use the standard install directory.

In Nexpose, you can generate a CSR, which you can then send to a trusted CA that will sign the certificate. The signed certificate must be base-64 encoded and be in a supported format, such as .PEM, .CRT, or .CER.

To generate the CSR and send the certificate:

  1. If you selected Create CSR Now after creating the certificate in Task 1, proceed to step 3. If you selected Later after creating the certificate in Task 1, complete these steps:
    1. Browse to the Manage Certificate window, located in Administration > Vulnerability Management > Console Administration.
    2. Go to Global and Console Settings > Administer > Web Server.
    3. Click the Manage Certificate button.
    4. Select Generate CSR.
  2. Send the filename.csr file to the CA for signing.

Import the certificate that was signed by the CA in Task 3, so that you can use it in Nexpose.

Windows users should check for the SAN

When the CA signed the certificate, they should have taken SAN data in your CSR and added it to the certificate. Because the SAN data is not automatically added through the CSR, we recommended verifying to make sure that the CA added the SAN data during the signing process.

Run this command to check that the SAN is present: openssl x509 -text -noout -in SignedCert.crt

The details should contain something similar to the following:

X509v3 extensions: X509v3 Issuer Alternative Name: DNS:samplehostname.com, IP Address:127.0.0.1

To import the CA-signed certificate:

  1. Ensure that the certificate file is zipped, so that the certificate isn't stripped if the file is emailed across the network (for example, zip the .PEM file).
  2. Browse to the Manage Certificate window, located in Administration > Vulnerability Management > Console Administration.
  3. Go to Global and Console Settings > Administer > Web Server.
  4. Click the Manage Certificate button.
  5. Select Import Certificate.
  6. Select the CA-signed certificate.
  7. Restart the the Nexpose console in Administration > Vulnerability Management > Console Administration > Troubleshooting > Run Commands.
  8. After a couple of minutes, once the web services have restarted, check that the import was successful by accessing the Nexpose console. In the console, check the certificate.

Use a self-signed certificate (not recommended)Copy link

Complete these steps to use a self-signed HTTPS certificate.

Create an HTTPS certificate in Nexpose, which is self-signed by default.

To generate an HTTPS certificate:

  1. Browse to the Manage Certificate window, located in Administration > Vulnerability Management > Console Administration.
  2. Go to Global and Console Settings > Administer > Web Server.
  3. Click the Manage Certificate button.
  4. Select Create New Certificate.
  5. Complete these fields with the required information:
    • Common Name - The hostname that you will access the on-premise console with (for example, mycompany.rapid7console.com). This value must exactly match the server name of the Nexpose deployment where the certificate will be installed. Use commonName format (in other words, do not include port numbers or protocols, such as http:// or https://). Rapid7 does not support wildcard certificates.
  6. Complete the remaining fields according to your company's policy.
  7. Click Create.
  8. Click Later to exit without creating a certificate signing request (CSR).

Import the self-signed certificate that you created in Task 1, so that you can use it in Nexpose.

To import the self-signed certificate:

  1. Ensure that the certificate file is zipped, so that the certificate isn't stripped if the file is emailed across the network (for example, zip the .PEM file).
  2. Browse to the Manage Certificate window, located in Administration > Vulnerability Management > Console Administration.
  3. Go to Global and Console Settings > Administer > Web Server.
  4. Click the Manage Certificate button.
  5. Select Import Certificate.
  6. Select the self-signed certificate.
  7. Restart the the Nexpose console in Administration > Vulnerability Management > Console Administration > Troubleshooting > Run Commands.
  8. After a couple of minutes, once the web services have restarted, check that the import was successful by accessing the Nexpose console. In the console, check the certificate.

Troubleshoot certificate issuesCopy link

Use this section to troubleshoot common errors when managing the HTTPS certificate.

This error might display in the browser if the endpoint accessing the console has issues with the certificate. To troubleshoot, expand Learn more in the browser and review the information.

This error might display in the browser if the SAN data is missing from the certificate. To troubleshoot, open the certificate in the browser, and review its details to ensure that the SAN field has been set.

This error might display in Nexpose if the certificate data has formatting issues. To troubleshoot, review the certificate to ensure that it is formatted correctly.

If sending the certificate file between machines, always zip the certificate file first to ensure that the formatting is preserved.

Change default Scan Engine settingsCopy link

The Security Console communicates with distributed Scan Engines over a network to initiate scans and retrieve scan results. If you want to obtain scan status information more quickly or reduce bandwidth or resource consumption required for Security Console to Scan Engine communication, you can tune various settings on the Scan Engines page of the Security Console Configuration panel.

Configure Security Console connections with distributed Scan EnginesCopy link

The Security Console establishes connections with distributed Scan Engines to launch scans and retrieve scan results. This communication can be disrupted by low network bandwidth, high latency, or situations in which Scan Engines are performing high numbers of simultaneous scans. If any of these conditions exist in your environment, you may want to consider increasing connection settings on the Scan Engines configuration page:

It is recommended that you consult with Technical Support before tuning these settings.

The Connection timeout setting controls how long the Security Console waits for the creation of a connection with a distributed Scan Engine. The Response timeout setting controls how long the Security Console waits for a response from an Scan Engine that it has contacted.

To configure these settings:

  1. Go to the Scan Engines page in the Security Console Configuration panel.
  2. Go to Administration > Vulnerability Management > Console Administration.
  3. Click manage for the Security Console.
  4. Click Scan Engines in the Security Console Configuration panel.
  5. Adjust the Connections settings.
  6. Edit the value in the Connection timeout field to change the number of milliseconds that elapse before a connection timeout occurs.
  7. Edit the value in the Response timeout field to change the number of milliseconds that elapse before the Security Console no longer waits for a response from an Scan Engine.
  8. Click Save in the top bar of the panel to save the changes.
  9. Restart the Security Console so that the configuration changes can take effect.
Because millisecond values can be difficult to read, a time value that is easier to read appears to the right of each value field. As you change either timeout value, note how the equivalent value changes.

Allocate threads for monitoring scansCopy link

The Security Console allocates a thread pool for retrieving scan status information. You can adjust the number of threads, which corresponds to the number of scan status messages that the Security Console can retrieve simultaneously. For example, if you increase the number of distributed Scan Engines and the number of scans running simultaneously, you can increase the threads in the pool so that the Security Console can retrieve more status messages at the same time.

It is recommended that you consult with Technical Support before tuning these settings.

Keep in mind that retrieval time is subject to network conditions such as bandwidth and latency. Whenever the number of active threads in use exceeds the overall number of threads in the pool, the Security Console removes unused scan status threads after specific time interval. If you notice an overall decrease in the frequency of scan status messages, you may want to consider increasing the timeout value.

  1. Go to Administration > Vulnerability Management > Console Administration and click Scans > Engine Pools.
  2. Click Scan Engines in the Security Console Configuration panel.
  3. Adjust the Scan Status settings.
  4. Edit the value in the Thread idle timeout field to change the number of milliseconds that elapse before the Security Console removes unused scan threads.
  5. Edit the value in the Thread pool size field to change the number of threads in the pool for monitoring scan status.
  6. Click Save in the top bar of the panel to save the changes.
  7. Restart the Security Console so that the configuration changes can take effect.
Because millisecond values can be difficult to read, a time value that is easier to read appears to the right of each value field. As you change either timeout value, note how the equivalent value changes.

Retrieve incremental scan results from distributed Scan EnginesCopy link

The Security Console communicates with Scan Engines over a network to retrieve scan results. By default, the Security Console retrieves scan results from distributed Scan Engines incrementally, displaying results in the Web interface as it integrates the data, rather than retrieving the full set of results after each scan completes. This allows you to view scan results as they become available while a scan is in progress. Incremental retrieval modulates bandwidth usage throughout the scan. It also makes it unnecessary for the Security Console to retrieve all the data at the end of the scan, which could cause a significant, temporary increase in bandwidth usage, especially with large sets of data.

The Scan Engines page of the Security Console Configuration panel displays a check box for incremental retrieval of scan results. It is selected by default. Do not disable this option unless directed to do so by Technical Support.

Run in maintenance modeCopy link

Only global administrators are permitted to run the application in maintenance mode.

Maintenance mode is a startup mode in which the application performs general maintenance tasks and recovers from critical failures of one or more of its subsystems. During maintenance mode, you cannot run scans or reports. Available functions include logging, the database, and the Security Console Web interface.

The application automatically runs in maintenance mode when a critical internal error occurs.

When the application is running in maintenance mode, you see the page /admin/maintenance/index.html upon logging on. This page shows all available maintenance tasks and indicates the current status of the task that is being performed. You cannot select a new task until the current task is completed. Afterward, you can switch tasks or click Restart to return to normal operating mode.

To work in Maintenance mode:

  1. Go to Administration > Vulnerability Management > Console Administration.
  2. Click Database > Maintenance.The Security Console displays the Maintenance Mode page.