Nessus Credential Checks

Nessus Credential Checks for
UNIX and Windows

February 5, 2007
(Revision 15)

The newest version of this document is available at the following URL:
http://www.nessus.org/documentation/nessus_credential_checks.pdf

Table of Contents

TABLE OF CONTENTS........................................................................................................................................2
INTRODUCTION...................................................................................................................................................3
WHY PERFORM HOST-BASED CHECKS? .................................................................................................3
WHAT KINDS OF CREDENTIALS ARE NEEDED?.................................................................................4
WHICH AUTHENTICATION METHODS DOES NESSUS SUPPORT?............................................5
ENABLING SSH LOCAL SECURITY CHECKS ON UNIX.....................................................................7
CONFIGURING NESSUS FOR SSH HOST-BASED CHECKS.............................................................9
ENABLING WINDOWS LOGINS FOR LOCAL AND REMOTE AUDITS......................................11
CONFIGURING NESSUS FOR WINDOWS LOGINS...........................................................................12
DETECTING WHEN CREDENTIALS FAIL................................................................................................12
TROUBLESHOOTING........................................................................................................................................14
SECURING YOUR SCANNER.........................................................................................................................15
FOR FURTHER INFORMATION...................................................................................................................17
ABOUT TENABLE NETWORK SECURI TY ................................................................................................18

Note: Currently Tenable Network Security, Inc. is going through a name change process
for all of our products. The directories, commands, configuration files, etc. will still reflect
the old names for the Log Correlation Engine and Passive Vulnerability Scanner until new
versions are released. Tenable would like to thank you for your patience through this
process.

Lightning will be known as Security Center
Thunder will be known as Log Correlation Engine
NeVO will be known as Passive Vulnerability Scanner

Copyright 2004-2006, Tenable Network Security, Inc.
Proprietary Information of Tenable Network Security, Inc.
2

Introduction

Welcome

Welcome to Tenable Network Securitys Nessus 3.0 Credential Checks for UNIX and
Windows. As you read this document, please share your comments and suggestions with us
by emailing them to support@tenablesecurity.com.

This paper will explain just about everything you need to know to perform authenticated
network scans with the Nessus Vulnerability Scanner. Authenticated network scans allow a
remote network audit to obtain host-based data such as missing patches and operating
system settings.

If you have been a long time Nessus user (the project is almost ten years old), host-based
checks for UNIX were introduced in 2004 and Windows support had existed before that.
Nessus leverages the ability to log into remote UNIX hosts via Secure Shell. For Windows
hosts, Nessus leverages a variety of Microsoft authentication technologies.

It should be noted that Nessus also uses the Simple Network Management Protocol 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 various web based management consoles for Nessus, such as Tenables Security
Center (formerly Lightning Console).

Standards and Conventions

Throughout the documentation, filenames, daemons, and executables will be indicated with
an italicized font such a setup.exe.

Command line options and keywords will be printed with the following font. Command line
options may or may not include the command line prompt and output text from the results
of the command. Often, the command being run will be boldfaced to indicate what the user
typed. Below is an example running of the UNIX pwd command.

# pwd
/ home/ t est /
Why Perform Host-based Checks?

Having host information obtained directly from a server has several advantages over
traditional network scans.

For determining missing security patches, host-based checks can be more accurate than
network scans. For example, some operating system vendors do not update the banners in
their network services, so remote network audits can not discriminate between a vulnerable
and a patched service. This is not to say that Nessus is blind to this situation. Nessus does
much more than simple banner checks and Tenable maintains a list of banners which may
have been fixed with a patch in its backport.inc file.
3

Host-based checks are also very fast. Typically, Nessus logs in and obtains all of the
information it needs in a few seconds. For network scans, latency of the network, firewalls
dropping network requests, and conducting port scans often takes longer than a host scan.
All networks and servers have different configuration and performance characteristics. But,
we have observed that in many cases it is quicker to log into a host and list the patches
than it is to actually scan a server.

Host-based checks also analyze the client software installed on the target host. For
example, a typical network scan of port 80 tells us a lot about the web server, but nothing
about the web client in use. In this age of spyware and malicious web sites, keeping our
email, secure shell, web, and other network clients up to date is critical.

