Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
OpenVASSD(8)			 User Manuals			  OpenVASSD(8)

       openvassd  -  The  Scanner  of the Open Vulnerability Assessment	System

       openvassd [-v] [-h]  [-c	config-file] [-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 vul-
       nerabilities and	common misconfigurations that affects them. Note  that
       openvassd  will run in daemon mode by default (unless you specify -f as
       an option).

       -c _config-file_, --config-file=_config-file_
	      Use  the	alternate  configuration  file	instead	 of   /usr/lo-

       -a _address_, --listen=_address_
	      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.

       -p _port-number_, --port=_port-number_
	      Tell the scanner to listen on connection on the port  <port-num-
	      ber> rather than listening on port 9391 (default).

	      Sets  the	GnuTLS priority	string for the listening socket	to ad-
	      just the supported cipher	suites.

	      Sets the path to a PEM file  containing  Diffie-Hellman  parame-
	      ters. Needed for key DHE-based key exchange algorithms that pro-
	      vide Perfect Forward Secrecy.  This file could be	generated  us-
	      ing  tools  like	"openssl dhparam" and "certtool	--generate-dh-

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

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

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

       The default openvassd configuration file,  /usr/local/etc/openvas/open-
       vassd.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	 open-
	      vassd  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

	      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-

	      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  op-
	      tions. 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	 open-
	      vassd will nice(2) itself	to a very low priority.	This may speed
	      up your scan as the main openvassd process will be able to  con-
	      tinue 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.

	      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

	      By default, openvassd 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	openvassd scan UDP ports 1 to 1024 and
	      TCP ports	1 to 65535 : "T:1-65535,U:1-1024".

	      By default, openvassd 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.

	      Number of	seconds	that the security checks will  wait  for  when
	      doing  a	recv().	You should increase this value if you are run-
	      ning 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 op-
	      tion  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,  Ser-
	      vices/www",  will	 prevent openvassd 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,	openvassd 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', 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 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 at-
	      tempts 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',	 open-
	      vassd  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.

	      Name of the network interface that will be used as the source of
	      connections established by OpenVAS. The scan won't  be  launched
	      if  the value isn't authorized according to (sys_)ifaces_allow /
	      (sys_)ifaces_deny	if present.

	      Comma-separated list of interfaces names that are	authorized  as
	      source_iface values.

	      Comma-separated list of interfaces names that are	not authorized
	      as source_iface values.

	      Like ifaces_allow. Can't be overridden by	the client.

	      Like ifaces_deny.	Can't be overridden by the client.

	      Comma-separated list of the only targets that are	authorized  to
	      be  scanned.  Supports the same syntax as	the list targets. Both
	      target hostnames and the	address	 to  which  they  resolve  are
	      checked. Hostnames in hosts_allow	list are not resolved however.

	      Comma-separated  list  of	 targets that are not authorized to be
	      scanned. Supports	the same syntax	as the list targets. Both tar-
	      get hostnames and	the address to which they resolve are checked.
	      Hostnames	in hosts_deny list are not resolved however.

	      Like hosts_allow.	Can't be overridden by the client.

	      Like hosts_deny. Can't be	overridden by the client.

	      The other	options	in this	file can usually be redefined  by  the

	      At   log	in  attempt, openvassd checks that the certificate has
	      been signed by a recognized authority.

       Bear in mind that OpenVAS can be	quite network intensive. Even  if  the
       OpenVAS	developers  have  taken	every effort to	avoid packet loss (in-
       cluding transparently resending UDP packets, waiting for	data to	be re-
       ceived  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  re-
       sults. There are	several	parameters that	can be modified	to reduce net-
       work 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.  No-
	      tice  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

	      It  is  not easy to give a bandwidth estimate for	a OpenVAS 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 worth of
	      traffic per scanned host.	 Reducing the amount  of  tested  part
	      and  such	 will reduce the amount	of data	to be transferred sig-


       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  Re-
       naud  Deraison <>. Since 2005 the	OpenVAS	devel-
       opment team improved and	extended the tool.

The OpenVAS Project		 January 2011			  OpenVASSD(8)


Want to link to this manual page? Use this URL:

home | help