The 'Nessus' Project was started in early 1998, and first released in April 1998. At this time, the most complete free security scanner was SATAN, which is clearly outdated, and you could see the emergence of several commercial ones, that were clearly too expensive.

The Nessus Security Scanner is not only another security auditing tool. It is a security auditing as I think it should be - never trust the version number, never trust that a given service is listening on the good port (do all the web servers on earth listen on port 80 ?).

The Nessus Security Scanner is free, open-sourced and wants to be easy to use.

Nobody funds the Nessus project. The authors give their free time to write their part. Jordan Hrycaj gives his free time to write the cipher layer. I give my free time to update the security tests (among other things). Users give their free time to report bugs or suggest enhancements.

No special reason. I needed a name when I started it. Mainly because the names my project and security scanner were too vague and too common.

You can contribute money, software or hardware to the project. In addition, you can also test new releases and contribute code. See http://www.nessus.org/ for more details.

Last change: 20011215

Thanks to: JL

All the compilation options are passed to the configure script of the nessus-libraries package. If you want to enable the cipher layer, then you should do:

cd nessus-libraries
./configure --enable-cipher

You need bison and flex to compile nessus-libraries, not yacc and lex. So, install bison and flex, then recompile nessus-libraries from scratch, and try again.

From scratch means you have to do at least a make distclean as just rerunning ./configure will not do.

Last change: 20020429

Thanks to: RD, HvdK

By default nessus-libraries installs a program in ${prefix}/bin (usually /usr/local/bin unless you specified something else). Make sure that this directory is in your path. Usually, a simple

PATH=$PATH:/usr/local/bin
export PATH

Then you just want a command-line client. Do ./configure --disable-gtk in nessus-core.

To compile Nessus under SuSE linux, you must first make sure that the following packages are installed:

• bison.rpm

• flex.rpm

• gtkdev.rpm

• glibdev.rpm

Note that recent SuSE version may use long names instead of the 8.3 notation.

A good description can be found on: http://www.sunhelpdesk.com/users/john/nessus.htm (It's written for Solaris 7 but definitly worth a look.)

You sure can do so. A sample script is included below. (It assumes you will use the development version and will update straight from the CVS server.)

#!/bin/sh
NESSUSROOT=/usr/local/src
NESSUSLIBOPS="--disable-cipher"
NESSUSCOREOPS="--disable-cipher \
    --enable-save-kb \
    --enable-save-sessions \
    --enable-gtk \
    --enable-syslog"
if [ -f /usr/bin/sudo ]; then
    SUDO="/usr/bin/sudo"
fi
cd $NESSUSROOT

# Get the Latest CVS code
# Use checkout instead of update on your first run!
export CVSROOT=":pserver:anonymous@cvs.nessus.org:/usr/local/cvs"
cvs login
# Password is "anon"!
cvs -z3 update nessus-libraries
cvs -z3 update libnasl
cvs -z3 update nessus-core
cvs -z3 update nessus-plugins

# Kill running versions!
$SUDO killall nessusd
$SUDO killall nessus

# CLEANUP old stuff!
cd $NESSUSROOT/nessus-libraries
uninstall-nessus
make distclean
cd $NESSUSROOT/libnasl
make distclean
cd $NESSUSROOT/nessus-core
make distclean
cd $NESSUSROOT/nessus-plugins
make distclean

# Now it's time to rock and roll.
cd $NESSUSROOT/nessus-libraries
./configure $NESSUSLIBOPS 2>&1|tee config.log
make 2>&1|tee make.log
$SUDO make install 2>&1|tee make-install.log
$SUDO ldconfig

cd $NESSUSROOT/libnasl
./configure 2>&1|tee config.log
make 2>&1|tee make.log
$SUDO make install 2>&1|tee make-install.log
$SUDO ldconfig

cd $NESSUSROOT/nessus-core
./configure $NESSUSCOREOPS 2>&1|tee config.log
make 2>&1|tee make.log
$SUDO make install 2>&1|tee make-install.log

cd $NESSUSROOT/nessus-plugins
./configure 2>&1|tee config.log
make 2>&1|tee make.log
make install 2>&1|tee make-install.log

# This is optional but usefull if you killed off everything
# or is it is your first run of the script.
#   Adjust as needed!
$SUDO nessus-mkrand
$SUDO nessus-mkcert
$SUDO nessus-adduser

Last change: 20020130

Thanks to: HvdK / PN

Nessus has its own user database. You must create an account for you, using nessus-adduser.

The general syntax is: nessus --output-type=html --config-file=nessusrc --batch-mode <host> <port> <login> <password> <target file> <results file>

• The valid output-type values are:

  • html (Renders to a single page)

  • html_pie (Renders to a directory full of html and some graphics) (This used to be called html_graph.)

  • latex

  • nbe (New native format as of version 1.1.9)

  • nsr (Which is the default!)

  • tex

  • xml

  
  
  

• host is the host running nessusd as IP address or hostname

• port Historicaly this was port 3001 but nowadays it is better to use the IANA assigned port of 1241

• login is you user you created earlier with nessus-adduser

• The password is only for Nessus v1.1.x and later Nessus v1.2.x and should not be used with Nessus v1.0.x!

