NESSUSD(8)

NAME
nessusd - The server part of the Nessus Security Scanner

SYNOPSIS
nessusd [ -v ] [ -h] [ -c config-file ] [ -a address ] [ -p port number ] [ -D ] [ -d ]

DESCRIPTION
The Nessus Security Scanner is a security auditing made up of two parts : a server, and a client. The server, nessusd is in charge of the attacks, while the client nessus(1) interfaces with the user. The attacks performed by nessusd are coded as external modules (or plugins if you want) written in different languages. Because nessusd is a security scanner, it is dangerous to let everyone use it. This man page describes how to configure nessusd properly, so that it can not be used for evil uses.

OPTIONS

-c config-file
    Use the alternate configuration file instead of @NESSUSD_CONFDIR@/nessusd.conf

-a <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 192.168.1.1" will make nessusd only listen to requests going to 192.168.1.1 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.

-p <port number>
    Tell the server to listen on connection on the port <port number> rather than listening on port 1241 (default).

-D  Make the server run in background (daemon mode)

-d  Make the server dumps its compilation options

-v  Writes the version number and exits

-h  Show a summary of the commands

THE CONFIGURATION FILE
The default nessusd configuration file, several informations :

plugins_folder
    Contains the location of the plugins folder. This is usually @NESSUSD_PLUGINS@, but you may change this.

logfile
    path to the logfile. You can enter if you want the nessusd messages to be logged via syslogd(8) You may also enter if you want the nessusd logs to be written on stdout. 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

max_threads
    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, and so on. The more threads you activate, the more likely you will loose packets during the test, and the more likely you will miss vulnerabilities. On the other hand, the more threads you put, the faster your test will go. I personnally tested 50 threads on a PII 450, with 128Mb of RAM, and the test was smooth and quick against a /24 network.

users
    path to the user database

rules
    path to the rules database

language
    Is the language you want nessusd to use when it sends its reports to the client. The currently available languages are "english" and "francais" (french).

checks_read_timeout
    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) The other options in this file can usually be redefined by the client.

THE USERS DATABASE
The user database contains the list of the users that are allowed to use nessusd. Why making a list of users, instead of allowing only one ? Well, with the rules file which will be defined later in this document, you can set up a central nessusd server in your company, and add users who will have the right to test only a part of your network. For instance, you may want the R&D folks to test their part of the network, while you will test the rest. You can even configure nessusd so that everyone can test it to test only one's computer. The user database has a very simple format which is : user:password [rules] Where :

user
    is the login name you want to add. This can be whatever you want.

password
    is the password associated with this user. The password is in plain text so check that the users database is in mode 0600.

rules
    The rules that apply to this specific user. A typical nessusd.users file would be :

# User foo, with password bar
foo:bar
deny 192.168.1.1/32
accept 192.168.0.0/16
default deny
#
# User oof :
#
oof:rab
deny 192.168.1.1/24
accept 192.168.0.0/16
default deny

THE RULE SET FORMAT
A rule has always the same format which is :
    keyword IP/mask Keyword is one of deny , 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
The rules database contains the system-wide rules, which applies for every user. Its syntax has been defined in the previous section. Example :
    accept 127.0.0.0/8
    deny 192.168.1.1/32
    deny !192.168.0.0/16
    default deny
This allows the user to test localhost, and all the hosts on 192.168.0.0/16, except 192.168.1.1/32.
The rules accept the special keyword 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 deny

SEE ALSO
nessus(1),nmap(1),nessus-adduser(8)

MORE INFORMATION ABOUT THE NESSUS PROJECT
The canonical places where you will find more information about the Nessus project are :
    http://www.nessus.org (Official site)
    http://cvs.nessus.org (Developers site)

AUTHORS
The Nessus Project was started and is being maintained by Renaud Deraison <deraison@cvs.nessus.org>. The nessus server is mainly Copyright (C) 1998-1999 Renaud Deraison. Jordan Hrycaj <jordan@mjh.teddy-net.com> is the author of the optional cipher layer between the server and the client. The cipher library (libpeks) is (C) 1998-1999 Jordan Hrycaj And several other people have been kind enough to send patches, bug reports and attack modules. Thanks to them.