Provided by: openvas-server_2.0.3-4_amd64 bug


       openvasd - The server part of the OpenVAS Security Scanner


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


       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.


       -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" will make  openvasd
              only  listen  to  requests  going  to 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
    ,,,   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

       -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  default  openvasd  configuration  file,  /etc/openvas/openvasd.conf  contains   these

              Contains    the    location    of    the    plugins   folder.   This   is   usually
              /usr/lib/openvas/plugins, but you may change this.

              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

              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 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.

              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.

              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.

              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.

              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,  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:...

              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".

              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.

              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)

              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.

              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, 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).

              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.

              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.

              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.


       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'.


              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,  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).


       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  contains  the  system-wide  rules, which applies for every user. Its
       syntax has been defined in the previous section.  Example:

              reject !
              default reject

       This allows the user to test localhost,  and  all  the  hosts  on,  except
       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


       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:

              (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.

              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

              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


       openvas(1), openvas-adduser(8), openvas-rmuser(8), openvas-mkcert(8)


       The canonical places where you will find more information about the OpenVAS project are:

     ⟨⟩ (Official site)
     ⟨⟩ (Developers site)
     ⟨⟩ (Mailing lists)


       openvasd was written by Renaud Deraison <>