#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass article
\begin_preamble
\usepackage{times}[12pt]
\end_preamble
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single 
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default

\layout Standard
\added_space_bottom bigskip \align center 

\series bold 
\size largest 
NessusClient User's Manual
\layout Standard
\added_space_bottom bigskip \align center 

\begin_inset Graphics
	filename nessus-logo.png
	keepAspectRatio
	clip

\end_inset 


\layout Standard
\added_space_bottom bigskip \align center 

\series bold 
\size large 
$Date: 2005/10/18 13:09:13 $
\layout Standard
\added_space_bottom bigskip \align center 

\series bold 
\size large 
Renaud Deraison <renaud@nessus.org>
\layout Standard
\added_space_bottom vfill \align center 

\series bold 
\size large 
Jan-Oliver Wagner <jan@intevation.de>
\layout Standard


\begin_inset LatexCommand \tableofcontents{}

\end_inset 


\layout Section*

About This Document
\layout Standard

This document describe how to use a Nessus Server via the GTK+ GUI 
\begin_inset Quotes eld
\end_inset 

NessusClient
\begin_inset Quotes erd
\end_inset 

.
 This may not cover the whole functionality of the Nessus Server nor does
 it claim to be complete.
 However, the text should be up-to-date and refers to the NessusClient 1.0
 release.
\layout Section

General Overview
\layout Standard

The 
\begin_inset Quotes eld
\end_inset 

Nessus
\begin_inset Quotes erd
\end_inset 

 Project provides powerful, up-to-date and easy to use remote security scanner
 as Free Software under GNU General Public License (GNU GPL).
 Nessus will allow you to audit remotely a given network and determine whether
 bad guys (aka 'crackers') may break into it, or misuse it in some way.
\layout Paragraph

Intelligent Scanning
\layout Standard

Unlike many other security scanners, Nessus does not take anything for granted.
 That is, it will not consider that a given service is running on a fixed
 port - that is, if you run your web server on port 1234, Nessus will detect
 it and test its security.
 It will also not determine a security vulnerability is present by just
 regarding the version number of the remote service, but will really attempt
 to exploit the vulnerability.
 
\layout Paragraph

Modular Architecture
\layout Standard

The client/server arquitecture allows you flexibility to deploy the scanner
 (server) and the GUI (client) in multiple configurations reducing management
 costs (one server can be used by multiple clients) Some other features
 of the Nessus Security Scanner are:
\layout Paragraph
\noindent 
CVE compatible
\layout Standard
\noindent 
Each plugin links to CVE for administrators to retrieve further information
 on published vulnerabilities.
 They also includes references to 
\series bold 
CERT, Bugtraq
\series default 
, and vendor security alerts.
\layout Paragraph
\noindent 
Plug-in architecture
\layout Standard
\noindent 
Each security test is written as an external plugin.
 This way, you can easily add your own tests without having to read the
 code of the Nessus Server engine 
\family typewriter 
nessusd
\family default 
.
 The complete list of the Nessus plugins is available at http://cgi.nessus.org/plu
gins.
\layout Paragraph
\noindent 
NASL
\layout Standard
\noindent 
The Nessus Security Scanner includes NASL, (Nessus Attack Scripting Language)
 a language designed to write security test easily and quickly.
 (security checks can also be written in C)
\layout Paragraph
\noindent 
Up-to-date security vulnerability database
\layout Standard
\noindent 
We mostly focus on the development of security checks for recent security
 holes.
 Our security checks database is updated on a daily basis, and all the newest
 security checks are available at http://www.nessus.org/scripts.php and on
 the FTP servers and mirrors.
 
\layout Paragraph
\noindent 
Can test an unlimited amount of hosts at the same time
\layout Standard
\noindent 
Depending of the power of the station you run the Nessus Server onto, you
 can test two, ten or forty hosts at the same time.
\layout Paragraph
\noindent 
Smart service recognition
\layout Standard
\noindent 
Nessus does not believe that the target hosts will respect the IANA assigned
 port numbers.
 This means that it will recognize a FTP server running on a non-standard
 port (31337 say), or a web server running on port 8080.
\layout Paragraph
\noindent 
Multiples services
\layout Standard
\noindent 
Imagine that you run two web servers (or more) on your host, one on port
 80 and another on port 8080.
 When it will come to testing their security, Nessus will test both of them.
\layout Paragraph
\noindent 
Tests cooperation
\layout Standard
\noindent 
The security tests performed by Nessus cooperate so that nothing useless
 is made.
 If your FTP server does not offer anonymous logins, then anonymous-related
 security checks will not be performed.
\layout Paragraph
\noindent 
Complete reports
\layout Standard
\noindent 
Nessus will not only tell you what's wrong on your network, but will, most
 of the time, tell you how to prevent crackers from exploiting the security
 holes found and will give you the risk level of each problem found (from
 Low to Very High)
\layout Paragraph
\noindent 
Exportable reports
\layout Standard
\noindent 
The Unix client can export Nessus reports as XML, HTML, text, LaTeX, PDF
 and an easy-to-parse file format.
\layout Paragraph
\noindent 
Full SSL support
\layout Standard
\noindent 
Nessus has the ability to test SSLized services such as https, smtps, imaps,
 and more.
 You can even supply Nessus with a certificate so that it can integrates
 into a PKI-fied environement.
\layout Paragraph
\noindent 
Smart plugins (optional)
\layout Standard
\noindent 
Nessus will determine which plugins should or should not be launched against
 the remote host (for instance, this prevents the testing of Sendmail vulnerabil
ities against Postfix).
 This option is called "optimizations".
\layout Paragraph
\noindent 
Non-destructive (optional)
\layout Standard
\noindent 
If you don't want to take the risk to bring down services on your network,
 you can enable the "safe checks" option of Nessus, which will make Nessus
 rely on banners rather than exploiting real flaws to determine if a vulnerabili
ty is present.
\layout Paragraph
\noindent 
Independent developers
\layout Standard
\noindent 
The Nessus developers are independent from the rest of the world, so we
 will not hide a security vulnerability in the program XYZ because we have
 a contract with them.
\layout Paragraph
\noindent 
Easy-to-reach developers
\layout Standard
\noindent 
You feel that there is a missing feature? Just contact ushttp://www.nessus.org/con
tact/ or use the Nessus mailing lists.
 We reply and implement what makes sense.
\layout Paragraph
\noindent 
Open bug tracking system.
\layout Standard
\noindent 
Found a bug? Report it here: http://bugs.nessus.org.
\layout Paragraph
\noindent 
Huge number of tests
\layout Standard
\noindent 
There are more than 7000 nessus tests (and constantly growing!) which are
 divided into 23 different families:
\layout Itemize

Backdoors
\layout Itemize

CGI abuses
\layout Itemize

CISCO
\layout Itemize

Denial of Service
\layout Itemize

Finger abuses
\layout Itemize

Firewalls
\layout Itemize

FTP
\layout Itemize

Gain a shell remotely
\layout Itemize

Gain root remotely
\layout Itemize

General
\layout Itemize

Misc.
\layout Itemize

Netware
\layout Itemize

NIS
\layout Itemize

Port scanners
\layout Itemize

Remote file access
\layout Itemize

RPC
\layout Itemize

Settings
\layout Itemize

SMTP problems
\layout Itemize

SNMP
\layout Itemize

Untested
\layout Itemize

Useless services
\layout Itemize

Windows
\layout Section

Installation
\layout Standard

Note that only the source is what the Nessus developer team primarily tests
 in depth.
 Binary installation packages are likely to be available for most standard
 operating systems but not necessarily be tested by the Nessus development
 team.
\layout Standard

Operating systems not listed here may offer well-maintained packages as
 well.
 
