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 the 2.3 development branch 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 pre-installed 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, LaTeX, and PDF (Windows client only). 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 for 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 order just listed.

Implementation

Keep in mind that Nessus is a client/server application. Before we can run Nessus, we have to set up and configure a few things for the server to accept user connections.

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 , but this is not recommended). This applies to the nessus-libraries package. Without SSL, network communications between the client and server will not be confidentialsomeone with access to the local network may be able to sniff information like passwords or vulnerability statistics.

To use SSL you must configure a certificate for the Nessus server. 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 generates the files necessary to create a CA, or Certification Authority, for the Nessus server. CA certificates are used to digitally sign other SSL certificates and authorize them as trusted. Take a look at the SSL certificate of your favorite web site and you'll see that it was signed by a company such as Verisign or Thawte (there are many others). Verisign and Thawte are two of the most well-known Certificate Authorities. When a certificate is signed by a CA, it means that the CA has verified the integrity and identity of the certificate. Trust in the CA implies trust in any certificate signed by the authority.

Note 

A stolen SSL certificate is not necessarily invalid. The CA merely indicates that the few dozen bytes that make up a certificate have been validated . It doesn't necessarily mean that the owner of the certificate is valid, but that's the assumption. Think of the certificate in terms of a very strong password: As long as only you know the password, it is secure and can identify you upon login; but if your password is stolen (or shared!), then it no longer uniquely identifies youit only identifies knowledge of a string. Nevertheless, SSL certificates can be reliable and provide good security from sniffing. Plus, services like certificate revocation lists (CRLs) aid in managing lost, stolen, or prematurely expired certificates.

Nessus creates its own CA for signing its own server certificate as well as any client certificates. This makes certificate management easier for the user because a full-fledged CA infrastructure can be expensive and time-consuming to establish. By default, Nessus will only accept certificates signed by the CA generated in this stage. After creating the CA, nessus-mkcert generates a certificate for the server and signs it. Then it updates the Nessus configuration files and places the certificate files in their proper location 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. They are world-readable, which is okay because they contain the public portion of the key. The private keys for those certificates are placed in a protected directory /usr/local/var/nessus/CA/, to which only root has access. The integrity of any SSL system relies on protecting the private keys, as anyone who obtained 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. Again, this is not recommended, but if you plan on using the Nessus server and client on the same physical machine, then the lack of SSL will not be an issue.

Step 2: Creating UsersPassword 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 access rules for the user at this stage. For example, the following rules will let the user scan only machines on the 10.0.1.0 class C network:

 accept 10.0.1.0/24 

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. If you wish to change a user's network access rights, then edit the rules file associated with their username in the Nessus configuration directory. By default, it will be here (for user mike ):

 [Paris:~] root# cd /usr/local/var/nessus/users/mike/auth [Paris:users/mike/auth] root# cat rules accept 10.0.1.0/24 default deny 

Rules in this location can be trumped by those defined in the /usr/local/etc/nessus/nessusd.rules file. The user's password hash is also in the auth directory. Make sure it is locked down to only root access.

Step 3: Creating UsersCertificate Authentication

Certificate-based user authentication involves a few more steps. Instead of using the nessus-adduser command, run the nessus-mkcert-client tool under root privileges. It will create the users' certificate files and register them in the user database. Answer "yes" to the first question, then supply the required 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. Enter the necessary certificate information or accept the defaults, which are populated from the previous certificate's answers. As with the nessus-adduser command, you will be asked for access rules for the user (see Step 2). Once finished, you can create another user's client certificate or exit by typing N . Nessus-mkcert-client indicates where to find new user's certificate files, usually in a temporary directory such as /tmp/nessus-mkcert.foo. The user won't be able to use the certificate until some manual steps are taken.

