Checking Your Work with Scanners, Part II: Nessus

Unless you're only going to use the Nessus server as its own client (i.e., run both nessusd and nessus on the same host), you'll need to perform additional installations of Nessus on each host you wish to use as a client. While the Nessus server (the host running nessusd) must be a UNIX host, clients can run on either UNIX or MS-Windows. Compiling and installing Nessus on UNIX client machines is no different than on servers (as described above).

Installing any of the Windows clients (WinNessus, NessusW and NessusWX) is a bit simpler, as all three are available in binary form. Personally, I prefer WinNessus of the three, since it so closely resembles the UNIX GUI (I'm lazy that way). All three Windows clients are available at www.nessus.org/win32.html.

Before we talk about proper use of the Nessus client, we'd better start our dæmon.

Okay, we're back at our Nessus server's console and ready to fire Nessus up for the first time. (Are you excited? For good reasons and not evil, I hope!) nessusd is different from many other dæmons in that it can be invoked either as a proper dæmon (i.e, running in the background) or with flags and parameters that reconfigure Nessus. Therefore, to actually start the dæmon in dæmon mode, we enter nessusd -D.

As we'd expect with a client/server application, we also need to create some Nessus user accounts on our server. These are independent of the server's local UNIX user accounts. Nessus accounts can be created two different ways. First, we can invoke nessusd with the -P flag immediately followed by a username and one-time password. This neither interferes with a running nessus dæmon nor starts a new one; it does, however, immediately update Nessus' user database and transparently restarts the dæmon.

For example, to add user “bobo” with a password of “scuz00DL”, we enter:

nessusd -P bobo,scuz00DL

The password is called a one-time password because by default, after bobo first logs in and gives this password, his public key will be registered with the Nessus server; subsequent logins will not require him to enter this password again (they'll be authenticated transparently using an SSL-like challenge/response transaction).

The second and more powerful way to create new user accounts on the server is to use the nessus-adduser command. This script actually does most of its magic by invoking nessusd, but it presents you with a convenient interface for managing users with more granularity than a simple nessusd -P. You are prompted not only for a username and one-time password, but also an IP address from which the user may connect and rules that restrict which hosts the user may scan with Nessus.

I leave it to you to read the nessus-adduser man page if you're interested in this level of user account management. Our remaining space here is better spent discussing how to build, run and interpret Nessus scans.

Before we leave the topic of authentication, though, I should mention the other kind of authentication Nessus uses: one local to each client session. When you start Nessus (the client, not the dæmon) for the first time, you are prompted for a passphrase. This passphrase protects a private key stored in the home directory of the UNIX account you're logged into when you start Nessus, and you'll be prompted for it every time. Then, when you connect to a Nessus server, your private key will be used in the transparent challenge/response transaction I described earlier; it actually authenticates you to the remote nessusd process.

If all this seems confusing, don't worry: just remember that the password you're prompted for each time you start Nessus has nothing to do with the password you use the first time you connect to a Nessus server.

Now the real fun begins! After Nessus has been installed and at least one user account set up, you're ready to scan. First, start a client session and enter your client-private-key's passphrase when prompted (by the way, you can change or delete this passphrase with the command nessus -C, which will prompt you for your current passphrase and what you'd like to change it to).

Next, enter the name or IP address of the Nessusd host (server) you wish to connect to, the port it's listening on, your preferred encryption method and your Nessus login/username (Figure 2). The defaults for Port and Encryption are usually fine.

Figure 2. User “bobo's” First Login to a Nessus Server

When you're ready to connect, click the Log in button. If this is the first time you've connected to the server using the specified login, you'll be prompted for your one-time password (next time, you won't be). And with that, you should be connected and ready to build a scan.

If you click the Plugins tab, you're presented with a list of all vulnerability tests available on the Nessus server, grouped by family (Figure 3). Click on a family's name (these are listed in the upper half of the window) to see a list of that family's plugins. Clicking on a family's check-box allows you to enable or disable all its plugins.

Figure 3. Plugins Screen (Windows Family Selected and Displayed)

If you don't know what a given plugin does, click its name and an information window will pop up. If you hover the mouse-pointer over a plugin's name, a summary caption will pop up that briefly states what the plugin does. Plugins with yellow triangles next to their check-boxes are dangerous: the particular tests they perform have the potential to interrupt or even crash services on the target (victim) host. Enable these with extreme care.

Don't be too worried about selecting all, or a large number of, plugins. Nessus is intelligent enough to skip, for example, Windows tests on non-Windows hosts. In general, Nessus is efficient in deciding what tests to run and in what circumstances.

The next screen to configure is Prefs (Figure 4). Contrary to what you might think, this screen contains not general, but plugin-specific, preferences, some of which are mandatory for the corresponding plugin to work properly. Be sure to scroll down the entire list and provide as much information as you can.

Figure 4. Preferences Screen

Take care with the Ping section (at the very top); more often than not, selecting either ping method (TCP or ICMP) can cause Nessus to mistakenly decide that hosts are down when in fact they are up. Nessus will not perform any tests on a host that doesn't reply to pings—when in doubt, don't ping. Warning: in the Nmap section, Linux users should select only tcp connect() and should deselect all other scan types, due to a bug in libpcap that affects the way Nessus performs port scans.

After Prefs comes Scan Options (Figure 5). Note that the Nessus installation in Figure 5 was compiled with the save-session feature, as evidenced by the Detached Scan and Continuous Scan options, which would otherwise be absent. As in the Prefs screen, you should deselect everything under Port scanner except Nmap tcp connect() scan due to the bug mentioned above.

Figure 5. Scan Options Screen

The “Optimize the test” option tells Nessus to avoid all apparently inapplicable tests, but this can result in false negatives, at least theoretically. Think about how much that worries you versus whether you want the scan to complete as quickly as possible. Speaking of speed, if you care about it you probably want to avoid using the “Do a reverse (DNS) lookup...” feature; it attempts to determine the hostnames for all scanned IP addresses.

And now it's time to specify our victims...oops, I mean targets. We specify these in the Target(s): field of the Target Selection screen (Figure 6). This can contain hostnames, IP addresses and network addresses in the format x.x.x.x/y (where x.x.x.x is the network number and y is the number of bits in the subnet mask, e.g., 192.168.1.0/24) in a comma-separated list.

Figure 6. Target Selection Screen

The “Perform a DNS zone transfer” option instructs Nessus to attempt to obtain all available DNS information on any domain names or subdomain names referred to in the Target(s): box. Note, most internet DNS servers are configured to deny zone-transfer requests from unknown hosts. The other options in this screen have to do with the experimental save-session feature I mentioned earlier—see www.nessus.org/documentation.html for more information on what the experimental features do and how to use them.

Finally, one last screen before we begin our scan: User (see Figure 7). (We're skipping KB, which only applies if you've compiled and wish to use the knowledge-base features.) In this screen, we can change our client passphrase (this has the same effect as nessus -C), and we can list exceptions (fine tunings, really) of the targets we specified in the Target Selection screen.

Figure 7. User Screen

These exceptions are called rules, and they follow a simple format: accept address, deny address, default accept or reject. In Figure 7, the rules listed mean don't scan 10.193.133.60, but scan everything else listed in the previous screen.

And now, the payoff. We click the Start the Scan button at the bottom of the screen, and we're off. The scan's length will vary, depending mainly on how many hosts you're scanning and how many tests you've enabled. The end result? A report such as that shown in Figure 1.

From the Report window, besides viewing the report and drilling down into its various details, you can save the report to a file. Supported report file formats include HTML, ASCII, LaTeX and, of course, a proprietary Nessus Report format, NSR (which you should use for reports you wish to view again within Nessus).

Read this report carefully; be sure to expand all + boxes and fix the things Nessus turns up. Nessus can find problems and can even suggest solutions, but it won't fix things for you. Also, Nessus won't necessarily find everything wrong with your system.

It's a fact of life with security scanners; they can only do so much, and not all plugins are equally effective at finding the things they're supposed to find. Even to the extent they are effective, Nessus obviously can't find vulnerabilities it doesn't have plugins for, so be sure to update your plugins regularly.