Tenable Network Security, Inc. • 7063 Columbia Gateway Drive, Suite 100, Columbia, MD 21046 • 410.872.0555 • sales@tenable.com • www.tenable.com
Copyright © 2011. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network
Security, Inc. The ProfessionalFeed is a trademark of Tenable Network Security, Inc. All other products or services are trademarks of their respective owners.
NNeessssuuss CCrreeddeennttiiaall CChheecckkss ffoorr
UUnniixx aanndd WWiinnddoowwss
April 21, 2011
(Revision 23)
Copyright © 2002-2011 Tenable Network Security, Inc.
2
TTaabbllee ooff CCoonntteennttss
Introduction ............................................................................................................................... 4
Standards and Conventions ....................................................................................................... 4
Overview of Nessus Credential Checks ..................................................................................... 4
Purpose ................................................................................................................................. 4
Access Level ......................................................................................................................... 5
Technologies Used ................................................................................................................ 5
Unix Systems ..................................................................................................................................... 5
Windows Systems .............................................................................................................................. 6
Credential Checks on Unix Platforms ...................................................................................... 7
Prerequisites .............................................................................................................................. 8
Configuration Requirements for SSH ..................................................................................... 8
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 ........................................................... 9
Example ...............................................................................................................................10
Configuring Nessus for SSH Host-Based Checks .....................................................................10
Nessus User Interface ..........................................................................................................10
Nessus Unix Command Line ................................................................................................13
Using .nessus Files ....................................................................................................................... 13
Using .nessusrc Files ................................................................................................................... 13
Using SSH Credentials with the Tenable SecurityCenter ..........................................................14
Credential Checks on Windows Platforms .............................................................................15
Prerequisites .............................................................................................................................15
User Privileges .....................................................................................................................15
Enabling Windows Logins for Local and Remote Audits ............................................................15
Configuring a Local Account .................................................................................................15
Configuring a Domain Account for Local Audits ....................................................................15
Configuring Windows XP and 2003 ......................................................................................16
Configuring Windows 2008 ...................................................................................................16
Configuring Nessus for Windows Logins ...................................................................................17
Nessus User Interface ..........................................................................................................17
Nessus Unix Command Line ................................................................................................18
Using .nessus Files ....................................................................................................................... 18
Using .nessusrc Files ................................................................................................................... 18
Detecting when Credentials Fail..............................................................................................18
Troubleshooting .......................................................................................................................19
Securing Your Scanner ............................................................................................................21
Why should I secure my scanner? ............................................................................................21
What does it mean to lock down a scanner? .............................................................................21
Secure Implementation of Unix SSH Audits ..............................................................................21
Copyright © 2002-2011 Tenable Network Security, Inc.
3
Secure Windows Audits ............................................................................................................21
For Further Information ...........................................................................................................22
About Tenable Network Security .............................................................................................23
Copyright © 2002-2011 Tenable Network Security, Inc.
4
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 share your comments and suggestions with us by emailing them to
support@tenable.com.
Nessus leverages the ability to log into remote Unix hosts via Secure Shell. For Windows
hosts, Nessus leverages a variety of Microsoft authentication technologies.
Note 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 Tenable’s SecurityCenter.
STANDARDS AND CONVENTIONS
Throughout the documentation, filenames, daemons and executables are indicated with a
courier bold font such as setup.exe.
Command line options and keywords are also printed with the courier bold font.
Command line options may or may not include the command line prompt and output text
from the results of the command. Often, the executed command will be boldfaced to
indicate what the user typed. Below 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 CREDENTIAL 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.
Copyright © 2002-2011 Tenable Network Security, Inc.
5
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.
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, Gramm-Leach-Bliley or HIPAA). Organizations that
accept credit card information must demonstrate compliance with the Payment Card
Industry (PCI) standards. 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 dependant 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 an 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. 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. On Windows XP Pro, this file access will only work with a local
administrator account if the “Network access: Sharing and security model for local
accounts” policy is changed to “Classic – local users authenticate as themselves”.
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 both Unix and Windows
platforms.
Unix Systems
On Unix systems, 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
Copyright © 2002-2011 Tenable Network Security, Inc.
6
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.
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.
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 ticket granting ticket, 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
Copyright © 2002-2011 Tenable Network Security, Inc.
7
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.
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 the users’ Windows
login credentials. Nessus supports use of SPNEGO with either NTLMSSP with LMv2
authentication or Kerberos and RC4 encryption.
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 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 first looks for this username in the local system’s list of
users, 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” 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
CREDENTIAL CHECKS ON UNIX PLATFORMS
The process described in this section enables you to perform local security checks on Unix
based systems. The SSH daemon used in this example is OpenSSH. If you have a
commercial variant of SSH, your procedure may be slightly different.
Copyright © 2002-2011 Tenable Network Security, Inc.
8
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 4.x supports the blowfish-cbc, aesXXX-cbc (aes128, aes192 and aes256), 3des-cbc
and aes-ctr algorithms.
Some commercial variants of SSH do not have support for the blowfish algorithm, possibly
for export reasons. It is also possible to configure an SSH server to only accept certain
types of encryption. Check your SSH server to ensure the correct algorithm is supported.
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
t
本文档为【Nessus_UNIX和WINDOWS扫描白皮书】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑,
图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。