And, if you were not convinced yet of the utility of testing for missing patches at the host
level, consider that this approach will also detect when security issues with entire libraries
are at hand.

And lastly, performing policy audits, such as testing if a screen saver is enabled, or if a
minimum password length has been set, is very easy with Nessus host-based checking
technology. Checks for a variety of Sarbanes-Oxley configuration audits, as well as other
US government and worldwide compliance standards, have been produced for Nessus which
make use of reading local files, checking registry settings, and running various operating
system commands.
What Kinds of Credentials are Needed?

UNIX Operating Systems

Tenables experience with the Nessus user community has been that non-root accounts are
good enough to conduct basic patch audits. Having said that, it is possible to configure
some UNIX operating systems with non-root accounts that have very little ability to do
anything useful. For example, locking down an account to the point that it can only run a
few commands will not allow for remote checking of patch levels.

For those who want to audit the commands that Nessus uses to conduct remote patch
audits, they can consider the ssh_get_info.nasl script. This script contains a list of all the
unique commands for each supported UNIX operating system used to obtain patch
information.

For compliance audits on UNIX systems, root accounts are generally needed. These
audits attempt to look at a wide variety of file and directory permissions and content. Not
having root access will not prevent all checks from occurring. For example, the /etc/passwd
file may be analyzed by non-root accounts, but not each accounts .rhosts or .shosts files.

Windows Operating Systems

Historically, patch audits have been performed by using an account that has the ability to
read registry settings on a Windows computer. This account could be on the machine being
scanned or part of a Windows domain account and used to log onto any host within that
domain.

4

However, several bulletins and software updates by Microsoft have made reading the
registry to determine software patch level unreliable. To overcome this, direct reading of
the file system is required. To do this, an Administrator account will be needed. This will
allow Nessus to attach to a computer and perform direct file analysis to determine the true
patch level of the systems being evaluated. On Windows XP Pro this file access will only
work with a local admin account if the Network access: Sharing and security model for local
accounts policy is changed. This is discussed in more detail later in this document under
Enabling Windows Logins for Local and Remote Audits.
Which Authentication Methods does Nessus Support?

UNIX Operating Systems

All UNIX host-based checks performed by Nessus make use of the Secure Shell (SSH)
protocol. Specifically, Nessus invokes an SSH version 2 session. Nessus has three types of
authentication methods for use with SSH. These are basic username and password,
public/private keys, and Kerberos.

Although basic username and password auditing via SSH works, it is not recommended.
The username and password are stored in clear text in the Nessus configuration file. Using
a username and password to audit one host may be reasonable, but this method also
encourages many remote UNIX hosts to be configured with the same username and
password combination. And finally, if this is the case, a malicious user can easily set up a
fake SSH daemon and capture the default username and password being used by the
security group.

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. Later on in this document
creating a unique public and private SSH key will be discussed, as well as placing the public
keys on the UNIX hosts to be tested.

It should also be noted that Nessus support for SSH only supports the blowfish-cbc
encryption algorithm. Some commercial variants of SSH do not have support for this
algorithm, possibly for export reasons. It is also possible to configure an SSH server to only
accept certain types of encryption. If blowfish-cbc is not supported by your SSH server,
Nessus will not be able to perform local checks with it.

The last form of authentication supported by Nessus for SSH on UNIX is Kerberos. To
configure a Nessus scanner to authenticate to a Kerberos Key Distribution Center (KDC), the
following information must be completed in the scanner nessusrc file:

Ker ber os KDC por t : 88
Ker ber os KDC Tr anspor t : udp
Ker ber os Real m( SSH Onl y) : myr eal m
Ker ber os Key Di st r i but i on Cent er ( KDC) : 192. 168. 20. 66

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

5

Nessus implementation of Kerberos authentication for SSH only supports the des-cbc
encryption algorithm as well.

Windows Operating Systems

Nessus supports several different types of authentication methods. Each of these methods
takes a username, password, and an optional (but sometimes required) domain name.

For historical compatibility, Nessus supports lanman authentication. This 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 are also supported by Nessus. NTLM is less secure than NTLMv2, but
used on many Windows 2000 servers and also supported for backwards compatibility on
older servers. NTLMv2 is cryptographically more secure than NTLM and also the default
authentication method chosen by Nessus when attempting to log into a Windows server.

