Nessus

---

Nessus is a remote vulnerability scanner that is freely available for download from http://www.nessus.org/. It performs a thorough yet efficient sweep of the systems on your network for known network misconfigurations and application vulnerabilities. In this chapter, we focus on version 2.0.7 of Nessus.

Nessus is a client/server application. The nessusd server runs on a Unix system and does the dirty work, keeping track of all of the different vulnerability tests and performing the actual scan. It has its own user database and secure authentication method so that remote users using the Nessus client (Unix and Windows versions are available) can log in, configure a vulnerability scan, and set it on its way.

The makers of Nessus developed a scripting language referred to as the Nessus Attack Scripting Language (NASL) for use with their product. In Nessus, each vulnerability scan is actually a separate script or plug-in written in NASL. This modular architecture allows vulnerability scans (and possible exploit tests) to be easily added as new vulnerabilities are discovered. The folks over at Nessus attempt to keep their vulnerability database updated on a daily basis, and they even offer a simple script (nessus-update-plugins) that you can run in a cron job nightly to update your plug-ins automatically.

Note 

Cron is a Unix tool that takes a list of commands (called a crontab) and runs those commands at scheduled times. It comes preinstalled on nearly all Unix systems. The actual syntax for setting up a crontab is beyond the scope of this book, but many Linux systems offer you subdirectories in the /etc/ directory such as cron.daily, cron.weekly, and cron.monthly. You can write a short shell script containing the command you want to run along with any command-line arguments and place that script in the appropriate directory (such as cron.daily if you want it to run every night). You can learn more by looking at the Unix man pages for cron and crontab.

Nessus is smart: It is able to recognize services running on any port, not just the standard Internet Assigned Numbers Authority (IANA) port number. If you have a web server running on TCP port 8888, Nessus will find it and try its common gateway interface (CGI) tests against it. On the flip side, if Nessus doesn’t find any web servers on the system it’s scanning, it will skip any further web server or CGI tests for that system.

Nessus is thorough. Many of the plug-ins will not only scan for the vulnerability, but they will also try to exploit the vulnerability and report on their success. Sometimes this activity can be a bit dangerous because a successful exploit might crash the system you’re scanning, rendering it useless or causing data loss. However, because Nessus gives you full descriptions of what each vulnerability test does, you can decide which tests are safe to run.

Unlike many freeware Unix tools, Nessus’s reporting is extensive, well organized, and available in many output formats such as plain text, HTML, and LaTeX. It classifies security events from notes to warnings to holes, each with a risk level ranging from Low to Very High.

Installation

Installing the Nessus daemon (nessusd) can be complicated even to intermediate-level Unix and Linux users. It requires the GIMP Toolkit (GTK) and OpenSSL packages to be installed for full functionality. Nessus is available for download in four separate packages: nessus- libraries, libnasl, nessus-core, and nessus-plugins. Each package needs to be downloaded, compiled, and installed (standard configure, make, make install procedures) in the package order just listed. Nessus also comes in a single shell archive (nessus-installer.sh) that includes all the packages and handles all the installation details for you.

Implementation

Remember that Nessus is a client/server application. Before we can run Nessus, we have to set up and configure a few things.

Step 1: Configure the Nessus Server Certificate

Nessus uses SSL for a number of different things. First, the server can use SSL so that Nessus clients on remote networks can communicate securely. It also allows those Nessus clients to use SSL certificates for authentication purposes. Third, it enables Nessus to run checks against SSL-based services such as HTTPS servers and SSH daemons. If you build Nessus on a system with OpenSSL installed, Nessus will be configured automatically to use SSL (unless you explicitly turned off SSL communication using ./configure -–disable -cipher) when building the nessus-libraries and nessus-core packages.

