I'm kind of looking for an in between solution as well. I can edit the .nessurc by hand, but I should be able to generate a new nessus rc with the CLI client. It should read my existing resource file, connect to the server, and add new plugins and options with default values. The resulting .nessurc should be my defaults with any new plugins and options included.
It might make sense to allow a switch to set some basic defaults. For example --enable_new_plugins or --disable_new_plugins. I have also wanted to look at the features available in the GUI and ensure that they are available in the CLI. Like uploading of nmap results, and all of the knowlege base features. These things may all be their now; I haven't looked recently. I liked some of the early suggestions like: nessus --generate_config -c output_file host port user pass > new_config_file The interface to select plugins and interact with the server would be nice, but seems like initially that's more then is needed. Dion > -----Original Message----- > From: Jay [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 06, 2002 5:24 PM > To: [EMAIL PROTECTED] > Subject: Re: .nessusrc Plugins > > > > On Wed, 6 Feb 2002, Renaud Deraison wrote: > > > Ok. I'll do it myself. Once again, would a shell-like > interface be ok ? > > > That would be great, but I think it is probably overkill. The > issue (for > me anyway) isn't that I *can't* run the GUI client to manually select > plugins. I can do that no problem at all. > > The real issue is that as the plugins on the server change, > the .nessusrc > file generated manually (either by the GUI or the CLI if that was > available) becomes very outdated very quickly. This means that for > unattended scans (i.e., from cron daily) I would have to > launch the GUI > *every day* to re-generate a new .nessusrc file to > incorporate that day's > plugin changes. > > Thus, the issue is really keeping the .nessusrc file > up-to-date with the > plugins on the server. From the server-side, this is automated with > nessus-update-plugins. However, on the client side, this > requires daily > manual GUI runs to re-create updated .nessusrc files. > > I think an easier way to "fix" this problem would be to allow > plugins to > be specified by family in the .nessusrc file. For example, > today it looks > like: > > > begin(PLUGIN_SET) > Services = yes > OpenSSH < 3.0.1 = no > FreeBSD 4.1.1 Finger = yes > ... (continuing on with a static list for every plugin) > end(PLUGIN_SET) > > > I am suggesting that the .nessusrc files should optionally accept > something like: > > > begin(PLUGIN_SET) > Backdoors Family = yes > CGI abuses Family = yes > Denial of Service Family = no > Finger abuses Family = yes > ... (continuing on with a line for every FAMILY instead of > every plugin) > end(PLUGIN_SET) > > > Thus, a "yes" would indicate to use ALL the plugins in that > family (even > the "dangerous" ones), while a "no" would indicate to use NONE of the > plugins in that family. > > I realize this is not as granular as specifying each > individual plugin, so > I would recommend something like this be an optional config > syntax - not > totally replacing the current syntax. This would then allow > the .nessusrc > file to *always* be up-to-date with the plugins on the server > (except when > a new family is added, but how often does that happen?). > > I'm still curious how other people are solving this issue. I > can't believe > (or maybe I'm just in denail :) that everyone is running the > GUI *every > day* to re-generate a new up-to-date .nessusrc file. :) > > ~Jay > > > > > > > Imagine the following, is that ok ? > > > > nessus -i localhost 1241 renaud password > > nessus> ls > > [ ] Denial of Service > > [ ] Windows > > [ ] Blah > > nessus> select * > > [X] Denial of Service > > [X] Windows > > [X] Blah > > nessus> cd Blah > > nessus/Blah> ls > > [X] Foo > > [X] Bar > > nessus> deselect Bar > > nessus> ls > > [X] Foo > > [X] Bar > > -- Renaud > > > > -- > ~Jay > > > >