It is possible to force Nessus to use NTLMv2 by enabling the Only use NTLMv2 setting at
scan time.

Nessus also supports SPNEGO, which stands for Simple and Protected Negotiate,
authentication. This protocol is used in a variety of Single Sign On (SSO) authentication
schemes. If the machine being scanned supports SPNEGO, Nessus will use that as an
authentication. If that is the case, either NTLMSSP with LMv2 authentication will be used or
Kerberos and RC4 encryption.

If Kerberos authentication is used throughout a Windows domain, Nessus can also use that.
In order to configure this though, the IP address of the Kerberos Domain Controller (actually
the IP address of the Windows 2003 Active Directory Server) must be provided. If Kerberos
authentication fails, Nessus will try to log on with NTLMSSP/LMv2.

If an extended security scheme is not supported (such as Kerberos or SPNEGO), Nessus will
first try to logon with LMv2, and if that fails, then with NTLM.

And as a last topic, as of early 2005, Nessus now had support for full SMB signing. This 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 the past, this prevented Nessus from
scanning servers configured with this feature. Since early 2005, Nessus has support for this
security mechanism and will do this by default. It is automatically used if it is required by
the remote Windows server.

Windows Usernames, Passwords, and Domains

The SMB domain field is optional and Nessus will be able to logon 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 would first look for this username in the local
systems list of users, and then 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 and
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
6

Administrator would be used with the password of that account. To log onto the domain,
the Administrator user name 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 Guests accounts
No username or password to test Null sessions
Enabling SSH Local Security Checks on UNIX

Outline

The process detailed below will allow you to perform local security checks on UNIX and
Linux systems. 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 the basic steps are:

1. Create a SSH private/public key pair for Nessus to use.
2. Create a user account on every system for which you want to perform a local scan.
3. Copy the SSH public key that Nessus will use in the directory of the new user.
4. Tell Nessus to use the SSH private and public keys and perform the scan.

Generating an SSH Public Key and Private Key

The first step is to generate a private/public key pair for the Nessus system to use. This
key pair can be generated from any of your Unix/Linux systems, using any user account.

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 install.)

# ssh-keygen -t dsa
Gener at i ng publ i c/ pr i vat e dsa key pai r .
Ent er f i l e i n whi ch t o save t he key ( / User s/ t est / . ssh/ i d_dsa) :
/home/test/Nessus/ssh_key
Ent er passphr ase ( empt y f or no passphr ase) :
Ent er same passphr ase agai n:
Your i dent i f i cat i on has been saved i n
/home/test/Nessus/ssh_key.
Your publ i c key has been saved i n
/home/test/Nessus/ssh_key. pub.
The key f i nger pr i nt i s:
06: 4a: f d: 76: ee: 0f : d4: e6: 4b: 74: 84: 9a: 99: e6: 12: ea

Do not transfer this file to any system other than the one running your Nessus client.
When ssh-keygen asks you for a passphrase, you may want to hit the Return key twice
(i.e.: do not set any passphrase). For this example, we will not use a passphrase.
7

For users of Nessus Windows, in order to more easily manage the public and private key
files, you may wish to copy both of them to the main Nessus application directory on the
system running Nessus (\Program Files\Tenable\Nessus by default), and then copy the
public key to the target systems as needed.

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 the purposes of this document we will call this user nessus, but you can use
any name.
Once the account is created for the user (using adduser or any utility that the system
provides you with), make sure that the account has no valid password set. To do this, you
will have to edit /etc/passwd with vi or vipw and change the password entry to an asterisk.
You must also create the directory under this new accounts home directory to hold the
public key. For this exercise, the directory will be /home/nessus/.ssh. An example is
provided below:

# vipw
( . . . )
nessus: *: 502: 502: : 0: 0: Test Account : / home/ nessus: / bi n/ bash
( . . . )
# cd /home/nessus
# mkdir .ssh

Now that the user account is created, you must transfer the key to the system and place it
in the appropriate directory. Finally, you must 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.

# scp ssh_key. pub r oot @192. 1. 1. 44: / home/ nessus/ . ssh/ aut hor i zed_keys

You can also copy the file from the system on which Nessus is installed. 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.

8

# chown -R nessus:nessus ~nessus/.ssh/
# chmod 0600 ~nessus/.ssh/authorized_keys
# chmod 0700 ~nessus/.ssh/

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).
Configuring Nessus for SSH Host-Based Checks

Nessus UNIX

A minimum of Nessus 2.2.0 is required to perform host-based checks. In addition, support
for SSL is also required. If your version of Nessus is new, but does not have SSL support
compiled in, it will not have the required logic to connect to the remote systems. Running
the nessud d command can show the available version and library info as shown below:

[ r oot @myt h Home] $ nessusd -d
Thi s i s Nessus 2. 2. 3 f or Dar wi n 7. 4. 0
compi l ed wi t h gcc ver si on 3. 3 20030304 ( Appl e Comput er , I nc. bui l d 1495)
Cur r ent set up :
nasl : 2. 2. 3 l i bnessus: 2. 2. 3 SSL suppor t : enabl ed

If you are using the Nessus GTK user interface, there is a tab named Credentials. Clicking
on it will reveal a user window such as the one shown below:

9

The highlighted area shows the parameters for specifying the SSH username or password as
well as the more secure SSH keys. If the SSH keys were created on a remote system, they
should be moved to the system running the Nessus client.

It should be pointed out that with a shared public and private key, the username of the
account on the remote system must be specified.

If you are not using the Nessus GUI, but creating manual .nessusrc files, there are several
parameters which can be manually configured to specify SSH authentication. An example of
an unpopulated listing is shown below:

Use SSH t o per f or ml ocal secur i t y checks[ ent r y] : SSH user name : =
Use SSH t o per f or ml ocal secur i t y checks[ f i l e] : SSH publ i c key t o use : =
Use SSH t o per f or ml ocal secur i t y checks[ f i l e] : SSH pr i vat e key t o use : =
Use SSH t o per f or ml ocal secur i t y checks[ passwor d] : Passphr ase f or SSH key : =
SSH set t i ngs[ ent r y] : SSH user name : =
SSH set t i ngs[ passwor d] : SSH passwor d ( unsaf e! ) : =
SSH set t i ngs[ f i l e] : SSH publ i c key t o use : = no
SSH set t i ngs[ f i l e] : SSH pr i vat e key t o use : =
SSH set t i ngs[ passwor d] : Passphr ase f or SSH key : =

Nessus Windows

If you have not already done so, secure copy the private and public key files to the system
that Nessus is installed on.

Open Nessus as seen above and select Manage Policies. Select Add a new policy, create
a name for the policy, and then click OK. The new policy will be added to the list of
managed policies. Next to the new policy, select Edit Settings.
10

From the Nessus configuration screen, select the Credentials tab and you will be
presented with the above screen.

For the item SSH user name enter the name of the account that is dedicated to
Nessus on each of the scan target systems.
For the item SSH public key to use click on the Browse button and locate the
public key file on the local system.
For the item SSH private key to use click on the Browse button and locate the
private key file on the local system.

At this point, click on Save at the bottom of the window and configuration should be
complete.
Enabling Windows Logins for Local and Remote Audits

Configuring a Local Account

To configure a stand-alone Windows server with credentials to be used that are not part of a
domain, as an administrator, simply create a unique account.

Within that account, make sure its configuration 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.

A very common mistake is to create a local account which does not have enough privileges
to log on remotely and do anything useful. As the last paragraph said, most Windows
servers are configured such that new local accounts go through a process such that if they
are logged in remotely, they actually inherit Guest privileges which will prevent remote
vulnerability audits. Another common mistake is to increase the amount of access that the
Guest users obtain. This reduces the security of your Windows server and should not be
used.
11

Configuring a Domain Account for Local Audits

In order 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 2003 Server.
It must also be part of a domain.

To configure the server to believe and 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. Under the Computer Configuration option open Windows Settings, and select
Security Settings, then Local Polices, and then click on Security Options.
3. From the list of polices open Network access: Sharing and security model for local
accounts.
4. In this dialog, select Classic local users authenticate as themselves 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.
Configuring Nessus for Windows Logins

Using the Nessus GUI

If you are running the Nessus UNIX GUI as shown on page 9, simply specifying the
username, password, and optional domain is required. A similar set of entries for Nessus
Windows is also available in its user interface in the configuration settings under the
Credentials tab.

Configuring Nessus through Command Line