If SSL is enabled, your first step is to configure a Nessus server certificate. This is easily accomplished by running the nessus-mkcert command as the root user. You will be asked a set of standard SSL certificate questions (such as the server’s location, organization name, and expiration date). From this information, nessus-mkcert will first generate the files necessary to create a CA, or Certification Authority, for the Nessus server. CAs are used to sign SSL certificates digitally, to authorize them as "trusted." When browsing an HTTPS web site, you may examine the site’s SSL certificate and see that it was "signed" by a company such as Verisign or Thawte. Verisign and Thawte are two of the most trusted and well-known CAs in the world. When a certificate is signed by a CA, it means that the CA has verified that the holder of the certificate is who he says he is. If you trust the CA, you should trust the holder of a certificate signed by the CA. Nessus creates its own CA for signing its own server certificate as well as any client certificates. By default, Nessus will only accept certificates signed by its CA. After creating the CA, nessus-mkcert generates a certificate for the server and has the CA sign it. It will then update your configuration files and place the proper certificate files on your system. The certificates for the Nessus server and the Nessus server’s CA are placed in /usr/local/com/nessus/CA by default and are world-readable. The private keys for those certificates are placed in a protected directory /usr/local/var/nessus/CA/, which can be read only by root. You’ll want to make sure the private keys are protected from other users, as anyone obtaining them could create and sign certificates that could be used to connect to your Nessus server.

If you don’t want to bother using SSL, you can disable it in the main Nessus configuration file (located at /usr/local/etc/nessus/nessusd.conf by default) by adding ssl_version=none on a line of its own at the end of the file.

Step 2: Creating Users—Password Authentication

The nessus-adduser utility can be used to add a user to the Nessus database. When you run nessus-adduser as the root user, you’ll be prompted for a login name and an authentication type (either password authentication or certificate authentication). Password authentication will usually suffice for small-scale Nessus installations. You can configure rules for each user (as to which machines the user is allowed to scan). For example, the following rules will let the user scan only machines on the 192.168.1.0 class C network:

accept 192.168.1.0/24 default deny

For our purposes, leave the rule list blank by pressing CTRL-D, and confirm the creation of the user by typing Y and pressing ENTER.

Step 3: Creating Users—Certificate Authentication

Certificate authentication is a bit trickier. You can accomplish this in a couple of different ways, but documentation on the subject is sparse at this time. The following process worked well for us.

Instead of using nessus-adduser, run the tool nessus-mkcert-client as the root user. This will allow you to create the user’s client certificate files as well as register the user in the user database (which is what nessus-adduser does). After answering “yes” to the first question, you will be asked for information about the client certificate (such as the client’s location, organization name, and expiration date). Next, you will be asked for a login name and certificate credentials for the user. You should be able to press ENTER after each question regarding the user’s certificate credentials, as it will default to the values you entered above. Finally, you will be asked whether you want to set up rules for the user (see Step 2). When you’re done, you can create another client certificate or exit by typing N. Nessus-mkcert-client will tell you that the new user’s certificate files are located in a temporary directory (such as /tmp/nessus-mkcert.31527) and that you will have to copy them by hand. What does that mean?

Let’s say we just created a client certificate for user jdoe. We would need to copy the directory /tmp/nessus-mkcert.31527 and all its files to a “private” directory for jdoe. For example, we could perform the following steps:

[jdoe@localhost ~]$ cd ~jdoe [jdoe@localhost ~]$ mkdir .private [jdoe@localhost ~]$ su Password: [root@localhost jdoe]# cp –R /tmp/nessus-mkcert.31527/* .private/ [root@localhost jdoe]# chmod 700 .private/; chown –R jdoe .private/

The last step is particularly important to make sure that other users on the system (who shouldn’t necessarily be allowed to use Nessus) can’t steal jdoe’s certificate.

When you run Nessus for the first time, it creates a .nessusrc file in your home directory. In jdoe’s case, it would be located at ~jdoe/.nessusrc. Before jdoe can use certificate authentication, the following lines need to be added to his .nessusrc file:

cert_file = /home/jdoe/.private/cert_jdoe.pem key_file = /home/jdoe/.private/key_jdoe.pem

The next time jdoe runs Nessus, he should be able to log into the Nessus server using only his certificate credentials.

Note 

