Host

Users can select SNMPv3 settings from the Credentials menu and enter credentials for scanning systems using an encrypted network management protocol.

These credentials are used to obtain local information from remote systems, including network devices, for patch auditing or compliance checks.

There is a field for entering the SNMPv3 user name for the account that will perform the checks on the target system, along with the SNMPv3 port, security level, authentication algorithm and password, and privacy algorithm and password.

If Nessus is unable to determine the community string or password, it may not perform a full audit of the service.

Option

Description

Username

The username for a SNMPv3 based account.

Port

Direct Nessus to scan a different port if SNMP is running on a port other than 161.

Security level

Select the security level for SNMP: authentication, privacy, or both.

Authentication algorithm

Select MD5 or SHA1 based on which algorithm the remote service supports.

This mechanism encrypts the data in transit to protect it from being viewed by sniffer programs. Nessus supports five types of authentication methods for use with SSH: username and password, public/private keys, digital certificates, and Kerberos.

Users can select SSH settings from the Credentials menu and enter credentials for scanning Unix systems.

These credentials are used to obtain local information from remote Unix systems for patch auditing or compliance checks.

Note: Non-privileged users with local access on Unix systems can determine basic security issues, such as patch levels or entries in the /etc/passwd file. For more comprehensive information, such as system configuration data or file permissions across the entire system, an account with root privileges is required

There are three settings for SSH credentials that apply to all SSH Authentication methods.

Option

Default Value

Description

known_hosts file

none

If an SSH known_hosts file is available and provided as part of the Global Settings of the scan policy in the known_hosts file field, Nessus will only attempt to log into hosts in this file. This can ensure that the same username and password you are using to audit your known SSH servers is not used to attempt a log into a system that may not be under your control.

Preferred port

22

This option can be set to direct Nessus to connect to SSH if it is running on a port other than 22.

Client version

OpenSSH_5.0

Specifies which type of SSH client Nessus will impersonate while scanning.

Public Key Encryption, also referred to as asymmetric key encryption, provides a more secure authentication mechanism by the use of a public and private key pair. In asymmetric cryptography, the public key is used to encrypt data and the private key is used to decrypt it. The use of public and private keys is a more secure and flexible method for SSH authentication. Nessus supports both DSA and RSA key formats.

Like Public Key Encryption, Nessus supports RSA and DSA OpenSSH certificates. Nessus also requires the user certificate, which is signed by a Certificate Authority (CA), and the user’s private key.

Note: Nessus supports the OpenSSH SSH public key format. Formats from other SSH applications, including PuTTY and SSH Communications Security, must be converted to OpenSSH public key format.

The most effective credentialed scans are when the supplied credentials have root privileges. Since many sites do not permit a remote login as root, Nessus can invoke su, sudo, su+sudo, dzdo, .k5login, or pbrun with a separate password for an account that has been set up to have su or sudo privileges. In addition, Nessus can escalate privileges on Cisco devices by selecting Cisco ‘enable’ or .k5login for Kerberos logins.

Note: Nessus supports the blowfish-cbc, aes-cbc, and aes-ctr cipher algorithms. Some commercial variants of SSH do not have support for the blowfish algorithm, possibly for export reasons. It is also possible to configure an SSH server to only accept certain types of encryption. Check your SSH server to ensure the correct algorithm is supported.

Nessus encrypts all passwords stored in policies. However, the use of SSH keys for authentication rather than SSH passwords is recommended. This helps ensure that the same username and password you are using to audit your known SSH servers is not used to attempt a log in to a system that may not be under your control.

Note: For supported network devices, Nessus will only support the network device’s username and password for SSH connections.

If an account other than root must be used for privilege escalation, it can be specified under the Escalation account with the Escalation password.

Option

Description

Username

Username of the account which is being used for authentication on the host system.

CyberArk is a popular enterprise password vault that helps you manage privileged credentials. Nessus can get credentials from CyberArk to use in a scan.

Option

Description

Username

The target system’s username.

Domain

This is an optional field if the above username is part of a domain.

Central Credential Provider Host

The CyberArk Central Credential Provider IP/DNS address.

