nessus_credential_checks

nessus_credential_checks

Nessus Credentialed Checks November 24, 2014

(Revision 38)

nessus_credential_checks

Table of Contents

Introduction (4)

Standards and Conventions (4)

Overview of Nessus Credentialed Checks (4)

Purpose (4)

Access Level (5)

Technologies Used (5)

Unix Systems and Network Devices (5)

Username and Password (5)

Public/Private Keys (6)

Digital Certificates (6)

Kerberos (6)

Windows Systems (6)

LANMAN (6)

NTLM and NTLMv2 (6)

SMB Signing (6)

SPNEGO (7)

Kerberos (7)

NTLMSSP (NT Lan Manager Security Support Provider) and LMv2 (7)

Windows Usernames, Passwords, and Domains (7)

VMware ESXi and vCenter (7)

Credentialed Checks on Unix-Based Platforms (7)

Prerequisites (7)

Configuration Requirements for SSH (7)

User Privileges (8)

Configuration Requirements for Kerberos (8)

Enabling SSH Local Security Checks on Unix (8)

Generating SSH Public and Private Keys (8)

Creating a User Account and Setting up the SSH Key (8)

Example (9)

Enabling SSH Local Security Checks on Network Devices (10)

Configuring Nessus for SSH Host-Based Checks (10)

Nessus User Interface (10)

Using SSH Credentials with the Tenable SecurityCenter (13)

Credentialed Checks on Windows Platforms (14)

Prerequisites (14)

User Privileges (14)

Enabling Windows Logins for Local and Remote Audits (14)

Configuring a Local Account (14)

Configuring a Domain Account for Authenticated Scanning (15)

Step 1: Creating a Security Group (15)

Step 2: Create Group Policy (15)

Step 3: Configure the policy to add the “Nessus Local Access” group as Administrators (15)

Step 4: Ensure proper ports are open in the firewall for Nessus to connect to the host (16)

Allowing WMI on Windows Vista, 7, 8, 2008, 2008R2 and 2012 Windows Firewall (16)

Step 5: Linking GPO (16)

Configuring Windows 2008, Vista and 7 (16)

Configuring Nessus for Windows Logins (17)

Nessus User Interface (17)

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 2

nessus_credential_checks

Configuring Nessus for VMware ESXi and vCenter Local Security Checks (20)

Nessus User Interface (20)

Detecting when Credentials Fail (22)

Troubleshooting (22)

Securing Your Scanner (24)

Why should I secure my scanner? (24)

What does it mean to lock down a scanner? (24)

Secure Implementation of Unix SSH Audits (24)

Secure Windows Audits (24)

For Further Information (25)

About Tenable Network Security (26)

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 3

nessus_credential_checks

Introduction

This paper describes how to perform authenticated network scans with Tenable Network Security’s Nessus vulnerability scanner. Authenticated network scans allow a remote network audit to obtain “host-based” data such as missing patches and operating system settings. Please email any comments and suggestions to support@http://www.77cn.com.cn.

Nessus leverages the ability to log into remote Unix hosts via Secure Shell (SSH). For Windows hosts, Nessus leverages a variety of Microsoft authentication technologies.

Note that Nessus also uses the Simple Network Management Protocol (SNMP) to make version and information queries to routers and switches. Although this is a form of “local checks”, it is not covered in this document.

This document also makes extensive references to “Nessus”, but the basic concepts are also true for Tenable’s SecurityCenter.

Standards and Conventions

Throughout the documentation, filenames, daemons, and executables are indicated with a courier bold font such as gunzip, httpd, and /etc/passwd.

Command line options and keywords are also indicated with the courier bold font. Command line examples may or may not include the command line prompt and output text from the results of the command. Command line examples will display the command being run in courier bold to indicate what the user typed while the sample output generated by the system will be indicated in courier (not bold). Following is an example running of the Unix pwd command:

# pwd

/home/test/

#

Important notes and considerations are highlighted with this symbol and grey text boxes.

Tips, examples, and best practices are highlighted with this symbol and white on blue text.

Overview of Nessus Credentialed Checks

Tenable’s Nessus scanner is a very effective network vulnerability scanner with a comprehensive database of plugins that check for a large variety of vulnerabilities that could be remotely exploited. In addition to remote scanning, the Nessus scanner can also be used to scan for local exposures.

Purpose

External network vulnerability scanning is useful to obtain a snapshot in time of the network services offered and the vulnerabilities they may contain. However, it is only an external perspective. It is important to determine what local services are running and to identify security exposures from local attacks or configuration settings that could expose the system to external attacks that may not be detected from an external scan.

