Provided by: openvas-server_2.0.3-6_amd64 
NAME
openvasd - The server part of the OpenVAS Security Scanner
SYNOPSIS
openvasd [-v] [-h] [-c config-file] [-S ip[,ip2,...]] [-a address ] [-p port-number] [-D] [-d] [-R] [-P]
[-q]
DESCRIPTION
The OpenVAS Security Scanner is a security auditing tool made up of two parts: a server, and a client.
The server, openvasd is in charge of the attacks, while the client openvas interfaces with the user.
openvasd inspect the remote hosts and attempts to list all the vulnerabilities and common
misconfigurations that affects them.
OPTIONS
-c <config-file>, --config-file=<config-file>
Use the alternate configuration file instead of /etc/openvas/openvasd.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, "openvasd -a 192.168.1.1" will make openvasd only listen to requests
going to 192.168.1.1 This option is useful if you are running openvasd on a gateway and if you
don't want people on the outside to connect to your openvasd.
-S <ip[,ip2,...]>, --src-ip=<ip[,ip2,...]>
Force the source IP of the connections established by OpenVAS 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 : openvasd -S 192.168.1.1,192.168.1.2,192.168.1.3,192.168.1.4 will make openvasd establish
connections with a source IP of one among those listed above. For this setup to work, the host
running openvasd 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
9390 (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.
-P, --no-plugin-server
By default, openvasd starts a plugin server which is in charge of pre-loading every compiled
plugin in memory and distribute them among all the openvasd processes. As a result, loading a
plugin in memory becomes a very inexpensive operation, at the expense of wasting ~ 40 megs of
memory to pre-load them all in binary form. By specifying the -P option, it is possible to disable
this functionnality and save this amount of memory.
-h, --help
Show a summary of the commands
THE CONFIGURATION FILE
The default openvasd configuration file, /etc/openvas/openvasd.conf contains these options:
plugins_folder
Contains the location of the plugins folder. This is usually /usr/lib/openvas/plugins, but you may
change this.
logfile
path to the logfile. You can enter syslog if you want the nessusd messages to be logged via
syslogd You may also enter stderr if you want the openvasd logs to be written on stderr. Because
openvasd 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 processor(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 careful.
be_nice
If this option is set to 'yes', then each child forked by openvasd will nice(2) itself to a very
low priority. This may speed up your scan as the main openvasd process will be able to continue to
spew processes, and this garantees that openvasd does not deprives other important processes from
their resources.
log_whole_attack
If this option is set to 'yes', openvasd 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
openvasd fill your disk rather quickly.
log_plugins_name_at_load
If this option is set to 'yes', openvasd 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 messages, 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, openvasd 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 openvasd scan UDP ports 1 to 1024 and TCP
ports 1 to 65535 : "T:1-65535,U:1-1024".
optimize_test
By default, openvasd 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.
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 running openvasd 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 openvasd 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 openvasd to designate a service formaly. Ex: "139, Services/www", will
prevent openvasd 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, openvasd attempts to reproduce an exceptional condition to detemermine 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', openvasd 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 openvasd 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
OpenVAS 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 availaible, tracking the dependencies can quickly
become tiresome. If you set this option to 'yes', openvasd 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.
admin_user
The user listed in this option will upload his plugins into the global openvas 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 openvas-adduser(8) creates new openvasd users. Each openvasd user is attributed a "home", in
@OPENVAS_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, openvasd first checks that the directory
@OPENVAS_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 openvasd 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 openvas-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 adress 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. Example:
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 everyone to test his own box only, then you can do:
accept client_ip/32
default reject
NETWORK USAGE
Bear in mind that OpenVAS can be quite network intensive. Even if the OpenVAS 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 bandwith use should always be closely monitored, with current
server hardware, bandwith is usually the bottleneck in a OpenVAS 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. OpenVAS will not report a security hole that is present in a remote host)
Users might need to tune OpenVAS configuration if running the server in low bandwith conditions (low
being 'less bandwith 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 OpenVAS 0.99.4) The default value is set to 5 seconds, that can (should) be
increased if network bandwith is low in the openvas.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.
max_hosts
Number of hosts to test at the same time (this value is set by the OpenVAS 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 OpenVAS 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 OpenVAS 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 bandwith use.
It is not easy to give a bandwith estimate for a OpenVAS 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.
SEE ALSO
openvas(1), openvas-adduser(8), openvas-rmuser(8), openvas-mkcert(8)
MORE INFORMATION ABOUT THE OpenVAS PROJECT
The canonical places where you will find more information about the OpenVAS project are:
http://www.openvas.org/ (Official site)
http://cvs.openvas.org/ (Developers site)
http://www.openvas.org/doku.php?id=mailing_lists (Mailing lists)
AUTHORS
openvasd was written by Renaud Deraison <deraison@cvs.nessus.org>
The OpenVAS Project February 2004 OpenVASD(8)