Let's say we just created a client certificate for user mike . We would need to copy the directory /tmp/nessus-mkcert.10889 and all its files to a private, protected directory for this user. Here is an example:

 [Paris:var/nessus/users] root# nessus-mkcert-client Do you want to register the users in the Nessus server as soon as  you create their certificates? (y/n): y This script will now ask you the relevant information to create the  SSL client certificates for Nessus. Client certificates lifetime in days [365]: Your country (two letter code) [US]: Your state or province name [none]: Your location (e.g. town) [Paris]: Your organization [none]: Your organizational unit [none]: ********** We are going to ask you some question for each client certificate. If some question has a default answer, you can force an empty answer  by entering a single dot '.' ********* User #1 name (e.g. Nessus username):mike Client certificates life time in days [365]: Country (two letter code) [US]: State or province name []: Location (e.g. town) [Paris]: Organization []: Organization unit []: e-Mail []: Generating RSA private key, 1024 bit long modulus ...<snip>... Using configuration from /tmp/nessus-mkcert.10889/stdC.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName           :PRINTABLE:'US' localityName          :PRINTABLE:'Paris' commonName            :PRINTABLE:'pyretta' Certificate is to be certified until Sep 22 05:33:51 2006 GMT (365 days) Write out database with 1 new entries Data Base Updated ...<snip>... User added to Nessus. Another client certificate? (y/n) n Your client certificates are in /tmp/nessus-mkcert.10889. [Paris:var/nessus/users] root# su - mike [Paris:~] mike% mkdir .private [Paris:~] mike% chmod 700 .private [Paris:~] mike% cd .private/ [Paris:~/.private] mike% sudo cp -r /tmp/nessus-mkcert.10889/ . [Paris:~/.private] mike% sudo chown mike * 

When you run Nessus for the first time, it creates a .nessusrc file in your home directory. In this example case, it would be located at ~mike/.nessusrc. You can edit this file to enable certificate-based authentication:

 cert_file = /Users/mike/.private/cert_mike.pem key_file = /Users/mike/.private/key_mike.pem 

Upon the next execution of the Nessus client, authentication will be performed via the certificates. You can also specify the certificate and key in the GUI, as shown in Figure 12-1. Leave the password field blank.

Figure 12-1: Nessus client authentication schemes

Tip 

Mac OS X users should be sure to compile Nessus against the OS X OpenSSL libraries; otherwise you may encounter SSL handshake or other connection errors. If you use DarwinPorts or Fink, make sure the system's include and lib directories come first during Nessus compilation, e.g. "-I/usr/include I/ opt/local/include."

Certificate authentication adds significant security to Nessus's client/server model, especially if the private key is password protected. Use OpenSSL to apply a password to the private key:

 [Paris:~/.private] mike% openssl rsa -in key_mike.pem  -aes256 -out passkey_mike.pem writing RSA key Enter PEM passphrase: Verifying - Enter PEM passphrase: 

Update the key_file entry in the .nessusrc file or choose the new password-protected key file in the GUI:

 key_file = /Users/mike/.private/passkey_mike.pem 

Enter the key file's password in the password field of the GUI. 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, installed in /usr/local/etc/nessus/ by default, contains several global scan options that deserve attention. These can be edited in the nessusd.conf file so they are applied to all users. These settings can be supplemented, but not overridden, by user-specified values. 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.

Note 

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

Figure 12-2: Nessus Plugin selection

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 than 1700 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 Plug-in Categories

Nessus Plug-in Category	Description
Backdoors	Checks for backdoors such as Trinity, Netbus, Back Orifice, SubSeven, and the like, as well as infections such as CodeRed and Bugbear
Brute Force Attacks	Checks authentication-based services for common credentials
CGI Abuses	Checks for CGI exploits for web servers and applications such as IIS, Lotus Domino, Apache, PHP, Cold Fusion, FrontPage, and more
CGI Abuses: XSS	Performs cross-site scripting (XSS) attacks against a web application
CISCO	Cisco system vulnerabilitiesincludes checks for problems mentioned in Cisco's bug database as well as empty passwords on accounts
Default Unix Accounts	Checks for username/password combinations set up by default on certain systems, unpassworded "default" accounts, and so on
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
Finger abuses	Executes common exploits against finger daemons
Firewalls
Gain a shell remotely	Exploits that target network-based services with buffer overflow vulnerabilities
Gain root remotely	Exploits that target local files (or services) with buffer overflow vulnerabilities
General
Misc.	Performs account tests, traceroute, default accounts, and other miscellaneous checks
NIS	Checks for vulnerabilities related to Sun's Network Information Service
Netware	Detects Novell NetWare vulnerabilities
Peer-To-Peer File Sharing	Detects the presence of running file-sharing utilities such as LimeWire, Trillian, Kazaa, ICQ, and so on
RPC	Checks for obtaining information and exploiting vulnerable RPC services such as mountd and statd
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
SMTP Problems	Checks for vulnerabilities in popular mail servers (sendmail, Lotus, and so on)
SNMP	Checks for Simple Network Management Protocol (SNMP) holes and vulnerabilities
Service Detection	Identifies the type and version of services running on a port
Settings	Allows you to configure login settings, plug-in options, and other goodies
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
Web Servers	Checks for vulnerabilities and outdated applications that related to web servers such as IIS or Apache
Windows	Checks for SMB, NetBIOS, and other Windows-related vulnerabilities
Windows: Microsoft Bulletins	Checks that correspond to a Microsoft KB article and security advisoryuseful for monitoring patch efficiency and compliance
Windows: User Management	Checks to obtain Windows-related user and group account information or misconfigurations