\layout Subsection

From Source
\layout Standard

The usual way of installing from scratch is to get a current CVS snapshot
 or a source tar-ball of the module 
\begin_inset Quotes eld
\end_inset 

NessusClient
\begin_inset Quotes erd
\end_inset 

 and perform the usual sequence 
\begin_inset Quotes eld
\end_inset 

./configure ; make ; make install
\begin_inset Quotes erd
\end_inset 

.
 Please also as usual read the files about installation and configuration
 options in the packages first.
\layout Subsection

Debian GNU/Linux
\layout Standard

Please refer to the Debian documentation on how to install standard Debian
 packages.
 Debian actively support Nessus packages.
\layout Subsubsection

Debian 
\begin_inset Quotes eld
\end_inset 

Woody
\begin_inset Quotes erd
\end_inset 

 3.0
\layout Standard

The official version of Nessus for Woody is 1.0.10.
 This is by far outdated, you should neither use Nessus Server nor Client
 as shipped with Woody! 
\layout Standard

The build- and run-dependencies of NessusClient are conservative so that
 you do not need to backport any other package for backporting NessusClient.
 Thus it might work to create a so-called 
\begin_inset Quotes eld
\end_inset 

backport
\begin_inset Quotes erd
\end_inset 

 for Woody from a newer Debian source package of NessusClient.
\layout Subsubsection

Debian 
\begin_inset Quotes eld
\end_inset 

Sarge
\begin_inset Quotes erd
\end_inset 

 3.1
\layout Standard

The official version of Nessus for Sarge is 2.2.3.
 NessusClient is compatible with this Nessus Server, but it is recommended
 to update the Nessus Server to get the newest bug-fixes.
\layout Standard

The build- and run-dependencies of NessusClient are conservative so that
 you do not need to backport any other package for backporting NessusClient.
 Thus it might work to create a so-called 
\begin_inset Quotes eld
\end_inset 

backport
\begin_inset Quotes erd
\end_inset 

 for Sarge from a newer Debian source package of NessusClient.
\layout Subsubsection

Debian 
\begin_inset Quotes eld
\end_inset 

Etch
\begin_inset Quotes erd
\end_inset 


\layout Standard

At time of writing, Etch is the current Testing version of Debian and thus
 in flux.
 At least Nessus 2.2.5 is included.
 It is expected that NessusClient packages will appear, once NessusClient
 is released.
\layout Subsection

RedHat Linux
\layout Subsubsection

Fedora Core 3 and 4
\layout Standard

This distribution actively maintains Nessus packages.
 In case you need a newer version than shipped, you may find backports.
 Backports for RPM packages maybe found via rpmfind.net or similar services.
\layout Standard

The build- and run-dependencies of NessusClient are conservative so that
 you do not need to backport any other package for backporting NessusClient.
 It might even work to install newer packages directly.
\layout Subsection

SUSE Linux
\layout Subsubsection

SUSE Linux 9.2
\layout Standard

Nessus is part of this distribution with the latest 2.0 release.
 It is highly recommended you update Nessus Server.
 Backports for RPM packages maybe found via rpmfind.net or similar services.
\layout Standard

The build- and run-dependencies of NessusClient are conservative so that
 you do not need to backport any other package for backporting NessusClient.
 It might even work to install newer packages directly.
\layout Subsection

MS Windows
\layout Subsubsection

Windows XP SP2
\layout Standard

For Windows a regular setup package is available for NessusClient, usually
 called 
\shape italic 
NessusClientN.N.N-setup-en.exe 
\shape default 
(for an english version) or
\shape italic 
 NessusClientN.N.N-setup-de.exe
\shape default 
 (for a german version).
 Either execute it directly or use this in the Windows Manager for Software.
 This is also the tool where you can easily and cleanly deinstall NessusClient
 again.
 N.N.N defines the version of Nessus, e.g.
 1.0.0.
\layout Subsection

Migrating Nessus GTK Client from version 2.2
\layout Standard

NessusClient has a new way to store session data locally compared to the
 GTK client that was included in Nessus 2.2.
 In fact, the whole concept of tasks, scopes and reports is new since then.
\layout Standard

The main difference is that Nessus GTK Clients upto 2.2 consider a single
 file 
\begin_inset Quotes eld
\end_inset 

.nessusrc
\begin_inset Quotes erd
\end_inset 

 in the users home directory.
 The newer versions use a directory structure with the main directory 
\begin_inset Quotes eld
\end_inset 

.nessus
\begin_inset Quotes erd
\end_inset 

 in the users home directory.
 
\layout Standard

Nonetheless, there will be no conflict when running the new version because
 the new version uses the .nessusrc file as the reference for the global
 setting (see below).
 In other words, the configuration of your Nessus GTK Client 2.2 will be
 the default configuration for NessusClient.
\layout Standard

It is even possible to run a Nessus GTK Client 2.2 after a newer version
 has been launched.
 Version 2.2 will simply use the same file 
\begin_inset Quotes eld
\end_inset 

.nessusrc
\begin_inset Quotes erd
\end_inset 

, the new version uses for the global settings.
 
\layout Section

The First Report
\layout Standard

This section is intended to lead a novice user quickly through a first security
 scan with Nessus.
 After a successful first scan it is recommended to proceed with the chapter
 on the general usage of NessusClient.
\layout Subsection

Invoking NessusClient
\layout Standard

On any unixoid system you can simply type 
\begin_inset Quotes eld
\end_inset 

NessusClient
\begin_inset Quotes erd
\end_inset 

 in a command shell.
 Of course you should have X running.
\layout Standard

For Debian GNU/Linux, SUSE Linux, ReadHat/Fedora and MS Windows you will
 additionally find a menu entry for NessusClient if installed with one of
 the above explained install packages.
\layout Subsection

The Nessus Scan Assistant
\layout Standard

If you are new to Nessus and NessusClient you may want to use the Nessus
 Scan Assistant to perform you first scan.
 The intention of this assistant is summarize the core parameters you need
 to enter for a scan and to be self-explanatory.
\layout Standard

However, 
\series bold 
you should note
\series default 
 that the scan performed through the Assistant will be based on the global
 settings.
 If you have switched on some dangerous options already in the global settings,
 these will be inherited! 
\layout Section

General Usage of NessusClient
\layout Standard

This section is intended to explain all general elements of NessusClient
 and how to use it in a standard way.
 A later chapter will then address more specific features suitable for advanced
 users.
\layout Subsection

The Main Window
\layout Standard

The main window of NessusClient is separated into two major sections: On
 the left-hand side the treelist with an overview of the locally stored
 tasks, scopes and reports.
 On the right-hand side there is a notebook with pages for comments, options
 and reports.
 That is the place where a security scan is to be configured, commented
 upon and the result reviewed.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/mainwindow-en.png

\end_inset 


\layout Standard

At the first start of NessusClient, you will see only one entry in the list:
 Global Settings.
 These settings are defaults coming with NessusClient.
 They are not covering a specific selection of plugins since a connection
 to a Nessus Server is required for that.
 You can establish a connection with a server and specify the global defaults
 for a plugin selection.
\layout Subsubsection

Tasks
\layout Standard

Tasks are intended to cover all activities of a major topic.
 E.g., a task could be 
\begin_inset Quotes eld
\end_inset 

Test the maschines of our headquarter
\begin_inset Quotes erd
\end_inset 

 or 
\begin_inset Quotes eld
\end_inset 

Customer XYZ Inc.
\begin_inset Quotes erd
\end_inset 

.
\layout Standard

A task can contain a comment that explains the task in more detail.
 Also any type of additional info or reminder can be entered in the comment
 area, e.g.
 when to run the next series of scans or based on which contract the scans
 are performed.
