-- A Powerful, Free Remote Security Scanner
Alan P. Laudicina
In the July 1999 issue of Sys Admin magazine, I wrote an
article called "Exploits" (http://www.samag.com/documents/s=1176/sam9907f/sam9907f.htm)
in which I rated five security tools, including Nessus. It wasn't
the first time I had used Nessus, but it was the first time I had
taken a serious look at it. I was astonished by its functionality,
as well as the many options.
What Is Nessus?
Nessus is one of the best security scanning tools available. A
security scanner is software that will remotely audit a computer
network to determine whether any machines can be accessed by crackers,
but Nessus takes it to the next level. While other scanners simply
try to guess what is running on every port by matching the ports
with the IANA assigned port numbers, Nessus finds out what is actually
running, but it doesn't stop there. Nessus also checks whether
the process that's running is a security hazard. For example,
if you run qpopper on port 678, Nessus will see that port 678 is
open, check what's running on that port, and see whether it
is vulnerable to even the most recent exploits. If it is an old
version of qpopper that is vulnerable to a remote root shell exploit,
Nessus will also attempt to exploit the hole and drop to a root
The Nessus scanner comprises two parts: a daemon (nessusd),
which performs the attacks, and a client, which is a front end to
the server. The client controls the server, so you can audit your
whole network from your personal computer at home, with your server
at work doing the actual attacking. The client can run on just about
any operating system because there are GTK, Java, and Windows versions
available. However, the server can only be used in a UNIX environment
(which shouldn't be a problem for most Sys Admin readers).
The fact that Nessus has both client and server components means
you can have the client and server on different machines. One of
these machines could be the "attacking" machine, which
would perform the attacks on remote hosts. The other machine (the
"watching" machine) could monitor the problems found by
the attacking machine. Or, you could have one machine running both
the server and the client, and use this one machine to test many
other remote machines. (If Nessus didn't come in two parts,
it is unlikely that it would support Windows because it would require
a lot more porting. However, because Nessus has these features,
it is possible to run the server on a UNIX-based operating system,
with the client on a Windows machine.)
How Does Nessus Know What's Exploitable?
Every security test that Nessus performs is an external plug-in,
which makes it easy for administrators to add their own tests without
having to read any of the source code for nessusd. Most of these
security checks are written in the NASL (Nessus Attack Scripting
Language), which was designed for the purpose of writing Nessus
plug-ins very quickly and easily. Although most of the plug-ins
are written in the NASL, it is also possible to write them in the
C programming language.
Nessus is licensed under the GPL. As with a lot of other open
source projects (including the Linux kernel), when people see a
good project that needs help, they submit patches and add-ons. In
the case of Nessus, each vulnerability is handled by a specific
plug-in. As of December 5th, 2001, there were 800 different plug-ins
sorted into the following 18 families:
- CGI abuses
- Denial of Service
- Finger abuses
- Gain a shell remotely
- Gain root remotely
- Port scanners
- Remote file access
- SMTP problems
- Useless services
Each family has an assortment of plug-ins that do various things.
Under the "Gain root remotely" family, there are plug-ins
that will test whether Nessus can succeed in gaining a root shell
over the network. For example, if I wanted to run the "qpopper
buffer overflow" plug-in, Nessus would scan my network to see
whether qpopper was running on any of the machines. If Nessus found
qpopper running on port 678, it would try to use the buffer overflow
plug-in, and if successful, it would report that it was possible
to gain a remote root shell. Nessus also provides information on
how to fix the problem. With the "qpopper buffer overflow"
plug-in, if Nessus gained a root shell remotely, it would provide
instructions to "upgrade to version 2.5 or newer" and
would report a Risk Factor, which would be "High" in this
You may be thinking that since the scanner does all this, the
scan itself must be a long and tedious process, but that is not
the case. The Nessus Web site (http://www.nessus.org/) boasts
that Nessus is "very fast, reliable, and has a modular architecture
that allows you to fit it to your needs".
Installing Nessus from Source
As with pretty much everything you install onto your machine,
the first thing you will need to do is download the source. The
source for Nessus is located at: http://www.nessus.org/download.html.
Since we are running UNIX-based machines, we will want the POSIX
version. When you enter the page, you will see that there are a
few prerequisites, which are GTK, Nmap, and m4. I will assume that
you have these installed already, but I've provided the URLs
in the "Other Sources of Information" section of this
If you would rather have a command-line client, GTK is not required.
You can build the command-line client by substituting the ./configure
command I use in the article with ./configure --disable-gtk.
I suggest using a mirror site instead of using the ftp.nessus.org
site directly. The files that need to be downloaded are in the src/
directory of every mirror. There are four packages that need to
be installed in a specific order to get Nessus properly working:
Installing each of these packages is easy. Once you have downloaded
the gzipped tarballs, the following steps are to be taken as a normal
(non-root) account. Building each of these packages can take a while.
tar -xvf package.tar
where "package" is the name of a package (such as nessus-libraries-1.0.8.tar.gz).
Once you are in the directory created by untarring the package, you
can run the following commands (again as a non-root user):
Once you have done this, you will need to run the following command
as a root user:
When you do that for the four packages that I listed previously, you
are just a few minutes away from actually firing up nessusd as well
as the nessus client.
Getting the nessusd Server Ready
First, you must add a user so you can log in to the nessus server
and issue commands via the client. To do this, run the nessus-adduser
command. Here is some sample output:
Add a new nessusd user
Login : alanp
Authentication method (cipher/plaintext) [cipher] : cipher
Is "alanp" a local user on this machine [y|n]? y
Ok, treating user "alanp" as a local user.
nessusd has a rules system which allows you to restrict the hosts
that alanp has the right to test. For instance, you may want
him to be able to scan his own host only.
Please see the nessus-adduser(8) man page for the rules syntax
Enter the rules for this user, and hit ctrl-D once you are done :
(the user can have an empty rules set)
Login : alanp
Auth. method : cipher, local user connecting from 127.0.0.1
Is that ok ? (y/n) [y]
Once you make it beyond this point, nessus-adduser will create
primes, and then ask you for a pass phrase. You will use this password
when connecting to the server with your client. Before you can start
nessusd, you may want to edit /usr/local/etc/nessus/nessusd.conf
(where several options for nessusd are set). You can check the defines
and change things to your liking, but you must be careful not to mess
The configuration file for the nessus daemon is usually located
at /usr/local/etc/nessusd.conf but this file may be located
somewhere else if a custom installation is done. The file is made
of lines in the form of:
<keyword> = <value>
Lines can also be started with a comment (# character). Here are some
of the values:
plugins_folder -- Points to the directory where the
plug-ins reside. You don't want to change this unless you move
the plug-ins to a different directory.
logfile -- Path to the logfile. It is usually a good
idea to set this to syslog so all the messages that nessusd
has will go directly to syslog, where you can control it better.
max_threads -- The maximum number of hosts that the
nessusd should scan at once. This number can be given to the client,
which will override max_threads in the nessusd.conf.
users -- Path to the user database.
rules -- Path to the rules database.
language -- The language you would like nessusd to
use when it reports to the client. This can be set to either "English"
or "Francais" (French). More languages are promised in
the future by the Nessus developers.
checks_read_timeout -- The number of seconds to wait
during security checks when doing a recv(). You should increase
this if you are on a slow link such as a modem.
peks_keylen -- The minimum key length for public keys.
peks_keyfile -- The path to the private key database.
peks_usrkeys -- The path to the public user key and
peks_pwdfail -- The maximum number of login failures
to allow before a temporary password is destroyed.
Some items listed here can be overridden by the Nessus client.
Once you have finished editing the nessusd configuration file,
it is safe to start nessusd as root with the command:
(The -D flag runs nessusd in the background, which it doesn't
do by default.)
Starting Up the Nessus Client
You are now ready to start the front end to nessusd. You can do
this by running nessus as a normal user. Once started, it
will ask for the pass phrase you created when running nessus-adduser.
Input it, and you will get to the main client configuration screen.
Here you need to set the Nessusd Host, Port, Encryption,
and Login. All of these variables were set when you set up
nessusd, so you will want to use the same ones that you did then.
Once everything is ready, you can click "Log In" and you
will be logged into the nessusd server.
Preparing for Your First Scan
If you followed the previous step correctly, you will now be at
a list of plug-ins. If the machine you are scanning isn't production,
feel free to click the "Enable All" button. However, if
it is a production machine, click the "Enable all but dangerous
plug-ins" button. Next, you need to set up some preferences.
If you choose to use the "dangerous plug-ins", your network
will be the victim of Denial Of Service attacks that could bring
single machines, or a whole network, down. It is usually safe not
to use Denial of Service attacks on a network that is home to production
The contents of the "Prefs." tab depends on which plug-ins
you have enabled. For many of the preferences, you must input a
valid login and password for services on the machine(s) that you
will be scanning. You must also decide which scans you will be doing.
I find that leaving the default values for most of the scanning
techniques is fine for my use, but you may want to do something
else on your network. Either way, all the different types of scans
are listed and easily selected.
In the "Scan Options" tab, you must specify the port
numbers, threads, and the path to CGIs. I find that scanning the
entire machine (port 1-65535) is the best setting to use. Setting
the max threads to "8" is fine. You will also want to
set the path to the CGIs that are included in your Web server, as
this isn't always /cgi-bin. The default Port Scanner
options are fine for normal use; if you need more, the other available
options are visible.
In the "Target Selection" tab, you set the machines
that you want to be scanning. If you want to scan more than one
machine at once, you can use a comma to separate the different machines.
Starting Your First Scan
You can start your first scan by clicking on "Start the scan".
This will take you to a window with the name of the computer you're
scanning and a status bar showing the scan's progress. If there's
a problem and you need to restart, you can stop the scan by clicking
the "Stop" button. Once your scan is done you will be
brought to a window showing the problems with the machine that you
were scanning. A "security warning" is something to worry
about. Don't be worried about a "security note",
as that's just a note, and doesn't mean anything is wrong.
The Output of Your First Scan
When your first security test is over, a window will pop up with
a complete report on the hosts that you have scanned. I ran Nessus
on one of the machines on my LAN, and Figure 1 shows the report
that I received.
There are three main parts to the report:
SUMMARY -- The summary of the network you scanned will tell
you how many hosts were scanned, and how many warnings, notes, and
holes were found. In the example we can see that one host, 192.168.1.1,
was scanned. During this scan Nessus found three security warnings,
five security notes, and no security holes.
TESTED HOSTS -- This is list of the hosts that were scanned.
Our example report shows that the only host scanned was 192.168.1.1,
and the highest severity of a problem found was a "Security
DETAILS -- This provides all of the information that Nessus
collected from the host(s) scanned.
Security Notes are simply the information on what is running on
every open port. As shown in the example report, the five warnings
show us that ssh-1.99-openssh_2.9, BIND-8.2.4-REL, and Apache/1.3.20+PHP/4.0.6
are running. The other two security notes are a traceroute to the
scanned host, and information on the remote host's operating
system. Nessus guesses the remote host's operating system by
running QueSO on the hosts that are scanned.
Security Warnings are usually not very serious. Whenever you get
a security warning, you will always get a "Risk Factor"
and a Solution to fix the problem that was found. Sometimes these
warnings can be false alarms. In the sample report, there is a "Medium
Risk Factor" associated with BIND. The report tells us that
the remote name server allows DNS zone transfers to be performed.
In fact, the only reason we were able to do a zone transfer from
192.168.1.1 was because we are on a machine that does secondary
DNS for a domain hosted by 192.168.1.1. If you are scanning your
local network and see security warnings with your internal nameserver,
you can usually ignore them, but use discretion in doing so.
Although no security holes were found on 192.168.1.1, if one had
been found, Nessus would have followed a scenario similar to that
of a warning -- meaning it would provide a "Risk Factor"
and "Solution" that you could use to fix the problem.
What To Do If There Are Problems with Daemons That Are Running
If you received a serious security warning about something you
are running on your machine, you want to upgrade it as soon as possible.
If it is not something of great importance, you want to disable
it as soon as you can, and only bring it back up when it is upgraded.
If you are aware of a vulnerability on your machine, and you leave
it open, chances are a cracker will find it, too. And when a cracker
finds out that he can get into your box, he will do so. This can
lead to serious problems, such as your machine being used for malicious
attacks on other systems, or user passwords being cracked.
Ensuring that your computer is secure from intrusion is not a
thing to do once a week -- it is something you should do every
day. I run Nessus on my local network every two or three days. Just
to be safe, I also run a sniffer on my FreeBSD gateway machine.
This allows me to watch all the incoming and outgoing packets for
which my machines are responsible.
Alan P. Laudicina is a student at Assumption College School
in Windsor, Ontario, Canada. He is currently the Web master of http://www.UnixPower.org.
He started using Unices at the age of nine and is the founder and
president of the Windsor Unix Users Group. More information on the
Windsor Unix User Group can be found at http://www.wuug.org/.
Alan can be contacted via email at: firstname.lastname@example.org.