Deploying Nessus Tenable….

I recently had the pleasure of setting up a deployment of Nessus Tenable for a client. Clearly I don’t mean pleasure or I wouldn’t be writing about it.

My first though was why would anyone want to deploy Warwick Davis?

Turns out it’s a different Tenable so here’s my way take on it.

It’s just a package in a DMG, should be easy!

So you download the installer DMG, check the SHA256 checksum and all is cool… so far so good.

Mount the DMG then check the PKG contained in it with Suspicious Package.

Again this all looks good.

So let’s drag the package out and test it works…

I deployed it with Jamf and found this in the logs;

installation failed. The installer reported: installer: Package name is Tenable Nessus Agent
installer: Certificate used to sign package is not trusted. Use --allow Untrusted to overwrite.

So digging deeper I ran Suspicious Package against the package dragged out…

So what’s going on here?

A quick search revealed some posts on Jamf Nation here and here. The first explains it all and the second has a lot of useful info. Turns out he actual PKG is a hidden file on the DMG!

So following the post copied out the actual package

cp /Volumes/Nessus\ Agent\ Install/.NessusAgent.pkg ~/Downloads/Install\ Nessus\ Agent_<version number>.pkg

and everything installs fine.

Quite why a vendor chooses to use this method of packaging a PKG is the question of the week/month/year!

Let’s get this deployed!

I wanted to get this deployed but also wanted to make a reusable method so I started with a deployment script because it is required to pass some parameters after installing to register with the cloud based console.

My client had four parameters, but looking at other posts a lot only have three.

NameContains
Group (opt)group to place device in e.g. Mac
Keylicense key
Hostcloud URL
Port443 most probably

So in Jamf these can be set as script variables allowing more than one configuration to be used in differing policies for different client groups or organisations.

The script is a simple one and has to be run after the package is installed;

#!/bin/sh
/Library/NessusAgent/run/sbin/nessuscli agent link --groups="$4" --key="$5" --host="$6" --port="$7"
exit 0

Let’s keep an eye on it

It’s always good to know what state your fleet is at so I used the EA in the second article and it worked but returned some extra characters; so I wrote my own based upon it which returns, based on current Tenableversion, only the version number, e.g. 8.0.0

#!/bin/sh
# Check to see if Nessus Agent is installed
if [ -e /Library/NessusAgent/run/sbin/nessuscli ]; then
 NessusAgentVersion=$(/Library/NessusAgent/run/sbin/nessuscli -v | awk 'NR==1{print $4}' | sed 's/^ //')
 echo "<result>$NessusAgentVersion</result>"
 else
 echo "<result>Not installed</result>"
fi

And that’s it in a nutshell. As mentioned in the second article there may be more things to consider but for what I needed, install, register and report, this is all that is required.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s