Print-friendly Version

Nessus: An Automated Network-Based Security Scanner

Crackers constantly probe machines looking for both old and new vulnerabilities. The script kiddies download an automated tool from the Net and bang away at any network they can reach, breaking into machines just to claim bragging rights in the cracker community. Often these cracked machines are used as platforms to launch new attacks against other internal and external machines.

In order to avoid becoming a casualty of a casual cracker, savvy sysadmins audit their own machines before they're probed by hostile outsiders (or even hostile insiders). As such, an automated network-based security scanner is a vital part of a site's security measures. Dan Farmer and Wietse Venema's SATAN, released in 1995, was the first such well known tool, but technology has come a long way since then.

Today's slick tools still have the same automation and modularity that SATAN first boasted, but with much improved front-end interfaces. Today's better tools provide an easy point-and-click GUI, charts and graphs, and the ability to share data across sessions. This article takes a look at what I consider one of the best such GPL tools out there, Nessus.

Nessus follows a client server model. The server, nessusd, requires a UNIX-like machine. The various client components may run on a UNIX-like machine (including OS X), Microsoft Windows, Zarus, or via a web interface. The GTK-based X11 client software distributed with Nessus, also called nessus, allows configuration of the scanning run and then provides an interface to the results after the scan completes. The server running nessusd actually scans the networks and hosts looking for vulnerabilities.

Once the scan completes, the data appears on the client and can then be discarded or saved in a variety of formats. Some formats include Nessus's own internal format (which can be loaded back into the client at a later date), plain text for easy script parsing, and HTML with graphs and pie charts for web viewing and presentations.

Installation

Nessus installation occurs in one of three ways:

1. Install a precompiled package from Sunfreeware. This method requires several other packages, as detailed on the Sunfreeware page for Nessus.
2. Use the Nessus installer to fetch and compile the source automatically.
3. Retrieve, compile and install the source by hand.

I prefer building and packaging most of my own software, so I'll cover my experience building Nessus from scratch. To start, there were a few prerequisite software packages. The machine where Nessus is built requires a compiler, lexical parser and analyzer, and GNU m4. OpenSSL and the GTK were highly recommended. I started with a full install of Solaris 9 OS, which included the important GTK packages and GNU zip and tar:

system      SUNWGtkr             GTK - The GIMP Toolkit (Root)
system      SUNWGtku             GTK - The GIMP Toolkit (Usr)
system      SUNWgzip             The GNU Zip (gzip) compression utility
system      SUNWgtar             gtar - GNU tar

Next I grabbed Sunfreeware packages for gcc-3.3, m4-1.4, flex-2.5.4a, and bison-1.875 and installed them:

ncftpget 
ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/gcc-3.3-sol9-sparc-local.gz
gunzip gcc-3.3-sol9-sparc-local.gz
pkgadd -d gcc-3.3-sol9-sparc-local

ncftpget 
ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/m4-1.4-sol9-sparc-local.gzgunzip \
    m4-1.4-sol9-sparc-local.gz
pkgadd -d m4-1.4-sol9-sparc-local
ncftpget 
ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/flex-2.5.4a-sol9-sparc-local.gz
gunzip flex-2.5.4a-sol9-sparc-local.gz
pkgadd -d flex-2.5.4a-sol9-sparc-local

ncftpget 
ftp://ftp.sunfreeware.com/pub/freeware/sparc/9/bison-1.875-sol9-sparc-local.gz

gunzip bison-1.875-sol9-sparc-local.gz
pkgadd -d bison-1.875-sol9-sparc-local

I also downloaded and compiled OpenSSL from source. If installing OpenSSL on Solaris OS versions prior to 9, be sure to install the /dev/random patch first so OpenSSL uses a good source of entropy. Also, using -fPIC creates an installation that is optimized for the hardware OpenSSL is compiled on. You may wish to compile without this flag for better portability.

ncftpget http://www.openssl.org/source/openssl-0.9.7b.tar.gz
gtar zxf openssl-0.9.7b.tar.gz
cd openssl-0.9.7b
./config -fPIC
make
make install

With the prerequisites installed, I downloaded and installed each of the four components that compose the Nessus installation. I made certain that /usr/local/bin appeared in my path before any other directory that contained an m4 binary, otherwise the build of nessus-libraries failed making grammar.y. When installing, these components must be built in the correct order or they will fail:

1. nessus-libraries
   

   ncftpget 
   ftp://ftp.nessus.org/pub/nessus/nessus-2.0.7/src/nessus-libraries-2.0.7.tar.gz
   
   gtar zxf nessus-libraries-2.0.7.tar.gz
   cd nessus-libraries-2.0.7
   ./configure
   make
   make install
   

2. libnasl
   

   cd ..
   ncftpget ftp://ftp.nessus.org/pub/nessus/nessus-2.0.7/src/libnasl-2.0.7.tar.gz
   
   gtar zxf libnasl-2.0.7.tar.gz
   cd libnasl
   ./configure
   make
   make install
   

