Man Linux: Main Page and Category List


       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

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

              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

              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

              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

              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

              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

              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


       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

              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


              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

              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


       The rules database contains the system-wide rules,  which  applies  for
       every  user.  Its  syntax  has  been  defined  in the previous section.

              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

              (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 minimum)

              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

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