Vulnerability Scanners to the Rescue

As you can see, modern computer networks have multiple potential areas of insecurity. How do you protect all these avenues of attack? You might start to feel like a single guard trying to protect a giant castle with multiple windows, doors, and other ways to get in. You can't be everywhere at once. You could spend all day, every day, just checking for these security holes manually. Even if you tried to automate it with scripts, it would seem to take dozens of programs. Well, fortunately for you and your sanity, there are packages out there called vulnerability scanners that will automatically check all these areas and more.

Nessus is a truly amazing program. It is a great example of how well open source projects can work. It is robust, well documented, well maintained, and top of its class. Nessus has consistently been rated in the top of all vulnerability scanners, commercial or noncommercial. This is amazing when you consider its counterparts cost thousands of dollars and are created by large companies. It continues to impress and improve, and most importantly, to protect thousands of companies' networks. There are some design features that make Nessus unique and superior to other vulnerability scanners.

Depth of Tests

Nessus currently offers over 2,000 individual vulnerability tests that cover practically every area of potential weakness in systems. Very few scanners out there can compete with this level of testing, and new tests are being added daily by a worldwide network of developers. The speed of release of new tests for emerging vulnerabilities is usually measured in days if not hours. Its plug-in based architecture allows new tests to be added easily. Here is a list of all the categories of tests that Nessus runs.

You can turn off whole categories of tests if they don't apply or if you are worried they could be dangerous to your systems, or you can deactivate individual tests if you have a concern about a specific one. For example, you may prefer to disable the untested category, which contains tests that haven't been fully tested yet (caveat emptor). See Appendix E for a complete list of all the security checks. Keep in mind, though, that this list is only complete as of the date listed and will be changing constantly as new plug-ins are added.

Client-Server Architecture

Nessus uses a client-server architecture to run its security checks. The server runs the tests and the client configures and controls the sessions. The fact that the client and server can e separated offers some unique advantages. This means that you can have your scanning server outside your network, yet access it from inside your network via the client. This also allows other operating systems to be supported via different clients. There are currently UNIX and Windows clients available, with projects to create additional ones ongoing. There is also now a Web client interface available, which makes Nessus truly platform independent (at least on the client end).

Independence

Because Nessus is open source and the plug-ins are written by a diverse group of individuals in the security community, you don't have to worry about any conflicts of interest that may arise with commercial companies. For example, if the provider of a commercial vulnerability scanner has a large contract with a major OS provider, they may be less critical and slower to release tests for their products. An open source project like Nessus has no financial motivation not to develop and release tests right away. And because of its extendability, you can always write your own rather than wait for the official one.

Built-in Scripting Language

To supplement the plug-in architecture, Nessus has its own scripting language called Nessus Attack Scripting Language (NASL). This easy-to-learn utility language allows you to quickly and easily write your own custom security plug-ins without having to know C or all of the internal workings of the main program. (There is an example of writing a custom plug-in with NASL later in this chapter.)

Integration with Other Tools

Nessus can be used by itself or with several other open source security tools. Some of these are discussed in this chapter, and all of them are best-of-breed tools. You can use Nmap, the best port scanner in the world, for the port scanning part of the job, rather than the built-in one. The Nessus port scanner is faster and a little more efficient with memory, but Nmap allows for a lot more options and settings as you learned in Chapter 4. Almost all of the Nmap settings are configurable from within the Nessus client. Nessus also works with Nikto and Whisker, tools that run more complex tests on Web servers; CGI programs; and Hydra, a tool for running brute-force password attacks against common services. The functionality of these tools is written right into Nessus, so you can make configuration changes from a single interface.

Smart Testing

Nessus can be set up so that it doesn't automatically run all of the vulnerability tests on every host. Based on the results of a port's scan or other input such as past vulnerability tests, Nessus will run only tests appropriate to that machine. So if the server is not running a Web server, it won't run Web server-related tests. Nessus is also smart in that it doesn't automatically assume that Web servers will run on port 80, but rather checks all the possible ports for signs of a Web server. Nessus will even find multiple instances of services running on different ports. This is especially important if you are inadvertently running a Web server or other public service on an unusual port.

Knowledge Base