\layout Standard

A task has neither options nor a report.
 It just contains a number of scopes.
\layout Standard

Possible operations for tasks are:
\layout Paragraph

New
\layout Standard

Adds a new task entitled 
\begin_inset Quotes eld
\end_inset 

unnamed
\begin_inset Quotes erd
\end_inset 

.
\layout Paragraph

Rename
\layout Standard

Allows to edit the title right in the treelist either by clicking on the
 title or by selecting the corresponding menu item.
\layout Paragraph

Remove
\layout Standard

This means the removal of all associated scopes and thus the removal action
 prompts for an additional confirmation.
\layout Subsubsection

Scopes
\layout Standard

A scope can be seen as a sub-task.
 It defines a certain security scan.
 The title should indicate the scope of this scan, e.g.
 
\begin_inset Quotes eld
\end_inset 

Careful scan of web server production system
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

Aggressive scan of web server alpha test sytem
\begin_inset Quotes erd
\end_inset 

 or 
\begin_inset Quotes eld
\end_inset 

All Sun workstations
\begin_inset Quotes erd
\end_inset 

.
\layout Standard

Comments can also be specified for each scope and may explain the scope
 in more detail as well as contain any other helpful hint regarding the
 respective scope.
\layout Standard

The scope is associated with a full set of options for the security scan.
 Creating a new scope, the general preferences are copied.
 The scan options are explained in detail in a later chapter.
 However, for each scope a connection to a Nessus Server can be established.
 Has this been done, the actual selection of the plugins being a part of
 the options can be performed (a plug icon right-hand of the title indicates
 the active connection).
 The reason is that each Nessus Server may contain its own set of plugins
 and thus with establishing a connection, NessusClient retrieves the list
 of available plugins.
\layout Standard

Next, a scope may contain a number of reports.
 Whenever a scope is successfully executed, the resulting report is added
 in its list of reports.
 Also, importing a report from a file or from a Nessus Server will add the
 report to the currently selected scope.
\layout Standard

Possible operations for scopes are: 
\layout Paragraph

Execute
\layout Standard

A security scan is executed with the currently specified options issueing
 the currently connected Nessus Server.
\layout Paragraph

New
\layout Standard

Adds a new scope entitled 
\begin_inset Quotes eld
\end_inset 

unnamed
\begin_inset Quotes erd
\end_inset 

 as part of the currently selected task.
 As a default the global settings are copied.
\layout Paragraph

Rename
\layout Standard

Allows to edit the title right in the treelist either by clicking on the
 title or by selecting the corresponding menu item.
\layout Paragraph

Remove
\layout Standard

This means the removal of all associated reports and thus the removal action
 prompts for an additional confirmation.
\layout Paragraph

Move to task
\layout Standard

It is possible to move a scope with all of its reports from one task to
 another.
 This menu item has subitems which represent the other tasks.
 Select one of them and the scope will be moved.
\layout Paragraph

Open
\layout Standard

You can load a scope file and add it to the current task with this menu
 command.
 Note that here only the parameter sets are covered but not the reports
 which are represented by files of their own.
 So, opening and saving (see below) scopes is a method to transfer you settings
 to someone else or to create a copy of the current scope for yourself.
\layout Paragraph

Save As
\layout Standard

Saves the current scope to a file (which is of nessusrc type).
 Note that only the parameter sets are stored but not the reports.
 See above the description of 
\begin_inset Quotes eld
\end_inset 

Open
\begin_inset Quotes erd
\end_inset 

 for more hints.
 
\layout Subsubsection

Reports
\layout Standard

A report is the result of a security scan.
 It contains the results of the executed plugins associated with the correspondi
ng subnet, host, port and severity.
\layout Standard

Managed within NessusClient, additionally a comment and, if available, the
 scan options leading to the report, are stored.
 These additional information are not contained in the plain Nessus report
 files and thus get lost when being exported.
 This also means that imported reports have no comments or scan options
 associated.
\layout Standard

Possible operations for reports are:
\layout Paragraph

Remove
\layout Standard

Deletes the report and, if associated, its comments and options.
 The user is prompted to confirm the removal.
\layout Paragraph

Import
\layout Standard

Allows to import a report from a file.
 The standard exchange format is NBE (files suffixed 
\begin_inset Quotes eld
\end_inset 

.nbe
\begin_inset Quotes erd
\end_inset 

).
 Older releases of Nessus used the format NSR (files suffixed 
\begin_inset Quotes eld
\end_inset 

.nsr
\begin_inset Quotes erd
\end_inset 

).
 It is recommended to use NBE format only.
 The file selection dialog allows to select the desired report file.
 A error hint will be displayed if the file format was not NBE.
 Else, the report is added to the currently selected scope.
 Neither comments nor options will be there for a report imported from a
 NBE file.
\layout Paragraph

Export
\layout Standard

Allows to export the currently selected report either in a re-importable
 format (NBE or the deprecated NSR) or in a format for further processing
 or presentation (XML, old deprecated XML, HTML, HTML with Pies and Graphs,
 LaTeX, ASCII Text and PDF).
 It is recommended to use NBE if re-importing is planned and to use PDF
 for creating simple report documents that need no further editing.
 Use one of the other if you want to further process the report or integrate
 it into your own document style.
\layout Paragraph

Print
\layout Standard

Selecting the Print command will issue the creation of a PDF report and
 run a PDF Viewer installed on your system.
 A number of well-known PDF Viewers is tried.
 If you think you have one installed but it still does not work, please
 check whether the executable file is covered by the search paths.
 
\layout Subsection

Authentication
\layout Standard

NessusClient needs to connect to a Nessus Server in order to retrieve the
 available plugins and to actually execute a security scan.
\layout Standard

NessusClient can handle mutiple connections to different servers.
 Each scope has a connection of its own.
 Additionally, the Global Settings can be connected to a Nessus Server to
 define default plugin selections and plugin parameters.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/authentication-dlg-en.png
	scale 90

\end_inset 


\layout Standard

The connection status is indicated with a icon in the tasks/scopes/reports
 treelist next to the title of the global settings or a scope.
 Only scopes are connected with Nessus Server.
\layout Standard

More information on the connection status is shown in the statusbar at the
 bottom of the main window.
 There, the actual connection information is displayed, ie.
 
\begin_inset Quotes eld
\end_inset 

Connection: username@host.test.example
\begin_inset Quotes erd
\end_inset 

.
 At bottom right there is an icon indicating whether the connection is encrypted
 or not, just like most web browsers indicate this.
\layout Standard

The connection dialog allows to specify the following data for establishing
 a connection to a Nessus Server:
\layout Paragraph

Host
\layout Standard

The domain name or IP of the server where a Nessus Server is running.
\layout Paragraph

Port
\layout Standard

The port where the Nessus Server waits for connections.
 Older Nessus Servers used 3001, but the official port now is 1241.
 With the default button you can always return to this default quickly.
\layout Paragraph

Login
\layout Standard

Your username at the selected host.
 To use a Nessus Server you have to have an account for the Nessus Server.
 The administrator of the server should create one for you.
\layout Paragraph

Password
\layout Standard

The password for your Nessus Server account.
 Don't use the same one you have for your other user accounts and especially
 if you ever use unencrypted connections.
\layout Paragraph

SSL Options
\layout Subparagraph

Use SSL encryption:
\layout Standard

For the authentication there are two basic methods, via login/password combinati
on or via certificate (with or without password).
 In any case you should switch on SSL encryption to not have the password
 transferred as cleartext.
 However, if you are in an evironment where you don't get SSL to work, switching
 it off is the work around to run Nessus at last.
\layout Subparagraph

Trusted CA:
\layout Standard

