Satisnet Ltd, Basepoint Innovation Centre, 110 Butterfield Great Marlings, Luton, Bedfordshire, LU2 8DL
+44 (0) 1582 434320

Tenable Allows Least Privilege SSH Scans

Tenable Allows Least Privilege SSH Scans

Tenable Allows Least Privilege SSH Scans

Credentialed scans have long been encouraged as the quickest and most accurate way to perform a vulnerability assessment against any network. However, customer always run into problems which are related to users or process which need to be followed.

Usually when the discussion of credentials become topic of a conversation, further questions are asked; who? why? what? Nevertheless, from a business perspective these are legitimate questions which should be rightly asked. This then causes many conversations between the people involved and then meaning polices and procedures have to be created. Eventually a final decision will be made either to grant access for the credentials; denied or not the correct privileges which was initially discussed.

To help solve this problem, Tenable provided 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.

  • Nessus 6.11 or later, either standalone or managed by Vulnerability Management or SecurityCenter
  • 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 summarised in five simple steps:

  • Configure a scan account to run with sudo privileges
  • Enable ‘Attempt Least Privilege’ preference in scan policy
  • Review plugin output of Nessus plugin IDs #102094 and #102095
  • Update /etc/sudoers file based on results on plugin #102094
  • 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.

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.

Image 1


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

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

Tenable Image 2

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.

Tenable Image 3

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.

Tenable Image 4

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.

Tenable Image 5

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 us here, we would love to hear from you.