Nessus can save all scan results in a database called the Knowledge Base. This allows it to use the results of past scans to intelligently figure out what tests to run. You can use this to avoid doing a port scan every time you run Nessus, because it will remember what ports it found open last time on each host and test only those. It can also remember what hosts it saw last time and test only new hosts. I don't recommend you do this every time, because you may miss new ports that open up on machines or new vulnerabilities that show up on previously scanned boxes. However, it can allow you to run scans more often with less bandwidth and processor power as long as you do a complete scan on a regular basis.

Multiple Report Formats

Nessus has some of the best reporting capabilities in the open source field. Although it's not perfect, it can output your scan data in just about any format. Basic HTML and HTML with pie charts and graphs are two of the more popular formats. These reports include summary data and are suitable for posting to an internal Web site with little or no editing. Other report formats supported include XML, LaTeX, and good old plain text. The Windows client offers additional report formats. There are additional tools available, discussed in the coming chapters, that allow you to do further manipulation of the data.

Robust Support Network

Nessus has an extensive support network for getting help, both on basic installation and use as well as more complex programming and customization. There are no fewer than five Nessus mailing lists, each dedicated to a different area. Subscribers to the lists will notice that Renaud himself frequently answers many of the questions. Try getting this kind of support from a commercial company! There is an archive of all the past posts so you can check to see if your question has ever been answered. The following are the main Nessus mailing lists.

To subscribe to any of the above lists, send an e-mail to majordomo@list.nessus.org with the following text in the body of the e-mail:

Replace listname with the name of the list you want to subscribe to. To unsubscribe, do the same but write Unsubscribe listname in the body.

Nessus has quite a bit of documentation on its Web site, including detailed instructions on installation, basic operation, and tutorials on how to write your own security checks in NASL. To my knowledge, no one has yet attempted to completely cover all the features and settings on the Nessus client in a single document. This section tries to do just that.

Nessus provides you with a quick and easy way to test your network and systems for almost every kind of vulnerability, so let's install it.

Installing Nessus for Linux Systems

There are two prerequisites you must have before installing Nessus, and two others that are nice to have installed beforehand to take full advantage of the add-on capabilities.

The two prerequisites are the Gimp Tool Kit (GTK) and libpcap. If you installed Nmap in Chapter 4, you should already have these programs installed. If not, you can download GTK from:
```
ftp://ftp.gimp.org/pub/gtk/v1.2
```
and libpcap from:
```
www.tcpdump.org
```
The two programs that are optional but recommended are OpenSSL and Nmap. Nessus can use Nmap as its port scanner and OpenSSL for secure communications between the server and client.

There are three ways to install Nessus on UNIX systems, ranging from very simple to slightly more complicated. This is one case where I recommend the more extensive install process in order to have more control over your installation.

The easiest way to install Nessus is to run the auto-installer script remotely. You can do this by typing:

This initiates the installation script and loads the program on your computer. However, I don't really recommend doing this as it could open your computer up to an attack if that URL was ever compromised. Follow these steps for a safer way to do it.

Download the auto-install script manually from install.nessus.org and run it with the following command:
```
sh nessus-installer.sh
```
If the auto-install script doesn't work properly for you, you must compile it manually.

NOTE: I recommend that you follow all these steps even if the auto-install "script" (this is a bit of a misnomer since the file actually contains the whole program and all of its elements) seems to work, because with a complex program like Nessus it is sometimes hard to tell what is being done and where it is bombing out if things go wrong with the script. At least when you do the process manually you have a better idea of what happens during the install process.
To install Nessus manually, you must first get the following four Nessus files, either from the CD-ROM or from the Nessus Web site, and install them in this order. If you do them out of order, Nessus won't work properly.
- Nessus-libraries: These are the core libraries needed for Nessus to run.
- Libnasl: This is the module for NASL, the built-in scripting language.
- Nessus-core: This is the main Nessus program.
- Nessus-plug-ins: This module contains all the plug-ins that do the security checks. To make sure you have all the latest plug-ins, you should run the nessus-update-plugins script after installation to grab any new ones.
Change into the nessus-libraries directory (using the cd command), then type the standard compile sequence of:
```
./configure

make

make install
```
There may be special instructions at the end of each compilation process. For example, nessus-libraries will want to you add /usr/local/lib to a file called ld.so.conf in /etc and then type ldconfig. This revises your libraries' directories so your operating system can find where your special Nessus directories are. Make sure you follow these instructions before going to the next step.
Do the same for libnasl. At the end of compilation, it will want you to make sure that /usr/local/sbin is in your PATH directory. This is the statement that contains a path to look for executables every time a command is typed. The install program should do it automatically for you, but check this by typing:
```
echo $PATH
```
This prints your PATH statement to the screen. If it doesn't have /usr/local/sbin and /usr/local/bin in there, you can add it by editing the bash.rc file in /etc (the correct path for Mandrake Linux using the bash shell). Other distribution locations may vary slightly.
Repeat this process for the other two modules.

