NESSUSD(8)

NAME
nessusd - The server part of the Nessus Security Scanner

SYNOPSIS
nessusd [-D] [-c CFG-FILE] [-a BIND] [-p PORT]

nessusd [-v] [-h] [-d]

nessusd [-C] [-L] [-K KEY] [-U USER] [-P USER[,[PWD]]]

nessusd [-X <key-file>]

or, using long options

nessusd [--background] [--config-file=CFG-FILE] \
[--listen=BIND] [--port=PORT]

nessusd [--version] [--help] [--dump-cfg]

nessusd [--change-pass-phrase] [--list-keys] \
[--delete-key=KEY] \
[--list-user-pwd=USER] [--make-user=USER[,[PWD]]]

nessus [--export-pubkey=<key-file>"]"

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.

Basically, the nessus suite is made of two parts, a client and a server. While the server is described here, see the man page nessus(1) for a description of the client. Optionally, the dialogue between server and client will be encrypted by a cipher layer if you configured your nessus-libraries package (which is part of the nessus suite) as

./configure --enable-cipher ...

You are strongly encouraged to use the nessus suite with the cipher layer version, only.

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 freely be used for evil purposes.

QUICK TAKE OFF
When the superuser root starts the nessusd server for the first time, nessusd will do all setup automatically assuming some defaults. If compiled with the cipher layer, you need to assign a one time password for the first user as

nessusd --make-user=username,passwd

or, equivalently using short options

nessusd -P username,passwd

where there must be no space on either side of the username and passwd separating comma. You can dispatch that command, above while another nessusd is already running (but wait until the pivate key is initially generated.) To verify, that the entry has been stored, you may do a key data base lookup as

nessusd --list-keys

or, equivalently using short options

nessusd -L

Now, let some nessus application login (see nessus(1)) as user username and with password passwd. Doing another key data base lookup you will see that the user password has been replaced by a public (El Gamal) user key.

OPTIONS

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

-c <config-file>, --config-file=<config-file>
    Use the alternate configuration file instead of /usr/local/etc/nessusd.conf

-a <address>, --listen=<address>
    Tell the server to only listen to the IP address <address> for possible connections. This address is 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>, --port=<port>
    Tell the server to listen to the TCP port number <port> rather than listening to PCP port 1241 (default)

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

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

-d, --dump-cfg
    Make the server dumps its compilation options

KEY MANAGEMENT OPTIONS
The key management options can be used while another instance of nessusd is already running. Modifications on the user key data base will be honoured by the running instance. If nessusd was invoked with a key manangement option, it will not start up as deamon. These options are available only if nessusd is invoked as superuser root.

-C, --change-pass-phrase
    Let nessusd secure the private key by a personal pass phrase. Using this feature, a pass phrase is read from the command line (see getpass(1) for details upon the input device) which is consequently used to encrypt that key. Upon restart, nessusd will not come up until you have entered the correct pass phrase. Once, the pass phrase is lost you can only delete the private key (usually in /usr/local/etc/nessus/nessusd.private-keys.)

    In order to remove the pass phrase from a key, you need to give an empty pass phrase.

The user and host key data base entries can be addressed by host, or network specifications, or user names. A host, or network specification can be

a simple host name, or an IP address

a network written as network-address/netmask, where the network-address can be a network name or an IP address and the netmask may look like an IP address or a number indicating the leading bits, set (eg. 127.0.0.0/8 is the same as 127.0.0.0/255.0.0.0)

a list host or network names concatenated by plus letters '+' like.127.0.0.0/8+cvs.nessus.org.

A user key looks similar to an email address. It can be

a simple name

a name followed by a commercial at '@' and a host, or a network specification like
jordan@127.0.0.0/8+cvs.nessus.org.

Using the general form of a network specification which is a list of networks, a user key or password can be made valid for a particuar collection client netwoks, all at once.

-L, --list-keys
    List the entries in the user key data base.

-K <key>, --delete-key=<key>
    Delete the user key from user the data base. The <key> argument can be a host, or user entry that matches the network specs associated with this key or the whole key literally as listed with the -L, or --list-keys option.

    For instance jordan@127.0.0.0/8+cvs.nessus.org does not match a data base entry jordan@127.0.0.0/8+212.198.14.17 even if cvs.nessus.org were resolved as 212.198.14.17. On the other hand, jordan@localhost matches the data base entry jordan@127.0.0.0/8+cvs.nessus.org,

-X <key-file>, --export-pubkey=<key-file>
    Export the public server key into the argument file <key-file>. If the key tag exists, already in the file and the key is the same as the current one, nothing is done. If the key tag is found with a different key, an error is printed. Otherwise the key is appended to the file.

    If the argument <key-file> is a dash -, the current key is printed to stdout.

-U <user-name>, --list-user-pwd=<user-name>
    Print the plain text information of the user specification as stored in the date base. This is the number of login failures, the username and password, and the network access sepecification (if available.)

    The matching rules for the <user-name> argument are similar to the ones decribed with the -K, or --delete-keys option, above.

-P <user-pwd-mod>, --make-user=<user-pwd-mod>
    Add, delete or modify a user name with an assigned password as described, below. User passwords are used only for the initial communication between server and client. Instead of manually putting the client key in a data base, a temporary password is used to initiate the connection. Server and client must have agreed upon using the same initial password.

    Once, a client has logged in successfully, it will send a public key to to the server. At subsequent connection set up, client and server will use a challenge/response scheme for authentication. There will be no login password, anymore.

    By default, there can be at most 5 login failures before a user password is destroyed, automagically.

    A username is always part of the <user-pwd-mod> argument. Note that in the case that user exists already in the data base, the matching rules for the username against the data base are similar to the ones decribed with the -K, or --delete-keys option, above.

    -P username,passwd, --make-user=username,passwd
    Add or replace the password passwd for the user username.

    It may happen, that a a general network specs is replaced by a more restricted one when setting a new password due to the matching rules for the username.

    -P username,, --make-user=username,
    Delete the password entry for the user username. Note that the option argument ends with a comma.

    -P username, --make-user=username
    This option is somewhat similar to the -U, or --list-user-pwd option described, above. It lets nessusd print some plain text information of the password data base separated by spaces as

    <login-failures> <username> <password>

    The option argument does not end with a comma, here.

THE CONFIGURATION FILE
The default nessusd configuration file is /usr/local/etc/nessusd.conf. It is made of lines looking like

<keyword> = <value>

or of comment lines that start with a hash # character. There follows a description of the keywords:

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

logfile
    path to the logfile. You can enter syslog if you want the nessusd messages to be logged via syslogd(8) You may also enter stderr 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 link (testing a host via a dialup connection for instance)

peks_username
    This is the name of the nessusd server used to identify themself in the private key data base.

peks_keylen
    The minimum key length for public keys.

peks_keyfile
    The path of the private key data base.

peks_usrkeys
    The path of the publuc user key and password data base.

peks_pwdfail
    The maximal number of login failured befor a temporary password is destroyed.

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. There must be a special entry : the user whose name is '*'. It is used for your public-key authentificated users.

password
    is the password associated with this user. The password is in plain text so check that the users database is in mode 0600. If you want the user to log in via its public key, set this to nothing.

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 authentificates using his public key :
#
oof:
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), nessus-adduser(8),getpass(1),nmap(1)

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, as well as most of the attack modules.

Jordan Hrycaj <jordan@mjh.teddy-net.com> is the author of the 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 patch and bug reports. Thanks to them.