Mailing List Archive

On Tue, Jul 20, 2004 at 04:57:11PM +0200, Martin Ma?ok wrote:
> I have come across some DNS server (probably LAN Suite 602 on Windows server,
> but who knows...) that was not fingerprinted by Nessus, nor it was a message in
> the report that it couldn't be fingerprinted etc.
>
> So I increased the magic constant "3" in dns_fingerprint.nasl:
>
> 54 function probe(message)
> ...
> 62 if ( ! r ) { timeouts ++; if (timeouts > 3) exit(0); return "t:";}
> ^
> and the result is:
>
> 1:t:t:t:t:t:t:t:0X:0X:t:0X:15X:0Z0X:0X:0X:t:t:t:0X:0X:4:t:
>
> So the magic constant "3" should be upgraded to "12" ?

It should, but in your case you end up with a plugin with takes nearly
one minute to be executed, for a result that is not really used in the
rest of the scan.

So this plugin is a perfect example of a speed vs. accuracy conflict we
often hit.


-- Renaud

On Tue, Jul 20, 2004 at 01:49:25PM -0400, Renaud Deraison wrote:

> So this plugin is a perfect example of a speed vs. accuracy conflict we
> often hit.

Shouldn't the primary concern in writing a plugin be accuracy?

For example, a couple of my plugins scan web directories looking for
particular versions of software. Once found, KB entries are added and
the plugins exit. I've been bothered by the fact this misses any
subsequent installs that might exist in alternate directories and have
been pondering scanning all directories and coping with multiple
installs even though I expect few targets to have two or more instances.
In my mind, this seems like a good thing even though it will of course
increase scan times. Doesn't this seem like a good tradeoff to make?

George
--
theall@tifaware.com

On Wed, Jul 21, 2004 at 12:28:56PM -0400, George Theall wrote:
> On Tue, Jul 20, 2004 at 01:49:25PM -0400, Renaud Deraison wrote:
>
> > So this plugin is a perfect example of a speed vs. accuracy conflict we
> > often hit.
>
> Shouldn't the primary concern in writing a plugin be accuracy?

Not really. If you consider it acceptable for every plugin to take over
two minutes, then a scan can basically take several days per host.

An automated scanner _has_ to do a tradeoff between speed, accuracy and
intrusiveness, otherwise it's just useless (if it takes four months to
scan half of your class C, you won't use it. If it takes down half of
your class C during the scan, you won't use it either).

I did a talk on that subject a year ago, I'll try to put it online.



-- Renaud

On Tue, 20 Jul 2004, Martin Maèok wrote:

> I have come across some DNS server (probably LAN Suite 602 on Windows
> server, but who knows...) that was not fingerprinted by Nessus, nor it
> was a message in the report that it couldn't be fingerprinted etc.

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).


On Wed, 21 Jul 2004, Renaud Deraison wrote:

> Not really. If you consider it acceptable for every plugin to take over
> two minutes, then a scan can basically take several days per host.

This depends on the level of parallelism. In fact, the plugin in question
itself is highly parallelizable because it makes no sense to wait several
seconds until one query times out before you send another query.


--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

On Wed, Jul 21, 2004 at 10:57:55PM +0200, Pavel Kankovsky wrote:
> On Tue, 20 Jul 2004, Martin Ma?ok wrote:
>
> > I have come across some DNS server (probably LAN Suite 602 on Windows
> > server, but who knows...) that was not fingerprinted by Nessus, nor it
> > was a message in the report that it couldn't be fingerprinted etc.
>
> 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.

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.

> On Wed, 21 Jul 2004, Renaud Deraison wrote:
>
> > Not really. If you consider it acceptable for every plugin to take over
> > two minutes, then a scan can basically take several days per host.
>
> This depends on the level of parallelism. In fact, the plugin in question
> itself is highly parallelizable because it makes no sense to wait several
> seconds until one query times out before you send another query.

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.


-- Renaud

On Wed, 21 Jul 2004, Renaud Deraison 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?

> 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 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?


--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

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

On Tue, Jul 20, 2004 at 01:49:25PM -0400, Renaud Deraison wrote:

> On Tue, Jul 20, 2004 at 04:57:11PM +0200, Martin Ma?ok wrote:
> > I have come across some DNS server (probably LAN Suite 602 on Windows server,
> > but who knows...) that was not fingerprinted by Nessus, nor it was a message in
> > the report that it couldn't be fingerprinted etc.

> > 1:t:t:t:t:t:t:t:0X:0X:t:0X:15X:0Z0X:0X:0X:t:t:t:0X:0X:4:t:

> It should, but in your case you end up with a plugin with takes
> nearly one minute to be executed, for a result that is not really
> used in the rest of the scan.

It is 20 seconds with no result versus 70 seconds with some result.

> So this plugin is a perfect example of a speed vs. accuracy conflict
> we often hit.

Is this acceptable?

--- dns_fingerprint.nasl.orig 2004-07-22 11:31:54.000000000 +0200
+++ dns_fingerprint.nasl 2004-07-23 10:38:19.000000000 +0200
@@ -44,6 +44,7 @@


include("misc_func.inc");
+include("global_settings.inc");

id = rand() % 1024;
TIMEOUT = 5;
@@ -59,7 +60,22 @@
send(socket:soc, data:message);
r = recv(socket:soc, length:4096);
close(soc);
- if ( ! r ) { timeouts ++; if (timeouts > 3) exit(0); return "t:";}
+
+ if ( ! r )
+ {
+ timeouts ++;
+ if (timeouts > 3 && ! thorough_tests)
+ {
+ if (report_verbosity < 2) exit(0);
+ else
+ {
+ report = "Name server could not be fingerprinted (too many timeouts)";
+ security_note(port:53, proto:"udp", data:report);
+ exit(0);
+ }
+ }
+ return "t:";
+ }


rcode = substr(r, 3, 3);



Martin Maèok
IT Security Consultant

On Fri, Jul 23, 2004 at 10:50:21AM +0200, Martin Ma?ok wrote:
> > So this plugin is a perfect example of a speed vs. accuracy conflict
> > we often hit.
>
> Is this acceptable?

Yes it is - I'll commit your patch right away, thanks !