In a typical network vulnerability assessment, a remote scan is performed against the external points of presence and an onsite scan is performed from within the network. Neither of these scans can determine local exposures on the target system. Some of the information gained relies on the banner information displayed, which may be inconclusive or incorrect. By using secured credentials, the Nessus scanner can be granted local access to scan the target system without requiring an agent. This can facilitate scanning of a very large network to determine local exposures or compliance violations.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 4

nessus_credential_checks

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 5

The most common security problem in an organization is that security patches are not applied in a timely manner. A Nessus credentialed scan can quickly determine which systems are out of date on patch installation. This is especially important when a new vulnerability is made public and executive management wants a quick answer regarding the impact to the organization.

Another major concern for organizations is to determine compliance with site policy, industry standards (such as the Center for Internet Security (CIS) benchmarks) or legislation (such as Sarbanes-Oxley (SOX), Gramm-Leach-Bliley (GLBA), or HIPAA). Organizations that accept credit card information must demonstrate compliance with the Payment Card Industry Data Security Standards (PCI DSS). There have been quite a few well-publicized cases where the credit card information for millions of customers was breached. This represents a significant financial loss to the banks responsible for covering the payments and heavy fines or loss of credit card acceptance capabilities by the breached merchant or processor.

Access Level

Credentialed scans can perform any operation that a local user can perform. The level of scanning is dependent on the privileges granted to the user account that Nessus is configured to use.

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.

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.

One audit, for SCAP compliance, requires sending an executable to the remote host. For systems that run security software (e.g., McAfee Host Intrusion Prevention), it may block or quarantine the executable required for auditing. For those systems, an exception must be made for the either the host or the executable sent.

Please note that Nessus will open several concurrent authenticated connections to carry out credentialed auditing to ensure it is done in a timely fashion. Ensure that the host being audited does not have a strict

account lockout policy based on concurrent sessions.

Technologies Used

The challenge in running a credentialed scan is to automatically provide the privileged credentials to the scanner in a secure manner. It would certainly defeat the purpose of scanning for security exposures if doing so would open an even greater exposure! Nessus supports the use of several secure methods to solve this problem on a variety of platforms.

Unix Systems and Network Devices

On Unix systems and supported network devices, Nessus uses Secure Shell (SSH) protocol version 2 based programs (e.g., OpenSSH, Solaris SSH, etc.) for host-based checks. This mechanism encrypts the data in transit to protect it from being viewed by sniffer programs. Nessus supports three types of authentication methods for use with SSH: username and password, public/private keys, and Kerberos.

Username and Password

Although supported, Tenable does not recommend using a username and password for authentication with SSH. Static

passwords are subject to “man in the middle” and brute force attacks when they have been in use over a long period of time.

For supported network devices, Nessus will only support the network device's username and password for

SSH connections.

nessus_credential_checks

Public/Private Keys

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.

Digital Certificates

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.

Kerberos

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.

The Nessus implementation of 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

Windows Systems

Nessus supports several different types of authentication methods for Windows-based systems. Each of these methods takes a username, password and domain name (sometimes optional for authentication).

LANMAN

The Lanman authentication method was prevalent on Windows NT and early Windows 2000 server deployments. It is not really used on newer Windows deployments, but is retained for backwards compatibility.

NTLM and NTLMv2

The NTLM authentication method, introduced with Windows NT, provided improved security over Lanman authentication. However, 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.

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. It is automatically used by Nessus if it is required by the remote Windows server.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 6

nessus_credential_checks

SPNEGO

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

Kerberos

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. NTLMSSP (NT Lan Manager Security Support Provider) and LMv2

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.

Windows Usernames, Passwords, and Domains

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 use rs, and then determines if it is part of a domain in there.

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.

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

VMware ESXi and vCenter

Nessus supports native SOAP API authentication methods for VMware ESXi, which is a server that supports hypervisors. Additionally, Nessus supports local security checks for VMware vCenter, which a management server for ESXi. Credentialed Checks on Unix-Based Platforms

The process described in this section enables you to perform local security checks on Unix-based systems (e.g., Linux, Solaris, Mac OS X). The SSH daemon used in this example is OpenSSH. If you have a commercial variant of SSH, your procedure may be slightly different.

To enable local security checks, there are two basic methods that can be used:

1. Use of a SSH private/public key pair

2. User credentials and sudo access or credentials for su access

Prerequisites

Configuration Requirements for SSH

Nessus 5 supports the blowfish-CBC, AESXXX-CBC (AES128, AES192, and AES256), 3DES-CBC, and AES-CTR algorithms.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 7

nessus_credential_checks

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.

