Checking Your Work with Scanners, Part II: Nessus
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.
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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
29 min 53 sec ago
- seo services in india
5 hours 1 min ago
- For KDE install kio-mtp
5 hours 2 min ago
- Evernote is much more...
7 hours 2 min ago
- Reply to comment | Linux Journal
15 hours 47 min ago
- Dynamic DNS
16 hours 21 min ago
- Reply to comment | Linux Journal
17 hours 20 min ago
- Reply to comment | Linux Journal
18 hours 10 min ago
- Not free anymore
22 hours 12 min ago
1 day 1 hour ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?