The Nessus client still requires that you enter a password when logging into the Nessus server, even if you’re using certificate authentication for the user. This is because you can actually use OpenSSL utilities to create your own certificate files and encrypt the certificate’s private key using a password. When using certificate authentication, the password you type in at the Nessus client login will be used to decrypt your key. If you have not encrypted your key with a password, it doesn’t matter what you type in the password box—but you must type something, even if it’s gibberish. Nessus will not allow a user to log in with an empty password in either authentication mode.

Certificate authentication adds a bit of security to Nessus’s client/server model, especially if you use a password to encrypt your certificate’s private key. If jdoe wanted to encrypt his client private key after the fact, he would simply do the following:

[jdoe@localhost ~]$ cd .private [jdoe@localhost ~/.private]$ openssl rsa –in key_jdoe.pem –des3 –out passkey_jdoe.pem writing RSA key Enter PEM pass phrase: Verifying – Enter PEM pass phrase: [jdoe@localhost ~/.private]$

Now jdoe has a new, encrypted private key file in passkey_jdoe.pem. Now we need to tell Nessus to use it when logging in. Change the key_file line in .nessusrc to reference the new key file:

cert_file = /home/jdoe/.private/cert_jdoe.pem key_file = /home/jdoe/.private/passkey_jdoe.pem 

Finally, you can delete the old key_jdoe.pem file. Anyone wanting to log into the Nessus server as jdoe will not only need access to jdoe’s certificate but will need to know the password to decrypt jdoe’s private key as well.

For more information on issues with Nessus and SSL, take a look at the README_SSL file in the nessus-core package.

Step 4: Tweaking nessusd.conf

The nessusd.conf file (which is installed in /usr/local/etc/nessus/ by default) contains several global scan options that you might want to tweak. The max_hosts and max_checks variables (which are 30 and 10, respectively, by default) can be increased if you want to speed up your scan and your system can handle the load. In addition to the nicely formatted reports, Nessus can store the details of all of its tests in a logfile. This is extremely useful if you see something in the report that you believe to be erroneous and you want to find out why Nessus reported it the way it did (and whether it was actually correct). You can configure this logfile location (default is /usr/local/var/nessus/nessusd.messages) and level of logging detail using the logfile and other log_-related variables. Nessus also has a dumpfile (at /usr/local/var/nessus/logs/nessusd.dump) for debugging information. Another important option to set is the range of ports you want to scan (port_range). Nessus uses its own built-in port scanner first to determine what ports are listening on a system. By default, Nessus will look only at ports in its “services” file (located in /usr/local/var/nessus). The default port range should be sufficient for most scans. Increasing the range will lengthen the time of the scan but is necessary if you want to perform a complete scan of your network vulnerabilities.

Tip 

The max_hosts, max_checks, and port_range variables can be configured on an individual scan basis from the Nessus client. Changing them here will simply affect a global change so that the default values will always match the ones you specify in this file.

Other variables that will affect the length (and accuracy) of your scans are check_read_timeout and plugins_timeout. The first value affects how long Nessus will wait to get data back on a socket before giving up, and the second value affects how long before Nessus gives up on a plug-in. The check_read_timeout variable is the big factor here. The default value is 5 seconds. Decreasing it will make your scan go much faster, but you could miss something by giving up too soon. Chances are, if you’re performing the scan on a local network, having a lower check_read_timeout value is a safe bet. The plugins_timeout default value is set to 320 seconds. You may want to decrease that if you find your scans are taking too long.

Finally, you should pay close attention to the optimize_test and safe_checks settings. When both are set to "yes," your scan will go faster and shouldn’t harm any network services. The optimize_test setting tells Nessus to be smart about its scan and, for example, run CGI tests against a host only if the port scan reveals a web server running on it. This gives your test added speed, but Nessus may glide over a vulnerability without noticing it. The safe_checks setting tells Nessus that even if it encounters a service that appears to be exploitable, it should simply report that it found the service without actually exploiting it. This is an important option, as you may not want to crash any hosts or services running on the network you’re scanning. However, because Nessus is relying only on the service’s banner or footprint to determine whether the service is vulnerable, you don’t actually know whether the exploit would have worked. When both settings are set to "no," you’ll get a much more thorough and complete scan at the price of speed and potential destruction. You’ll want to consider whether speed, accuracy, or safety is more important to you. Both of these settings can also be configured on a per-scan basis inside the Nessus client.

