Man page of NESSUSD
Section: User Manuals (8)
Updated: February 2004
Return to Main Contents
nessusd - The server part of the Nessus Security Scanner
nessusd [-v] [-h] [-c config-file] [-S ip[,ip2,...]] [-a address
] [-p port-number] [-D] [-d] [-R] [-P] [-q]
Nessus Security Scanner
is a security auditing tool made up of two parts: a server, and a client.
is in charge of the attacks, while the client
interfaces with the user.
inspect the remote hosts and attempts to list all the vulnerabilities and common
misconfigurations that affects them.
- -c <config-file>, --config-file=<config-file>
Use the alternate configuration file instead of
- -a <address>, --listen=<address>
Tell the server to only listen to connections on the address
which is an IP, not a machine name. For instance,
"nessusd -a 192.168.1.1"
only listen to requests going to
This option is useful if you are running nessusd on a gateway and if you don't
want people on the outside to connect to your
- -S <ip[,ip2,...]>, --src-ip=<ip[,ip2,...]>
Force the source IP of the connections established by Nessus to
. Note that you can not set arbitrary addresses here, as most Nessus
checks need to fully establish a connection to the remote host. This
option is only useful if you have a multi-homed machine with multiple
public IP addresses that you would like to use instead of the default
one. Example :
nessusd -S 192.168.1.1,192.168.1.2,192.168.1.3,192.168.1.4
establish connections with a source IP of one among those listed above.
For this setup to work, the host running nessusd should have multiple
NICs with these IP addresses set.
- -p <port-number>, --port=<port-number>
Tell the server to listen on connection on the port <port-number> rather
than listening on port 1241 (default).
- -D, --background
Make the server run in background (daemon mode)
- -q, --quiet
Prevent the server from printing the loading status of the plugins at startup
- -d, --dump-cfg
Make the server dumps its compilation options
- -v, --version
Writes the version number and exits
- -R, --recompile
Compiles every .nasl plugin as a binary file and exits.
- -h, --help
Show a summary of the commands
THE CONFIGURATION FILE
contains these options:
Contains the location of the plugins folder. This is usually
/var/lib/nessus/plugins, but you may change this.
path to the logfile.
if you want the nessusd logs to be written on stderr.
Because nessusd is a sensitive program, you should keep your logs.
is maximum number of hosts to test at the same time which should be
given to the client (which can override it). This value must be computed
given your bandwidth, the number of hosts you want to test, your amount
of memory and the horsepower of your processor(s).
is the number of plugins that will run against each host being tested. Note that the total number of process will be
so you need to find a balance between these two options. Note that launching too many plugins at the same time may disable the remote host, either temporarily (ie: inetd closes its ports) or definitely (the remote host crash because it is asked to do too many things at the same time), so be careful.
If this option is set to 'yes', then each child forked by nessusd will
nice(2) itself to a very low priority. This may speed up your scan as the main nessusd process will be able to continue to spew processes, and this guarantees that nessusd does not deprives other important processes from their resources.
If this option is set to 'yes', nessusd will store the name, pid, date and target of each plugin launched. This is helpful for monitoring and debugging purpose, however this option might make nessusd fill your disk rather quickly.
If this option is set to 'yes', nessusd will log the name of each plugin being loaded at startup, or each time it receives the HUP signal.
Some plugins might issue messages, most of the time to inform you that something went wrong. If you want to read these messages, set this value to a given file name. If you want to save space, set this option value to /dev/null
By default, nessusd looks for default CGIs in /cgi-bin and /scripts. You may
change these to something else to reflect the policy of your site. The syntax of this option is the same as the shell $PATH variable: path1:path2:...
This is the default range of ports that the scanner plugins will probe. The syntax of this option is flexible, it can be a single range ("1-1500"), several ports ("21,23,80"), several ranges of ports ("1-1500,32000-33000"). Note that you can specify UDP and TCP ports by prefixing each range by T or U. For instance, the following range will make nessusd scan UDP ports 1 to 1024 and TCP ports 1 to 65535 : "T:1-65535,U:1-1024".
By default, nessusd does not trust the remote host banners. It means that it will check a webserver claiming to be IIS for Apache flaws, and so on. This behavior might generate false positive and will slow the scan down somehow. If you are sure the banners of the remote host have not been tampered with, you can safely enable this option, which will force the plugins to perform their job only against the services they have been designed to check.
Number of seconds that the security checks will wait for when doing a recv(). You should increase this value if you are running nessusd across a slow network slink (testing a host via a dialup connection for instance)
Some services (in particular SMB) do not appreciate multiple connections at the same time coming from the same host. This option allows you to prevent nessusd to make two connections on the same given ports at the same time. The syntax of this option is "port1[, port2....]". Note that you can use the KB notation of nessusd to designate a service formally. Ex: "139, Services/www", will prevent nessusd from making two connections at the same time on port 139 and on every port which hosts a web server.
This is the maximum lifetime, in seconds of a plugin. It may happen that some plugins are slow because of the way they are written or the way the remote server behaves. This option allows you to make sure your scan is never caught in an endless loop because of a non-finishing plugin.
Most of the time, nessusd attempts to reproduce an exceptional condition to determine if the remote services are vulnerable to certain flaws. This includes the reproduction of buffer overflows or format strings, which may make the remote server crash. If you set this option to 'yes', nessusd will disable the plugins which have the potential to crash the remote services, and will at the same time make several checks rely on the banner of the service tested instead of its behavior towards a certain input. This reduces false positives and makes nessusd nicer towards your network, however this may make you miss important vulnerabilities (as a vulnerability affecting a given service may also affect another one).
Nessus plugins use the result of each other to execute their job. For instance, a plugin which logs into the remote SMB registry will need the results of the plugin which finds the SMB name of the remote host and the results of the plugin which attempts to log into the remote host. If you want to only select a subset of the plugins available, tracking the dependencies can quickly become tiresome. If you set this option to 'yes', nessusd will automatically enable the plugins that are depended on.
Set this option to 'yes' if you are testing your local network and each local host has a dynamic IP address (affected by DHCP or BOOTP), and all the tested hosts will be referred to by their MAC address.
Set this option to 'yes' if you want to let nessusd users upload their own plugins. Note that the plugins they will upload will end up in their nessusd home directory, so they won't be shared among users (except if the user who uploads the plugins is the one declared in the option 'admin_user'
The user listed in this option will upload his plugins into the global nessus plugins directory, and they will be shared by every other users
path to the rules database
The other options in this file can usually be redefined by the client.
The utility nessus-adduser(8) creates new nessusd users. Each nessusd user
is attributed a "home", in @NESSUS_STATEDIR@/users/<username>. This home contains the following directories :
This directory contains the authentification information for this user. It might contain the file 'dname' if the user is authenticating using a certificate, or 'hash' (or 'passwd') if the user is authenticating using a password. The file 'hash' contains a MD5 hash of the user password, as well as a random seed. The file 'password' should contain the password in clear text.
This directory also contains the file 'rules' which contains the rules which apply to this user.
The content of this directory can
be altered by the user in any way whatsoever
This directory contains the knowledge base (KB) of each host tested by this user, if the user has enable the option 'save_kb'.
This directory contains the list and contents of the sessions done by this user.
This directory contains the plugins this user uploaded.
When a user attempts to log in, nessusd first checks that the directory
@NESSUS_STATEDIR@/users/<username> exists, then hashes the password sent by the user with the random salt found in <username>/auth/hash, and compares it with the password hash stored in the same file. If the users authenticates using a certificate, then nessusd checks that the certificate has been signed by a recognized authority, and makes sure that the dname of the certificate shown by the user is the same as the one in <username>/dname.
To remove a given user, use the command nessus-rmuser(8).
THE RULE SET FORMAT
A rule has always the same format which is:
is one of
In addition to this, the IP address may be preceded by
an exclamation mark (!) which means: ``not''
There are three sources of rules:
the rules database, which applies to every users
the users database rules, which applies to one user
the users rules, defined by the user in the client
You must know that there is a priority in the rules: the user
can not extend its privileges, but can only lower them.
(that it, it can only restrict the set of hosts he is allowed
THE RULES DATABASE
The rules database contains the system-wide rules, which applies
for every user. Its syntax has been defined in the previous section.
This allows the user to test localhost, and all the hosts on
192.168.0.0/16, except 192.168.1.1/32.
The rules accept the special keyword
which is replaced, at connection time, by the IP of the user who logs
in. If you want everyone to test his own box only, then you can do:
Bear in mind that Nessus can be quite network intensive. Even if the
Nessus developers have taken every effor to avoid packet loss (including
transparently resending UDP packets, waiting for data to be received
in TCP connections, etc.) so bandwidth use should always be closely monitored,
with current server hardware, bandwidth is usually the bottleneck in
a Nessus scan. It might not became too aparent in the final reports,
scanners will still run, holes might be detected, but you will risk to
run into false negatives (i.e. Nessus will not report a security
hole that is present in a remote host)
Users might need to tune Nessus configuration if running the server in
low bandwidth conditions (low being 'less bandwidth that the one your
hardware system can produce) or otherwise will get erratic results. There are
several parameters that can be modified to reduce network load:
(Introduced in Nessus 0.99.4) The default value is set to 5 seconds, that can
(should) be increased if network bandwidth is low in the
nessus.conf or nessusrc configuration files. Notice that it is recommended
to increase this this value, if you are running a test outside your LAN
(i.e. to Internet hosts through an Internet connection), to over 10 seconds.
Number of hosts to test at the same time (this value is set by the Nessus
GUI client or by .nessusrc) it can be as low as you want it to be
(obviously 1 is the minimum)
Number of checkst to test at the same time (this value is also set by
the Nessus GUI client or by .nessusrc ) it can be as low as you want it
to be and it will also reduce network load and improve performance
(obviously 1 is the minimum)
Notice that the Nessus server will spawn max_hosts * max_checks processes.
Other options might be using the QoS features offered by your server
operating system or your network to improve the bandwidth use.
It is not easy to give a bandwidth estimate for a Nessus run, you will
probably need to make your own counts. However, assuming you test 65536
TCP ports. This will require at least a single packet per port that is
at least 40 bytes large. Add 14 bytes for the ethernet header and you
will send 65536 * (40 + 14) = 3670016 bytes. So for just probing all
TCP ports we may need a multitude of this as nmap will try to
resend the packets twice if no response is received.
A very rough estimate is that a full scan for UDP, TCP and RPC as well as
all NASL scripts may result in 8 to 32 MB wrth of traffic per scanned host.
Reducing the amount of tested part and such will reduce the amout of data
to be transfered significantly.
nessus(1), nessus-adduser(8), nessus-rmuser(8), nessus-mkcert(8)
MORE INFORMATION ABOUT THE NESSUS PROJECT
The canonical places where you will find more information
about the Nessus project are:
nessusd was written by Renaud Deraison <email@example.com>
- THE CONFIGURATION FILE
- USERS MANAGEMENT
- THE RULE SET FORMAT
- THE RULES DATABASE
- NETWORK USAGE
- SEE ALSO
- MORE INFORMATION ABOUT THE NESSUS PROJECT
This document was created by
using the manual pages.
Time: 04:17:50 GMT, September 24, 2010