Nessus -- 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 shell.

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:

• Backdoors
• CGI abuses
• Denial of Service
• Finger abuses
• Firewalls
• FTP
• Gain a shell remotely
• Gain root remotely
• General
• Miscellaneous
• NIS
• Port scanners
• Remote file access
• RPC
• SMTP problems
• SNMP
• Useless services
• Windows

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 case.

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 article.

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:

• nessus-libraries
• libnasl
• nessus-core
• nessus-plugins

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.

gunzip package.tar.gz
tar -xvf package.tar
cd package

./configure
make

make install

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.

User rules
----------
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)
^D

Login             : alanp
Auth. method      : cipher, local user connecting from 127.0.0.1

Rules             : 

Is that ok ? (y/n) [y]

nessusd.conf

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>

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 password database.

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:

nessusd -D

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 machines.

Prefs.

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.

Scan Options

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.

Target Selection

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 Warning".

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.

Conclusion

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: [email protected].