This certificate defines a certificate authority (CA) you trust.
 With this certificate you will check that you are connecting to a trusted
 Nessus Server.
 This is checked if you have the Paranoia Level set to 2 or 3, it is not
 checked with a Paranoia Level of 1.
 Note, that you can set the Paranoia Level by hand in the nessusrc files
 or when first connecting to a Nessus Server where you are asked explictly.
\layout Standard

The default path for the Trusted CA is the filename used by the Nessus Server
 itself.
 Thus, if you are running Nessus Client on the same maschine or have the
 same volume mounted, you can just use the default.
\layout Standard

If you are running Nessus Client from a more remote maschine, you need to
 have a copy of the CA certificate and place it to some arbitrary place
 in your home directory.
\layout Subparagraph

Authentication by Certificate:
\layout Standard

If you use this method you have to have a key/certificate pair created for
 you.
 This is usually done by the administrator of Nessus Server using the correspond
ing scripts.
 The administrator will give you the two files you need to specify (User
 Certificate File and User Key File).
 The administrator may create a key without a password or with a password.
 If you have a password for the User Key File you must enter the password
 in the corresponding textentry.
\layout Subsection

Scan Options
\layout Standard

This section explains the most important configuration options for a security
 scan.
 More special option (access rules, knowledge base detached scans) are explained
 later in the chapter on special features.
\layout Subsubsection

General
\layout Standard

This page covers all the general scan options.
 See the screenshot for the main window above.
\layout Paragraph

Port range
\layout Standard

Ports that will be scanned by Nessus Server.
 You can enter single ports, such as 
\begin_inset Quotes eld
\end_inset 

1-8000
\begin_inset Quotes erd
\end_inset 

 or more complex sets, such as 
\begin_inset Quotes eld
\end_inset 

21,23,25,1024-2048,6000
\begin_inset Quotes erd
\end_inset 

.
 Put 
\begin_inset Quotes eld
\end_inset 

-1
\begin_inset Quotes erd
\end_inset 

 for no portscan, or put 
\begin_inset Quotes eld
\end_inset 

default
\begin_inset Quotes erd
\end_inset 

 to scan the default ports in the Nessus services file.
\layout Paragraph

Consider unscanned ports as closed
\layout Standard

To save scanning time, you may ask Nessus Server to declare TCP ports it
 did not scan as closed.
 This will result in an incomplete audit but it will reduce scanning time
 and prevent Nessus Server from sending packets to ports you did not specify.
 If this option is disabled, then Nessus Server will consider ports whose
 state it does not know as open.
\layout Paragraph

Number of hosts to test at the same time
\layout Standard

Maximal number of hosts that the Nessus Server will test at the same time.
 Be aware that the Nessus Server will spawn max_hosts max_checks processes!
\layout Paragraph

Number of checks to perform at the same time
\layout Standard

Maximal number of security checks that will be launched at the same time
 against each host.
 Be aware that the Nessus Server will spawn max_hosts x max_checks processes!
\layout Paragraph

Path to CGIs
\layout Standard

It is possible to check for the presence of CGIs in multiple paths like
 
\begin_inset Quotes eld
\end_inset 

/cgi-bin
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

/cgis
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

/home-cgis
\begin_inset Quotes erd
\end_inset 

 and so on.
 In that case, put all your paths here separated by colons.
 For instance: 
\begin_inset Quotes eld
\end_inset 

/cgi-bin:/cgi-aws:/~deraison/cgi
\begin_inset Quotes erd
\end_inset 

.
\layout Paragraph

Do a reverse lookup of the IP before testing it
\layout Standard

If this option is set, Nessus Server will do a reverse lookup on the IP
 addresses before it tests them.
 This may slow down the whole test.
\layout Paragraph

Optimize the test
\layout Standard

Security tests may ask the Nessus Server to be launched if and only if some
 information gathered by other test exist in the knowledge base, or if and
 only if a given port is open.
 This option speeds up the test, but may make Nessus Server miss some vulnerabil
ity.
 If you are paranoid, disable this option.
\layout Paragraph

Safe checks
\layout Standard

Some security checks may harm the target server, by disabling the remote
 service temporarily or until a reboot.
 If you enable this option, Nessus Server will rely on banners instead of
 actually performing a security check.
 You will obtain a less reliable report, but you will less likely disrupt
 the network users by doing a test.
 From a security point of view, we recommend you disable this option.
 From a sysadmin point of view, we recommand you enable it.
\layout Paragraph

Designate hosts by their MAC address
\layout Standard

If you enable this option, the hosts on the local network will be designated
 by their ethernet MAC address instead of their IP address.
 This is especially useful if you are using Nessus in a DHCP network.
 If unsure, disable this option.
\layout Paragraph

Port Scanner
\layout Standard

This is the list of available port scanners.
 Port scanners are a special category of plugins and therefore presented
 separately from the other plugins.
 The list is only filled if a connection to a Nessus Server has been established.
 You can switch on one or more of the scanners.
 Clicking on an entry shows the details for the respecitve scanner plugin.
\layout Subsubsection

Plugins
\layout Standard

The plugins are stored on the Nessus Server.
 Thus, to make a selection of the plugins to apply you need to connect to
 a server.
 Otherwise this page will remain empty.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/mainwindow-plugins-en.png
	scale 90

\end_inset 


\layout Standard

The Plugins are separated into a number of families which can be as a whole
 activated or deactivated by checking the box right of family title.
 Also, a family can be expanded to show all of its member plugins where
 you can refine the selection by activating or deactivating single plugins
 using the checkbox to the right.
\layout Standard

The column 
\begin_inset Quotes eld
\end_inset 

Warning
\begin_inset Quotes erd
\end_inset 

 contains warning sign for some plugins.
 The warning sign means that this plugin may harm the target host by disabling
 the attacked service or by crashing the host.
 You should be careful when you enable it since it may force you to reboot
 your servers or restart some services manually.
\layout Standard

Below the plugin list the total number of plugins loaded from the server
 is shown, together with the total number of currently selected plugin as
 well as the number of plugins shown due to a applied filter.
\layout Standard

The following actions are possible:
\layout Subparagraph

Enable all
\layout Standard

Enables all plugin categories.
\layout Subparagraph

Disable all
\layout Standard

Disables all plugin categories.
\layout Subparagraph

Expand all
\layout Standard

Expands the Plugin tree-list to maximum so that the list contains all plugins.
\layout Subparagraph

Collapse all
\layout Standard

Only show the Plugin families.
\layout Subparagraph

Enable dependencies at runtime
\layout Standard

If you enable this option, then Nessus Server will enable the plugins that
 are depended on by the set of plugins you selected.
\layout Subparagraph

Silent dependencies
\layout Standard

If you enable this option, then Nessus Server will not report data coming
 from the plugins that you did not specifically enable.
\layout Subparagraph

Filter
\layout Standard

The filter dialog lets you select plugins with the characteristics you want.
 
\series bold 
Note
\series default 
, that you will erase your previous selection immedialty with applying a
 filter.
\layout Paragraph

Plugin information dialog
\layout Standard

Double-Clicking on a specific plugin title will raise a information dialog
 for the respective plugin.
\layout Standard

The information shown are the ones specified within the corresponding plugin.
\layout Standard

The following actions are possible in this dialog:
\layout Subparagraph

Set plugin timeout
\layout Standard

Allows to specify a timeout for the plugin.
\layout Subparagraph

Show dependencies
\layout Standard

Another info dialog is raised listing up the dependencies for the plugin.
 Also it is provided a hint whether the dependencies are currently enabled
 or disabled.
\layout Subsubsection

Credentials
\layout Standard

