                      HOW TO TEST A NETWORK WITH NESSUS
                                  or
                 QUICK MANUAL EXPLAINING HOW TO USE NESSUS
                                



The test of a network with Nessus is quite straightforward. You
first have to launch the Nessus server (nessusd) which will be
in charge of the attacks, and then to connect to it via a Nessus
client. Once the user has connected to a nessusd with its client, 
he can configure the test.

1. The target selection

The test of a whole network starts with a 'primary target', which
is one host on the network (ie: www.nessus.org). The primary
target can also be a little set of hosts (ie: www.nessus.org,
www.nain.org, www.domain.com)

Several options, called the 'host expansion options' will allow 
Nessus to test more hosts. There are three options : the DNS, 
NFS and subnet expansion options. I think it is necessary to
explain what does each option do.

The DNS expansion performs a zone transfer request to the remote
nameserver which is in charge of the domain of the primary target
(here nessus.org) : it will download the list of all the hosts that are
in this subnet (we would have www.fr.nessus.org, list.nessus.org,
mail.nessus.org and some others).

The subnet expansion is the 'brute force attack'. It will test all
the hosts of the subnet. Here, www.nessus.org has the address 
199.181.107.23, so allowing the 'subnet expansion' option would
cause nessusd to test all the hosts, from 199.181.107.1 to
199.181.107.254. Another option allows the user to select the
subnet class (here we used a class C, but Nessus can test
class A and B networks).

The NFS expansion option tests the hosts that have a NFS relationship
with the other hosts. For instance, let's imagine that www.nessus.org
exports a filesystem to the host www.nain.org. This would mean
that nessusd would test both host. 

These options can be combined and are recursive, for instance if the
user checks the DNS and NFS options, we could imagine the following
story :
we test www.nessus.org
we test the whole nessus.org domain (DNS option)
www.nessus.org exports a filesystem to www.nain.org, so
the whole nain.org domain will be tested (NFS option)
if ever prof.nain.org exports a filesystem to www.nsa.gov, we will
test www.nsa.gov (NFS is recursive), and thus, we would test
the whole nsa.gov domain (as long as the administators allow the
zone transfer requests on their nameservers)

That's why I set up a filter system : the rules.


2. The Nessus rules

The Nessus rules are a set of filters which will avoid to the Nessus users
to not test what they don't want to. This is mostly a set commands which
will say things like "do not test the hosts called *.nain.org except 
*.fr.nain.org, and even though, I don't want to test ppp*.nain.org). 
This sentence would be written :
n:*.nessus.org;		# don't test the domain nessus.org
y:*.fr.nessus.org;      # ... except the hosts that belong to the
		        # subdomain fr.nessus.org...
N:ppp*.nain.org;	# ... and except the hosts called ppp*.nain.org

3. The scan options

Nessus offers several scan options that can be found in every security scanner :
will we ping the remote host to determine if it's alive before we attack it ?
how many childs should the server create ? What is the name of the remote
file we'll attempt to read (usually : /etc/passwd) ? What is the port range 
to scan ?

4. The plugins selection

The Nessus plugins are classified into several families ("FTP checks", "Sendmail
checks","gain root remotely", "denial of service" and so on...). 
The user can select or deselect a each plugin or the whole family. 
Each plugin has a tooltips associated to it, as well as a longer description 
which explains what it does, so that the user does not need to be an expert to 
make its plugins selection.


5. The test

Once every option has been set by the user, it is possible to start the scan of 
the remote networks. The test is somewhat noisy : most hosts will log that an attack
is being made. This is quite intentional : I hope this will prevent the script
kiddies from using Nessus against websites that don't belong to them.

6. The report

Once the test is finished, the Nessus client displays the report, which is
sorted by hosts. 
The Java and Windows client can save the report to the HTML format.
The Unix client saves the report in a proprietary format, but a perl converter to
HTML will be published soon.
