Using a Custom Inventory Script to Gather the Installed Version of Tenable (Nessus and/or Splunk) Agents
search cancel

Using a Custom Inventory Script to Gather the Installed Version of Tenable (Nessus and/or Splunk) Agents

book

Article ID: 405906

calendar_today

Updated On:

Products

Inventory Solution

Issue/Introduction

Some of the Tenable Agents, like Nessus and/or Splunk are not returning the current version.

For example:

The Tenable Nessus Agent is scanned and reported back to the SMP server with the name of NessusAgent.Preferences 0 and no version.  When reviewing the installed application on the Mac OS computer, the actual installed version is displayed properly.  For example, 10.9.0.

 

Similar issue can be noticed with Splunk: no returned installed version. Splunk 9.4.4 is installed, but the version is not being returned by inventory. 

Same thing thing can be noticed if you go to that MacOS machine under Manage>Computers and then look at the "Software" section

Environment

Inventory Solution 8.x
MacOS client machine

Cause

Both products are from Tenable. The vendor application needs to be corrected

Resolution

This is not caused by a fault in the Broadcom Inventory Solution product, but rather by how the vendor packages this application.  This would need to be reported to the vendor, and they would need to provide proper data in their own *.pkg file so users would be able to properly identify the installed software and its version.

Thankfully, Inventory Solution has the capability for you to use a custom inventory script to gather this data. 

 

Nessus Scenario

Here is a breakdown of how to accomplish this using a basic script. 
NOTE: This script is not supported by Broadcom support and is provided as is for an example.

Create the custom data class (SQL table) that will be used to store this data.  In the SMP console, navigate to Settings and then All Settings. Expand Discovery and Inventory, and then expand the folder inventory solution.  Now click on Manage Custom Data Classes.  Click on the new data class.  For the name, enter Nessus_Version.  For the attribute, enter:  version.  The data type should be set to Unicode String, the Size to 50, and No for key and required.  The following screenshot illustrates how this should look:

Don't forget to click on Save changes towards the bottom of the page to save the new custom data class.  This will also create a new table in the SQL database called Inv_Nessus_Version.

The next step is to create the script task that will execute against your Apple Mac OS X clients.

Click on Manage and then on Jobs and Tasks.

Right-click on any folder of your choosing and choose New Task.  In the Create New Task window, select Run Script

Give the task a name of your choosing

For the Script Type drop-down, choose UNIX Script

Leave the Insert token drop-down default

Now copy the following script into the run script task:

. `aex-helper info path -s INVENTORY`/lib/helpers/custominv_inc.sh

# SCRIPT_BEGINS_HERE

#!/bin/sh
echo Nessus_Version
echo 'Delimiters="|"'
echo string50
echo version

if [ -x /Library/Nessus/run/sbin/nessuscli ]; then
/Library/Nessus/run/sbin/nessuscli -v | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'
fi

You may wish to click on the Advanced button and change the show script drop-down to say Hidden.

Make sure to save changes to create the run script task.

The last thing to do would be to verify the path of the software on a Mac OS X computer.  From the terminal, you can run the following command:  

sudo /Library/NessusAgent/run/sbin/nessuscli -v

OR

sudo /Library/Nessus/run/sbin/nessuscli -v

 Notice that the path, when tested, could be either of the paths displayed above.  The script sample uses /Library/Nessus/run/sbin/nessuscli.  If you find it under /Library/NessusAgent/run/sbin/nessuscli then change the path location in the script where it's listed.

After running this script against a test computer, you should see results in the SQL database table:

Once you validate this, you can proceed to build a report to show you the installed version.

 

 

Splunk scenario:

You can follow the same recommendations as mentioned above but adjust your script to match Splunk paths.

You want your custom inventory script (custominv_inc.sh) to detect and return the Splunk version, similar to how you’re doing with nessuscli.

Splunk ships with a binary called splunk (usually under /opt/splunk/bin/splunk), and you can query the version with:

 
/opt/splunk/bin/splunk version

That prints something like:

Splunk 9.2.0.1 (build a1234567890)

So in your script, you’d parse it just like you did with Nessus. Here’s how you can structure the if statement:

 

#!/bin/sh
echo Splunk_Version
echo 'Delimiters="|"'
echo string50
echo version

if [ -x /opt/splunk/bin/splunk ]; then
    /opt/splunk/bin/splunk version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?'
fi

 

Explanation:

  • -x /opt/splunk/bin/splunk → checks if the Splunk binary exists and is executable.

  • splunk version → prints version info.

  • grep -oE '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' → extracts only the version number (e.g. 9.2.0.1).

If your Splunk installation is in a different directory (sometimes /opt/splunkforwarder/bin/splunk for universal forwarder), just adjust the path in the if check.

 

 

Here’s a version that will auto-detect Splunk Enterprise or Splunk Forwarder and return the version:

#!/bin/sh
echo Splunk_Version
echo 'Delimiters="|"'
echo string50
echo version
if [ -x /opt/splunk/bin/splunk ]; then
    /opt/splunk/bin/splunk version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?'
elif [ -x /opt/splunkforwarder/bin/splunk ]; then
    /opt/splunkforwarder/bin/splunk version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?'
fi