Step 5: Starting the Server and Running the Client

After you’ve finished tweaking the nessusd configuration file, you can start up the daemon (nessusd –D as root) and start up your graphical Nessus client by typing nessus and pressing ENTER at the command line. Before you can continue, though, you must log into the Nessus daemon (which is running on localhost at port 1241 by default) using one of the users you created earlier in Step 2 or 3. If you’re using SSL and it’s your first time connecting to the Nessus daemon, you will be asked how paranoid you want to be about SSL certificates. For small-scale situations like this one, the first option is fine. The other options are necessary only if you are managing multiple Nessus servers (using the same CA) from your client. After answering that question, you will be presented with the Nessus daemons’s SSL certificate. If you accept it, the client will remember it and continue the connection. If that server certificate changes at some point, you will be warned of a potential security breach.

After a few moments, the Nessus client should be loaded and ready to go. Now the big configuration decision you’ll encounter is what vulnerability checks (plug-ins) you want to run and what hosts you want to run them against. Click the Plugins tab and you’ll see a screen similar to that shown in Figure 12-1.

Figure 12-1: Nessus Plugins tab

The first time you run Nessus, you should probably disable all the selections in the Nessus Plugins tab and go through each category to learn exactly what each check (plug-in) does. It’s a good idea to do this with any vulnerability scanner. This can be a very time-consuming process, as more than1700 different plug-ins are available for version 2. Nessus breaks down the plug-ins into groups or categories. These categories and short descriptions of them are listed in Table 12-1.

Table 12-1: Nessus Categories of Vulnerabilities

Nessus Plug-in Category	Description
Miscellaneous	Performs account tests, traceroute, default accounts, and other miscellaneous checks
Gain A Shell Remotely	Checks for buffer overflows, bypass of authentication
Finger Abuses	Checks for Finger daemons that can allow hackers access to restricted files, restricted system commands, or user information
Windows	Checks for SMB, NetBIOS, and other Windows-related vulnerabilities
Backdoors	Checks for backdoors such as Trinity, Netbus, Back Orifice, SubSeven, and the like, as well as infections such as CodeRed and Bugbear
General	Checks for the ability to obtain version and other program information that might help a hacker identify a system, services running on a system, system configurations, and so on
SNMP	Checks for Simple Network Management Protocol (SNMP) holes and vulnerabilities
CGI Abuses	Checks for CGI exploits for web servers and applications such as IIS, Lotus Domino, Apache, PHP, Cold Fusion, FrontPage, and more
Remote File Access	Checks for unauthorized methods of grabbing files through such services as NFS (Network File System), TFTP (Trivial File Transfer Protocol), HTTP (Hypertext Transfer Protocol), and Napster as well as poorly secured remotely accessible databases like MySQL and PostgreSQL
RPC	Checks for obtaining information and exploiting vulnerable RPC services such as mountd and statd
Gain Root Remotely	Checks for vulnerabilities that allow remote users to gain root or Administrator access to a machine
Firewalls	Checks for firewall-related misconfigurations and vulnerabilities, and detects and identifies particular firewall products
Useless Services	Checks for outdated services that shouldn't be running or accessible to the Internet at large, such as echo, daytime, chargen, Finger, rsh, and more
Denial-of-Service	Checks for DoS exploits for a number of different Unix and Windows applications and services
FTP	Checks for FTP-related vulnerabilities, including FTP misconfigurations, unnecessary anonymous FTP access, FTP Bounce vulnerability (nmap in Chapter 4 can take advantage of this), and more
NIS	Checks for vulnerabilities related to Sun's Network Information Service
SMTP Problems	Checks for vulnerabilities in popular mail servers (sendmail, Lotus, and so on)
Windows: User Management	Checks to obtain Windows-related user and group account information or misconfigurations
Default Unix Accounts	Checks for username/password combinations set up by default on certain systems, unpassworded “default” accounts, and so on
CISCO	Cisco system vulnerabilities—includes checks for problems mentioned in Cisco's bug database as well as empty passwords on accounts
Peer-To-Peer File Sharing	Detects the presence of running file-sharing utilities such as LimeWire, Trillian, Kazaa, ICQ, and so on
Netware	Detects Novell NetWare vulnerabilities
Settings	Allows you to configure login settings, plug-in options, and other goodies

