Checking Your Work with Scanners, Part II: Nessus

Take security evaluation and vulnerability reduction to a higher level with Nessus.
Nessus' Architecture

Nessus has two major parts: a server, which runs all scans, and a client, with which you control scans and view reports. This distributed architecture makes Nessus flexible and also allows you to avoid monopolizing your workstation's CPU cycles with scanning activities. It also allows you to mix and match platforms; you can use the UNIX variant of your choice as the server, with your choice of X, Java or MS-Windows clients. (Note, however, the Java client no longer appears to be in active development.)

nessusd listens for client connections on TCP port 3001 and also TCP 1241 (1241 was recently assigned to Nessus by the Internet Assigned Numbers Authority; 3001 will be phased out eventually). Client sessions are authenticated using an El Gamal-based public-key scheme and encrypted using a stream cipher whose session key is negotiated dynamically for each connection. In this regard, Nessus' cipher layer (implemented by Jordan Hrycaj using his libpeks library) behaves similarly to SSL.

Nessus' client component, nessus, can be configured to log in either transparently (i.e., with no password associated with your private key) or with a password that protects your private key, thereby preventing unauthorized users from connecting to the Nessus server from your workstation.

Once you've connected with a Nessus server, you're presented with a list of plugins (vulnerability tests) supported by the server and a number of other options. If you've compiled it into Nessus, you may also be given the option to run a detached scan that can continue running even if you close your client-session. A whole page of options pertaining to the creation and maintenance of a knowledge base can also be compiled in, allowing you to store scan data and use it to track your hosts' security from scan to scan (e.g., to run differential scans).

Note that these are both experimental features; they must be explicitly compiled into Nessus due to minor stability issues, but these will have been fixed (and the features fully integrated) by the time Nessus version 1.2 is released. I mention them here because the Detached Scan feature in particular is a good example of the value of Nessus' client-server architecture.

Once you've configured and begun a scan, Nessus invokes each appropriate module and plugin as specified and/or applicable, beginning with an Nmap scan. The results of one plugin test may affect how or even whether subsequent tests are run; Nessus is pretty intelligent that way. When the scan is finished, the results are sent back to the client. If the session-saving feature is enabled, the results may also be stored on the server.

Getting and Installing Nessus

Nessus, like most open-source packages, is available in both source-code and binary distributions. Red Hat 7.0 binaries of Nessus version 1.0.7a (the latest version as of this writing), however, are available only from redhat.aldil.org/rpm.html?id=73, courtesy of Matthias Saou (these binaries have not been compiled with the experimental features).

If you don't use Red Hat 7.0, if your distribution doesn't have its own Nessus packages (Debian 2.2 does) or if you want to use experimental features, you'll need to compile Nessus from source. Not to worry, if you first install a few prerequisites and follow Nessus' installation instructions, this compile should go smoothly. The Nessus FAQ (www.nessus.org/doc/faq.html) and Nessus Mailing List (list.nessus.org) provide ample hints to compile and install Nessus.

Nessus' prerequisites are: Nmap, the port scanner we discussed last month; gtk, the GIMP toolkit, including the packages gtk+, gtk+-devel, glib-devel and XFree86-devel; and the scripting environment m4, or libgmp (whose package is simply called gmp).

Once you've installed these, your distribution may have further prerequisites; I'm aware of two such situations. First, gmp-2.0 is needed for Red Hat 7.0 (which usually includes gmp-3.0 but not 2.0; you'll need to use RPM's --force option if you install 2.0 and 3.0 is already in place). This package is available from www.redhat.com/swr/i686/gmp-2.0.2-5.i686.html.

Second, to install or compile Nessus on SuSE Linux you must first install the packages bison, flex, gtkdev and glibdev. See www.nessus.org/doc/faq.html for more details.

After all prerequisites are in place you're ready to compile and/or install your Nessus packages. Compiling is easy: for each of the four packages simply 1) un-gzip and un-tar it; 2) cd into its directory and run ./configure; 3) make; and 4) make install. The packages should be compiled and installed in the following order: nessus-libraries, libnasl, nessus-core and nessus-plugins.

Before you run the configure script for nessus-core, consider whether you want to use the session-saving and/or knowledge-base features. Session saving allows both crash recovery (e.g., the resumption of a scan interrupted by an application or OS crash) and detached scans (see above) and is enabled by including the flag --enable-save-sessions when you run configure.

The knowledge-base feature allows you to store scan results in a database on the server, which in turn allows you to run differential scans. The configure flag to activate the knowledge base is --enable-save-kb.

Thus, if I want to compile Nessus to enable both session-saving and the knowledge base (and their corresponding features), before I compile nessus-core, I'll invoke configure this way:

./configure --enable-save-sessions --enable-save-kb

See http://www.nessus.org/documentation.html for detailed instructions on compiling and using these features (because they're experimental, that's the last thing I'll say about them in this article).

After all four packages are compiled and installed, make sure that the file /etc/ld.so.conf contains the line /usr/local/lib (if it doesn't, add it with the text editor of your choice). Then, run ldconfig to update ld's (the dynamic linker's) cache.

Finally, since one of the strengths of Nessus is the regularity with which the developers add new vulnerability scripts, it makes sense to start out with a complete vulnerability database. If you run the script nessus-update-plugins, all plugins created since the current version of Nessus was released will be automatically downloaded to your system using lynx. I recommend the usage nessus-update-plugins -v, since without the -v flag the script will not print the names of the plugins it's installing. After downloading, uncompressing and saving new scripts, nessus-update-plugins will reset nessusd so it sees the new plugins (assuming a nessus dæmon is active at that moment).

At present this script does not check these scripts against MD5 or other hashes; this mechanism can therefore be subverted in various ways. If that bothers you, you can always download the plugins manually from www.nessus.org/scripts.html, one at a time, but even then you won't know if anything's fishy unless you review each script (they go in /usr/local/lib/nessus/plugins) before the next time you run a scan.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

External nmap not really a pre requisite

Anonymous's picture

The subject syas it all.. U can still run nessus and use snmpwalk or the nmap plugins

Regards

Ashutosh

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix