openvassd(8) The Scanner of the Open Vulnerability Assessment System (OpenVAS)


openvassd [-v] [-h] [-c config-file] [-S ip[,ip2,...]] [-a address ] [-p port-number] [-D] [-R] [-P] [-q] [-f]


OpenVAS is a security auditing framework made up of several modules. The Scanner, openvassd is in charge of executing many security tests against many target hosts in a highly optimized way.

openvassd inspects the remote hosts and attempts to list all the vulnerabilities and common misconfigurations that affects them. Note that openvassd will run in daemon mode by default (unless you specify -f as an option).


Use the alternate configuration file instead of /etc/openvas/openvassd.conf

Tell the scanner to only listen to connections on the address <address> which is an IP, not a machine name. For instance, "openvassd -a" will make openvassd only listen to requests going to This option is useful if you are running openvassd on a gateway and if you don't want people on the outside to connect to your openvassd.

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 : openvassd -S,,, will make openvassd establish connections with a source IP of one among those listed above. For this setup to work, the host running openvassd should have multiple NICs with these IP addresses set.

Tell the scanner to listen on connection on the port <port-number> rather than listening on port 9391 (default).

-f, --foreground
Make the scanner stay in foreground (non-daemon mode)

-q, --quiet
Prevent the scanner from printing the loading status of the plugins at startup

-v, --version
Writes the version number and exits

-h, --help
Show a summary of the commands


The default openvassd configuration file, /etc/openvas/openvassd.conf contains these options:

Contains the location of the plugins folder. This is usually /var/lib/openvas/plugins, but you may change this.
path to the logfile. You can enter syslog if you want the openvassd messages to be logged via syslogd You may also enter stderr if you want the openvassd logs to be written on stderr. Because openvassd is a sensitive program, you should keep your logs.



If this option is set to 'yes', then each child forked by openvassd will nice(2) itself to a very low priority. This may speed up your scan as the main openvassd process will be able to continue to spew processes, and this guarantees that openvassd does not deprives other important processes from their resources.

If this option is set to 'yes', openvassd 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 openvassd fill your disk rather quickly.

If this option is set to 'yes', openvassd will log the name of each plugin being loaded at startup, or each time it receives the HUP signal.





Number of seconds that the security checks will wait for when doing a recv(). You should increase this value if you are running openvassd 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 openvassd 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 openvassd to designate a service formally. Ex: "139, Services/www", will prevent openvassd from making two connections at the same time on port 139 and on every port which hosts a web server.


Most of the time, openvassd 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', openvassd 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 openvassd nicer towards your network, however this may make you miss important vulnerabilities (as a vulnerability affecting a given service may also affect another one).

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 available, tracking the dependencies can quickly become tiresome. If you set this option to 'yes', openvassd will automatically enable the plugins that are depended on.


path to the rules database



The utility openvas-adduser(8) creates new openvassd users. Each openvassd user is attributed a "home", in /var/lib/openvas/users/<username>. This home contains the following directories :





When a user attempts to log in, openvassd first checks that the directory /var/lib/openvas/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 openvassd 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.



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




reject !
default reject


accept client_ip/32
default reject


Bear in mind that OpenVAS can be quite network intensive. Even if the OpenVAS developers have taken every effort 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 OpenVAS scan. It might not became too apparent 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 scanner 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 OpenVAS 0.99.4) The default value is set to 5 seconds, that can (should) be increased if network bandwidth is low in the openvassd.conf or openvasrc 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 OpenVAS GUI client or by .openvasrc) it can be as low as you want it to be (obviously 1 is the minimum)

Number of checks to test at the same time (this value is also set by the OpenVAS GUI client or by .openvasrc ) 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 scanner 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.


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 worth of traffic per scanned host. Reducing the amount of tested part and such will reduce the amount of data to be transfered significantly.


The canonical places where you will find more information about the OpenVAS project are: (Official site) (Developers site) (Bug Tracker)


openvassd was forked from nessusd in 2005. Nessusd was written by Renaud Deraison <[email protected]>. Since 2005 the OpenVAS development team improved and extended the tool.