If you double-click one of the options (vulnerability checks) in the lower window, you’ll get more information as well as any configuration options that are available for that specific option (usually timeout values). Figure 12-2 shows information obtained by double-clicking the option NT IP Fragment Reassembly Patch Not Applied (jolt2).

Figure 12-2: Nessus vulnerability check information

Some vulnerability check plug-ins are considered dangerous in that they may cause the system being scanned to crash. Figure 12-3 shows dangerous Nessus plug-ins, indicated by the caution icon. You can disable all dangerous plug-ins by clicking the Enable All But Dangerous Plugins button.

Figure 12-3: Disabling dangerous Nessus plug-ins

To include a particular vulnerability check in your scan, check the box next to the desired plug-in. A new feature in Nessus lets you search for particular plug-ins (using the Filter button) by name, author, category, or a number of other fields. Because some plug-ins require other plug-ins to be enabled, you might want to check the Enable Dependencies At Runtime box. Otherwise, a dependent check won’t run.

After you’ve looked through all the plug-ins and decided what you want to scan for, you can configure other aspects of the plug-ins’ behavior, such as those shown in the Prefs. tab in Figure 12-4. With version 2, you can configure a slew of plug-in preferences on the Prefs. tab, from individual plug-in settings (the same as those configured in the Settings Plug-in section), IDS evasion techniques, brute-force login attempts, and nmap scanning options.

Figure 12-4: Setting Nessus preferences

In the Scan Options tab, shown in Figure 12-5, you can set up some of the same options that we saw in the global nessusd.conf file. (See the “Step 4: Tweaking nessusd.conf” section for details on configuring these options.) This allows you to configure these options (such as port range, number of hosts and checks to run simultaneously, and so on) on a per-scan basis. A new Nessus option allows you to “detach” the scan and have it run continuously, e-mailing you reports periodically. Additionally, you can check the Nmap box to have Nessus use nmap (covered in Chapter 4) for additional port scanning capabilities, including OS fingerprinting.

Figure 12-5: Nessus Scan Options tab

Note 

Nessus can scan for LaBrea tarpitted hosts. The LaBrea utility can be used to lure port scanners, vulnerability scanners, and automated worms into thinking they’ve made an actual TCP connection to a viable service. In reality, LaBrea fakes a TCP response but sets the TCP window of the return packet to zero, telling the scanner or worm on the other side that it can receive no more data at the moment. Unless configured to look for this behavior, the scanner or worm will obey the TCP window size and wait infinitely, allowing LaBrea to trap them there. This option allows Nessus to identify any IP addresses that are using LaBrea and avoid the tarpit. More information about LaBrea can be found at http://www.hackbusters.net/LaBrea/, although it is no longer distributed at that location due to legal issues.

You’ve done a lot of configuration by this point, but you’re still missing an important piece: the target(s) you wish to scan! On the Target Selection tab, you can specify a single IP or hostname, a subnet (such as 192.168.1.0/24), or a list of hosts and IP addresses separated by commas. Alternatively, you can store the IP addresses and hostnames in a separate file and load them from there by clicking the Read File button.

Nessus gives you two ways to save information about your scan. From the Target Selection tab, you can simply save the session and restore it at a later time. This allows you to continue an interrupted scan at a later time but doesn’t let you do anything else. Alternatively, you can use the KB tab of the Nessus client to have it save your scan to the Nessus server’s “knowledge base.” This allows you to store port scan, host identification, and other assorted vulnerability information in the server’s knowledge base for a certain period of time. This is useful if you’ll be testing a particular group of hosts on a regular basis and you want Nessus to remember what happened during previous scans.