• target file is the file containing the targets to be scanned. These must be in a nessus valid format.

• If you use --output-type=html_pie the option results file will in fact be a directory which will be filled with the spiffy html output files.

Last change: 20020418

Thanks to: RCH / RD / HvdK

Try following these steps:

Please note that you can only do this using a GTK GUI. The Windows GUI (nessuswx) uses it's own format.

Last change: 20011220

Thanks to: MH / HvdK

Ensure the server daemon is running. Type: ps -A | grep "nessusd"

If "nessusd" does not exist, start the nessus daemon with the command: nessusd -D (assuming that "nessusd" is in your PATH and you have enough priviliges to start "nessusd".)

If "nessusd" does exist, verify the port number in use. The comand netstat -na may be usefull in this. The traditional port is 3001. The IANA assigned port is 1241.

Make sure that versions of the client and the server are in sync. Running a v1.0.x client against a v1.1.x server will not work.

Last change: 20020418

Thanks to: RF / HvdK / ML

After installing new dynamic libraries you must make sure your system can find them. On a Linux system this means that the directory in which you installed the dynamic library must be in your /etc/ld.so.conf file and you must run ldconfig after that. (This requires root access!) On a Solaris system you must add the directory to your LD_LIBRARY_PATH variable. This must be done prior to your attempt to use a nessus binary. On Solaris 8 a better way seems to be: crle -u -l lib_directory (this updates the /var/ld/ld.config file).

Last change: 20011220

Thanks, to: HvdK / RvdB

You can invoke the nasl interpreter by typing: nasl -t IP script_name

For example, nasl -t 10.10.10.9 ISN.nasl would test the machine with IP address 10.0.10.9 with the ISN.nasl script for that specific vunerability.

Last change: 20011215

Thanks, to: JL

UDP scans are rather slow. Doing a NMAP scan of all 65536 UDP ports may take as long as 24 hours. If you are testing against a firewall doing TCP scans can take a while as well.

The progressbar for the NMAP scan is in fact fake. (Honest) It makes a step every now and again but it may be done in 5 minutes. The scan however is not done at all and will continue.

For those that do not believe me here is the relevant quote from the code itself. (taken from nessus-plugins/nmap_wrapper.c)

/*
 * That's a *FAKE* progress bar. Its purpose is just
 * to show users that nmap is still alive, not to
 * show the level of completion of a scan
 *
 * This is update "MacOS-style", meaning that
 * n% of the remaining chart is updated every
 * three seconds
 *
 * Thanks to Michel Arboi for this suggestion
 *
 * Q: "is not it lame to have a fake progress bar ?"
 * A: "Yes it is. However, nmap offers no convienent way to have a
 *     real progress bar, because of the retries, and users would
 *     send me panicked emails saying that 'nmap does not work' because
 *     the progress bar was not updated. If you can come up with
 *     a better solution, let me know"
 */

One suggestion is to run your NMAP scan first and feed the results into NESSUS. Like: nmap -oN output_file -sT -sU -O .... target1 target2 ...

Last change: 20020429

Thanks, to: MAr, HvdK, CS

You are using a newer version of nessus server (version 1.1.14, version 1.2 or later) with an outdated version of WinNessus client (version 1.0.9 or earlier).

Upgrade nessus client to the most recent NessusWX (version 1.3.x as of this writing). There is no recent WinNessus version.

Last change: 20020424

Thanks, to: RF, HvdK

Something was changed in the way the cipher layer works. Delete your ${prefix}share/nessus/nessus*keys* and your ~/.nessus.keys and try again.

Nessus uses a key for authentication. In this key is also the IP address of the client. So if you used user A to connnect from station X and then use user A to connect from station Y nessusd will get another key and sound the alarm. This may also occur if you generated a new user key.

The best thing to do is use different users for different stations. To remove the keys you must remove /usr/local/etc/nessusd.keys or at least the obsolete key from this file. (Unless you used RPM packages which will use /etc/nessus as path.)

In the more recent nessus clients you can go to "User" and select the host that does not accept you. Then delete that host and retry.

Last change: 20011213

Thanks to: HvdK / RD

Looks like you should delete your ~/.nessus.keys

Last change: 20011217

Thanks to: RD / MA

Try the following option ./configure --disable-cipher while working on the nessus-libraries.

Last change: 20011218

Thanks to: RD

Follow the simple steps below.

Last change: 20020429

Thanks to: VK,HvdK

You must first connect to the nessusd server. If you are connected to a nessusd server already, make sure you are using Nessus 0.98.4 or better, which fixes a nasty bug in the way the tabs were drawn.

Starting with Nessus 0.99.4, there is a way for the user to control how long the security checks should wait for their recv() calls. In older versions (pre-0.99.4) this timeout was set to 5 seconds, which is enough when you scan a network across a fast link, but not enough in the other cases, so the default has been set to 15 seconds. If you are using nessus accross a fast network, then change nessusd.conf to include a line like:

checks_read_timeout = 5

This is more needed under non-Linux systems.

It is most likely you didn't have lynx nor wget installed at the time you compiled nessus. The simple solution is to install one of them (or both ;-) and rebuild nessus.

