Nessus is one of those tools that is both wonderful and, at times, wonderfully frustrating.
I recently ran into a situation where I wanted to run a Nessus vulnerability test against a service running on a non-standard port. Quite a few of Nessus’ bundled plugins use hard-coded ports. Rather than just copying the plugin and making a second version with the custom port number, I thought that it would be fun to build a Preferences screen for the plugin. This would allow me to scan for the service on multiple different ports using a scan Policy per port.
It turned out to not be too difficult, but required reading the NASL documentation as well as looking at some existing plugins with port settings. Hopefully this write-up will save you some time doing this on your own.
First, Nessus needs to be configured to allow unsigned plugins. On Backtrack, you will have to edit /opt/nessus/etc/nessus/nessusd.conf , and change the line that starts “nasl_no_signature_check = “. Set it to ‘yes’.
Then, make a copy of the plugin that you want to customize. Nessus plugins are stored in /opt/nessus/lib/nessus/plugins/ . I just call it <originalName>2.nasl. In my example, I am customizing a copy of the Oracle Glassfish TRACE method authentication bypass plugin. So I make a copy and call it “glassfish_trace_auth_bypass2.nasl”.
Now it is time to edit the new plugin. This new plugin needs a unique ID. I start my custom plugins to begin with id number 99001 and count up. I have seen various tutorials (even ones from Tenable) suggesting the use of plugin IDs in the 50000-60000 range, however these IDs are now being used by Tenable’s signed plugins. So go high. Change the script_id() call to use whatever number you come up with. It is wise to change the script_name() and script_summary() calls to reflect that this is a modified plugin, and so that you can more easily find it in Nessus.