don at n2
Nov 17, 2004, 11:02 PM
Post #22 of 28
(2561 views)
Permalink
|
Even after the port scan of a system is finished, yes, it can take quite
a bit of time to get through all the scripts. When a lot of systems are
being scanned simultaneously it can put a great load on the CPU. I would
say to concentrate on optimizing CPU, because nessus already has a user
definable settings for max number of IPs to scan, and max number of
scripts to run simultaneously, should the network or memory load be too
great.
I agree a great way to optimize CPU is to run scripts smarter, i.e. not
to run scripts unnecessarily. So I think the optimize setting is great, and
anything that can improve the reliability of the optimization (namely,
running as few things unnecessarily as possible, without skipping anything
that should have been run) will be a good thing.
Since I don't know much about nessus internals I can't speak much to that,
but I can offer the perspective of someone who is able to use nessus on
a wide range of systems, and sees strange results regularly.
In regard to banner collection it seems like a good idea to collect the
banners first, reliably, and then move on to the analysis of that collection,
rather than trying to recollect. If there was a problem collecting, then
either try harder (i.e. quickly send request again, with longer timeouts,
etc) or freeze for a while to ride out whatever problem might be out there
before trying again. (And perhaps nessus automatically tries harder on well
known ports) But I'm in agreement that this is a bad idea to distribute
collection into scripts. At least if the user knows there is "no result" from
the scan, they know to try again later. With "some result", they do not.
Further on that topic, it seems to me that the current plugins are producing
a lot of conflicting results from scripts. A great example is simply knowing
what kind of web server is on a port. One script detects that it's a VNC
HTTP server. Another script says oh yeah, that port is Pi3Web. Or a bunch of
stuff on a CompaqHTTPd. Or IIS findings on a platform another script figured
out was a Unice. The kb/optimization could do a better job of not running
scripts that don't apply. Among those scripts whose job it is to figure out
what kind of platform is, the kb can collect results. The first script to
submit a result (i.e. asserts platform like windows/unice or application
like apache/iis) is presumed to be correct. Any conflicting results (i.e.
unice+iis, iis+apache, apache+other, etc) can be dealt with before the
"worker bee" scripts are launched. The way to deal with it could range
from logging a security_hole of "Not sure what platform" and setting both
kbs, or silently keeping a vote and ignoring vastly outvoted kb settings,
or whatever. Fundamentally, you can't have two different services listening
the same port of the same ip address, and I think stuff related to http
is the majority of conflicting results, so this would be a good way to
not only weed out bad results but also optimize scripts from being run at
all.
I agree that old scripts shouldn't be removed, but one possible input into
the optimization decision could be whether to trust version numbers. There
are two ways to look at version numbers. If version 1.14 is vulnerable and
1.15 is fixed, nessus can trust that if you see 1.14 it's vulnerable
(although frequently wrong because vendors do not see fit to alter the
version numbers in any way to so indicate.) However, it can also trust that
if it sees 1.15, that it's not vulnerable and there's no point in running
the script to test a vulnerability that went away (unless it comes back in
a later version).
(Another option that comes to mind is a firewall/no firewall detected/
known no firewall result, possibly even set by the user if they wish. It's
a waste of time to be told about "holes in the firewall" ala port 53 etc,
when I'm scanning a LAN and not going through a firewall.)
Thanks
|
1