When you are done, you will have installed Nessus. However, you will still need to do a few things to set it up before you can use it.

Setting Up Nessus

The first thing you need do to get Nessus ready to run is create a certificate that Nessus will use for SSL communications.

Type:
```
nessus-mkcert
```
This runs a utility that creates a secure certificate for your installation. You can also use third-party certificates signed by a certificate authority like VeriSign with Nessus.

If you get "file not found" error, make sure both /usr/local/bin and /usr/local/sbin are in your PATH statement (as described in the installation procedure).

Answer the questions as they come up. You will want to register the certificate to your organization. If you are not sure what values to put in, accept the defaults provided.
Next, you need to create some user accounts so that you can log into Nessus. Because of the client-server architecture, you have to log into the server with the client before running any scans. Nessus can have any number of users with rules for each user, which you designate in this setup phase. If you are going to be the only person using Nessus, then you just need to set up one user with no rules, though you can limit the IP addresses that it can log on from if you want to. If you have multiple users, this functionality can help you track who is using your Nessus server.

To create a new user, type:
```
nessus-adduser
```
This walks you through creating a new user account.
Run this command each time you need to create a new user. You must have at least one user set up to be able to use Nessus.

Make sure you are running X-Windows (the graphical environment) and start up a shell.
From the command line, type:
```
nessusd &
```
This starts the Nessus server process. The & (ampersand) indicates to run the program in the background so you can type another command.
The next command to type is:
```
nessus
```
This starts the client piece of Nessus and displays the graphical interface.

Nessus Login Page

The first thing you will see is the login page for Nessus (see Figure 5.1). Because of the client-server architecture, you must first log in to a Nessus server before you can begin using Nessus. If you will be running the client and server on the same machine, the correct login parameters are:

You can also run the client on a separate machine from the server. In this case, just replace localhost with the IP address or host name of your Nessus server. This gives you the ability to log in from home and access the Nessus servers at work so you can start scans late at night. Or you may have your Nessus server in a data center where it has access to lots of bandwidth and need to access it from your desk inside your firewall. This flexibility is a big advantage of Nessus over some of the competitive scanners and increases its scalability for larger organizations. You can also perform other local functions on the client without logging into a Nessus server. You can bring up scans run previously to view and manipulate them. You can configure the scan options, but you can't access the plug-ins or preferences section without being logged into a server (because these are saved on the server side).

Nessus Plugins Tab

Once you are logged in, you can access the other tab sections. The Plugins tab is where you can selectively enable or disable certain groups of plug-ins as well as individual plug-ins (see Figure 5.2). Each category is listed, and when you click on a category the individual plug-ins in that category appear in the lower section. By deselecting the box to the right of an item, you can disable that category or plug-in.

Plug-ins that may cause a problem with a service or can crash servers are highlighted with a triangular exclamation symbol (see Figure 5.2). Nessus also has buttons that make it easy to quickly enable all plug-ins, enable all but dangerous plug-ins, disable all plug-ins, or load a custom plug-in. You can use the Filter button to sort the plug-ins by Name, Description, Summary, Author, ID number, or Category. I recommend that you generally run Nessus with dangerous plug-ins disabled, unless you have prepared for a true denial of service test and are willing to risk crashing some of your servers.

Nessus Preferences Tab

Most of the server-side Nessus options are configured on the Preferences tab (see Figure 5.3). The following sections and subsections cover these options.

Nmap

You use these Nmap settings to customize the configuration of how the port scan part of the test runs. Many of these correlate directly to the Nmap settings discussed in Chapter 4, so refer there for details on what each option means.