Some of the plugins allow to enter credentials to test certain applications,
 for example Samba or Web-Sites (HTTP).
 These plugins work the very same way as the plugins listed in the 
\begin_inset Quotes eld
\end_inset 

Plugin Preferences
\begin_inset Quotes erd
\end_inset 

 list.
 For better handling they are collected under 
\begin_inset Quotes eld
\end_inset 

Credentials
\begin_inset Quotes erd
\end_inset 

.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/mainwindow-credentials-en.png
	scale 90

\end_inset 


\layout Subsubsection

Plugin Preferences
\layout Standard

Some of the plugins allow to refine with specific parameters.
 All of the configurable plugins' parameters are collected on this page
 where the user may modify the default values.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/mainwindow-pluginprefs-en.png
	scale 90

\end_inset 


\layout Standard

Only a comparably small number of plugins offers a configuration.
\layout Subsubsection

Target Selection
\layout Standard
\align center 

\begin_inset Graphics
	filename images/mainwindow-targetselection-en.png
	scale 90

\end_inset 


\layout Paragraph

Target(s)
\layout Standard

The first host(s) that will be attacked by Nessus Server.
 The options below allow you to extend the test to a larger set of computer.
 You may define several primary targets by separating them with a comma
 (,).
 ie : 
\begin_inset Quotes eld
\end_inset 

host1,host2
\begin_inset Quotes erd
\end_inset 

.
\layout Standard

A special syntax is 
\begin_inset Quotes eld
\end_inset 

file:/some/where/targetlist.txt
\begin_inset Quotes erd
\end_inset 

 which means that the actual target names are loaded from that list.
 See for the file syntax also below the description for the button 
\begin_inset Quotes eld
\end_inset 

Read from file
\begin_inset Quotes erd
\end_inset 

.
\layout Paragraph

Read from file
\layout Standard

A textfile can be specified that contains the list of targets.
 This textfile may contain comma-separated lists of host and also may contain
 many of such lines.
\layout Paragraph

Perform a DNS Zone transfer
\layout Standard

Nessus Server will perform an AXFR request (that is, a zone transfer) to
 the target name server and will attempt to obtain the list of the hosts
 of the target domain.
 Then, it will test each host.
\layout Subsection

Reports
\layout Subsubsection

Report Page of NessusClient
\layout Standard

The report page consists of 5 elements.
 The size of each element can be changed to set a comfortable layout for
 viewing the report.
 The whole design is focused on supporting an explorative understanding
 of the scan results.
 The fifth element at the bottom right corner always contains the scan results
 for the subselection done through the first 4 elements.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/mainwindow-report-en.png
	scale 90

\end_inset 


\layout Standard

The default filtering selection has the sequence 
\begin_inset Quotes eld
\end_inset 

Subnet
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

Host
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

Port
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

Severity
\begin_inset Quotes erd
\end_inset 

.
 By changing this sequence and the selections in the corresponding list
 you may creat arbitrary filters in order to create helpful views for exploring
 and understanding the scan results.
\layout Subsubsection

Report Formats
\layout Standard

The scan results can be exported into a number of formats.
 Basically it can be distinguished between 3 types of formats: Interchange-Forma
ts, Editable Documents and Read-only Documents.
 The last type currently is the PDF Report file.
 With a capable view it allows to browse back and forth through the document
 using the various inserted hyperlinks.
\layout Standard

For further information see the section about the menu command 
\begin_inset Quotes eld
\end_inset 

Report->Export
\begin_inset Quotes erd
\end_inset 

.
\layout Section

Special Features
\layout Subsection

NessusClient Preferences
\layout Standard

NessusClient allows to specify some individual preferences that determine
 some ways how the client GUI works.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/preferences-dlg-en.png
	scale 90
	keepAspectRatio

\end_inset 


\layout Standard

The following selection are available:
\layout Subsubsection

User Interface
\layout Paragraph

Auto expand tree elements
\layout Standard

In the left-hand treeview clicking on a task or a scope automatically expands
 the corresponding tree if checked.
\layout Standard

If not checked, the user has to manually click on the expand icon each time.
\layout Subsubsection

Connection to Nessus Server
\layout Paragraph

Automatically connect
\layout Standard

If this setting is enabled, the NessusClient will try to connect to the
 server when a scope is executed.
 For user certificates without a password, this will work immediately.
 For password protected user certificates or simple password based authenticatio
n, the password will be stored in memory after a successful login until
 NessusClient is closed.
\layout Subsubsection

External Links in HTML/PDF
\layout Standard

These settings determine the URLs for linking more information on Nessus
 Plugin, CVE/CAN and BugTraq ID in Reports of format HTML or PDF.
 The defaults as shown in the screenshots are recommended since there up-to-date
 information are to be found.
 The defaults are reactivated when field is left empty.
\layout Standard

In case you want to package a Nessus report with e.g.
 CVE/CAN details for offline-reading, you may enter an apropriate definition
 like ``mitre/%s/%s/%s.html'' in case you have a directory structure relative
 to the report file with mitre/CVE/yyyy/nnnn.html and mitre/CAN/yyyy/nnnn.html
 where yyyy is the year and nnnn is the number of the record.
 Then you could package all files together.
\layout Standard

Note, that the strings defined here are filled into the html link parameter
 ``href'' as it is.
 The tool ``htmldoc'' is issued to produce a pdf out of this html report.
 Depending on the version and features the created links in the PDF file
 may be created differently.
\layout Subsection

User-defined Access Rules
\layout Subsubsection

General
\layout Standard

Nessus Server keeps a list of access rules similar to usual firewall rules.
 In no way can these be overridden by the Nessus Client.
\layout Standard

Furthermore, the Nessus Server Administrator can add specific rules for
 each user while applying the tool 
\family typewriter 
nessus-adduser
\family default 
.
\layout Standard

And finally, the User may add another set of rules in NessusClient.
\layout Subsubsection

Syntax
\layout Standard

A rule might either be a default definition: 
\begin_inset Quotes eld
\end_inset 

default deny
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

default reject
\begin_inset Quotes erd
\end_inset 

 or 
\begin_inset Quotes eld
\end_inset 

default accept
\begin_inset Quotes erd
\end_inset 

.
\layout Standard

Or it is a target specific definition that consists of the action (
\begin_inset Quotes eld
\end_inset 

deny
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

reject
\begin_inset Quotes erd
\end_inset 

 or 
\begin_inset Quotes eld
\end_inset 

accept
\begin_inset Quotes erd
\end_inset 

) and a target specified with its IP (eg.
 192.168.10.10).
\layout Standard

Note that it must be an IP.
 The use of hostnames is not allowed due to security reasons.
\layout Subsubsection

Manage rules in NessusClient
\layout Standard

A rule consists of a action and (in case no default action is dfined) a
 target.
 There are in total 6 actions available where the user can select one in
 the selection box.
 The target is to be specified manually in a text entry field.
\layout Standard

Once clicking the button 
\begin_inset Quotes eld
\end_inset 

Add rule
\begin_inset Quotes erd
\end_inset 

, the specified action/target is added to the group 
\begin_inset Quotes eld
\end_inset 

Clientside userrules
\begin_inset Quotes erd
\end_inset 

.
\layout Standard

If a rule in this section is selected, the button 
\begin_inset Quotes eld
\end_inset 

Remove rule
\begin_inset Quotes erd
\end_inset 

 will delete it from the list.
 No serverside rule can be removed of course.
\layout Subsubsection

Example for User-defined Access Rule
\layout Standard

You are the security team of BigBank Corp.
 The management authorized you to scan the network, BUT you're not allowed
 to scan 172.20.142.2 under any circumstance, because it's a SWIFT server and
 if it goes down, so does the bank (and your company and legal responsability).
 So you add :
