Remediating A Nessus Agent Connection Issue
Every so often a machine may not check in to Tenable for some time, for some reason.
Whatever the reason may be, we’ve got to get it linked up again, and preferably in a “silent” manner.
Here’s a script to assist with that:
|
|
So how did we get here?
- Let’s focus on the
$group
variable first:
- Nessus includes a robust command line interface when installed, and this particular command allows us to list registration info and log data for this install.
In particular we want the group name. As this is just a re-link, we want to keep the MacBook in the same group. - We can find the group by piping in
grep groups
and get a result like this:
|
|
- Once we’ve got the group, we’ll iterate on that by “grep-ing” for just the group name
|
|
- Now this is fine if we’ve only got one group in the organization, but like many orgs we have many groups.
For example: if we’ve got an admin group, security group, IT group, and creative group; then we’ve got to account for all of them.
This is where the wildcard (*
) will come into play.
So let’s run this command instead:
|
|
- We’ve now isolated the group, and the wildcard will account for machines in other groups.
If we run the command on a creative MacBook, we will receivecreative_group
instead. - We are almost done setting up the variable, but there’s a space before our group name.
This is where the translate (td
) command comes in. So let’s pipe that in there.
|
|
- That final command deletes characters that match the quoted string. In this case, spaces.
Troubleshooting Note: If you forget the space before .*group
, then your output will look like this:
|
|
or this
|
|
- For the next piece of the script we have to un-link the Nessus Agent, or we will receive an error message along the lines of this:
|
|
-
We then put the script to
sleep
for moment while Nessus un-links. -
Finally, we link the Nessus Agent back to our Tenable instance utilizing the group we gathered earlier.
NOTE: If you’re utilizing Tenable’s cloud offering, you can use --cloud
as opposed to having to specify --host
and --port
This script can be run silently, but if you do want to put the onus on the end-user, then you can definitely throw this into Self-Service.
Take it easy y’all.