Expand the plug-in category to view the list of all available checks. If you double-click one of the checks, then a pop-up window displays detailed information and permits you to specify additional configuration options (usually timeout values). Figure 12-3 shows the details for a script injection test. This also gives you a chance to see the plug-ins upon which the test depends. You may always run full-bore scans, but dependencies are necessary when you pare down checks to make scans complete more quickly.

Figure 12-3: Detail information about a single check

The vast community behind Nessus has also created suites of checks for an array of operating systems. These Local Security Checks are designed to search for specific files, RPMs, or packages that have reported vulnerabilities.

AIX	Debian	Fedora	FreeBSD
Gentoo	HP-UX	MacOS X	Mandrake
Red Hat	Slackware	Solaris	SuSE

Some vulnerability check plug-ins are considered dangerous in that they may crash the target system or service. Such checks have a triangular caution symbol in the Warning column of the Plugins display under Global Settings. If you wish to find all of the current plug-ins that are considered dangerous, then create a display filter for Categories with a "destructive_attack" entry. (The filter button is visible on the Plugins tab under Global Settings.) Rather than letting you worry about accidentally enabling a destructive attack, Nessus provides a "Safe checks" option on the General tab of the Global Settings menu, as shown in Figure 12-4.

Figure 12-4: Prevent Nessus from executing potentially dangerous checks.

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, it's a good idea 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 Plugin Prefs. tab in Figure 12-5. You can configure a slew of plug-in preferences in this tab, from individual plug-in settings, the same as those configured in the Plugins tab, IDS evasion techniques, brute-force login attempts, and nmap scanning options.

Figure 12-5: Customize scan behavior.

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.

The KB (Knowledge Base) tab enables Nessus to 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. 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.

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 hosts on the 10.0.1.0/24 network, as indicated in the Target Selection tab.

1. Click the gear icon to begin a scan.

2. In the status screen, depending on how many concurrent host checks you configured in the Scan options, you should see several vulnerability checks. They will run in parallel and use as many resources as you permitted in the General tab of Global Settings, such as number of hosts to test at the same time or the number of checks to perform at the same time.

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 completes, the results are ready for you to review in the Nessus Report window, shown in Figure 12-6.

Figure 12-6: Nessus Report window

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-6, you can see that Nessus found a security hole with a risk factor of High regarding the web server on 10.0.1.1. If Safe Checks were enabled for a scan, then Nessus typically just relies on the service's version number, if any, and compares to the expected version that is vulnerable. You might want to consider rerunning a scan again with Safe Checks disabled to verify that a service is vulnerable. Nessus has also gathered general information about each host as well as the host's services. This includes OS identification information and flaws in each host's TCP/IP stack that could lead to fingerprinting the device or more potentially dangerous exploits such as packet spoofing.

Nessus orders target entities by the severity associated with its findings. 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 lightbulb 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, select the Export entry under the Report menu item. You can save the report in the native Nessus format (NBE, which is the default) if you want to be able to view it later in Nessus. Otherwise, you can save it in ASCII text, XML, HTML (with or without summary graphics), LaTeX, or PDF. The number of choices enables you to share the results in an easy format, or analyze the results easily in another tool or with a customized set of scripts.

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

If you wish to see which plug-ins have been updated, include the v option.

 [Paris:src/nessus/nessus-core] mike% sudo nessus-update-plugins -v ./basomail_overflow.nasl ./batalla_server_overflow.nasl ./baytech_rpc3_telnetd_auth_bypass.nasl ./bb-hist.nasl ./bb-hostsvc.nasl ./bblog_0_7_4.nasl ./bblog_sql_inject.nasl ./bboard.nasl 

Note 

Many Nessus plug-ins, like Nessus itself, are open-source. The Nessus.org web site provides free registration for access to the latest plug-ins. Without registration, plug-ins created by Tenable (the commercial venture behind Nessus) won't be downloaded until seven days after their initial release. Such hyper- vigilance isn't necessary for everyone.

Summary

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. Perhaps the biggest drawback to Nessus is that it doesn't yet support a database infrastructure for storing, tracking, and resolving vulnerabilities. There is a large development group behind Nessus, however, and these aspects are being worked on.