vscweb-devel Mailing List for Vulnerability Scanning Cluster (Page 17)
Brought to you by:
cirrusrex
You can subscribe to this list here.
2004 |
Jan
|
Feb
(4) |
Mar
(9) |
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(1) |
Feb
(14) |
Mar
(18) |
Apr
(43) |
May
(108) |
Jun
(22) |
Jul
(18) |
Aug
(36) |
Sep
(14) |
Oct
(11) |
Nov
(5) |
Dec
(2) |
2006 |
Jan
(6) |
Feb
(6) |
Mar
(3) |
Apr
(28) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(5) |
Jul
(4) |
Aug
(6) |
Sep
(10) |
Oct
(8) |
Nov
(27) |
Dec
(39) |
2009 |
Jan
(10) |
Feb
(12) |
Mar
(10) |
Apr
(18) |
May
(37) |
Jun
(17) |
Jul
(30) |
Aug
(9) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(10) |
2010 |
Jan
(7) |
Feb
(6) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
From: Matt W. <wi...@pu...> - 2004-02-29 18:56:29
|
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. More on this monday. -matt -- Matthew Wirges IT Security and Policy Analyst Purdue University - Security and Policy wi...@pu... :: (765)49-62307 |
From: Matt W. <wi...@pu...> - 2004-02-26 03:21:24
|
Brent, I've wasted a bunch of time trying to work on putting something together without success, no matter what I did, I always got absolutely *jack* from the nessusd server after I sent "< NTP/1.2 >". Then, I finally came across this: Net::Nessus::ScanLite it works and uses the IO::Socket::SSL, which is amazingly simple. We can either, based on this, write our own interface, or use this module itself to perform our scans. Unfortunately, you can't add the module to the server via cpan because it requires perl 5.8.0 and Woody (Stable) doesn't have perl 5.8. However, I grabbed the source to the module myself, removed the perl 5.8 requirement and installed all of the dependencies and it seems to work fine. If you get a chance, please give it a look. I've added a tests directory to the daemon/ dir of the cvstree, which has a test script for the ScanLite module. I've also added "Net/Nessus/ScanLite.pm" to the cvs repository as well. To update it, just cd into the vsc/daemon dir and type 'cvs update -d'. -matt |
From: Matt W. <wi...@pu...> - 2004-02-23 14:25:34
|
Brent and I had a discussion about the new scan queue that we need to implement for the 2.0 version of the VSC. From our discussion, I've wrote up some information about the existing scan queue, and then I wrote up some information on what I would like to see out of the new queue. The posts can be found here: Background on the old queue: http://bitwarehouse.com/bloq/index.php?type=archiv&post=200402#prispevek6 Thoughts for the new queue: http://bitwarehouse.com/bloq/index.php?type=archiv&post=200402#prispevek7 -matt -- Matthew Wirges IT Security and Policy Analyst Security and Policy Information Technology at Purdue wi...@pu... :: (765)49-62307 www.itap.purdue.edu/security |
From: Matt W. <wi...@mo...> - 2004-02-12 19:06:29
|
Yet another test message. |