Central Credential Provider Port

The port the CyberArk Central Credential Provider is listening on.

Vault Username (optional)

If the CyberArk Central Credential Provider is configured to use basic authentication you can fill in this field for authentication.

Vault Password (optional)

If the CyberArk Central Credential Provider is configured to use basic authentication you can fill in this field for authentication.

Safe

The safe on the CyberArk Central Credential Provider server that contained the authentication information you would like to retrieve.

AppId

The AppId that has been allocated permissions on the CyberArk Central Credential Provider to retrieve the target password.

Folder

The folder on the CyberArk Central Credential Provider server that contains the authentication information you would like to retrieve.

PolicyId

The PolicyID assigned to the credentials you would like to retrieve from the CyberArk Central Credential Provider.

Use SSL

If CyberArk Central Credential Provider is configured to support SSL through IIS check for secure communication.

Verify SSL Certificate

If CyberArk Central Credential Provider is configured to support SSL through IIS and you want to validate the certificate check this. Refer to the custom_CA.inc documentation for how to use self-signed certificates.

Kerberos, developed by MIT’s Project Athena, is a client/server application that uses a symmetric key encryption protocol. In symmetric encryption, the key used to encrypt the data is the same as the key used to decrypt the data. Organizations deploy a KDC (Key Distribution Center) that contains all users and services that require Kerberos authentication. Users authenticate to Kerberos by requesting a TGT (Ticket Granting Ticket). Once a user is granted a TGT, it can be used to request service tickets from the KDC to be able to utilize other Kerberos based services. Kerberos uses the CBC (Cipher Block Chain) DES encryption protocol to encrypt all communications.

Note: You must already have a Kerberos environment established to use this method of authentication.

The Nessus implementation of Unix-based Kerberos authentication for SSH supports the aes-cbc and aes-ctr encryption algorithms. An overview of how Nessus interacts with Kerberos is as follows:

End-user gives the IP of the KDC

nessusd asks sshd if it supports Kerberos authentication

sshd says yes

nessusd requests a Kerberos TGT, along with login and password

Kerberos sends a ticket back to nessusd

nessusd gives the ticket to sshd

nessusd is logged in

In both Windows and SSH credentials settings, you can specify credentials using Kerberos keys from a remote system. Note that there are differences in the configurations for Windows and SSH.

Option

Description

Username

The target system’s username.

Password

Password of the username specified.

Key Distribution Center (KDC)

This host supplies the session tickets for the user.

KDC Port

This option can be set to direct Nessus to connect to the KDC if it is running on a port other than 88.

KDC Transport

The KDC uses TCP by default in Unix implementations. For UDP, change this option. Note that if you need to change the KDC Transport value, you may also need to change the port as the KDC UDP uses either port 88 or 750 by default, depending on the implementation.

Realm

The Realm is the authentication domain, usually noted as the domain name of the target (e.g., example.com).

Elevate privileges with

Allows for increasing privileges once authenticated.

If Kerberos is used, sshd must be configured with Kerberos support to verify the ticket with the KDC. Reverse DNS lookups must be properly configured for this to work. The Kerberos interaction method must be gssapi-with-mic.

This is the value that the secret is stored as on the Thycotic server. It is referred to as the “Secret Name” on the Thycotic server.

Thycotic Secret Server URL (required)

This is used to set the transfer method, target , and target directory for the scanner. The value can be found in Admin->Configuration->Application Settings->Secret Server URL on the Thycotic server. For example consider the following address https://pw.mydomain.com/SecretServer/We will parse this to know that https defines it is a ssl connectionpw.mydomain.com is the target address/SecretServer/ is the root directory.

Thycotic Login Name (required)

The username to authenticate to the Thycotic server.

Thycotic Password (required)

The password associated to the Thycotic Login Name.

Thycotic Organization (required)

This value is used in cloud instances of Thycotic to define which organization your query should hit.

Thycotic Domain (optional)

This is an optional value set if the domain value is set for the Thycotic server.

Private Key (optional)

Use key based authentication for SSH connections instead of password.

Verify SSL Certificate

Verify if the SSL Certificate on the server is signed by a trusted CA.