You can also enter a location for an Nmap results file so that Nessus will use that data rather than run a new scan.

Ping the remote host

This selection lets you ping the machines on the target network to determine first if they are alive, or just scan all the IPs in the target range. By default, Nessus tries ICMP and TCP pings on both the Web and secure socket layers ports. If a host is online, it should respond to one of these polls. This is the setting I recommend using most of the time, because you don't want to waste time and bandwidth running the tests against dead addresses. However, if you are scanning from outside a firewall, you may want to run Nessus without pinging the hosts so you don't risk missing anything. You can also configure the number of tries it makes before considering a nonresponding host dead. The default of 10 is probably too high for most high-speed networks. Unless you are scanning from a dial-up connection, turn the retries rate down to 3 to speed up the scan process, especially on large target networks. You can also set whether dead hosts should appear in the report. Usually you don't want these to be included because they will skew your overall scan statistics, reporting that there are more hosts scanned on your network than there really are. However, this can be useful when you want to know each IP that was contacted.

This section is where you set up login accounts if you want Nessus to test some services at a deeper level. The standard Nessus scan tests the network as if it had no additional knowledge about it other than just the IP addresses. However, if you specify an account and password for a certain service, Nessus will run additional tests on it. For example, if you enter a Windows domain login (SMB account), it will further test your Windows domain security as a logged-on user. By default, it tests only for an anonymous FTP server using the account of "anonymous" and the standard password of an e-mail address. You can have it test FTP, HTTP, IMAP, NNTP, POP2, POP3, and SNMP services with valid logins.

There is a special section for testing HTTP login forms. You can give it the specific URL and form fields to be filled in. By default, it will test an index directory for blank user and password fields.

Brute-force login (Hydra)

This section lets you take advantage of the add-on program Hydra, which tests the integrity of your system's passwords. You give it a file of logins and passwords and it will attempt to go through the whole list on each service you designate. I don't recommend you use this option unless you are prepared to deal with the aftermath of a brute-force attack, which may leave many users locked out of their accounts as the scanner maxes out the number of login attempts they are allowed. A better way to test your password strength would be to run your password file through a password cracker offline. However, it might be useful to test a single service that isn't used much, such as FTP or Telnet. With Hydra, you can attempt brute force on the following services: Cisco IOS standard and enable passwords, FTP, HTTP, ICQ, IMAP, LDAP, NNTP, PCNFS, POP3, Rexec, SMB (Windows Domain), SOCKS 5, Telnet, and VNC.

SMB use host SID to enumerate local users

This section gives a range of User ID (UID) numbers to try to get additional information about the user names in the domain. The default uses UIDs 1,000–1,020, which always encompasses at least the administrator and guest users accounts on Windows networks. Nessus will try administrator and guest with passwords as blank and the same as the login.

Services

This section has to do with testing SSL services. You can specify certificates to check and get reports on the level of encryption your Web servers will accept. This can locate servers that are still accepting older 40-bit encryption, which is now considered insecure for highly sensitive data.

Web mirroring

This setting lets you adjust how deeply into a Web site the scanner will read looking for any flaws or security holes. You can also change the default start directory.

Misc. Information on the News Server

If there is a Network News (NNTP) server located on any of the IPs in the target range, Nessus checks the settings and restrictions set on postings. This ensures that your news servers aren't susceptible to spamming or other misuse.

Test HTTP dangerous methods

The Integrist test checks to see if any Web servers on the network will allow dangerous commands such as PUT and DELETE. This is disabled by default because the test could delete your home page if your server responds to these commands.

Ftp writable directories

This checks for FTP servers that allow write access to anonymous users (which is not a good idea at all). The default setting checks the permissions listed by the file system and responds if one shows as being writable. You can also have it ignore what the file system says and try to write a file anyway to test that there are no writable directories. Again, like the Integrist test above, be careful with this option because you could end up overwriting files on your FTP server.

SMTP settings

These settings are used for additional testing of a mail system. Nessus does this by attempting to send bogus e-mail messages to see how the system responds. Nessus.org is used as the default domain the test mail would be coming from, though this is configurable here. Many mail servers won't respond if the mail server name isn't real. You may want to change this address if you are an outside consultant and want your client to know where the dummy e-mails are coming from. However, don't use your own domain if you are scanning from within a company; this will confuse your mail server to see e-mail coming from itself and may produce unreliable test results.