Last change: 20011123

Thanks to: RD

For the following reasons:

• To be able to craft packets

• To be able to use the libpcap

• To be able to bind some sockets to some ports < 1024 (needed for some tests)

• To be able to start external programs (ie: nmap) as root, because they also require root privileges

The R tools (rlogin, rsh) and lpd expect that a session is started from a privliged port (< 1023). So a good audit needs to mimick this and start from a priviliged port as well or the test will be utterly useless.

You can in fact run nessusd as mortal user but you will miss out on issues like the ones listed above.

Last change: 20011213

Thanks to: RD / HvdK

To be honest: If you put any kind of firewall on the nessus server or between the nessus server and the host you are trying to test you will get a distorted result. You will not be able to rely on the results from your scan.

Putting a firewall on the nessus server to secure the nessus server is an incorrect approach. (Or at least an incomplete approach.) Harden the server instead.

If you have a firewall between the host you are about to test and the nessus server then you will get a result that is not similar to that of testing the host directly. This may be the desired result. If you want to be 100% sure you have hardened you host you should not rely on a firewall in front of it.

In general this issue is hotly debated and not everyone shares the same view on this.

A suggested firewall ruleset would be something that allows traffic like:

OUTBOUND ICMP except Time Exceeded, Timestamp Reply, Address 
    Mask Reply, and Destination unreachable (Echo Reply being 
    (ab)used by some backdoor protocols)
OUTBOUND TCP & UDP from any port to any port
INBOUND UDP from any port to any port
INBOUND ICMP Destination Unreachable, Echo Reply, Address Mask
    Reply, Timestamp Reply, Time Exceeded
INBOUND non-SYN TCP from any port to any port

Last change: 20020111

Thanks to: HvdK / RD / AB

There are no plans to do so. It is unlikely that Renaud Deraison or Michel Arboi will ever do so. But if you have an urge feel free to contribute in this matter.

There is a Windows GUI called NessusWX that you can find on http://www.securityprojects.org/nessuswx

Last change: 20020111

Thanks to: MA / HvdK

Nessus tries to find security problems by connecting to it's targets over IP and simulating various application protocols. When testing a problem in a web server for example, Nessus pretends to be a web browser (talking http). When testing a Windows fileserver, Nessus pretends to be a Windows client (talking SMB).

Most of these test are performed by (NASL) scripts. Each script is crafted to perform one specific task.

Last change: 20020111

Thanks to: RvdB / HvdK

This is a rather hard question to answer. There are some guesses to make but do not use it yourself.

Now assume we 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 significantly.

Last change: 20020418

Thanks to: HvdK

Your HTTP server is in fact being lame. It should send a 404 error code but did send a 200 code instead. So in fact you HTTP server is lying about the result page. This violates the relevant RFC's.

Here is list of some of the known violators:

Last change: 20020429

Thanks to: HvdK

In general: It is not the task of nessus (nor the nessus developers) to fix your server. (So please do not ask such questions on the mailinglist.)

However most scans include links to existing vunerability databases. These should have all the information you require.

If you can not find it contact you local reseller of the product in question and ask them for a fix. (They broke it, they fix it!)

Last change: 20020429

Thanks to: HvdK

More details for the various mailinglists itself are on: http://list.nessus.org/

If you need assistence make sure you are clear and included relevant error messages and such. Put a small description in the subject. Include a full description on the steps you did to create the problem. State you Operating System (OS), OS version and nessus version for the server. Do this as well for the client if they are not on the same machine. (This is common for all support requests but is most often ignored.)

Just be friendly and do NOT send any unsubscribe messages to the mailinglist itself. (That is like inviting a bunch of sharks to have you for dinner ;-)

Last change: 20020418

Thanks to: HvdK

Try these:

• http://www.certcc.or.kr/tools/Nessus.html (Korean CERT) has a nice picture that explains the nessus components.

• http://bengal.missouri.edu/~johnsong/audit/: "Using NMAP and NESSUS to Audit Large Networks" by Greg Johnson

It may be any of the following reasons:

• No one asked. (so it's not a FAQ ;-)

• No one answered. (So either no one knows or no one bothered to answer ;-)

• The given answer was incorrect or may be misleading. (I am still no guru but go a long way with these computer things and can usually tell wether or not this may happen.)

• I didn't like the answer. (The use of profane language and such will definitly be a reason to dislike the message and in such event it will not make it to the FAQ.)

But if you want to contribute to the FAQ feel free to send a clear question and answer to me. I just might put it into the next edition provided I have time for it. If you want to add info to an existing question you MUST quote the full question as numbers are irrelevant to me. The source document is not numbered at all! (It's added automagically during compilation!)

Please don't start sending me questions without answers. Goto to the mailinglist instead.

The preferred way is to make a copy of the SGML source; make the required changes and send in the diff (diff -uri) of the SGML source. If you can't do this please use plain text as I have a particular dislike of HTML in my email box.

FAQ entries should be send in a message exclusively to me and not to one of the mailinglists or contain a copy to one of them as they will be handled differently by my mail handling software and it's likely I may overlook them in such case.