Hi Scott,
On Jun 18, 2008, at 5:07 PM, Scott Pate wrote:
Thanks Renaud,
I understand documentation is difficult, but I have to say it's
frustrating when certains features are added or removed with little
or no documentation. For instance, the KB. It has been my practice
to use the KB and it's functionality when re-running a scan, such as
"don't scan hosts already scanned", or "don't re-run port
scanners"....I also know that when you use the nasl command to run
individual plugins, some of them depend on information from the KB
and they will not run if you have not saved the KB. So when these
options no longer exist in the new client, it leaves me to wonder
how this change affects the funtionality of the scanner, and how
that will impact my scans.
KB saving is still there and exposed (and can be re-used in command-
line nasl with the -k switch).
Once again, we try to document everything, but in this particular case
what you really want is not so much documentation vs. documenting
what's different in the new re-written client compared to the older
one, which is a much more difficult exercise.
Also, with regard to "optimize tests", when this functionality is
removed, how does that affect the scan as well? Do I know that the
functionality of un-checking this box still extists? Where is this
documented?
"optimize tests" is still there on the server side, but not exposed in
the client. You can still control this by editing nessusd.conf or
your .nessus files directly.
Why did we remove it ? Because it does not do what most people think
it does. This option was added in 2001 (I believe) and should never
have been exposed, as it as more to do with the inner workings of
nessusd (likewise, you do not have a checkbox telling nessusd not to
re-order plugins based on their dependencies - it's just there).
I also noticed the addition of the "Probe services on every port"
option which to me sounds familiar to what "optimze tests" used to do.
"Optimize the test" has never been similar to this option. What
"optimize the tests" does is that plugins have an API where there
expose their run requirements to nessusd -- ie: they want port 80 OR
Services/www to be open (or to be in an unknown state). Or they want
registry access, etc... If you disable this option, you get to force
plugins to run in spite of missing requirements, and you basically
obtain the same result (the plugin exits quicky) although you spent a
lot of CPU cycles and network traffic for nothing.
The description for this option is that nessus will attempt to
"match each open port with the service that is running on that
port". So does this mean every port that was scanned, or every
port that is open? and If I don't have this checked, does this mean
nessus will not try to identify services on all ports? What services
will it try to identify? What exactly does "All" ports mean? All
65535 ports or just ports that are specified in the port scanner, or
just ports that are open?
This option means that we're going to identify the list of services
running on every port we found to be open. If the list of open ports
was obtained via a TCP scanner, then that list of ports will
(obviously) be in the port range specified. If it was possible to log
into the remote host via SSH and obtain the list of ports via netstat,
or to get it via SNMP, then that means "all" open ports.
I have learned through experience that documentation on nessus,
while helpful, does not address all, nor some of the more advanced
features of nessus. There are obviously many many options that can
be set, and I have taught myself through many hours of trial and
error what exactly each option does and how it affects the scan.
Particularly when you are dealing with multiple options that seem
related. For instance, I learned (alteast with the older nessus
client) that if you disable "ping host" in the general tab, but
still leave "tcp ping" enabled in global options, that nessus will
still try to ping the host.
The problem is that we're trying to make Nessus evolve quickly, even
between two releases (due to updates in the plugins which can add/
remove options). We try to document that but sometimes there's a crack
in the process. Fortunately, we're staffing up our research team so in
the future you should see better and more up-to-date documentation.
There are also helpful KB articles available on our support portal and
we hope to deploy a wiki "soon", which should also help.
And if everything else fails, you can always hit the nessus list or
ask your questions to me directly.
Thanks,
-- Renaud
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