Note 

Saving sessions from the Target Selection tab is disabled by default. You must build the nessus-core package using ./configure -–enable-save-sessions to enable the functionality. Keep in mind that Nessus will "remember" the results only from hosts that have been completely scanned. Scans in progress when the session was interrupted will have to be restarted.

Step 6: Scanning and Analyzing Hosts

Now we’re ready to start the scan. In this example, we’ve configured a simple scan to run all but the dangerous plug-ins/checks with an additional nmap connect scan for OS identification. We’ve also enabled the Optimize The Test and Safe Checks options in the Scan Options tab, sacrificing thoroughness in the name of speed and safety. We’ll scan five hosts on the network: 192.168.1.1, 192.168.1.50, 192.168.1.100, 192.168.1.102, and 192.168.1.103, as indicated in the Target Selection tab shown in Figure 12-6. We’ve checked the Save This Session box so that we can restore it at a later time if necessary.

Figure 12-6: Nessus Target Selection tab

1. Click the Start The Scan button in the bottom-left corner of the Target Selection tab.

2. In the status screen, depending on how many concurrent host checks you configured in the Scan options, you should see several vulnerability checks running in parallel, as shown in Figure 12-7.

   
   Figure 12-7: Nessus scan status

3. Go grab a cup of coffee or, depending on the number of systems, grab lunch. Even a scan of only five hosts can take quite a bit of time. When the scan has completed, the results are ready for you to review in the Nessus Report window, shown in Figure 12-8.

   
   Figure 12-8: Nessus Report showing output results

Now it’s time to analyze the report. By default, Nessus summarizes the problems it found and breaks down the ports and problems by host. Click a host on the left side of the Report window to reveal a list of the ports found open on that host. Double-click a port to see whether Nessus found any security problems with that port. In Figure 12-8, you can see that Nessus found a security hole with a risk factor of High regarding the web server on 192.168.1.50. Notice, however, that it also warns you that because safe checks were enabled, it relied solely on the web server’s version number; it didn’t actually try the exploit. We might want to consider scanning again with safe checks disabled to know for certain. Nessus has also gathered general information about each host as well as the hosts’ services. This includes OS identification information and flaws in the hosts’ TCP/IP stacks.

You can view the report in a number of different ways by changing the entity you’re viewing in the top-left corner of the report. For example, if you were mainly concerned about security holes, sort by “Severity” instead of “Subnet.” Now by clicking the Security Hole severity in the top-left and selecting a host at the bottom-left, you will see only information classified as security holes for that host. You can do the same with hosts and ports, which is useful if you want to concentrate on a particular system or service.

In either view, Nessus orders the entities by problem severity. The red circular icon means at least one security hole exists, the orange triangular warning icon means at least one security warning exists, and the light bulb icon means at least one security note is present. No icon means that the port is open, but nothing wrong could be found.

If you want to save the report to a file, click the Save Report button. You can save the report in the native Nessus format (NBE, the default) if you want to be able to view it later in Nessus. Otherwise, you can save it in XML, HTML or LaTeX—or if all else fails, you can save it to a text file. It’s not as pretty, but at least the information is there.

Keeping Vulnerability Checks Current

As mentioned, Nessus plug-ins are updated daily as new vulnerabilities arise. Nessus comes with a script called nessus-update-plugins that will automatically download and install the latest plug-ins from http://www.nessus.org. You can make this application a cron job, as it requires no user input. This is the quickest and easiest way to make sure you have the most up-to-date vulnerability checks when performing a scan, but some administrators might like to see exactly what it is they’re updating. You can view all of the available Nessus plug-ins online at http://cgi.nessus.org/plugins/.

Summarizing Nessus

Because Nessus is free and open source, it is one of the most widely used vulnerability scanners in operation today and an absolute must-have in the system administrator’s arsenal. Although Nessus is a great starting point, several commercial scanners will greatly increase your assessment capabilities, especially on a Windows network.

---