Windows

The Windows credentials menu item has settings to provide Nessus with information such as SMB account name, password, and domain name. By default, you can specify a username, password, and domain with which to log in to Windows hosts. Additionally, Nessus supports several different types of authentication methods for Windows-based systems:

The Lanman authentication method was prevalent on Windows NT and early Windows 2000 server deployments. It is retained for backward compatibility.

The NTLM authentication method, introduced with Windows NT, provided improved security over Lanman authentication. The enhanced version, NTLMv2, is cryptographically more secure than NTLM and is the default authentication method chosen by Nessus when attempting to log into a Windows server. NTLMv2 can make use of SMB Signing.

SMB signing is a cryptographic checksum applied to all SMB traffic to and from a Windows server. Many system administrators enable this feature on their servers to ensure that remote users are 100% authenticated and part of a domain. In addition, make sure you enforce a policy that mandates the use of strong passwords that cannot be easily broken via dictionary attacks from tools like John the Ripper and L0phtCrack. It is automatically used by Nessus if it is required by the remote Windows server. Note that there have been many different types of attacks against Windows security to illicit hashes from computers for re-use in attacking servers. SMB Signing adds a layer of security to prevent these man-in-the-middle attacks.

The SPNEGO (Simple and Protected Negotiate) protocol provides Single Sign On (SSO) capability from a Windows client to a variety of protected resources via the users’ Windows login credentials. Nessus supports use of SPNEGO Scans and Policies: Scans 54 of 151 with either NTLMSSP with LMv2 authentication or Kerberos and RC4 encryption. SPNEGO authentication happens through NTLM or Kerberos authentication; nothing needs to be configured in the Nessus policy.

If an extended security scheme (such as Kerberos or SPNEGO) is not supported or fails, Nessus will attempt to log in via NTLMSSP/LMv2 authentication. If that fails, Nessus will then attempt to log in using NTLM authentication.

Nessus also supports the use of Kerberos authentication in a Windows domain. To configure this, the IP address of the Kerberos Domain Controller (actually, the IP address of the Windows Active Directory Server) must be provided.

Server Message Block (SMB) is a file-sharing protocol that allows computers to share information across the network. Providing this information to Nessus will allow it to find local information from a remote Windows host. For example, using credentials enables Nessus to determine if important security patches have been applied. It is not necessary to modify other SMB parameters from default settings.

The SMB domain field is optional and Nessus will be able to log on with domain credentials without this field. The username, password, and optional domain refer to an account that the target machine is aware of. For example, given a username of joesmith and a password of my4x4mpl3, a Windows server first looks for this username in the local system’s list of users, and then determines if it is part of a domain.

Regardless of credentials used, Nessus always attempts to log into a Windows server with the following combinations:

Administrator without a password

A random username and password to test Guest accounts

No username or password to test null sessions

The actual domain name is only required if an account name is different on the domain from that on the computer. It is entirely possible to have an Administrator account on a Windows server and within the domain. In this case, to log onto the local server, the username of Administrator is used with the password of that account. To log onto the domain, the Administrator username would also be used, but with the domain password and the name of the domain.

When multiple SMB accounts are configured, Nessus will try to log in with the supplied credentials sequentially. Once Nessus is able to authenticate with a set of credentials, it will check subsequent credentials supplied, but only use them if administrative privileges are granted when previous accounts provided user access.

Some versions of Windows allow you to create a new account and designate it as an administrator. These accounts are not always suitable for performing credentialed scans. Tenable recommends that the original administrative account, named Administrator be used for credentialed scanning to ensure full access is permitted. On some versions of Windows, this account may be hidden. The real administrator account can be unhidden by running a DOS prompt with administrative privileges and typing the following command:

C:\> net user administrator /active:yes

If an SMB account is created with limited administrator privileges, Nessus can easily and securely scan multiple domains. Tenable recommends that network administrators consider creating specific domain accounts to facilitate testing. Nessus includes a variety of security checks for Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 that are more accurate if a domain account is provided. Nessus does attempt to try several checks in most cases if no account is provided.