Libwhisker options

These options are for use with the add-on Whisker program, which tests the integrity of your Web servers. Refer to the Whisker documentation program for explanations of these settings. These options are disabled by default.

SMB use domain SID to enumerate users

This Windows domain test tries to identify users based on their Security ID (SID). In typical Windows domains, SID 1,000 is the administrator, and several other standard designations are used for system accounts such as guest. Nessus polls this range of SIDs to try to extrapolate user names.

HTTP NIDS evasion

This section lets you use various techniques to avoid detection by a network intrusion detection system (NIDS) by crafting and mal-forming special URLs for attacks on Web servers. You need the Whisker add-on program to take advantage of these. The various tests try to send strange URLs to your Web servers to see if they will allow a user to do things that they aren't supposed to be able to do using CGI scripts. For a complete description of these tests, see the Whisker documentation or the article at www.wiretrip.net/rfp/libwhisker/README.

These methods are disabled by default because they tend to create a lot of network traffic and may generate many false positives. However, if you do run a NIDS on your network and want to see if it's really working, you can run these tests to see if it picks up your scans.

NIDS evasion

This section is similar to the HTTP NIDS evasion section, except that Nessus does strange things to the actual TCP packets to avoid pattern-matching NIDS rather than just the URL requests. Most modern NIDS will catch these tricks, but if you have an older system or one that hasn't been patched in a while, it is worth trying these to see if your NIDS catches them. Once again, this will cause your reports to contain data that may be suspect, so it's not recommended for normal vulnerabilities testing.

Scan Options Tab

Unlike the individual tests on the Preferences tab, this tab contains settings that affect the overall scan (see Figure 5.4).

Port range

This controls which ports are scanned during the port scan phase of the test. The default is 1–15,000, which should catch most normal services. However, you should open it up to scan all 65,535 TCP and UDP ports if you want to search for Trojan horses and other services operating on unusual high ports. You should do a full port scan of the machines on your network on regular basis, either monthly or quarterly depending on the network size.

Consider unscanned ports as closed

This option causes Nessus to declare unscanned ports as closed. If you didn't set your port range wide enough in the last option, you may miss something, but it makes your scan run faster and puts less traffic on the network.

Number of hosts to test at the same time

This sets the number of hosts that Nessus tests concurrently. On a large network, you may be tempted to crank this setting way up and run all of them at once. However, at some point this becomes counterproductive and your scan will actually take longer or may not finish at all if it gets bogged down on one particular host. In fact, on average servers (under 2Ghz) machines, I recommend changing this to 10 hosts from the default setting of 30. This seems to be the optimal setting for most scans. However, if you have a super-server and have a very large network, you can try turning it up as high as you can get away with.

Number of checks to perform at the same time

Nessus has the ability to multitask not only how many hosts it scans at once but also the tests. The default setting of 10 seems to work well; however, you can do more or fewer depending on your how much horsepower your Nessus server has.

Path to the CGIs

This is the default location where Nessus will look for CGI scripts on the remote system to test them. If you have an unusual configuration on a machine, you should change this to the correct path so that Nessus will test your CGIs.

Do a reverse lookup on the IP before testing it

This setting attempts to do a reverse DNS lookup and determine every IP's hostname before testing them. This will considerably slow down your scan and is disabled by default.

Optimize the test

Nessus, by default, attempts to be smart about the tests it runs and won't run tests that don't apply to a particular host. You can disable this here so Nessus will run every test on every host regardless of what the port scan finds.

Safe checks

This setting is always on by default. It means Nessus won't perform any unsafe checks that may crash or otherwise harm a server. It will depend on banners or other information to determine if a host has a particular vulnerability. I recommended to always keep this on, even though it will result in more false positives.

Designate hosts by their MAC address

Enable this option if you want Nessus to show hosts in the report by their MAC address rather than IP address, which is the default. If you have a good database of MAC addresses on your network and you have a hard time correlating IP addresses to specific hosts because of DHCP, this may create a more useful report for you.

Detached scan