User Privileges

For maximum effectiveness, the SSH user must have the ability to run any command on the system. On Unix systems, this is known as “root” privileges. While it is possible to run some checks (such as patch levels) with non-privileged access, full compliance checks that audit system configuration and file permissions require root access. For this reason, it is strongly recommended that SSH keys be used instead of credentials when possible.

Configuration Requirements for Kerberos

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. Enabling SSH Local Security Checks on Unix

This section is intended to provide a high-level procedure for enabling SSH between the systems involved in the Nessus credentialed checks. It is not intended to be an in-depth tutorial on SSH. It is assumed the reader has the prerequisite knowledge of Unix system commands.

Generating SSH Public and Private Keys

The first step is to generate a private/public key pair for the Nessus scanner to use. This key pair can be generated from any of your Unix systems, using any user account. However, it is important that the keys be owned by the defined Nessus user. To generate the key pair, use ssh-keygen and save the key in a safe place. In the following example the keys are generated on a Red Hat ES 3 installation.

Do not transfer the private key to any system other than the one running the Nessus server. When ssh-keygen asks you for a passphrase, enter a strong passphrase or hit the “Return” key twice (i.e., do not set any passphrase). If a passphrase is specified, it must be specified in the Policies -> Credentials -> SSH settings options in order for Nessus to use key-based authentication.

Nessus Windows users may wish to copy both keys to the main Nessus application directory on the system running Nessus (C:\Program Files\Tenable\Nessus by default), and then copy the public key to the target systems as needed. This makes it easier to manage the public and private key files.

Creating a User Account and Setting up the SSH Key

On every target system to be scanned using local security checks, create a new user account dedicated to Nessus. This user account must have exactly the same name on all systems. For this document, we will call the user “nessus”, but you can use any name.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 8

nessus_credential_checks

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 9

Once the account is created for the user, make sure that the account has no valid password set. On Linux systems, new user accounts are locked by default, unless an initial password was explicitly set. If you are using an account where a password had been set, use the “passwd –l ” command to lock the account.

You must also create the directory under this new account’s home directory to hold the public key. For this exercise, the directory will be /home/nessus/.ssh . An example for Linux systems is provided below:

For Solaris 10 systems, Sun has enhanced the “passwd(1)” command to distinguish between locked and non-login accounts. This is to ensure that a user account that has been locked may not be used to execute commands (e.g., cron jobs). Non-login accounts are used only to execute commands and do not support an interactive login session. These accounts have the “NP” token in the password field of /etc/shadow . To set a non-login account and create the SSH public key directory in Solaris 10, run the following commands:

Now that the user account is created, you must transfer the key to the system, place it in the appropriate directory and set the correct permissions.

Example

From the system containing the keys, secure copy the public key to system that will be scanned for host checks as shown below. 192.1.1.44 is an example remote system that will be tested with the host-based checks.

You can also copy the file from the system on which Nessus is installed using the secure FTP command, “sftp ”. Note that the file on the target system must be named “

authorized_keys ”.

Return to the System Housing the Public Key

Set the permissions on both the /home/nessus/.ssh directory, as well as the authorized_keys file.

Repeat this process on all systems that will be tested for SSH checks (starting at “Creating a User Account and Setting up the SSH Key ” above).

nessus_credential_checks

Test to make sure that the accounts and networks are configured correctly. Using the simple Unix command “id”, from the Nessus scanner, run the following command:

If it successfully returns information about the nessus user, the key exchange was successful.

Enabling SSH Local Security Checks on Network Devices

In addition to using SSH for local security checks, Nessus also supports local security checks on various network devices. Those network devices currently include Cisco IOS devices, F5 networks devices, Huawei devices, Junos devices, and Palo Alto Networks devices.

Network devices that support SSH require both a username and password. Currently, Nessus does not support any other forms of authentication to network devices.

See your appropriate network device manual for configuring SSH support.

Configuring Nessus for SSH Host-Based Checks

Nessus User Interface

If you have not already done so, secure copy the private and public key files to the system that you will use to access the Nessus scanner.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 10

nessus_credential_checks

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 11

Open a web browser and connect to the Nessus scanner user interface as seen above and click on the “Policies” tab. Create a new policy or edit an existing policy and select the “Credentials” menu on the top . Select “SSH” from the "Host" drop-down menu at the top as shown below:

?

For the item “SSH user name ”, enter the name of the account that is dedicated to Nessus on each of the scan target systems. It is set to “root” by default. ?

If you are using a password for SSH, enter it in the “password” box. ?

If you are using SSH keys instead of a password (recommended), select "public key" from the "Authentication method" drop-down. ?

