users-manual.lyx

linux平台下的多系统漏洞扫描工具客户端

\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
 [e-mail]
\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 
\begi