3. nessus-core
   

   cd..
   ncftpget 
   ftp://ftp.nessus.org/pub/nessus/nessus-2.0.7/src/nessus-core-2.0.7.tar.gz
   gtar zxf nessus-core-2.0.7.tar.gz
   cd nessus-core
   ./configure
   make
   make install
   

4. nessus-plugins
   

   cd ..
   ncftpget 
   ftp://ftp.nessus.org/pub/nessus/nessus-2.0.7/src/nessus-plugins-2.0.7.tar.gz
   
   gtar zxf nessus-plugins-2.0.7.tar.gz
   cd nessus-plugins
   ./configure
   make
   make install
   

Server Configuration

Nessus protects the communication between the client and the server by using SSL. So, after the installation completed, the next task was to create SSL certificates. Nessus comes with the nessus-mkcert script, which asks a few basic questions and then feeds that information and some defaults chosen by the author to OpenSSL to generate a Certificate Authority key and a server key, signed by the newly created CA key. If you're already your own CA, generating and signing the server key by hand may be preferable. Here's the output from the nessus-mkcert command:

/usr/local/var/nessus/CA created
/usr/local/com/nessus/CA created

-------------------------------------------------------------------------------
                        Creation of the Nessus SSL Certificate
-------------------------------------------------------------------------------

This script will now ask you the relevant information to create the SSL
certificate of Nessus. Note that this information will *NOT* be sent to
anybody (everything stays local), but anyone with the ability to connect to
your Nessus daemon will be able to retrieve this information.


CA certificate life time in days [1460]: 3650
Server certificate life time in days [365]: 3650
Your country (two letter code) [FR]: US
Your state or province name [none]: California
Your location (e.g. town) [Paris]: Palo Alto
Your organization [Nessus Users United]: My Organization


-------------------------------------------------------------------------------
                        Creation of the Nessus SSL Certificate
-------------------------------------------------------------------------------

Congratulations. Your server certificate was properly created.

/usr/local/etc/nessus/nessusd.conf updated

The following files were created :

. Certification authority :
   Certificate = /usr/local/com/nessus/CA/cacert.pem
   Private key = /usr/local/var/nessus/CA/cakey.pem

. Nessus Server :
    Certificate = /usr/local/com/nessus/CA/servercert.pem
    Private key = /usr/local/var/nessus/CA/serverkey.pem

Press [ENTER] to exit

Next, I added a user to the Nessus database. Nessus keeps its own user database so that multiple people can be authorized to use the same nessus server for disparate portions of the network. Individual users have associated rules that restrict what hosts and networks they may probe. The rules are of the form:

accept|deny IP/CIDR
default accept|deny

The program nessus-adduser adds a user and the user's associated rules to the proper nessusd configuration files and then sends a signal to nessusd to notify it of the changes. A corresponding nessus-rmuser script removes users from the Nessus database. Below, I added the user arr and rules that only allowed scanning of the class C sized address space of 192.168.1.0/24:

Add a new nessusd user
-----------------------


Login : arr
Authentication (pass/cert) [pass] : pass
Login password : testpass

User rules
-----------
nessusd has a rules system which allows you to restrict the hosts
that arr has the right to test. For instance, you may want
the user to be able to only scan his desktop or lab of machines.

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)

accept 192.168.1.0/24
default deny

Any final server configuration can be accomplished by editing /usr/local/etc/nessus/nessusd.conf. I left this file untouched since the defaults suited my environment. I started the daemon by running /usr/local/sbin/nessusd. (You may wish to add an init script if you want the daemon to start automatically on boot.) Then I moved on to the using client.

Client Configuration

For simplicity's sake, I used the nessus client located on the server instead of installing the client on another machine. I sshed in from my laptop, making certain that X11Forwarding was turned on in the sshd_config file on the server and that I was specifying -X to request an X session. From the shell window on the server, I ran the following, which brought up the initial window and backgrounded my session:

First, I need to log in to the Nessus server using the username and password I created above. Since I ran the Nessus client from the server itself, I specified localhost as the Nessusd Host, and specified the default port of 1241.

The next screen, which only appears during the first login, required me to set my level of SSL paranoia. Since I just created the junk CA and the server certificate, I chose the third option, to verify the server certificate and remember it for later use.

Now having logged into the Nessus server, I was presented with the plugin configuration tab. From this screen I chose which plugins to enable for this scan. This tab lists all of the classes of scanning plugins provided to the nessus server. Clicking on a category of plugins shows each individual plugin in the area below. Clicking on an actual plugin name will launch another window explaining what the plugin does, showing dependencies, and allowing the plugin timeout to be set.

Any plugins that could crash services or machines, denoted by the image of an exclamation point inside a yellow triangle, are disabled by default. These can be enabled individually or all plugins can be enabled by clicking on Enable all. Autoloading dependencies (running plugins depended upon by other plugins) is also disabled by default but can be enabled by clicking on Enable dependencies at runtime.