This feature allows Nessus to run scans without being connected to the client. This is usually done to run scans at unusual times without human intervention. It can be set up to e-mail the scan report to a specific address when it is done.

Continuous scan

This feature starts a new scan on a regular basis. You can use this to set up an automatic scan of your network on a scheduled basis. Set the "Delay between two scans" timing in seconds (86,400 for a daily scan, 604,800 for weekly scans, and approximately 2,592,000 for monthly scans). There are better ways to do this, such as using the Nessus Command Center (NCC) tool described in Chapter 8. However, if you don't want to set up the Web server and database required by NCC, this feature is a quick and easy way to do a regular scan.

Port scanner

Target Selection Tab

This tab is where you set your targets to scan (see Figure 5.5). The following list describes the ways you can designate scan targets.

Read file

Click here to read your targets from a file. This must be a standard text file with addresses formatted as in the above example.

Perform a DNS zone transfer

This attempts to pull a zone file for the domain represented by the target IPs. This doesn't work on private (nonroutable) IP addresses.

Save this session

Keeps a record of the targets and settings so they can be restored at a future date. By default, this is turned on.

Save empty sessions

This saves sessions even when they contain no data, for example, an IP range with no live hosts in it.

Previous sessions

This lists all your previously run sessions and allows you to reload them by clicking on the listing.

User Tab

This tab shows all the users you have set up to use the Nessus server and any rules associated with those users (for example, only able to log on from a specific IP address). These are set up when you create the user with the nessus-adduser script, but you can also edit or add rules for any users from this tab at any time.

KB (Knowledge Base) Tab

This tab contains the configuration and controls for the Nessus Knowledge Base (see Figure 5.6). This is one of the most useful features Nessus offers. It is disabled by default, so you need to select the Enable KB saving check box to turn it on. The Knowledge Base keeps track of all the scans you have done. Then when you want to run that scan again, Nessus uses that data to be intelligent about which hosts it scans and what tests are run on those hosts. Each setting is described below.

Test all hosts

This is the default setting. Knowledge Base data will be saved but each host will be tested in full.

Test only hosts that have been tested in the past

This setting has Nessus test only hosts that it has tested in the past in the target range. This means it will not scan for any new hosts. This reduces network traffic a little, but Nessus won't test any machines on your network that have been added since your last scan.

Test only hosts that have never been tested in the past

This is the opposite of that last setting; it looks only for new hosts on the target network. This is useful for doing a quick check for new machines on your network without scanning your existing machines.

Reuse the knowledge bases about the hosts for the test

This eliminates running certain tests based on what it found and the options you set.

Max age of a saved KB (in secs)

This setting prevents the server from using a scan Knowledge Base that is older than the entry. The default setting is 86,400 seconds, which is one day. You can set this up to 60 days, which is 5,184,000 seconds. Setting it for any longer is not useful, as you will be relying on data that is too old.

The Knowledge Base features can make your scanning quicker and easier. However, you should use the features selectively and always run a full scan on a regular basis (monthly is recommended).

Nessus Scan in Process Options

Once your scan is underway, Nessus displays a screen showing the status of your scan. You can see each host being tested and how far along in the process it is. It also shows you the plug-in that is running at the moment. Most of these fly by very quickly, but sometimes it will get stuck on a particular plug-in. You can stop the testing on that host only by clicking on the Stop button on the right side (see Figure 5.7). You can also click the Stop the whole test button at the bottom to stop all the testing and just report the results thus far.

NessusWX is a Windows client for Nessus. It represents the client end only of the program. Unfortunately, Nessus doesn't yet offer an all-Windows solutions for vulnerability testing. Tenable Network Security makes a commercial Windows Nessus port called NeWT, but if you can't afford that you will have to use a UNIX-based Nessus server for your NessusWX client to attach to.

NessusWX is far more than just a clone of the UNIX client. Besides giving you access to your Nessus server from your Windows machine, NessusWX adds some features that are missing from the UNIX client. It also implements some of the other settings in a more logical and easier to use manner. If fact, some consider NessusWX a superior way to use Nessus. Just keep in mind that you will still need to have a UNIX Nessus server to connect to in order to run your scans. Also, because NessusWX is a separate programming effort, its features will sometimes be a little behind those of the native UNIX platform. Here are a few nice extras you get with NessusWX.

