Nessus Tutorial

Materials are Collected from Internet and Edited by Dijiang Huang Feb. 2008 It's time that you learn how to use Nessus! (Downloadable from http://www.nessus.org/nessus/) This free tool offers a surprisingly robust feature set and is widely supported among the information security community. It doesn't take long between the discovery of a new vulnerability and the posting of an updated script for Nessus to detect it. In fact, Nessus takes advantage of the Common Vulnerabilities and Exposures architecture that facilitates easy cross-linking between compliant security tools. The Nessus tool works a little differently than other scanners. Rather than purporting to offer a single, all-encompassing vulnerability database that gets updated regularly, Nessus supports the Nessus Attack Scripting Language (NASL), which allows security professionals to use a simple language to describe individual attacks. Nessus administrators then simply include the NASL descriptions of all desired vulnerabilities to develop their own customized scans. Nessus uses a modular architecture consisting of centralized servers that conduct scanning and remote clients that allow for administrator interaction. The Nessus server is currently available for Unix, Linux and FreeBSD. The client is available for any Unix- or Windows-based operating system. It's important to note that the fact that the server is Unix-based doesn't limit the extent of the systems that may be scanned. NASL descriptions exist for a large number of Windows vulnerabilities, and the tool is extremely powerful for use even within a Windows-only environment.

How to install and configure Nessus

Nessus is a member of the family of security tools known as vulnerability scanners. As the name implies, these products scan the network for potential security risks and provide detailed reporting that enables you to remediate gaps in your security posture. These scans run using a client/server architecture. You can go nessus.org to download redhat RPMs. Once you've completed the installation, you need to complete three steps to get up and running: 1. Start the Nessus scan server by running the command "nessusd&" 2. Add a Nessus user to your system by executing "nessus adduser" 3. Start the Nessus client and explore away!

If you'd like to run the Nessus client on a system other than the one you installed the server on, you're free to do so. You may download the NessusClient GUI for Unix systems or the NessusWX client for Windows systems from the Nessus download page. Once you've installed your client, simply point it at the IP address of your Nessus server and connect using the username and password you created in step two above. The Nessus project began as an open-source community project more than seven years ago. While the basic Unix/Linux scanner is still freely available, many elements of the Nessus line are going commercial. Tenable Security, the current custodians of Nessus, also produce NeWT, a Windows version that uses the wizard-based installation and GUI familiar to Windows users. A free version (limited to scanning hosts on the same Class C subnet as the scanning system) is available for download from Tenable. One last word of wisdom: the Nessus plug-ins (the scripts that provide the scanning functionality of Nessus) change frequently. Be sure to update your plug-ins from the official site on a regular basis using the "nessus-update-plugins" command on the Nessus server. Our next tip will explore using Nessus to conduct vulnerability scans, and we'll wrap up the series with a look at deploying Nessus as part of an enterprise vulnerability scanning program.

How to run a Nessus system scan

In our previous tip in this series on using Nessus in the enterprise, we detailed the process of downloading and installing Nessus on the platform of your choice. Now that you've got it up and running, we'll examine how to use this powerful open source vulnerability scanner to monitor systems for security issues. We'll assume that you're using the Unix Nessus GUI, but the commands are quite similar for those using NessusWX (for Windows). First, start the Nessus client by issuing the "nessus" command. You'll be presented with the window shown below:

The top portion of this window allows you to specify the Nessus server that you'd like to use to originate the scan. If you're running the client and server on the same host, keep the default settings. Otherwise, you'll need to enter the appropriate hostname and port. The lower portion of the window requires that you enter the appropriate Nessus credentials to begin the scan. It's important to remember that these are separate and distinct from system login credentials and must be created using the nessus-adduser command. After entering this information, click the "Log in" button to authenticate to the Nessus server. Next, we'll take a look at the Scan Options tab, shown below:

This tab contains several important options. First, the "Port range" textbox allows you to enter the specific ports that you'd like to scan. If you leave this set to "default," it will scan all of the destination ports contained within the nessus-services file. Otherwise, you may specify ports using ranges (e.g. "1-1024") and/or comma-delimited lists (e.g. "80, 443, 8080"). The other important option contained on this tab is the "Safe checks" box. Checking this box ensures that Nessus only runs plug-ins designated by their developers as "nondangerous." If you're running a scan against a production system, it's critical that you check this box, as the unsafe plug-ins could cause an unintentional denial of service on the target system. (On the other hand, if you can do it, so can the bad guys!) Next, let's move on to the Target tab, shown below:

You may use this tab to select either a single system or a comma-delimited list. Alternatively, you may read a list of hosts from a text file using the "Read file" button or attempt to perform a DNS zone transfer to obtain all of the hostnames in a domain by checking the "Perform a DNS zone transfer" box. Once you've set the appropriate options for your scan, click the "Start the scan" button at the bottom of any tab, and you'll be off and running. The system will display the dialog box shown below:

It's important to note that scanning a single system could take several minutes or longer, depending upon the specified scope. When the scan completes, you'll see a full scan report, such as the one shown below:

You may navigate through this report to view the various alerts shown for each system grouped by host, port and severity. That's all there is to it! You now have the basic information you need to conduct vulnerability scans with Nessus.

Nessus: Vulnerability scanning in the enterprise

In the previous two installments of our series on using Nessus in the enterprise, we explored downloading and installing the Nessus vulnerability scanner and conducting system scans. Now that you have these basic procedures under your belt, we'll examine some general advice for building an enterprise scanning program with Nessus. Developing an enterprise scanning program is, by necessity, a highly customized task. You can't simply take a stock plan off the shelf and implement it in your organization. You need to consider the unique technical, regulatory, political and cultural requirements facing your enterprise before launching this inherently intrusive activity. For example, the scanning program used by a research university would necessarily be quite different from that used by an ultra-secret government agency. Both plans would differ

significantly from the scanning plan used by an e-commerce retailer. Let's look at a few broad principles that apply in any large enterprise.

