Nessus Scans
Topic: Elastic Tests
Related: Sonar Scans, Import a Test Asset, Fortify Scans, Elastic Test Tools

Nessus is a test tool used to identify system vulnerabilities (NOTE: Nessus is known as ACAS in the DISA community). Nessus allows scans for many types of vulnerabilities such as:

  • Vulnerabilities - scan for weaknesses that a remote hacker can use to control or access sensitive data on a system
  • Misconfiguration - (e.g. open mail relay, missing patches, etc.)
  • Default passwords - Scan for common passwords, and blank/absent passwords on some system accounts. Nessus can also call Hydra (an external tool) to launch a dictionary attack
  • Denials of service - Scan against the TCP/IP stack by using malformed packets
  • PCI DSS Audit - Scan with specific templates to prepare for audits

Nessus Test Assets allow for on demand vulnerability scanning and auditing of all deployment runs (i.e., both newly provisioned and long standing). There are two ways in which Nessus Test Assets can be used:

  1. Part of a Deployment - By default, adding a Nessus Test Asset to a deployment will scan all hosts that are part of that deployment. If one or more targets are specified in the deployment properties (see below), only those specific targets will be scanned
  2. Test-Only Deployment - Nessus Test Asset is stood up as its own deployment run and will scan targets specified in the deployment properties (see below)

Nessus documentation can be found at the Tenable site here: https://docs.tenable.com/Nessus.htm

How to use the Nessus Elastic Test Tool

The basic steps for running a Nessus test using the community test case are outlined below and detailed in the following steps:

  1. Select Test Case
  2. Configure Deployment
  3. Run Test
  4. Review Results
  5. (Optional) Repeat

Nessus Test Structure

All Nessus Test Cases consists of a Policy file and (optional) Audit file. A scan policy consists of configuration options related to performing a vulnerability scan. These options include, but are not limited to:

  • Parameters that control technical aspects of the scan such as timeouts, number of hosts, type of port scanner, and more.
  • Granular plugin family or individual plugin based scan specifications.
  • Compliance policy checks (Windows, Linux, Database, etc.), report verbosity, service detection scan settings, audit files, patch management systems, and more.

Once the policies have been configured and included in a Nessus Test asset, they can be repeatedly used with little effort.

1. Select a Test Case

Running a Nessus test begins with selecting the Nessus Test asset. It is possible that community Nessus tests will fit your needs; if that is the case, choose the test most appropriate to your application. If you can’t find a community Nessus ETT asset that will suit your needs, don’t despair. Building a new Nessus Test Case is straight forward.

Note: If you change the credentials on your template, you will need to update this test case. Credentials for devices to be audited are required for Nessus to log into the target servers. If the user performing the audit does not have “Super user” privileges, many of the remote system commands will not be able to be run or will return incorrect results.

Building a Nessus Test

First, create a scan policy within Nessus. If you have a specific audit file that you would like to use, you must first upload it into Nessus. Instructions for uploading an audit file and creating a scan policy in Nessus can be found here. Note that the profile chosen will be based on your system’s MAC level (e.g., MAC-2_Sensitive).

Once a new scan policy is created, you must download it from Nessus. Additionally, you have to download an example Nessus Test asset from Arcus. After the two files are downloaded, unzip the Nessus Test and rename the folder to something that makes sense to you (e.g., Nessus_RHEL_7_STIG).