Installing NessusWX

You can also get packages with the source code if you care to monkey around with it and see if you can improve on it. But if you are not intending on doing that, there is no real reason to get the sources. Simply click on the file and the install program will guide you through the process.

Using the NessusWX Windows Client

The NessusWX interface looks different from the native UNIX client (see Figure 5.8). You won't see the same tabs described earlier, but all the configuration options discussed are available in this version. The NessusWX client makes it clearer which settings are client controlled and which are server controlled. The server-controlled settings are the ones found in the nessus.rc text file and constitute global settings, whereas the client-side settings are mostly related to specific scans. You can see the contents of the nessus.rc file and edit it by choosing Server Preferences from the Communication menu.

Another nice thing about the Windows client is that you can interactively create scan configurations (called sessions) and then connect to a Nessus server. This means you can do your configuration offline without connecting to the server. However, to start a scan or view and configure the server-side preferences you need to be connected and log in. To do this, on the Communications tab click on Connect. You can also use the Quick Connect option and set a default server to always log in to. It will also remember your password and login so that you don't have to enter it each time, which is nice (though certainly less secure!).

Creating a Session Profile

The first thing you want to do is create a session profile. This is a target or collection of targets that you want to scan.

From the Profile menu choose New. Enter a name for the scan session in the dialog box that displays. This name appears at the top of the scan report, so you may want to name it something sufficiently descriptive.
You will then see the Session Properties window (see Figure 5.9). Be sure to click Apply after entering data on each tab.

Figure 5.9. NessusWX Session Properties Screen
Click Add to specify the addresses to scan. Notice the easy-to-use format for entering different ranges. You can also opt to import a list of targets by entering the name of a text file that contains them.
Click Remove to delete hosts from the status screen as they complete or choose not to show the executing plug-ins as they run.
Next, click on the Options tab (see Figure 5.10) to set your scan options. These settings are much the same as the scan options in the UNIX client.

Figure 5.10. NessusWX Scan Options Tab
The Port scan tab is where you configure the port scan portion of the test (see Figure 5.11). The default setting is only the common server ports (1–1,024) rather than the 1–15,000 setting on the UNIX client. Of course, you can change these to whatever you want. There are two other settings available, Well-known services or Specific range. The latter lets you set any port range you want.

Figure 5.11. NessusWX Port Scan Options
Once you are logged in, the Plugins tab offers you the ability to selectively enable or disable individual plug-ins or whole groups of plug-ins. You can actually configure some of the plug-in parameters right from the client. Things like the default password used, default directories, and so forth can be set here, which isn't possible on the UNIX client.
There is also a Comments tab. This neat addition lets you document different scans so that you can remember later when you look at them what you were trying to do.
Click OK to close the window.
Once you have all your scan settings configured, double-click on the icon for the scan profile you want to use and then click Execute. The scan should start and bring up a status screen while the scan executes (see Figure 5.12).

Figure 5.12. NessusWX Scan in Process Screen

[View full size image]

You will notice that the Scan Status screen for NessusWX is more detailed than the UNIX client. It shows things such as the percentage done with the port scan. The UNIX client shows this only as a bar, which isn't accurate. It also shows how far the tests are from being done and a running total of open ports, information alerts, security warnings, and security holes found for each host. And, just like the UNIX client, you can stop scanning individual hosts or the whole test.

NessusWX Reports

To get, create, and view NessusWX reports, right click on any scan profile and select Results. Several options on this screen allow you to control the output of the reports. You can choose whether the report is sorted by host or by vulnerability. You can select to leave false positives out of the report and to include the scan configuration so you can remember what settings were used to obtain these results. You can also have it show only reports on open ports, and low, medium, or high severity alerts by deselecting the check boxes for each one. This gives you more flexibility on how the report will look. This is important if you are presenting these reports to nontechnical management, auditors, customers, or other outsiders.

