Re: dns_fingerprint.nasl - silent exit after 3 timeouts, why?

On Thu, Jul 22, 2004 at 09:04:48PM +0200, Pavel Kankovsky wrote:
> > > I think the most annoying part of this was the fact the plugin exited
> > > silently (and this is a "feature" of many other plugins). I think all
> > > those occurences of exit(0) should be replaced with
> > > exit("unable to open connection") or exit("too many timeouts") etc.
> > > and Nessus should write those messages to its log (and perhaps,
> > > optionally, include them in the report).
> > 
> > We are heading this way thanks to global_settings.inc. I receive too
> > many complaints already of "useless output" (like the service banners),
> > so adding a message per failing plugin is not an option.
> 
> "Not an option" is supposed to mean it won't be available, not even as
> an optional feature for people who would like it?

No. It means that _today_ having a plugin which issues
non-vulnerability related messages in the report (like reporting
connections issues) is not something that everyone wants. Thanks to
global_settings.inc this will become an optional feature in a
not-so-distant future, but it requires a lot of work as you probably
guessed already. And at the same time we have to stay up-to-date
vulnerability-wise, and unfortunately the days in the US have the same
length at those in Europe.

> > Besides, in that particular case we _know_ that not everything can be
> > fingerprinted reliably. Adding an extra message to emphasize this fact
> > is not a good idea.
> 
> But it is still a good idea (in general) to make it possible to figure out
> why the given plugin failed without having to resort to trial and error.
> Detailed error diagnostics helps to find and fix bugs, esp. bugs that are
> hard to reproduce (I am afraid quite a lot of plugin failure falls in this
> category).


Yes - Prefs->Verbose report (or maybe "Report failures") will be your
next new best friend.

> > Yes and no. The plugin you are talking about is a real special case
> > because it's UDP and stateless. If you start to highly parallelize TCP
> > plugins (80% of the network-based checks), you end up crashing embedded
> > devices and old Solaris boxes.
> 
> Most TCP plugins do not need to wait for a timeout, do they?

Yes they do. recv() takes a long time if supplied with incorrect
expected length (which is a good thing), network connectivity can be
slow, and so on. Besides, the simple fact to run N connections at the
same time really crashes many devices for a ridiculously low value of N.

That is not to say that things could not be parallelized a little
better, but this also requires a lot of work : if we decided tomorrow
that UDP plugins can run in a highly parallel setup (say 100 plugins at
the same time), then we'd have to cope problems such as excessive
bandwidth consumption (if 100 plugins _start_ at the same time, you end
up sending too many packets to the remote host). You'll also notice that
the recv() function in the UDP plugins actually _resends_ the packets,
in case the initial request has been lost, and this also consumes
bandwidth if you have many of them in parallel.


				-- Renaud
_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel