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 SECURITY ................................................................................................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 [email protected]. 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/test/

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:

Kerberos KDC port : 88 Kerberos KDC Transport : udp Kerberos Realm (SSH Only) : myrealm Kerberos Key Distribution Center (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 Generating public/private dsa key pair. Enter file in which to save the key (/Users/test/.ssh/id_dsa): /home/test/Nessus/ssh_key Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/test/Nessus/ssh_key. Your public key has been saved in /home/test/Nessus/ssh_key.pub. The key fingerprint is: 06:4a:fd: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:/bin/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 [email protected]:/home/nessus/.ssh/authorized_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:

[root@myth Home]$ nessusd -d This is Nessus 2.2.3 for Darwin 7.4.0 compiled with gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) Current setup : nasl: 2.2.3 libnessus: 2.2.3 SSL support: enabled

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 to perform local security checks[entry]:SSH user name : = Use SSH to perform local security checks[file]:SSH public key to use : =Use SSH to perform local security checks[file]:SSH private key to use : = Use SSH to perform local security checks[password]:Passphrase for SSH key : =SSH settings[entry]:SSH user name : = SSH settings[password]:SSH password (unsafe!) : = SSH settings[file]:SSH public key to use : = no SSH settings[file]:SSH private key to use : = SSH settings[password]:Passphrase for 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:

Login configurations[entry]:SMB account : = Login configurations[password]:SMB password : = Login configurations[entry]:SMB domain (optional) : =

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/test/nessus/ssh_key [email protected] id

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 [email protected], [email protected] 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

Table of ContentsIntroductionWhy Perform Host-based Checks?What Kinds of Credentials are Needed?Which Authentication Methods does Nessus Support?Enabling SSH Local Security Checks on UNIXConfiguring Nessus for SSH Host-Based ChecksEnabling Windows Logins for Local and Remote AuditsConfiguring Nessus for Windows LoginsDetecting when Credentials FailTroubleshootingSecuring Your ScannerFor Further InformationAbout Tenable Network Security

Nessus Credential Checks

Documents

Transcript of Nessus Credential Checks