Using SSL to Secure Your Vulnerability Data

The Benefits of Proper SSL Configuration

Protecting your vulnerability data from unauthorized users, whether the threat comes from external attackers or malicious insiders, is an important part of a vulnerability management program. Nessus allows users to configure SSL to provide both privacy and authentication. SSL can be configured locally or integrated into your own PKI infrastructure, allowing Nessus to be compliant with in-house security policies and standards.

While Nessus comes with a default set of SSL certificates, some configuration by the end user is required to eliminate web browser errors indicating invalid certificates. First, the hostname or IP address tied to the SSL certificate will be different for every Nessus user. In addition, since the name is an unknown variable, we do not distribute a CA certificate that is recognized by your web browser. Organizations may have their own PKI implementation used to issue valid SSL certificates, which is the best option for configuring secure connections to a Nessus server. Generating a valid SSL certificate improves the security of the connection between clients and the Nessus server, making it difficult for attackers to perform Man-in-the-Middle attacks. While there are several known attacks against the SSL protocol, there are significant security benefits to a proper SSL configuration.

The second phase to improve Nessus security is to generate SSL client certificates. This eliminates the need for username and password combinations to authenticate to the Nessus server. It improves the security of the login process, and prevents remote attackers from being able to perform password brute-force attacks.

Generating Server-Side SSL Certificates for Nessus

Nessus includes several command-line tools for SSL certificate management. The examples below demonstrate how to generate your own local SSL certificates. The Nessus User Guide goes into more detail on how to generate certificates if you've implemented your own PKI infrastructure.

The first step is to issue the command /opt/nessus/sbin/nessus-mkcert. This allows you to generate an SSL certificate that matches the name (or IP address) of your Nessus server.

I set higher limits on the certificate lifetime, as this is a local server that will primarily be used by one or two users. The hostname is one of the most important fields; this must match the name or IP address used to access the server.

NOTE: Certain web browsers, such as Google Chrome, will identify the certificate as invalid if it does not contain the "." character. For example, the first time I generated the certificate I used the name "nessusserver" and when I accessed it using Google Chrome, it complained and informed me the certificate was invalid. I appended the ".local" and the error messages no longer appeared.

The command above also provides you with a CA (Certificate Authority) certificate that you can import into your web browser, allowing it to trust the certificates you've generated. To install the new CA certificate in your browser, visit the URL https://nessusserver.local[Nessus Server IP]:8834/getcert (where "nessusserver.local" is the name or IP address of your Nessus server). Using Google Chrome as an example, I imported the CA certificate. You can see it listed below in the entry titled "Nessus Users United":

During the import of the CA certificate I chose to only trust it for use in identifying websites:

The next step is to add the name "nessusserver.local" (or the name of your server) to either your local hosts file if it is not in your configured DNS server. I chose to add it to my /etc/hosts file, since I only access this particular Nessus server from one host:

The final step is to visit your Nessus server using the host name:

Notice the lock and "https" portion of the URL is green, meaning that Google Chrome has identified it as a valid SSL certificate. Clicking the lock provides the full details of the certificate:

The steps above will differ slightly depending on the web browser used to access your Nessus server, but the concepts remain the same.

Creating and Using Client Certificates

Nessus includes another command-line utility to generate client-side SSL certificates to authenticate users. You can run /opt/nessus/sbin/nessus-mkcert-client as follows:

Copy the newly-created files from the /tmp directory listed in the output, then run the following command (as shown in the Nessus Installation and Configuration Guide):

openssl pkcs12 -export -out combined_bob.pfx -inkey \
key_bob.pem -in cert_bob.pem -chain -CAfile  /opt/nessus/com/nessus/CA/cacert.pem \
-passout pass:'sekretPassword' -name  'Nessus User Certificate for: bob'

The command above will package the certificates into a format that can be imported into your web browser. For example, using Mac OS X, I was able to double-click on the "combined_bob.pfx" file and add it to the operating system's keychain:

I accepted the defaults, adding it to the login keychain and clicked "Add". Next, you will need to change your Nessus server preferences to include the option "force_pubkey_auth" and set it to the value of "yes". This preference entry does not exist by default, but can be added by navigating to the “Configuration” button, selecting the “Advanced Settings” tab, and then "Add Setting. To activate this change, you must restart your Nessus server (/etc/init.d/nessusd restart for all UNIX/Linux systems).


Once the server restarts, visit the URL of your Nessus server and you will be prompted to use the certificate to authenticate:

Nessus will not prompt you for a username or password and you will be taken directly to the Nessus interface. Note that once you've enabled SSL authentication you will no longer be able to log in using a username and password unless you remove the "force_pubkey_auth" setting.

Conclusion

While it may seem tedious at first, the security benefits are well-worth the time spent configuring SSL properly. Nessus will not overwrite your SSL certificates, so once new certificates are created, the SSL management is performed by the end user. For more information, please refer to the Nessus documentation.