Report options in NessusWX include .nsr, which is the older native Nessus format, .nbe, html, plain text, and .pdf format. All of the results are stored in a database, so you can easily retrieve old scans. You can also compare results from one scan to another by using the diff option. The basic HTML report has some nice additions from the UNIX HTML reports. It adds the profile name, so you know what was scanned. It also timestamps it and gives other statistics, such as how long the scan took. In addition, the scan can be ordered by IP address, as mentioned earlier, which greatly assists in finding a particular host, as anyone who has tried to sort through the randomly ordered UNIX scan report can attest to. Unfortunately, it doesn't have the embedded HTML links that the UNIX reports do, which would greatly improve the ease of navigation through the report. (Hopefully someone is working on merging the best of the UNIX and Windows reports.) Or you scan it all into a database and create your own reports using NCC, which is described in Chapter 8.

Sample Nessus Scanning Configurations

With so many settings to choose from, it can be rather bewildering to know what to do for your first scan. It does take time to learn the intricacies of all the options, but here are a few sample configurations that should produce good results for the most common network configurations.

Sample Configuration 1: External scan of multiple IP addresses; no firewall

This is the simplest possible configuration and requires the fewest changes in the default Nessus configuration.

Sample Configuration 2: External scan of a network with a single external IP address on the firewall

This is a little more complex and requires some stealth to get scan packets past the firewall.

Sample Configuration 3: External scan of a network with multiple public IP addresses on the firewall and DMZ

Sample Configuration 4: Multiple external IP addresses with a Network Intrusion Detection System

Sample Configuration 5: Internal scan behind the firewall

With this kind of scan you are much less concerned about stealth (since you are already inside the firewall) and more concerned about the kind of data you generate.

graphics/fire_head_icon.gif
Flamey the Tech Coders Corner
Writing Your Own Nessus Scripts
As mentioned earlier, it is possible to customize and extend Nessus for your own specific needs because it is open source. It is even easier to add to Nessus than other open source programs because it has its own built-in scripting language, called Nessus Attack Scripting Language (NASL). NASL allows you to quickly and easily write new tests for your Nessus scans without delving into the Nessus engine or other complicated programming.
Note: You should at least have a working knowledge of programming though, specifically the C programming language, before jumping into NASL. NASL is very C-like without a lot of things such as structures and declaring variables. This makes it easy to quickly write a new script to test for some condition.
A NASL script looks much like any other program, with variables, if statements, and functions you can call. Thankfully, Renaud and his team created many functions you can use to easily do the work instead of having to figure out on your own how to craft a packet or check for an open port.
Each script has two sections. The first is the register section, which Nessus uses for documentation purposes. Here you tell Nessus what kind of script this is and provide a little information on it for users to know what it does. The second section is the attack section. This is where you actually execute your code against the remote machine and do something with the results.
For this example, let's say you are having a real problem with Yahoo Messenger on your network. Running Nessus or a port scanner turns up the open ports, but you want to be notified specifically when the Yahoo port shows up.
You can write a custom Nessus script using NASL to do just that. Machines with the Yahoo messenger program running show port 5,101 open, so using the NASL function get_port_state(), you can quickly and easily look for machines running this program and report it. Here is the sample code to accomplish this in NASL. All the lines with # in front of them are comments and are not read by the NASL interpreter.
# This is the register section.
# Check for Yahoo Messenger
#
if(description)
{
#This is the register section and contains information for Nessus
script_name(english:"Looks for Yahoo Messenger Running");
script_description(english:"This script checks to see if Yahoo
Messenger is running");
script_summary(english:"connects on remote tcp port 5101");
script_category(ACT_GATHER_INFO);
script_family(english:"Misc.");
script_copyright(english:"This script was written by
Tony Howlett");
exit(0);
}
# This is the attack section.
# This checks to see if port 5101 is open on the remote system.
# If it is, return the warning
port=5101;
if(get_port_state(port))
{
report = "Yahoo Messenger is running on this machine!";
security_warning(port:5101, data:report);
}
# The end.
That's all there is to it! This simple script assumes two things: first, that the remote machine was port scanned at least up through port 5,101 as get_port_ state function will erroneously return true on port 5,101 if the state is unknown. It also assumes that a machine with port 5,101 open is running Yahoo when it may be some other application. If you want, you could code some additional logic to verify this, by grabbing a banner or some piece of the response and examining its characteristics.
This is a very simple example and much, much more can be done with NASL. Refer to the online references for NASL for more information on all the functions you can use and additional syntax. There is an excellent tutorial written by Renaud himself located at www.nessus.org/doc/nasl.html.