For the item “Private key",click on the “Add file ” button and locate the private key file (that is associated with the public key above) on the local system. ?

If you are using a passphrase for the SSH key (optional), enter it in the box labeled “Private key passphrase". ?

Nessus and SecurityCenter users can additionally invoke “su ” ,“sudo ”, "su+sudo ", "Cisco 'enable'".k5login ", "dzdo ", and "pbrun ", with the “Elevate privileges with” field and a separate password. ? 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.

nessus_credential_checks

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 12

The most effective credentialed scans are those when the supplied credentials have “root” privileges. Since ma ny sites do not permit a remote login as root, Nessus users can invoke “su ” or “sudo ” with a separate password for an account that has been set up to have “su ” or “sudo ” privileges.

An example screen capture of using “sudo ” in conjunction with SSH keys fol lows. For this example, the user account is “audit”, which has been added to the /etc/sudoers file on the system to be scanned. The password provided is the password for the “audit” account, not the root password. The SSH keys correspond with keys generated for the “audit” account:

If you are using Kerberos, you must configure a Nessus scanner to authenticate to a KDC. Select “Kerberos” from the

drop-down menu as shown below:

nessus_credential_checks

The default KDC port is “88” and the default transport protocol is “udp”. The other value for transport is “tcp”. Last, the Kerberos Realm name and IP address of the KDC are required.

Note that you must already have a Kerberos environment established to use this method of authentication.

At this point, click on “Save” at the bottom of the window and the configuration will be complete. The new scan policy will be added to the list of managed scan policies.

Using SSH Credentials with the Tenable SecurityCenter

SSH credentials are used to obtain local information from remote Linux, Unix, Cisco IOS, and other systems using SSH for connectivity for patch auditing or compliance checks.

The following is an example of the “Add Credential” screen when creating a SSH credential, which is selected from the Type drop-down. There is a field for entering the SSH user name for the account that will perform the checks on the target system, along with either the SSH password or the SSH public key and private key pair. The SSH key is selected using the “Browse” button next to the field. There is also a field for entering the Passphrase for the SSH key, if it is required. In

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 13

nessus_credential_checks

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 14

case of invalid or expired SSH keys, use the “Clear” button to remove the current SSH keys , available when a key is in use. Select the appropriate "Privilege Escalation method as needed.

Various SSH credential sets may be created for selection in SecurityCenter scans. SSH credential sets may be shared by Organizations, groups, users, or designated for use by a single user. When creating scans one SSH credential set may be assigned as needed.

SecurityCenter ships with several pre-defined vulnerability policies that have all of the “local checks” enabled for each individual OS.

The SSH public/private key pairs are managed by SecurityCenter and will be passed to each managed Nessus scanner.

Once these SSH public keys are configured for use on the desired Unix hosts and the private keys are

installed under SecurityCenter, a trust relationship is created such that a user can log into each of the hosts

from the Nessus scanners. If the security of the Nessus scanners is compromised, new SSH public/private

key pairs must be produced.

Credentialed Checks on Windows Platforms

Prerequisites

User Privileges

A very common mistake is to create a local account that does not have enough privileges to log on remotely and do anything useful. By default, Windows will assign new local accounts “Guest” privileges if they are logged into remotely. This prevents remote vulnerability audits from succeeding. Another common mistake is to increase the amount of access that the “Guest” users obtain. This reduces the security of your Windows server.

Enabling 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, and in many cases this 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. Configuring 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 an administrator.

nessus_credential_checks

Make sure that the configuration of this account is not set with a typical default of “Guest only: local users authenticate a s guest”. Instead, switch this to “Classic: local users authenticate as themselves”.

To configur e the server to allow logins from a domain account, the “Classic” security model should be invoked. To do this, follow these steps:

1. Open “Group Policy” by clicking on “start”, click “Run”, type “gpedit.msc” and then click “OK”.

2. Select Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.

3. From the list of policies open “Network access: Sharing and security model for local accounts”.

4. In this dialog, select “Classic – local users authenticate as them selves” and click “OK” to save this.

This will cause users local to the domain to authenticate as themselves, even though they are actually not really physically “local” on the particular server. Without doing this, all remote users, even real users in the domain, will actually authenticate as a “Guest” and will likely not have enough credentials to perform a remote audit.

Note that the gpedit.msc tool is not available on some version such as Windows 7 Home, which is not supported by Tenable.

Configuring 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, Windows 7, and Windows 8 and be part of a domain. There are five general steps that should be performed to facilitate this scanning while keeping security in mind.

Step 1: Creating a Security Group