\layout Standard
\added_space_top smallskip \added_space_bottom smallskip 

\family typewriter 
deny 172.20.142.2
\layout Standard
\noindent 
as a user rule in the GUI, and you are now SURE that you'll never scan this
 IP - even if you later on ask nessusd to scan it.
 
\layout Subsubsection

Example for a Adminstrator-defined Access Rule
\layout Standard
\added_space_bottom smallskip 
By editing nessusd.rules (only the administrator for Nessus Server can do
 that), you make sure that nessusd will not be used to scan any system it
 should not scan.
 If your internal network is 10.0.0.0/8, you basically want to make sure that
 nobody will scan anything else (either by fat-fingering an IP or just by
 malice), so you edit 
\family typewriter 
nessusd.rules
\family default 
 and you add :
\layout Standard


\family typewriter 
allow 10.0.0.0/8
\layout Standard


\family typewriter 
allow 127.0.0.1
\layout Standard


\family typewriter 
default deny
\layout Subsection

Local Security Checks: Theory
\layout Subsubsection

What are "local" security checks?
\layout Standard

Starting with Nessus 2.1.0, it is possible to give Nessus SSH credentials
 to log into the remote Unix systems and determine which patchs need to
 be applied.
 What this really means is that if you give Nessus the proper SSH key, it
 will litterally log into the remote host, extract the list of installed
 software, and tell you which packages have an update ready for them.
\layout Standard

The real goal of this feature is to easily keep track of all the missing
 patches of a given system, without the potential hazards and false positives
 of remote security checks.
 It is really important to understand that enabling local security checks
 do not discover flaws such as unauthorized suid binaries, they simply determine
 which patches are missing from the remote operating system.
\layout Subsubsection

Which operating systems are supported at this time?
\layout Standard

At this time, Nessus is able to determine the missing patches of the following
 operating systems :
\layout Itemize

AIX 5.x
\layout Itemize

Debian
\layout Itemize

Fedora Core 1 and 2
\layout Itemize

FreeBSD 4.x, 5.x (including the port collection)
\layout Itemize

Gentoo Linux (all advisories from 2004)
\layout Itemize

Mac OS X (and Mac OS X Server)
\layout Itemize

Mandrake Linux (8.0 to 10.0)
\layout Itemize

RedHat Enterprise Linux (2.1 and 3.0)
\layout Itemize

Solaris (2.5.1, 2.6, 7, 8 and 9)
\layout Itemize

SuSE Linux (7.0 to 9.1)
\layout Itemize

Microsoft Windows NT, 2000, XP, 2003 
\layout Standard

We hope to support more systems in the future (HP-UX, Tru64, etc...).
 
\layout Subsubsection

Which Solaris patches are checked for?
\layout Standard

We have implemented checks for Solaris 2.5.1, 7, 8 and 9 (both on sparc and
 i386 architectures).
 We check for every patch listed by Sun in the "Patch containing security
 fixes" of their patch page.
\layout Subsubsection

Is it intended to support more systems?
\layout Standard

We do not intend to support every operating system which has ever surfaced
 on the face of earth.
 However, we intend to create 
\begin_inset Quotes eld
\end_inset 

working groups
\begin_inset Quotes erd
\end_inset 

 of people working on a given operating system.
 Basically, we are looking for people who would be responsible for producing
 the security checks relevant to the operating system they use (and love).
 If you are interested in taking part in such a group (or to even lead a
 given OS group), please contact the Nessus Development Team.
\layout Subsubsection

What are "local" security checks NOT?
\layout Standard

At this time, Nessus does not check the local security policy of the remote
 system, like Tiger does (ie: directories writeable by any users, wrong
 permissions on a sensitive configuration file, and so on...).
 Read about SLAD (Security Local Auditing Daemon) for extensive on-site
 testing of remote targets that porentially are compromised.
 SLAD can be accessed via respective NASL scripts.
\layout Subsubsection

Why do we need to perform local security checks, is not Nessus good enough
 to determine security issues?
\layout Standard

Nessus 2.0 is, at its heart, a network based scanner.
 This means that it will connect to the remote host and attempt to determine
 the flaws affecting every service on it.
 However, testing everything from the point of view of the network has its
 own shortcomings.
 In particular, a 100% network-based security scanner can not do the following
 :
\layout Itemize

Determine client-side flaws: There are more and more client-side vulnerabilities
 published every day, ranging from flaws in mail clients to XML libraries.
 It simply is not possible to check for those from the point of view of
 an active scanner.
 The only way to detect such flaws is to deploy a passive scanner (ie: NeVO)
 or to locally check that every host has been patched.
\layout Itemize

Determine local flaws: Obviously, the security level of local utilities
 can not be determined from the point of view of the network.
 By running local security checks, Nessus will tell you if a user logged
 into the remote host can use an overflow in a suid binary to gain root
 privileges.
\layout Itemize

Determine flaws in disabled services: If a host has a vulnerable service
 installed, but it's not running at the time of the scan, a vulnerability
 will be missed.
 Having an unpatched disabled service is a potential security hazard - if
 the service is ever enabled in the future, it might be exploited.
\layout Standard

So traditional network-based scanners have their inherent limitations, which
 can now be overcomed thanks to this new feature.
\layout Subsubsection

Will Nessus recognize individually compiled and installed packages?
\layout Standard

If you e.g.
 compiled your DNS server by hand instead of using the system's one: Will
 Nessus see it ? No!
\layout Standard

Nessus sticks to the patches provided by your OS vendor.
 However, note that it usually is a good administrative practice to stick
 to your vendor packages, as it makes the upgrade of your system much easier.
\layout Standard

In the future, Nessus might be able to detect if a running server is not
 of the same version as the one installed by RPM (or any other packaging
 system) and may improve its output this way.
\layout Subsubsection

Why care about local security if there is no local user?
\layout Standard

E.g.
 why should one care if the web server has local overflows in suid binaries
 but there's no local user on it, apart from oneself?
\layout Standard

At the time this feature starts to be discussed, many people would object
 that they don't really care about local security because their server simply
 is a web server with no local users, therefore nobody can exploit a local
 vulnerability.
 The answer is a simple security practice: 
\series bold 
containment
\series default 
.
 If your web server is vulnerable to a given flaw (be it a misconfiguration,
 a badly written PHP script, or an 0day in Apache), an attacker will be
 able to obtain a shell on your system.
 The question really is: do you want to make it easy for the attacker to
 gain super-user privileges and gain the full control of your system, or
 do you want to contain him to the privileges your web server is running
 with? (These privileges will prevent the attacker to modify your kernel,
 load a rogue kernel module, and generally will make it harder for him to
 cover his tracks).
 So 
\series bold 
local security really matters
\series default 
, since it's your last line of defense.
\layout Subsubsection

How can enabling local security checks improve my scanning experience?
\layout Standard

Depending on how you use them, local security checks can dramatically improve
 your scanning experience:
\layout Itemize