If you are building a manual nessusrc file, there are three entries which allow for the
configuration of the username, password, and optional domain as shown below:

Logi n conf i gur at i ons[ ent r y] : SMB account : =
Logi n conf i gur at i ons[ passwor d] : SMB passwor d : =
Logi n conf i gur at i ons[ ent r y] : SMB domai n ( opt i onal ) : =
Detecting when Credentials Fail

If you are using Nessus to perform credentialed audits of UNIX or Windows systems,
analyzing the results to determine if you had the correct passwords and SSH keys can be
difficult. Nessus users can now easily detect if their credentials are not working. Tenable
has added Nessus plugin #21745 to the General plugins family as shown below:

12

This plugin detects if either SSH or Windows credentials did not allow the scan to log into
the remote host. When a login is successful, this plugin does not produce a result. The
following is an example report that was produced from trying to log into a remote Windows
machine with the incorrect username or password with Nessus Windows:

The following is an example report that was produced from trying to log into a UNIX
machine with the incorrect SSH credentials with Nessus Windows:

13

Troubleshooting

Q. How do we know if the local scan is working?

A. Unless you have a 100% patched server, any local scan will likely return some sort of
patch information. Depending on the operating system, it will also return a variety of
information audits.

It may also be useful to take Nessus out of the equation and 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:

ssh - i / home/ t est / nessus/ ssh_key nessus@192. 1. 1. 44 i d

Make sure to use the IP address of the system that the trust relationship is configured with
as well as the user account (in this case user Nessus). If the command succeeds, you
should see the results of the id command as if it were run on your remote system.

On UNIX audits the ssh_get_info.nasl script will report if the authentication was successful.
If SSH logins are not working, you can increase the report_verbosity setting of your
Nessus scan to Verbose. This will show any error or diagnostic messages while this
particular script is running.

For Windows audits, the smb_login.nasl and smb_registry_access.nasl scripts indicate if the
login and password provided during the scan worked and if it was possible to read the
remote registry. The smb_registry_full_access.nasl warns only if it was not possible to fully
read the registry. Looking at the results of host-based checks for audits of Windows server
will show how the credentials worked.

In addition, the hostlevel_check_failed.nasl script detects if either SSH or Windows
credentials did not allow the scan to log into the remote host.

Q. How do we know if the local scan is not working?

14

A. On Windows systems, login failure events will be generated at the server. If a domain
controller is in use, the login failure events will be located there as well.

On UNIX systems, login failures will be present in the system logs (such as
/var/log/messages) unless a remote Kerberos controller is in use.

In addition, the hostlevel_check_failed.nasl script detects if either SSH or Windows
credentials did not allow the scan to log into the remote host.

Q. What else can go wrong with my host checks?

A. There are many things that can block access. Some to consider include:

Network firewalls that filter port 22 for SSH on UNIX or port 445 for Windows
Host-based firewalls that block connections to the mentioned ports
On UNIX systems, administrators that move SSH to ports other than 22
Some host and network intrusion prevention systems prevent remote access
The machine you are scanning is not a UNIX or Windows server and could be a
printer, router, fax machine, or video display device

Q. I am testing SSH connections from the shell prompt of scan target hosts to the
Nessus system to ensure proper connectivity. I find it experiences a delay as it
connects, why?

A. This is most likely because the system is performing a DNS lookup. There are several
ways to prevent this:

1. Edit the /etc/nsswitch.conf file so that the hosts: lines reads hosts: files
Note: This may not be applicable to all OpenSSH releases.

2. Add the IP/name of the server running Nessus to the system's /etc/hosts file.

3. Configure the remote OpenSSH server to not do reverse DNS lookups on a host by
setting both:

UseDNS no in the sshd_config file (for release 3.8), the default value is yes
VerifyReverseMapping no

4. Have the network administrator add reverse DNS entries for all IPs. Note: If you do
this, you can test it from the system you will be scanning by timing the execution of:

host IP_ADRR_OF_NESSUS_SERVER

If you have dig installed, you can also check with:

dig -x IP_ADRR_OF_NESSUS_SERVER
Securing Your Scanner

Why should I secure my scanner?

15

If you configure a Nessus scanner to use credentials to log into a UNIX or Windows server,
your system will have credentials which could be leveraged by a malicious user. To prevent
this you must not only practice good security for the operating system your scanner is
running on, but you must also be aware how an adversary can trick the scanner into giving
up security information.