First, create a security group called Nessus Local Access:

?Log onto a Domain Controller, open Active Directory Users and Computers.

?Create a security Group from Menu select Action -> New -> Group.

?Name the group Nessus Local Access. Make sure it has a “Scope” of Global and a “Type” of Security.

?Add the account you will use to perform Nessus Windows Authenticated Scans to the Nessus Local Access group. Step 2: Create Group Policy

Next, you need to create a group policy called Local Admin GPO.

?Open the Group Policy Management Console.

?Right click on Group Policy Objects and select New.

?Type the name of the policy Nessus Scan GPO”.

Step 3: Configure the policy to add the “Nessus Local Access” group as Administrators

Here you will add the Nessus Local Access group to the Nessus Scan GPO policy and put them in the groups you wish them to use.

?Right click “Nessus Scan GPO” Policy then select Edit.

?Expand Computer configuration\Policies\Windows Settings\Security Settings\Restricted Groups.

?In the Left pane on Restricted Groups, right click and select “Add Group”.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 15

nessus_credential_checks

?In the Add Group dialog box, select browse and type Nessus Local Access and then click “Check Names”.

?Click OK twice to close the dialog box.

?Click Add under “This group is a member of:”

?Add the “Administrators” Group.

?Click OK twice.

Step 4: Ensure proper ports are open in the firewall for Nessus to connect to the host

Nessus uses SMB (Server Message Block) and WMI (Windows Management Instrumentation) for this we need to make sure that the Windows Firewall will allow access to the system.

Allowing WMI on Windows Vista, 7, 8, 2008, 2008R2 and 2012 Windows Firewall

?Right click “Nessus Scan GPO” Policy then select Edit.

?Expand Computer configuration\Policies\Windows Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security\Inbound Rules

?Right-click in the working area and choose New Rule...

?Choose the Predefined option, and select Windows Management Instrumentation (WMI) from the drop-down list.

?Click on Next.

?Select the Checkboxes for:

-Windows Management Instrumentation (ASync-In)

-Windows Management Instrumentation (WMI-In)

-Windows Management Instrumentation (DCOM-In)

?Click on Next

?Click on Finish

?Note: You can later edit the predefined rule created and limit the connection to the ports by IP Address and Domain User so as to reduce any risk for abuse of WMI.

Step 5: Linking GPO

?In Group policy management console, right click on the domain or the OU and select Link an Existing GPO ?Select the Nessus Scan GPO

Configuring Windows 2008, Vista and 7

When performing authenticated scans against Windows 2008, Vista or 7 systems, there are several configuration options that must be enabled:

1. Under Windows Firewall -> Windows Firewall Settings, “File and Printer Sharing” must be enabled.

2. Using the gpedit.msc tool (via the “Run..” prompt), invoke the Group Policy Object Editor. Navigate to Local

Computer Policy -> Administrative Templates -> Network -> Network Connections - > Windows Firewall -> Standard Profile -> Windows Firewall : Allow inbound file and printer exception, and enable it.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 16

nessus_credential_checks

3. While in the Group Policy Object Editor, navigate to Local Computer Policy -> Administrative Templates ->

Network -> Network Connections -> Prohibit use of Internet connection firewall on your DNS domain and ensure it is set to either “Disabled” or “Not Configured”.

4. The Remote Registry service must be enabled (it is disabled by default). It can be enabled manually for

continuing audits, either by an administrator or by Nessus. Using plugin IDs 42897 and 42898, Nessus can enable the service just for the duration of the scan.

Nessus has the ability to enable and disable the Remote Registry service. For this to work, the target must

have the Remote Registry service set to “Manual” and not “Disabled”.

Windows User Account Control (UAC) can be disabled alternatively, but that is not recommended. 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 “

value to “1”. This key

Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

information on this registry setting, consult the

then

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System

Configuring Nessus for Windows Logins

Nessus User Interface

Open a web browser and connect to the Nessus scanner user interface as seen above and click the “Policies” tab. Create a new policy or edit an existing policy and select the “Credentials” menu on the top.

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 17

nessus_credential_checks

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 18

Select “Windows” from the "Host" drop-down menu on the left as shown below:

Specify the SMB account name, password, and optional domain. Note that if you choose "LM Hash" or "NTLM Hash", you must provide the hash instead of the password.

nessus_credential_checks

Copyright © 2014. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. 19

The Windows Kerberos options are similar to those in the SSH Kerberos section.

At this point, click on “Save ” at the bottom of the window and configuration will be complete. The new scan policy will be

added to the list of managed scan policies.

本文来源：https://www.bwwdw.com/article/2o3m.html