Note: The Windows Remote Registry service allows remote computers with credentials to access the registry of the computer being audited. If the service is not running, reading keys and values from the registry will not be possible, even with full credentials. This service must be started for a Nessus credentialed scan to fully audit a system using credentials.

Credentialed scans on Windows systems require that a full administrator level account be used. Several bulletins and software updates by Microsoft have made reading the registry to determine software patch level unreliable without administrator privileges, but not all of them. Nessus plugins will check that the provided credentials have full administrative access to ensure they execute properly. For example, full administrative access is required to perform direct reading of the file system. This allows Nessus to attach to a computer and perform direct file analysis to determine the true patch level of the systems being evaluated.

For security reasons, Windows credentials are not sent in the clear by default.

Do not use NTLMv1 authentication

Enabled

If the Do not use NTLMv1 authentication option is disabled, then it is theoretically possible to trick Nessus into attempting to log into a Windows server with domain credentials via the NTLM version 1 protocol. This provides the remote attacker with the ability to use a hash obtained from Nessus. This hash can be potentially cracked to reveal a username or password. It may also be used to directly log into other servers. Force Nessus to use NTLMv2 by enabling the Only use NTLMv2 setting at scan time. This prevents a hostile Windows server from using NTLM and receiving a hash. Because NTLMv1 is an insecure protocol this option is enabled by default.

Start the Remote Registry service during the scan

Disabled

This option tells Nessus to start the Remote Registry service on computers being scanned if it is not running. This service must be running in order for Nessus to execute some Windows local check plugins.

Enable administrative shares during the scan

Disabled

This option will allow Nessus to access certain registry entries that can be read with administrator privileges.

CyberArk is a popular enterprise password vault that helps you manage privileged credentials. Nessus can get credentials from CyberArk to use in a scan.

Option

Description

Username

The target system’s username.

Domain

This is an optional field if the above username is part of a domain.

Central Credential Provider Host

The CyberArk Central Credential Provider IP/DNS address.

Central Credential Provider Port

The port the CyberArk Central Credential Provider is listening on.

Vault Username (optional)

If the CyberArk Central Credential Provider is configured to use basic authentication you can fill in this field for authentication.

Valut Password (optional)

If the CyberArk Central Credential Provider is configured to use basic authentication you can fill in this field for authentication.

Safe

The safe on the CyberArk Central Credential Provider server that contained the authentication information you would like to retrieve.

AppId

The AppId that has been allocated permissions on the CyberArk Central Credential Provider to retrieve the target password.

Folder

The folder on the CyberArk Central Credential Provider server that contains the authentication information you would like to retrieve.

PolicyId

The PolicyID assigned to the credentials you would like to retrieve from the CyberArk Central Credential Provider.

Use SSL

If CyberArk Central Credential Provider is configured to support SSL through IIS check for secure communication.

Verify SSL Certificate

If CyberArk Central Credential Provider is configured to support SSL through IIS and you want to validate the certificate check this. Refer to custom_CA.inc documentation for how to use self-signed certificates.

This is the value that the secret is stored as on the Thycotic server. It is referred to as the “Secret Name” on the Thycotic server.

Thycotic Secret Server URL (required)

This is used to set the transfer method, target , and target directory for the scanner. The value can be found in Admin->Configuration->Application Settings->Secret Server URL on the Thycotic server. For example consider the following address https://pw.mydomain.com/SecretServer/We will parse this to know that https defines it is a ssl connectionpw.mydomain.com is the target address/SecretServer/ is the root directory.

Thycotic Login Name (required)

The username to authenticate to the Thycotic server.

Thycotic Password (required)

The password associated to the Thycotic Login Name.

Thycotic Organization (required)

This value is used in cloud instances of Thycotic to define which organization your query should hit.

Thycotic Domain (optional)

This is an optional value set if the domain value is set for the Thycotic server.

Private Key (optional)

Use key based authentication for SSH connections instead of password.

Verify SSL Certificate

Verify if the SSL Certificate on the server is signed by a trusted CA.

Copyright 2017 Tenable, Inc. All rights reserved. Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of Tenable, Inc. Tenable, Tenable.io, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.