By reducing false positives: it is not always possible to remotely determine
 if a given service is vulnerable to a given flaw or not (sometimes the
 only way to check for it is to actually crash the service, which is not
 an option in a production network).
 Sometimes, vendors do not upgrade a faulty product to the newest version
 but backport the fix instead (see Red Hat's statement about this), which
 also makes life more difficult for network-based scanners .
\layout Itemize

By speeding up the checks: if all you are interested in is to determine
 if all the patches have been installed on your remote hosts, you may want
 to only enable local security checks and dramatically reduce the time it
 takes to scan your systems.
 It only takes 6 seconds to find all the local flaws of a remote system
 (over a VPN link) whereas it takes over one minute to scan the same system
 entirely with all the network checks.
\layout Itemize

By scanning more often: Every network-based security scanner create the
 risk of crashing devices/services on your network.
 This is not specific to Nessus, this really is a hard fact about security
 scanning in general.
 The reason is simple: a scanner attempts to connect to all the services
 on the remote host, and some services (and TCP/IP stacks) out there are
 so poorly written that connecting to them too quickly or not sending them
 the exact data they are waiting for may crash them.
 No matter how gentle the scanner is, there is always a risk of crashing
 a custom application, a loaded server which is low on memory, and so on.
 This is especially true for embedded devices, most of which being designed
 without any consideration for security.
 There are scanners vendors out there who are trying to claim that they
 have reached 
\begin_inset Quotes eld
\end_inset 

100% unintrusive scanning
\begin_inset Quotes erd
\end_inset 

, and this is simple not true.
 If a scanner interacts with a network service, there is always a risk for
 crashing it.
\newline 
As a result, many people only scan once a month or once a quarter, even
 though security issues appear every day!
\newline 
By only enabling local checks and disabling port scanners and every other
 plugins, Nessus Server will only connect to the SSH port of the remote
 hosts - no stress on the network, no bad surprises.
\layout Standard

So wether you administrate a small number of hosts or a huge number of systems,
 local security checks can definitely make your job much easier.
\layout Subsubsection

Does this feature slow down the scan?
\layout Standard

No.
 Nessus will minimize the number of SSH logins into the remote host, and
 will actually log in once, then load its knowledge base with various informatio
n found on the remote host.
 Please view the source code of the plugin ssh_get_info.nasl for more details
 about what is gathered.
\layout Subsubsection

What are the caveats of this new feature?
\layout Standard

At this time, the following caveats are known:
\layout Itemize

Only SSHv2 is supported.
 You can not log into the remote host using SSHv1.
\layout Itemize

You have to use SSH public key authentication.
 It's slightly harder to deploy than a password, but it's much more secure.
\layout Itemize

This documentation only deals with OpenSSH.
 
\layout Subsection

Local Security Checks: How to enable
\layout Comment

What to do with this text - we can probably not just copy the referenced
 document, so have a URL instead or write a new text?:
\layout Comment


\begin_inset Quotes eld
\end_inset 

As a reminder, if you are interested in Windows security checks please read
 this document instead.
\begin_inset Quotes erd
\end_inset 


\layout Subsubsection

The principle
\layout Standard

To enable local security checks, the idea is to:
\layout Itemize

Create a SSH private/public key pair for Nessus to use
\layout Itemize

Create a user account on every system for which you want to perform a local
 scan
\layout Itemize

Copy the SSH public key Nessus will use in the directory of the new user
\layout Itemize

Tell Nessus to use this SSH private and public keys and perform the scan
 
\layout Standard

As you can see this is pretty simple.
 Nessus can not use password authentication, otherwise it would be vulnerable
 to a man-in-the-middle attack when scanning the remote systems (we do not
 want to handle key management for the remote systems just yet).
\layout Standard

If you are not familiar with SSH public key authentication and understand
 what it does, you should consult the ssh documentation or corresponding
 publications.
\layout Subsubsection

Generating a SSH public key
\layout Standard
\added_space_bottom defskip 
To generate a SSH public key, use ssh-keygen and save the key in a safe
 place.
\layout Standard
\align left 

\family typewriter 
\size scriptsize 
$ ssh-keygen -t dsa
\newline 
Generating public/private dsa key pair.
 Enter file in which to save the key (/Users/renaud/.ssh/id_dsa):
\newline 
/home/renaud/Nessus/ssh_key
\newline 
Enter passphrase (empty for no passphrase):
\newline 
Enter same passphrase again:
\newline 
Your identification has been saved in /home/renaud/Nessus/ssh_key.
\newline 
Your public key has been saved in /home/renaud/Nessus/ssh_key.pub.
\newline 
The key fingerprint is: 06:4a:fd:76:ee:0f:d4:e6:4b:74:84:9a:99:e6:12:ea
 renaud@myth.local
\newline 

\layout Standard

As you can see in the example above, two files have been created:
\layout Itemize

/home/renaud/Nessus/ssh_key is the private SSH key.
 Do not transfer it on a system other than the one running your Nessus client.
\layout Itemize

/home/renaud/Nessus/ssh_key.pub is the public SSH key.
 You will copy this file on every system you want to scan with Nessus.
 
\layout Standard

When ssh-keygen asks you for a passphrase, you may want to enter return
 twice (ie: don't set any passphrase).
 It's safer to protect a key with a passphrase, however, given the way Nessus
 is implemented it will not buy you extra security, as the passphrase will
 have to circulate between your Nessus Client and the Nessus Server, and
 will be stored in clear text in your .nessusrc configuration file.
 If you feel safer, feel free to enter a passphrase.
\layout Subsubsection

Creating a user account and setting up the SSH key
\layout Standard
\added_space_bottom defskip \align left 
On every platform you want to test, you want to create a new user account
 dedicated to Nessus.
 We will call this user nessus in this document, but you can set his name
 to any value.
 Once you created an account for the user (using adduser or any utility
 that the system provides you with), make sure that he has no valid password
 set (ie: when editing the file with 'vipw' make sure that the password
 field only contains a star):
\layout Standard
\align left 

\family typewriter 
\size scriptsize 
# vipw
\newline 
(...) 
\newline 
nessus:*:502:502::0:0:Nessus Test Account:/home/nessus:/bin/bash 
\newline 
(...)
\family default 
\size default 

\newline 

\layout Standard
\added_space_bottom defskip 
Now that the user has been created, you simply need to copy the key to his
 home and set the correct permissions on the .ssh directory:
\layout Standard
\align left 

\family typewriter 
\size scriptsize 
# mkdir ~nessus/.ssh 
\newline 
# mv ssh_key.pub ~nessus/.ssh/authorized_keys 
\newline 
# chown -R nessus:nessus ~nessus/.ssh/ 
\newline 
# chmod 0600 ~nessus/.ssh/authorized_keys 
\newline 
# chmod 0700 ~nessus/.ssh/
\family default 
\size default 

\newline 

\layout Subsubsection

Setting up Nessus
\layout Standard
\added_space_bottom defskip 
First, make sure that you are running Nessus 2.1.0 or newer and that it has
 been compiled with SSL support.
 You can do that by typing nessusd -d:
\layout Standard
\align left 

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

\layout Standard

Then start the NessusClient, and go to the 
\begin_inset Quotes eld
\end_inset 

Credentials
\begin_inset Quotes erd
\end_inset 

 section and set the SSH user name and SSH keys properly:
\layout Comment

TODO: screenshot like on http://www.nessus.org/doc/nessus_ssh_local.html
\layout Standard

Make sure not to mix the public key (keyname.pub) and the private one.
 Make sure that the option 
\begin_inset Quotes eld
\end_inset 

enable dependencies
\begin_inset Quotes erd
\end_inset 

 at runtime (in the plugins) section is checked, and run a scan against
 the remote host.
 The Nessus report should now tell you that login in was successful, and
 should show you all the missing patches on the remote system:
\layout Comment

TODO: Report excerpt like on http://www.nessus.org/doc/nessus_ssh_local.html
\layout Standard

Repeat the operation for every server for which you want to do a local scan,
 and you are ready to go!
\layout Subsubsection

Acknowledgements
\layout Standard

The SSH local checks functionality is a courtesy of:
\layout Itemize

Nicolas Pouvesle who wrote a lightweight SSH client implementation in NASL
\layout Itemize

Tenable Network Security.
 Tenable wrote over 1200 plugins performing local security audits.
 
\layout Section

Optimizing and Fine Tuning
\layout Subsection

Knowledge Base
\layout Standard

Knowledge Base saving allows you to not disturb the users of your network
 by doing daily portscans of a /24 network and to not waste the result of
 other tests.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/mainwindow-kb-en.png
	scale 90

\end_inset 


\layout Standard

The Nessus Server as well as the Nessus Clients have a compile option to
 switch on Knowledge Base support.
 Usually that is the case but you may find servers or clients installations
 without this feature.
\layout Standard

In the NessusClient you find the configuration of the knowldege base on
 the page 
\begin_inset Quotes eld
\end_inset 

KB
\begin_inset Quotes erd
\end_inset 

 of the 
\begin_inset Quotes eld
\end_inset 

Options
\begin_inset Quotes erd
\end_inset 

 notebook (provided the respective client support the KB feature).
\layout Subsubsection

Introduction
\layout Standard

The knowledge base (KB) is the list of information gathered about a tested
 host.
 It contains the list of open ports, the operating system type of the host,
 and many more information.
 Its first purpose was to reduce the redundancy of the tests, so that a
 plugin A which finds a fact (for instance, a way to log into the remote
 FTP server) writes can share its result with the other plugins (for instance,
 a plugin which needs to log into the remote FTP server will look in the
 KB if there is a way to do so).
 After a test, the KB would be freed from memory, and would be rebuilt from
 scratch during the next test.
 The idea behind the saving of the knowledge base is to re-use it for another
 audit, to reduce the bandwidth consumption of a test.
 For instance, if you have not touched the configuration of your web server
 during the last 5 hours, it's very unlikely that a new port will be opened
 when you do a new port scan on it.
 So why waste your bandwidth and time re-doing a portscan when you could
 just re-use the result of the previous portscan you did against this host
 ? Saving the KB allows you to:
\layout Itemize

save bandwidth
\layout Itemize

save time 
\layout Itemize

test the hosts of your network for new vulnerabilities only 
\layout Standard

You can define a lifetime for the knowledge bases attached to the tested
 hosts.
 This lifetime can range between a few seconds to a hundred of years - you
 are free to configure it the way you want.
 The purpose of this section is to explain you how to enable and use this
 feature to increase your security by making more tests more often, thus
 having a day-to-day view of your network.
 
\layout Subsubsection

Using the KB saving
\layout Standard

If you want the knowledge bases to be saved on the Nessus Server side, you
 must enable the option 
\begin_inset Quotes eld
\end_inset 


\series bold 
Enable KB saving
\series default 

\begin_inset Quotes erd
\end_inset 

 in the client:
\layout Standard

This option enables all the knowledge base saving, and by enabling this
 checkbox, you know that all the information collected about the remote
 hosts will be saved on disk.
 If you enable this option only, then the data gathered from the hosts you
 are testing for will be saved on disk, and that's all.
 That is, nessusd will not use it when you test the same host again.
 If you want to take advantage of it for the rest of your tests, continue
 to read.
\layout Standard

Technically speaking, each knowledge base is saved on the remote host as
 a different file for each tested host.
 A database may be pluggable here in the future, but at this time, this
 is fine.
 The files are located in 
\begin_inset Quotes eld
\end_inset 

/usr/local/var/nessus/username/kbs/
\begin_inset Quotes erd
\end_inset 

 where username is the Nessus Server login name in use.
\layout Subsubsection

Reducing the hosts tested to (re)populate the knowledge bases
\layout Standard

When 
\begin_inset Quotes eld
\end_inset 


\series bold 
Enable KB saving
\series default 

\begin_inset Quotes erd
\end_inset 

 is set, then it is possible to reduce the set of tested hosts to populate
 the knowledge bases of the current user.
 You may want to just test the hosts that already have a knowledge base
 attached to, or at the opposite, you may want to only tests the hosts that
 have no, or an outdated, knowledge base, so that the set of knowledge bases
 is up-to-date and complete.
 That's where the three options 
\begin_inset Quotes eld
\end_inset 


\series bold 
Test all hosts
\series default 
", 
\begin_inset Quotes eld
\end_inset 


\series bold 
Only test hosts that have been tested in the past
\series default 
" and 
\begin_inset Quotes eld
\end_inset 


\series bold 
Only tests hosts that have never been tested in the past
\series default 
" are handy.
\layout Itemize

If 
\begin_inset Quotes eld
\end_inset 


\series bold 
Test all hosts
\series default 

\begin_inset Quotes erd
\end_inset 

 is set, then all the hosts present in the 
\begin_inset Quotes eld
\end_inset 

Target
\begin_inset Quotes erd
\end_inset 

 field of the target selection panel will be tested; that is, no filtering
 will be done, and everything will be tested as it used to be.
 
\layout Itemize

If you set the option 
\begin_inset Quotes eld
\end_inset 


\series bold 
Only test hosts that have been tested in the past
\series default 

\begin_inset Quotes erd
\end_inset 

, only the hosts to which an up-to-date knowledge base is attached will
 be tested.
 This allows you to make sure that, for instance, no port scan will be done
 against hosts that have never been tested in your selection, so you are
 sure that network noise will be low.
\layout Itemize

Last but not least, the option 
\begin_inset Quotes eld
\end_inset 


\series bold 
Only test hosts that have never been tested in the past
\begin_inset Quotes erd
\end_inset 


\series default 
 is set, then only the hosts that have no knowledge base, or an outdated
 one, will be tested, and will be given a fresh new KB.
 
\layout Standard

These three options allow you to do what you want :
\layout Itemize

test everything
\layout Itemize

make sure that no noise will be generated during this test
\layout Itemize

populate the set of knowledge bases 
\layout Subsubsection

Re-using the knowledge base between multiple tests
\layout Standard

Re-using a knowledge base saved in the past may be dangerous, suppose for
 instance that the host you have audited yesterday was broken into during
 the night, and that the attacker left a root shell open on a port that
 used to be closed.
 If you re-use the knowledge base, then you will miss this fact.
 On the other hand, on a well-secured network, you may want to re-use a
 previously saved KB to save time and test a restricted set of new security
 checks against the host.
\layout Standard

If you enable the option 
\begin_inset Quotes eld
\end_inset 


\series bold 
Reuse the knowledge bases about the hosts for the test
\series default 

\begin_inset Quotes erd
\end_inset 

, then the older knowledge base will be reloaded in memory, and Nessus Server
 will make an active use of it.
 You can control what Nessus Server will make of it using the four following
 options:
\layout Standard

...
\layout Standard

If 
\begin_inset Quotes eld
\end_inset 

Do not execute scanners that have already been executed
\begin_inset Quotes erd
\end_inset 

 is set, then scanners you used in an older test won't be used again.
 The same for the other three options.
 If you just want to execute the new checks you gathered using the command
 
\begin_inset Quotes eld
\end_inset 

nessus-update-plugins
\begin_inset Quotes erd
\end_inset 

, then it is suggested you enable all these options.
 If you just want to reduce the noise of your network and don't do any port
 scan, just enable the first option.
 And so on...
\layout Subsubsection

Defining the meaning of up-to-date
\layout Standard

Throughout this section, it is said that a KB can be declared as being up-to-dat
e or outdated.
 What is meant by this is what you want.
 Each time a KB is created, it is attributed a date tag.
 The option 
\begin_inset Quotes eld
\end_inset 


\series bold 
max age of a saved KB
\series default 

\begin_inset Quotes erd
\end_inset 

 defines, in seconds, the amount of time after which a KB is declared as
 being obsolete and will be regenerated from scratch.
\layout Standard

The default value is 864000 (10 days), but you are free to lower this to
 3600 (one hour), or less, or at the opposite, raise this value to whatever
 you want.
 
\the_end
