Configuring Least Privilege SSH scans with Nessus

Credentialed scans have long been advocated as the quickest and most accurate way to perform a vulnerability assessment against any network. But like with all things technology, it runs into two usual roadblocks: people and processes.

When the topic of credentialed network scans is discussed it inevitably leads to questions such as, who is requesting access and why? What level of privileges is needed and why? Which commands will be run and why? All legitimate questions which should be rightly asked before granting access to any system. But the back-and-forth between different teams typically leads to a long, drawn-out process eventually resulting in either the requestor being denied access or getting access to a limited account which may lead to incomplete scan results.

To help solve this problem, our customers have asked us to provide transparency around which commands are run by a Nessus® scan, what privileges are required to run the commands and if the commands failed, which Nessus plugins would fail as a result. An additional requirement was to provide this information in an easy-to-consume output format so that they can configure a scan account while having the least privileges and still be able to perform a complete and accurate scan.

With the recent release of Nessus 6.11, we are taking steps to address that issue by releasing a beta feature which will allow our customers to do just that across™ Vulnerability Management, Nessus and Security Center™.


  • Nessus 6.11 or later, either standalone or managed by Vulnerability Management or Security Center
  • Scan Target Operating System
    • CentOS, Redhat, Amazon Linux, SuSE, Ubuntu, Debian, HP-UX, Scientific Linux, AIX, Oracle Linux, Gentoo.

Scan Configuration

At a high level, the process can be summarized in five simple steps :

  1. Configure a scan account to run with sudo privileges
  2. Enable ‘Attempt Least Privilege’ preference in scan policy
  3. Review plugin output of Nessus plugin IDs #102094 and #102095
  4. Update /etc/sudoers file based on results on plugin #102094
  5. Repeat Step 4, until commands which run with higher privileges are accounted in /etc/sudoers file

Step 1 : Configure user to run commands via sudo

Log in to the system as the root user and create a normal user account. Run visudo to edit the /etc/sudoers file, and add the commands the user is allowed to run with sudo. In the example below I created a user ‘nessus_scan_account’ assigned it SUDOER User_Alias who can run the ‘/usr/bin/dmidecode’ command which requires root privileges to run.

Subdoer File

Step 2. Enable ‘Attempt Least Privilege’ checkbox in scan policy

Follow the below steps to enable ‘‘Attempt Least Privilege’ preference in the scan policy. Vulnerability Management & Nessus

Click Scans -> New Scan -> Advanced Scan -> Credentials -> SSH -> Attempt Least Privilege

When this preference is enabled, Nessus plugins attempt to execute commands with least privileges (i.e. without privilege escalation), and if the initial attempt fails, it retries executing the command with privilege escalation. It also logs commands which failed and succeeded with privilege escalation and reports the information in two plugins (#102094, #102095) which will be discussed in the next steps. As a result of running the same command twice, customers should note the scans could run 10-30 percent slower according to our lab tests.

Security Center

For Security Center, follow the below screens to enable the preference.

Click Scans -> Policies -> Add -> Advanced Scan -> Authentication -> Attempt Least Privilege


Step 3 : Review Plugin Outputs

Once the scan finishes, review output of plugins #102094 and #102095 to determine which plugins successfully ran with privilege escalation and which plugins failed due to insufficient privileges.

SSH Commands Ran With Privilege Escalation (#102095)

Plugin #102095 reports all plugins which ran with escalated privileges. The plugin output is in YAML, and includes information about the account used, plugin file name, id, name and the command it ran. This plugin will help users verify only authorized commands are run with sudo privileges.

Commands Passed

SSH Commands Require Privilege Escalation (#102094)

Plugin #102094 reports all plugins which failed to run with escalated privileges due to insufficient privileges. As was the case in the previous plugin, the plugin output is in YAML to facilitate easier creation of /etc/sudoers file. It includes information about the account used, plugin file name, id, name, and the command it ran.

Customers should review the output of this plugin to fine tune the commands which can be run with the sudo account. Note the command ‘cat /etc/shadow’ failed in the below example. We will resolve this issue in the next step.

Commands Failed

Step 4 : Update /etc/sudoers file

In the previous step, plugin #102094 reported execution of command ‘cat /etc/shadow’ failed due to privilege escalation failure. We can easily resolve this by adding ‘/bin/cat /etc/shadow’ as an allowed command to the SUDOER alias we created earlier in /etc/sudoer file, which will allow the next scan to run this command successfully with escalated privileges. You could also continue to block certain privileged commands from running by not updating the /etc/sudoers file and accepting the risk of certain vulnerabilities not being detected due to incomplete information.


Step 5 : Repeat

To perform an accurate authenticated scan, repeat step four such that commands that fail are accounted in the /etc/sudoers file.  

At this point, one might wonder, “Why not just share a static list of ssh commands with customers?” The reason is two-fold. First, we routinely add new commands to our plugins, so there is a risk of a static file going stale. And second, we don’t always know if a command will require admin privileges across a wide variety of operating systems.


In this blog post, we demonstrated how a user can create a tailored Nessus scan account to perform authenticated scans over SSH with the least privileges required to perform the scan. Currently, the feature is supported on a limited number of OSs, and we expect to roll out support for additional OSs over the next few months. If you have feedback about the feature, please reach out to Tenable™ support. We would love to hear from you.

This is a Security Bloggers Network syndicated blog post authored by Mehul Revankar. Read the original post at: Tenable Blog