Don't keep scanning secret. Over the course of my career, I've seen many organizations implement vulnerability scanning programs for the first time. With very few exceptions, the security officials responsible for the program decide that the best way to launch this effort is to treat these scans as a tightly-held secret. Invariably, this backfires. The primary reason is political you don't want system administrators to feel that you're policing their configuration management. On the contrary, the goal of your scanning program should be to increase administrator awareness and assist them in the secure configuration of their systems. A scan that produces very few results is a successful scan! Coordinate your scans widely. This advice goes hand-in-hand with the previous tip. In addition to notifying system administrators, make sure that everyone who's even tangentially affected by your scans knows what you're doing. Remember that the scanning process can have unforeseen effects on your infrastructure. You certainly don't want your company to become aware of your new scanning procedures because they brought the network to its knees! Notify system administrators, network engineers, application administrators, management and support personnel of the scans in advance they will serve as an early-warning system if problems arise. This is especially true the first several times you scan systems. Balance the risks and benefits of scanning. Some scans may produce unpredictable results. If you're running scans for vulnerabilities that might produce a denial of service when exploited, the scan itself might induce that denial of service. As a remedy, you may wish to enable the "All but dangerous" option in Nessus for the majority of your routine scans and then perform periodic full scans on a highly coordinated basis. (Don't, however, decide that you'll

never
run the dangerous scans because you're not the only one with a copy of Nessus the bad guys also have it!)

Provide a self-service option. If possible, allow administrators to initiate scans on their own. With Nessus, you can simply create accounts for them using the nessus-adduser command. You can also create rules that limit the systems that individual users may scan. For example, if an administrator is only responsible for the 192.168.53.x subnet and the individual server 192.168.22.13, you might use the following rules to limit the access for that user:
accept 192.168.53.0/24 accept 192.168.22.13 default deny

Allowing users to initiate their own scans lets them go above and beyond your enterprise scanning program. For example, administrators might want to self-

initiate scans at various points during the system build process or after making configuration changes on a system. Hopefully, these tips gave you some good general advice on incorporating Nessus into your enterprise security architecture. In the final installment of this series, we'll take a look at building reports using Nessus output.

Nessus: Managing data

If you've been following along in our series on Nessus, you've now learned how to install and configure Nessus, use the vulnerability scanner and incorporate it into your enterprise. If you're like most security practitioners, you're probably now facing a mountain of data, have no time to read through it and are wondering whether using Nessus is really practical for your complex environment. Rest assured there are methods to save you from this madness! In this tip, we'll explore three techniques that may help you get the most out of Nessus and manage the data produced by this valuable tool. We'll look at manipulating output files, parsing data with Perl scripts and creating a Nessus database. Perhaps the most straightforward way of handling these reports is to simply manipulate the output files that Nessus produces after each scan. One straightforward way of doing this is to use the Unix diff command to compare two output files from different scans. Before doing this, you'll want to first process them into a more readable format. You can take a raw .nbe file and process it using the following commands:
nessus -i example.nbe -o example.nsr

This converts the file into a less verbose format that excludes timestamps and other less relevant data. Once you have these, you'll want to sort the output to facilitate the diff:
sort example.nsr > sorted.nsr

Then, run the diff command on the sorted output files as follows:
diff older_sorted.nsr newer_sorted.nsr

Working with these files can be a bit cumbersome, but this is a good quick-and-dirty approach to comparing Nessus output files. Scripting in Perl allows you to automate some of these functions. While you could certainly use any scripting language to perform the type of raw-text manipulation described above, choosing Perl allows you to access some powerful library modules through the Comprehensive Perl Archive Network (CPAN) (http://www.cpan.org).

Chief among these is the Parse::Nessus::NBE module, which allows you to quickly perform text processing of NBE output files without writing tedious parsing code. The module may be installed using the following CPAN command:
install Parse::Nessus::NBE

Once you have it installed, you may make use of the following predefined functions in your Perl code by including the statement use Parse::Nessus::NBE in your header:

nbanners(@input) returns a list of welcome banners for each system included in the input data while nos(@input) provides a list of operating systems nports(@input, $port) returns a list of all hosts listening on the specified port. nwebdirs(@input) returns two lists: the first contains all open access Web directories while the second contains those that require authentication nnfs(@input) returns a list of NFS shares

Other functions in the module allow you to query by plug-in ID, return a summary count of hosts by operating system and/or service, and provide a summary count by vulnerability. Creating a Nessus database is the obvious extension to this effort. Once you have Perl scripts that effectively parse the NBE files, you may wish to consider writing the results to a database using Perl's DBI module. If you store historical records of scan results, you'll soon have a treasure trove of vulnerability data combined with the flexibility of SQL queries. This tip should have you well on your way toward developing a Nessus reporting infrastructure for your organization. The key principle is to be creative! Nessus provides a great deal of raw information that's yours for the taking. Parse, store and manipulate it however you wish to achieve your information security objectives.

Simplifying Nessus security scans with a spreadsheet model

Let's face it; unless you have a 10-node test network, running a full network scan is a sure-fire recipe for crashing systems and dragging performance. I have seen a Nessus scan cause an entire QA subnet to grind to a halt due to open connections that exhausted server memory. You can avoid this scenario by dividing networks into small, manageable IP spaces and maintaining data in a spreadsheet. This approach allows for more intelligent scanning, even when using common off-the-shelf or open source tools that lack heavy enterprise management features.

Required Tools You will need a spreadsheet program such as Microsoft Excel or OpenOffice (openoffice.org). For scanning tools you may use your commercial scanner, or download Nessus (nessus.org) and NMAP (insecure.org). Step one: Collect inventory Create a spreadsheet that lists all the systems you manage and the following columns: Systems Internal External Host FQDN OS Version Purpose Type System Criticality Managed IP Address Name Owner Address

So it might have a record set like the following: Systems Internal External Host FQDN OS VersionPurpose Type Managed IP Address Name Address (System) 192.168. 65.214.43 web0 www.i LINUX 2.4.2 Public Server 1.23 .37 2 nfosec Webserv mag.co er m System Critica Owner lity MIS Group High

Completing the initial inventory of your network will take some doing, and it may require an overnight scan to cover the entire network. However, once you have the inventory you won't need to resort to mega scans for a long time. If you have an inventory of your network already, then you can jump to step two. For large networks it's best to start with an NMAP or Nessus scan to collect the host names and related information. The owners and purpose data will take some time to populate, but this data may be gathered over time. Once you unplug a highly vulnerable system on the network, the owner usually becomes apparent very quickly. At the very least, define the IP addresses, host name, FQDN if known and OS information on systems attached to the network. Import existing data to the spreadsheet or run a scan and dump the information out as comma separated values. Step two: System classification

The next step is to categorize the host list in the spreadsheet by OS, logical and physical locations. Depending on what your network looks like and who uses it, this may vary. For example, I can divide my networks into Boston and New York locations. For Boston, I can subdivide the address space into /24 networks, and the servers on one floor can be separated from the rest of the workstations. Generally, I recommend that you use the worksheet's sort function to organize the data by criticality, then by purpose. This way, production Web servers, less important desktops and R&D systems are separated even if they reside on the same /24 network. The next major classification would be the OS and version. Such a classification would have a breakdown of the production and QA Web servers, desktops and development systems by OS and version. This is beneficial when a security vulnerability targeting a specific OS and version is announced. You can quickly determine which systems are vulnerable, and the criticality of the system can drive your patching order. You can organize the data anyway that meets your particular security needs. These are just some helpful choices I have seen work well in the real world. Also, by having your production systems called out, you can take the proper precautions in running your scans as to avoid outages. You may also extend the spreadsheet with other fields as you please. Step three: Scanning With your systems list broken down into manageable segments, the next step is to set up your scan jobs. In Nessus, I generally name new scan jobs with the same names used in the spreadsheet. For example, I may have a job named "Production Web servers" that contains the entire list of IP addresses from the relevant server grouping in the spreadsheet, or a job named "New York Desktops," again using the same labels used in the spreadsheet. This approach provides a simplified dashboard-like interface that makes it easier to target specific environments when setting up jobs. Coordinating job names offers you the benefit of improved performance, because it minimizes the number of plugins used by the scanner to only those needed for a specific platform. In the above example, I have a list of production Web servers. If they all are Linux-based, then my plugin selection can be limited to a handful of platform-specific issues. There's no reason to waste network bandwidth scanning for the latest Windows vulnerability when you have a Linux Web server. Most scanning tools will accept a list of session profiles as described above. If you are using a tool other than Nessus, check your product documentation for details on how to set up your particular scanner to accept profiles that define a scan session. If you are using port scanners like Nessus, then it's best to break up your target files into simple tab-delimited text files. For example, I can cut and paste or export the Web servers list to a text file for use by NMAP. NMAP has a flag whereby an external file can be used to enumerate hosts for scanning. The following text is from the NMAP MAN page:

-iL <inputfilename> Reads target specifications from the file specified RATHER than from the command line. The file should contain a list of host or network expressions separated by spaces, tabs, or newlines. Use a hyphen (-) as inputfilename if you want nmap to read host expressions from stdin.. It's useful to have both the NMAP and the full-blown scanner working side-by-side. The recent W32/NetSky-Z worm, for example, opened a backdoor listening on TCP port 665. If I only used my preset scan jobs I would need to scan all Windows subnets for the worm, but because I had my NMAP host files configured I was able to execute three commands and use the port flag to only scan for 665. The scans were done in less than 15 minutes. Building a spreadsheet to divide your network into manageable IP spaces may take some time. However, the result is worth the initial investment when you find you have a powerful vulnerability management system at your fingertips.

Nessus vulnerability assessment with the SANS Top 20

Eliminating exposures that give unauthorized system or root access to vulnerable hosts is an arduous task. Fortunately, the annual SANS Top 20 classifies most of these dangerous holes for both Windows and Unix, and prescribes best practices for patching and remediation. Universal support of the list by high-level incident response teams from the UK and Canada and members of the Information Systems Security Association has also led to the development of numerous open source and commercial detection tools. Many of these tools, including Nessus, are recommended on the SANS Top 20 for finding vulnerabilities. The SANS Top 20 arranges vulnerabilities into 10 classes for each platform with categories of vulnerabilities within them. For instance, Windows classes target issues with Web servers, remote access services, file sharing applications and LSAS exposures. Unix classes cover Web servers, mail transport service, simple network management protocol, databases and kernel vulnerabilities. The list specifies which vulnerability detection tools are best used for particular Windows and Unix vulnerability classes. Nessus, for example, is recommended for the Web server vulnerability class. In fact it's promoted for four Windows and five Unix classes, so using Nessus is a huge benefit since it crosses over the greatest number of classes. As an open source tool, Nessus has been widely used since 1998 for doing vulnerability assessments. It can scan a network and find specific vulnerabilities, such as PHP, IIS and Apache buffer overflows as listed for the Windows Web server class. Nessus currently

detects vulnerabilities via a range of more than 6,000 plug-ins, where each looks for a single vulnerability. Nessus conducts its vulnerability assessment in a four or five step process (depending on whether denial-of-service tests are conducted). First it determines whether the scanned host is alive. It then conducts a port scan to determine what services are available. It scans each service to identify the software version running, then uses this information to determine what specific vulnerabilities to test -- that is, which plug-ins to call. It conducts the vulnerability test using the required plug-in set. Then if DoS testing is selected Nessus will conduct this sequence last, as it may take the host offline. After scanning, Nessus provides a prioritized report of the SANS Top 20 vulnerabilities that were discovered. However, like many pure-play vulnerability scanning tools, Nessus doesn't offer remediation capabilities. It merely provides links to the Common Vulnerability and Exposure list entries for the potential problems it finds. You'll need to refer to the SANS Top 20 list for links to the various vendor sites for patch remediation. Nessus is a medium-difficulty tool to use since it requires a Linux workstation and knowledge of the Linux command line to install, configure, update the plug-in list and start the Nessus server daemon. Nessus client(s) can either be Linux- or Windows-based. You can have many clients attached to one server, and for testing a global network this may be preferable. (Note: Understanding the complexities of Nessus takes time. A new book by Syngress Publishing, Nessus Network Auditing is a valuable reference that comprehensively explains the tool's range of use). Other tools promoted by the SANS Top 20 include L0phtCrack's LC5 password-auditing tool, open source Snort, eEye Digital Security Retina scanner (a direct competitor to Nessus), which uses a streamlined detection algorithm that's well known for detecting potential vulnerabilities. Foundstone Enterprise and Qualys Guard vulnerability scanners are also recommended and offer similar functionality. In my humble opinion, the Nessus tool gives me 95% of the value for free -- providing that you're willing to wait the required seven days to get the plug-in updates. Tenable Network Security now charges for its "Direct Feed" of the latest and greatest plug-ins, however as an open source tool, user created plug-ins or plug-ins created under a GPL remain free to all. Some tools work well in tandem. For example, a Snort system can monitor for attacks on vulnerabilities discovered on the specific hosts scanned by Nessus. The administrator reads the Nessus report and then sets up Snort to look for those specific vulnerabilities, though it's a highly manual process. While a powerful tool, Snort is resource intensive, requiring manpower for viewing logs and assessing possible attack sequences. The SANS Top 20 list completes each vulnerability class description by offering best practices to use in remediation. Software updates (patches) are typically recommended, and security pros are advised to go back to the software vendor to retrieve the latest updates. The list also gives general best practice information, such as setting a proper password length and how often it should be changed.

The purpose of the SANS Top 20 report is to list the most serious vulnerability classes for Windows and Unix and then offer general guidelines on detection and remediation. If you have the right skill set in-house, the SANS Top 20 paired with recommended open source detection tools and suggested remediation offers an effective strategy for strengthening network security.