Follow these steps after unzipping the Nessus Test asset:

  1. Replace the .nessus file in the “config” directory with the scan policy you created
  2. Update the nessus-config.properties file in the “config” directory with the name of the Nessus policy file you just created. The nessusPolicy field must reference the exact name of the policy file you placed in the “config” directory.
  3. Update the following fields in the asset.properties file
    • name - Name the test something simple that represents the scan policy (e.g., RHEL 6 STIG
    • description - Describe what the test will do in enough detail such that other users could understand what the test will accomplish
    • pocEmail, pocName, pocOrganization - Put your information in these fields so that other users could reach out to you for questions if they were to use the test case
  4. Update the README file
  5. Zip the entire Nessus Test directory and upload to Arcus by using the “Import test asset” button in the Tests portion of the asset library

If everything was done correctly you will get a notification that your test asset was imported successfully. At that time you can begin using your new Nessus Test asset.

2. Configuring Deployment Properties

After selecting the appropriate Nessus test, you will need to configure the deployment. This step only needs to be completed once, because the deployment can be reused over and over. The deployment can be configured with or without a Scenario. If the deployment has a scenario, Nessus will scan all the systems in the scenario by default. If the deployment doesn’t have a scenario, Nessus will scan systems identified as targets in Custom Properties.

Nessus Test Assets accept the deployment properties described below.

  • nessus.targets :  Specifies the target host(s) to scan. Should only be used as part of a Test-Only Deployment
    Targets can be entered by single IP address (e.g., nessus.targets=192.168.0.1), set of IPs (e.g., nessus.targets=192.168.1.1,192.168.1.3,192.168.1.24), IP range (e.g., nessus.targets=192.168.0.1-192.168.0.255), subnet with CIDR notation (e.g., nessus.targets=192.168.0.0/24), resolvable host (e.g., nessus.targets=www.nessus.org), or a single IPv6 address (e.g., nessus.targets=link6%eth0, fe80::2120d:17ff:fe57:333b, fe80:0000:0000:0000:0216:cbff:fe92:88d0%eth0).
  • nessus.format :  Specifies the format of the report.
    Options are pdf, html, and db (nessus and csv formatted reports will be generated in addition. Default is pdf). Example: nessus.format=html
  • nessus.chapters :  Specifies the chapters to include in report. Expect a semi-colon delimited string comprised of some combination of the following options: vuln_hosts_summary, vuln_by_host, compliance_exec, remediations, vuln_by_plugin, compliance (e.g., nessus.chapters=vuln_by_host;vuln_by_plugin). See http://static.tenable.com/documentation/nessus_6.4_user_guide.pdf for information about Nessus Chapters.

Default: vuln_hosts_summary or vuln_hosts_summary;compliance if audit file is detected

Configuring Nessus Test Assets

The following describes the different components of a Nessus Test Asset.

  • nessus-config.properties: This file allows the user to specify what files within the test asset correspond to one of the following configuration files
  • In Arcus the following keys are used, which if present must exist in the config directory of the test asset

nessusPolicy=nessus_policy_Full_Scan_Policy.nessus

  • nessus.credentials=nessus-credentials.txt
  • nessus.audit=test.audit
  • nessus.audit-category=Unix

Any file provided must exist in the scripts directory

nessus.policy=nessus_policy_Full_Scan_Policy.nessus

  • nessus.credentials=nessus-credentials.txt
  • nessus.audit=test.audit
  • nessus.audit-category=Unix
  • Policy File : A .nessus file that details what families of plugins to run during scanning. These files can be created on a nessus scanner and exported.
  • Credentials File : This file allows for the inclusion of credentials within a Nessus scan. Each set of credentials must be passed by detailing the following information:
    • Credential Type : WINDOWS_PASSWORD, SSH_PASSWORD, SSH_SUDO, SSH_SU
      Username : the username of the user for the given credentials 
      Password : the password of the user for the given credentials
    • The following two fields must be provided if the credentials are of type SSH_SUDO or SSH_SU
      • Escalation Account : the account username to escalate to
      • Escalation Password : the password required to escalate permissions

Note: Multiple credentials can be passed as long as they are separated by the pattern: --break--

An example credentials file would appear as follows:

* 
credential_type=WINDOWSPASSWORD
* username=administrator
* password=your_password
* 
* --break--
* 
* credential_type=SSH_PASSWORD
* username=root
* password=your_password
* 
* --break--
* 
* credential_type=SSH_SUDO
* username=underprivileged account
* password=yourpassword
* escalation_account=privileged account
* escalation_password=sudopassword
* 
* --break--
* 
* credential_type=SSH_SU
* username=underprivileged account
* password=yourpassword
* escalation_account=privileged account
* escalation_password=supassword
  • Audit File : This file allows for the configuration of audits to be run against the system(s) in question, and for their compliance to that audit to be measured ie: passed, or failed. Audit files can be of two types, Unix and windows. In order for an audit file to run, there must be credentials of that corresponding type included as well. Additional audits are at the discretion of the user, although Arcus reccomends automation of Nessus Scans on each deployment
    • The audit file in the basic Nessus test asset is included to display the intended use and reporting changes that come with the inclusion of an audit file in a Nessus scan, as the audit itself merely determines whether or not the system (if unix) has a password greater than 14 characters.

For Example the default audit file contains:

* <check_type: "Unix">
* </item>
* name: "min_password_length"
* description: "Minimum password length"
* value: "14..MAX"
* </item>
* </check_type>

3. Run Test

Now you are ready to run the test.

4. Review Results

After the test is completed, results are available in the browser for viewing and download. The results are retained even after the scanner VM is released.

NOTE: If you click the Delete button on the Run, the history and the results will be gone.

(Optional) 5. Repeat

Optionally, after the run is complete you get a new set of scan results by clicking the Retest or Rerun button.

  • Retest - This button runs your Nessus Scan again. It does not update the underlying system or plugins. New scan results useful if you have done some mitigation on the systems under test, or updated your assets.
  • Rerun - This button will relaunch the Nessus Scanner and rerun your Nessus Scan, including picking up any system, plugin updates, policy, and or test updates.

Recap

The Nessus ETT has many benefits:

  • No need to be an ACAS expert. You can easily run the test by simply adding a community-provided Nessus test case to your deployment
  • The scanner is automatically built and updated with each new run
    • Policies and audit files automatically updated to the latest
    • Your Nessus Scan is automatically run
    • Test assets are customizable (Credentials, Policies, Audits, IP ranges, Report content, Report format)
  • Scan results saved until run is RELEASED and DELETED
  • Results are available without a running scanner

Tips

  • If you change the credentials on your template, you will need to update this test case. Credentials for devices to be audited are required for Nessus to log into the target servers. If the user performing the audit does not have “Super user” privileges, many of the remote system commands will not be able to be run or will return incorrect results.

Known Issues

  • If you encounter a Test Error in a Nessus Scan with an error message including invalid credentials, simply click the Re-Test button. This is an issue with the Nessus product, and we are working on a fix to avoid this issue in the future.

More Help

Review this process with our video tutorials: