NESSUS VULNERABILITY SCANNER FOR AUTHENTICATED SCANS
Credentialed Checks on Windows
The process described in this section enables you to perform local security checks on Windows systems. Only Domain Administrator accounts can be used to scan Domain Controllers.
Configure a Domain Account for Authenticated Scanning
To create a domain account for remote host-based auditing of a Windows server, the server must first be Windows Server 2008, Server 2008 R2*, Server 2012, Server 2012 R2, Server 2016, Windows 7, Windows 8, or Windows 10 and must be part of a domain.
Create a Security Group called Nessus Local Access
Create Group Policy called Local Admin GPO
Add the Nessus Local Access group to the Nessus Scan GPO
Nessus uses Server Message Block (SMB) and Windows Management Instrumentation (WMI). You must ensure Windows Firewall allows access to the system.
Allow WMI on Windows Vista, 7, 8, 10, 2008, 2008 R2, 2012, 2012 R2, and 2016 Windows Firewall
Tip: Later, you can edit the predefined rule created and limit the connection to the ports by IP Address and Domain User to reduce any risk for abuse of WMI.
Link the GPO
Configure Windows 2008, Vista, 7, 8, and 10
Note: Enabling this option configures Nessus to attempt to start the remote registry service prior to starting the scan.
The Windows credentials provided in the Nessus scan policy must have administrative permissions to start the Remote Registry service on the host being scanned.
Caution: While not recommended, Windows User Account Control (UAC) can be disabled.
Tip: To turn off UAC completely, open the Control Panel, select User Accounts and then set Turn User Account Control to off. Alternatively, you can add a new registry key named LocalAccountTokenFilterPolicy and set its value to 1.
This key must be created in the registry at the following location: HKLM\SOFTWARE\Microsoft\ Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy.
For more information on this registry setting, consult the MSDN 766945 KB. In Windows 7 and 8, if UAC is disabled, then EnableLUA must be set to 0 in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System as well.
Enable Windows Logins for Local and Remote Audits
The most important aspect about Windows credentials is that the account used to perform the checks should have privileges to access all required files and registry entries, which in many cases means administrative privileges. If Nessus is not provided the credentials for an administrative account, at best it can be used to perform registry checks for the patches. While this is still a valid method to determine if a patch is installed, it is incompatible with some third party patch management tools that may neglect to set the key in the policy. If Nessus has administrative privileges, then it will actually check the version of the dynamic-link library (.dll) on the remote host, which is considerably more accurate.
Configure a Local Account
To configure a stand-alone Windows server with credentials to be used that is not part of a domain, simply create a unique account as the administrator.
Make sure that the configuration of this account is not set with a typical default of Guest only: local users authenticate as guest. Instead, switch this to Classic: local users authenticate as themselves.
Configuring a Domain Account for Local Audits
To create a domain account for remote host-based auditing of a Windows server, the server must first be Windows 2000 Server, Windows XP Pro, or Windows 2008 Server and be part of a domain.
To configure the server to allow logins from a domain account, use the Classic security model. To do this, follow these steps:
The Network access: Sharing and security model for local accounts window appears.
This will cause users local to the domain to authenticate as themselves, even though they are not physically local on the particular server. Without doing this, all remote users, even real users in the domain, will authenticate as a guest and will likely not have enough credentials to perform a remote audit.
Configuring Windows XP
When performing authenticated scans against Windows XP systems, there are several configuration options that must be enabled:
You may be required to change the Windows local security policies or they could block access or inherent permissions. A common policy that will affect credentialed scans is found under:
Administrative Tools > Local Security Policy > Security Settings > Local Policies > Security Options > Network access: Sharing and security model for local accounts.
If this local security policy is set to something other than Classic - local users authenticate as themselves, a compliance scan will not run successfully.
Configuring Windows Server, Vista, 7, 8, and 10.
When performing authenticated scans against Windows systems, there are several configuration options that must be enabled: