NESSUSD(8) User Manuals NESSUSD(8)NAMEnessusd - The server part of the Nessus Security Scanner
SYNOPSISnessusd [-v] [-h] [-c config-file] [-S ip[,ip2,...]] [-a address ] [-p
port-number] [-D] [-d] [-R] [-P] [-q]
DESCRIPTION
The Nessus Security Scanner is a security auditing tool made up of two
parts: a server, and a client. The server, nessusd is in charge of the
attacks, while the client nessus interfaces with the user.
nessusd inspect the remote hosts and attempts to list all the vulnera‐
bilities and common misconfigurations that affects them.
OPTIONS-c <config-file>, --config-file=<config-file>
Use the alternate configuration file instead of
/usr/local/etc/nessus/nessusd.conf
-a <address>, --listen=<address>
Tell the server to only listen to connections on the address
<address> which is an IP, not a machine name. For instance,
"nessusd -a 192.168.1.1" will make nessusd only listen to
requests going to 192.168.1.1 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 nessusd.
-S <ip[,ip2,...]>, --src-ip=<ip[,ip2,...]>
Force the source IP of the connections established by Nessus to
<ip> 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 will make nes‐
susd 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-num‐
ber> 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 plug‐
ins 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
The default nessusd configuration file, /usr/local/etc/nessus/nes‐
susd.conf contains these options:
plugins_folder
Contains the location of the plugins folder. This is usually
/usr/local/lib/nessus/plugins, but you may change this.
logfile
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.
max_hosts
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 pro‐
cessor(s).
max_checks
is the number of plugins that will run against each host being
tested. Note that the total number of process will be max_checks
x max_hosts 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 care‐
ful.
be_nice
If this option is set to 'yes', then each child forked by nes‐
susd will nice(2) itself to a very low priority. This may speed
up your scan as the main nessusd process will be able to con‐
tinue to spew processes, and this guarantees that nessusd does
not deprives other important processes from their resources.
log_whole_attack
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.
log_plugins_name_at_load
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.
dumpfile
Some plugins might issue messages, most of the time to inform
you that something went wrong. If you want to read these mes‐
sages, set this value to a given file name. If you want to save
space, set this option value to /dev/null
cgi_path
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:...
port_range
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".
optimize_test
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 pos‐
itive 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 per‐
form their job only against the services they have been designed
to check.
checks_read_timeout
Number of seconds that the security checks will wait for when
doing a recv(). You should increase this value if you are run‐
ning nessusd across a slow network slink (testing a host via a
dialup connection for instance)
non_simult_ports
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, Ser‐
vices/www", will prevent nessusd from making two connections at
the same time on port 139 and on every port which hosts a web
server.
plugins_timeout
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.
safe_checks
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 over‐
flows or format strings, which may make the remote server crash.
If you set this option to 'yes', nessusd will disable the plug‐
ins 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).
auto_enable_dependencies
Nessus plugins use the result of each other to execute their
job. For instance, a plugin which logs into the remote SMB reg‐
istry 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', nes‐
susd will automatically enable the plugins that are depended on.
use_mac_addr
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.
plugin_upload
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'
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
rules path to the rules database
The other options in this file can usually be redefined by the
client.
USERS MANAGEMENT
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 :
auth/ 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 not be altered by the user in
any way whatsoever
kbs/ This directory contains the knowledge base (KB) of each host
tested by this user, if the user has enable the option
'save_kb'.
sessions/
This directory contains the list and contents of the sessions
done by this user.
plugins/
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 cer‐
tificate, 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:
keyword IP/mask
Keyword is one of reject , accept or default
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 to
test).
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. Exam‐
ple:
accept 127.0.0.0/8
reject 192.168.1.1/32
reject !192.168.0.0/16
default reject
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 client_ip which is replaced, at
connection time, by the IP of the user who logs in. If you want every‐
one to test his own box only, then you can do:
accept client_ip/32
default reject
NETWORK USAGE
Bear in mind that Nessus can be quite network intensive. Even if the
Nessus developers have taken every effor to avoid packet loss (includ‐
ing 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:
checks_read_timeout
(Introduced in Nessus 0.99.4) The default value is set to 5 sec‐
onds, 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 run‐
ning a test outside your LAN (i.e. to Internet hosts through an
Internet connection), to over 10 seconds.
max_hosts
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)
max_checks
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, assum‐
ing you test 65536 TCP ports. This will require at least a sin‐
gle 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 signifi‐
cantly.
SEE ALSOnessus(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:
http://www.nessus.org/ ⟨⟩ (Official site)
http://cvs.nessus.org/ ⟨⟩ (Developers site)
http://list.nessus.org/ ⟨⟩ (Mailing lists)
AUTHORSnessusd was written by Renaud Deraison <deraison@cvs.nessus.org>
The Nessus Project February 2004 NESSUSD(8)
