Creating Custom Reports With Nessus 4

XSLT Reporting

A new feature in Nessus 4 is the ability to use XSLT stylesheets to create custom reports. The stylesheets read the .nessus XML file and allow you to create a number of different report styles, such as HTML and CSV, as well as extract or sort specific data from the scan results. Nessus 4 comes with several built-in stylesheets that can sort results and display a report based on several criteria, including:

• Sort By CVE
• Sort By IP Address
• Sort By Port
• Sort By Vulnerability

You can use this feature in conjunction with the report filtering to more easily create custom reports.

Using the Built-In Stylesheets

This feature is especially useful for filtering low priority alerts in scan results that are using audit file checking. Typically, there are many low priority alerts mixed in the results, which can make analyzing a report difficult by taking away from higher priority issues:

The screenshot above shows a scan of one particular host and some example results from a UNIX compliance check. You can select from the default stylesheets using the pull down menu at the bottom. Once you've selected a stylesheet, click the "View template..." button to view the results, which will automatically open in your default web browser. Reports that contain large result sets can be filtered based on user-defined criteria. For example, to restrict the results to display only High alerts, setup a filter as follows:

Now the NessusClient will only display the High alerts in the report output. Next, you can select "Sort By Vulnerability Detail" and then click "View template..."

This will produce an HTML report that only contains the High alerts:

Creating Your Own Customized Reports

Let’s take a look at an example of filtering a large report from a network-based scan. This report contains several hosts with a large amount of scan data. Using the defaults, I can generate a report that will display the vulnerability details as described above:

This report enables you to see each of the plugin IDs that were triggered and click on them to go to a section of the report with more details. However, there is a lot of data to sift through. Additionally, when I pull up the report I only get the plugin IDs in the table at the top (in the left hand column) and the severity level in the right hand column. While I may know a few plugin IDs from memory, I don't have the entire database memorized (shame on me). We can easily fix the first problem by creating a filter to hone in on certain portions of the report:

Rather than just keying in on a particular plugin ID or severity level, I like to add keywords to search the plugin report. This provides a much broader picture of my vulnerabilities and presents a greater chance that I will catch something interesting. In this example I use the keyword "share", to search for open file shares on the network, without limiting myself to a particular type of share. Next I want to modify the report, so I made a copy of the "Sort By Vulnerability Detail" report and place it where the XSL reports are stored in the Nessus data directory. Refer to the table below for the location of the data directory on the supported platforms.

When creating a custom stylesheet, make sure that it has a ".xsl" extension or it will not show up in the NessusClient. Once the stylesheet has been created, restart the NessuClient and it will show up in the stylesheet pull down menu. I edited my stylesheet copy to add the following column to the report template:

I saved my changes, restarted the NessusClient, and ran my report. The above code produced a new column that lists the plugin name in a center column within the "List of vulnerabilities" table:

You can see that we have some interesting results from our search filter. We get to see both SMB and NFS shares that were found readable during the scan. We can click on any of the plugin IDs and it will take us to that section of the report and display the vulnerability details for each host.

Conclusion

The new XSLT reporting function is very flexible and easy to use. The built-in reports, in combination with the filtering feature, provide a quick way to create customized reports in several different formats. XSLT enables interaction with the .nessus XML format so the end user can write and define custom report styles. You can start by modifying some of the existing stylesheets, then move on to creating new ones on your own. Whether you are creating brand new reports or modifying the existing ones, you are encouraged to share your work with the community. If you think that others will benefit from your custom reports please head over to the Nessus discussions forum and feel free to post your work. This is a great way to get feedback on your stylesheets and participate in the community.

Resources

• Nessus 4 Users Guide
• XSLT Tutorial