By clicking on the Prefs tab, I could set various options for scans based on ping, HTTP, news, SMB, TCP evasion, SMTP, inetd, SSL, SOCKS, FTP, POP, IMAP, SNMP, LDAP, and so on. The more information provided, the more intrusive the testing will be. For example, I may allow passworded ftp, but not want people with passwords to have write permission to upload files. If I provide a username and password in the FTP section, I may discover that I do actually have writable areas in my FTP tree.

The Scan options tab allows for customization of how nessus performs the port scanning portion of the run. Some options include setting the port range scanned, specifying how many hosts to scan at once, and detaching the client while scans are performed and then later emailing the result.

The address, range of addresses, or hostnames to scan are specified in the Target selection tab. Specify targets in the Target(s) field, or import a list of targets from a file by clicking on the Read file... button.

The format for the Target(s) field includes:

• Single IP: 192.168.1.1
• Range of IPs: 192.168.1.1-254
• Range of IPs spanning blocks: 192.168.1.1-192.168.5.2
• CIDR notation: 192.168.1.1/24
• FQDN: www.my.domain
• Bare hostname (must be resolvable by the Nessus server): www
• A comma separated list of any of the above

I specified a range of IPs from 192.168.1.2 to 192.168.1.16:

Tweaking the scanning rules happens under the User tab. The format here mirrors that of the nessus-adduser command. Fine tuning the rules at this point allows for specifying a broad range of addresses under the Target selection and then just denying select unwanted addresses. To enter a rule, type it into the Rules field and click on Add rule. The rules are added top down, so the first rule I entered will be the first rule read when the scans are run. To remove a rule, double click on it.

In this example, I wanted to skip testing 192.168.1.5, which happened to fall in the middle of my scanning block of addresses. I entered the following rules to accomplish this:

reject 192.168.1.5
default accept

The KB tab is for the experimental knowledge base saving feature. The knowledge base is the list of information gathered about a tested host. During a scan, the knowledge base allows plugins to share any discovered information about the host. The knowledge base is traditionally destroyed once the scan is over, however. The idea behind saving the knowledge base is to allow plugins across scans to share information. This saves time, bandwidth, and allows for the testing of new vulnerabilities only. Since it's experimental, knowledge base saving is disabled by default.

The Credits tab simply lists information about the authors and copyright program version information about the installed version of nessus.

The Scan and its Results

With my client configured to my liking, I clicked on Start the scan. Depending on the number of hosts Nessus scans and how beefy the server is, this may take some time. When the scan finished, it provided a report grouped into four sections, subnet, host, port, and severity. Each section provided finer notification granularity. The severity levels included notes (a light bulb icon), warnings (the exclamation point inside a triangle icon), and holes (an icon consisting of a red circle with a white bar through the center). The severity levels are fairly self explanatory, and each individual explanation provides quite a bit of detail.

In the following screen shot, I only polled one host (it happened to be the server running nessusd), so only one subnet and one host appear in my report. Nessus turned up several security notes, warnings, and even flagged a couple of holes.

The two ports it marked as having holes were the SMTP port and the submission port. Each port listed the same four vulnerabilities for sendmail and included a listing of URLs for sites (like CERT) that announced this bug and the workaround/fix back when it was first discovered. Nessus noted that it judged the sendmail version solely by the SMTP banner, and there was also a note specifically about Sun Microsystems, which informed me that Sun doesn't update the SMTP version number with patches, so this hole might be a false positive. This machine was recently patched (and I know that the sendmail patch had been applied by using showrev -p) so this was a false positive, just as Nessus warned.

There was also a warning about ssh. However, this machine runs the set of ssh packages shipped with the Solaris 9 OS, and not OpenSSH; as a result, the version numbering is different and, again, the warning didn't apply. The one valid warning that nessus found for this host is XDMCP. Nessus informed me that people can sniff the XDMCP session and capture keystrokes. Nessus listed the risk factor for XDMCP as medium and suggested turning it off as a workaround.

As is evident by scanning this one machine, each note, warning, and hole that Nessus flags could potentially be a false positive. It's best to read through the information Nessus provides and cross check with installed patches, modified banners, and other custom changes made to the system.

Plugins and Keeping Up With the Joneses

A vulnerability scanner is only as good as the scripts it runs. New vulnerabilities appear all the time, so keeping the scripts up to date requires diligence. Nessus installs a script called nessus-update-plugins, which downloads and installs the latest tar ball of scripts for the installed version of Nessus. In order to do this, the Nessus server must have tar, gzip, and one of lynx, links, wget, or curl. The nessus-update-plugins script also has options to display the names for the newly installed plugins, install just the named plugin, or display the source code of the named plugin.

While keeping up-to-date with the scripts on the Nessus web site is good practice, users can also create their own scripts. Documentation exists for writing a test in C, and about NASL, the Nessus Attack Scripting Language (PDF). Both allow users to create custom tests tailored specifically to their environment.

References

All of the Nessus documentation, source, scripts, and so on, can be found by following a link off of the main Nessus page. The documentation page also includes additional information that might prove useful for the advanced user.

• SATAN
• The main Nessus site
• Additional Nessus programs and clients
• The GNU GPL
• Sunfreeware
• OpenSSL
• The main CERT (Computer Emergency Response Team) site

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.