[vscweb-devel] scan queue nessus client thoughts

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Brent,

   I spent some time playing around with the Net::Nessus::ScanLite and 
started to write my own client (Net::Nessus::FE), however, I think I may 
be wasting a lot of time.  So, after thinking about it abit more, here's 
what I propose (feel free to chime in):

Let's continue writing the scan queue.  You carry on where you are at, 
I'll start writing a package which will have interfaces to the database 
(prolly something like VSC::Scan::Request, VSC::Scan::Results, 
VSC::Scan::Plugins, VSC::Scan::Preferences)  These would all be in 
VSC/Scan.pm which has yet to be added.. Also, there would be a 
VSC::Queue.pm which would have various functions needed by the queue. 
Not sure about this yet, I'll put some thought into it on my drive up to 
Chicago this afternoon.

Now, as far as accessing the ScanLite client, here's what I'm envisioning:

#inside the perl queue
# at this point, we've already decided to scan
# hosts in @host stack and have forked
# other assumptions:
# %_config is a hash we created early on in the queue which has the
#_main and _vsc config values in them
my $n = Net::Nessus::ScanLite->new(
	host     => $_config{nessusd_host},
	port     => $_config{nessusd_port},
	user     => $_config{nessusd_user},
	password => $_config{nessusd_pass},
	ssl      => 1);

my %preferences = $scan->get_preferences_hash($scan_id);
#set preferences in the nessus client
$n->preferences(%preferences);

my @plugins = $scan->get_plugins($scan_id);

#convert array of plugins to "<id>;<id>;<id>" format
my $pl_str = $queue->format_plugins_list(@plugins);
#set plugins for the scan
$n->plugin_set($pl_str);

if ($n->login()) {
   my $hosts = join (",",@hosts);
   $n->attack(@host_ips);
   foreach ($n->info_list) {
     my $info = $_;
     # info plugins are informational and warnings
     # we can grab their data using the following methods
     # to store in the database
     # $info->Host, $info->ScanID, $info->Port, $info->Proto,
     # $info->Description
     # Note: ScanID is the same as PluginID
   }
   foreach ($n->hole_list) {
     my $hole = $_;
     # $hole has the same methods as INFO's
   }
}

#end scan

There are still a lot of questions to be asked, I guess.  How do you 
differentiate an Informational INFO result and a Warning INFO result?
I guess that can be determined by the "severity" attribute.
For example, the plugin 10234 which checks for RPC statd service has a 
severity of "Low" and in Nessus reports it shows up as "Informational", 
however, plugin 11618 is the tcpip_ambiguities test which is listed as 
severity "Medium" and shows up in reports as Warnings.

Also, the NTP 1.1 white paper (which covers NTP 1.1 and 1.2) in the 
nessus-core CVS mentions a "NOTE" type of attack response as well.. In 
my tests with ScanLite, I've not come up across this type of response 
(debugging at the server response level) so I wonder if its actually used.

Finally, I also learned that while a some plugins which are specifically 
for vulnerabilities or "holes" can be run individually.  For example, 
the SSH plugins which check to see that you are running the latest, 
greatest, SSH can be run by themselves yielding a very quick response. 
However, some plugins like the aforementioned "tcpip_ambiguities" plugin 
_must_ have had the nmap TCP connect scan plugin enabled 10335.