What does it mean to lock down a scanner?

The ideal Nessus scanner would be driven entirely from a system console and not accept
any network connections from any remote host. Such a system will be physically secured
such that only authorized people are allowed access to it. This server could further be
restricted with a firewall or switch policy which only allowed it to scan specific networks.
The actual Nessus scanner can also be configured to only scan specific networks as well.

This type of scanner is not that useful. Allowing remote network access to the server should
be considered. Nessus supports the Nessus Transfer Protocol (NTP) and can receive
connections to port 1241 for new scan jobs. A system firewall should be configured to only
accept connections on port 1241 from valid Nessus clients.

If the box is to be administrated or operated remotely, secure remote access should also be
used. On UNIX, the Secure Shell (SSH) protocol can be used. Keeping the SSH daemon up
to date, using strong passwords and/or using stronger authentication techniques should be
considered. On Windows servers, remote Terminal Services can be used to provide
command and control over the services for Nessus Windows. In both cases, keeping the
system up to date and not running unneeded network services should also be followed.

Secure Implementation of UNIX SSH Audits

Never use SSH passwords to perform remote scans. If you are scanning a network, then all
an adversary or malicious user would need to do is run a modified SSH daemon and record
the attempted username and password. Even if you are using a unique username and
password combination for each unique host, this information can be useful to an adversary
for guessing account names and likely passwords.

If you are auditing one server with a known username and password for logging in over
SSH, there is less chance that an adversary can use this against you. However, be sure to
secure the configuration of the scan, because the username and password will be stored
there in clear text.

Secure Windows Audits

As of writing this paper, Nessus can be tricked into attempting to log into a Windows Server
with their domain credentials via the NTLM protocol. Without describing the step-by-step
details on how to exploit this, this would provide 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. This hash may also be used to directly log into other servers.

To prevent this attack ensure that SMB Signing is enabled on all of your Windows servers.
This will prevent any server which obtains a hash from a Nessus scan to reuse it. Also, in
case the hash may be broken, strong passwords should be chosen to avoid dictionary
attacks from tools like John The Ripper and L0phtCrack.

16

NTLMv2 can make use of SMB Signing. As was said earlier in this document, it is possible
to 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.

It should also be noted 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.
For Further Information

Tenable hopes your experience with Nessus is very positive, and we strongly encourage you
to contact us via email or phone to discuss any issues you have. Tenable has produced a
variety of other documents detailing Nessus deployment, configuration, user operation, and
overall testing. These are listed here:

Nessus Installation Guide step by step walk through of installation
Nessus Client Guide how to install, configure, and operate the various clients
available for Nessus
Nessus Advanced User Guide elaborates on some of Nessus dustier corners
by explaining additional features
Real-Time Compliance Monitoring outlines how Tenables solutions can be used
to assist in meeting many different types of government and financial regulations

Please feel free to contact us at support@tenablesecurity.com, sales@tenablesecurity.com
or visit our web site at http://www.tenablesecurity.com. For more information about
Nessus, please visit http://www.nessus.org.

17

About Tenable Network Security

Tenable, located in Columbia, Md., develops enterprise security solutions that provide
vulnerability management, intrusion detection, and security event notifications across entire
organizations for effective network security management. Tenable is uniquely positioned to
detect vulnerabilities with active and passive scanning and analysis, and host-based patch
monitoring for enterprise networks. Key product lines include: Nessus Vulnerability
Scanner, the leading global technology utilized for vulnerability scanning; Passive
Vulnerability Scanner (formerly NeVO), for passive vulnerability monitoring; Security Center
(formerly Lightning Console), for enterprise security management; and Log Correlation
Engine (formerly Thunder), for secure log aggregation and analysis. For more information,
please visit us at http://www.tenablesecurity.com.

TENABLE Network Security, Inc.
7063 Columbia Gateway Drive
Suite 100
Columbia, MD 21046
TEL: 1-877-448-0489
http://www.tenablesecurity.com
18

Nessus Credential Checks

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Nessus Credential Checks

Enviado por

Direitos autorais:

Formatos disponíveis

Nessus Credential Checks for

UNIX and Windows

Você também pode gostar