Provided by: nessusd_2.2.6-0ubuntu2_i386 bug


       nessusd - The server part of the Nessus Security Scanner


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


       The Nessus Security Scanner is a security auditing tool made up of  two
       parts: a server, and a client.  The server, nessusd is in charge of the
       attacks, while the client nessus interfaces with the user.

       nessusd  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,
              "nessusd -a"  will  make  nessusd  only  listen  to
              requests  going  to This option is useful if you are
              running nessusd on a gateway and if you don’t want people on the
              outside to connect to your nessusd.

       -S <ip[,ip2,...]>, --src-ip=<ip[,ip2,...]>
              Force  the source IP of the connections established by Nessus 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  :  nessusd  -S
    ,,,    will     make
              nessusd  establish  connections  with  a  source IP of one among
              those listed above.  For this setup to work,  the  host  running
              nessusd 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 1241 (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, nessusd starts a plugin server which is in charge of
              pre-loading every compiled plugin in memory and distribute  them
              among  all  the nessusd 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   nessusd  configuration  file,  /etc/nessus/nessusd.conf
       contains these options:

              Contains the location of the plugins  folder.  This  is  usually
              /var/lib/nessus/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 nessusd logs to be written on stderr.
              Because nessusd is a sensitive program,  you  should  keep  your
              logs.  So  entering syslog is usually not a good idea and should
              be done only for debugging purposes

              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
              nessusd will nice(2) itself to a very  low  priority.  This  may
              speed  up  your scan as the main nessusd process will be able to
              continue to spew processes, and this garantees that nessusd does
              not deprives other important processes from their resources.

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

              If this option is set to ’yes’, nessusd 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,  nessusd  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 nessusd scan UDP ports 1 to 1024 and
              TCP ports 1 to 65535 : "T:1-65535,U:1-1024".

              By default, nessusd 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  nessusd 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 nessusd 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   nessusd   to   designate   a  service  formaly.  Ex:  "139,
              Services/www", will prevent nessusd 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, nessusd 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’, nessusd 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  nessusd  nicer
              towards  your  network, however this may make you miss important
              vulnerabilities (as a vulnerability affecting  a  given  service
              may also affect another one).

              Nessus  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’,
              nessusd 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.

              Set this option to ’yes’ if you want to let nessusd users upload
              their  own  plugins. Note that the plugins they will upload will
              end up in their nessusd home directory, so they won’t be  shared
              among  users  (except if the user who uploads the plugins is the
              one declared in the option ’admin_user’

              The user listed in this option will upload his plugins into  the
              global  nessus  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  nessus-adduser(8) creates new nessusd users. Each nessusd
       user is attributed  a  "home",  in  @NESSUS_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, nessusd first  checks  that  the
              directory @NESSUS_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  nessusd 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 nessus-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 Nessus can be quite network intensive. Even if the
       Nessus  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 Nessus 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. Nessus will not  report
       a security hole that is present in a remote host)

       Users  might need to tune Nessus 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  Nessus  0.99.4)  The  default value is set to 5
              seconds, that can (should) be increased if network  bandwith  is
              low  in  the nessus.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.

              The default value  is  set  to  15  threads,  reducing  that  in
              nessus.conf  or  nessusrc  configuration  files.   will eat less
              bandwith and also improve performance.

              Number of hosts to test at the same time (this value is  set  by
              the  Nessus  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 Nessus 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
              Nessus 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 Nessus 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


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


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

     (Official site)
     (Developers site)
     (Mailing lists)


       nessusd was written by Renaud Deraison <>