Re: Nessus scripts and Moore's Law

On Sun Nov 14 2004 at 02:07, Pavel Kankovsky wrote:

> The memory will stay shared among all nessusd processes unless you write
> to it.

Only the cleaning process would write it. We can disable than.

> You might even dump the result into a big file and map the file
> readonly

Not easy, because the tree contains pointers and each cell is
allocated indivually on the heap, among other things like string.

> Yes but it is much easier to catch that all the reports for a particular 
> service are missing than that some of the reports are missing.

Honestly, I think that adaptative timeout should be the best answer to
this problem. It could issue a proper warning when it triggers under
some circumstances like a timeout.
I've worked once on a WAN which was supposed to be the 8th marvel of
the world and happened to be very unreliable. It was not as quick as
full switch 100 Mb ethernet, of course, I increase the timeouts and
lowered the parallelism and everything should have run well. But the
gizmo decided to lose packets from time to time, maybe during 30 s.
The 1st Nessus report contained crap, so I re-run it. The 2nd report
contained crap (at other places) so I re-run it. The 3rd report
contained crap *again*. I looked at my watch, it was 1 a.m., I merged
the 3 reports and went back home :-\
As the network glitch appeared at random time, I had a good chance to
have a full report from the merge. I had no way to be sure (not in a
reasonable time anyway)

> Fine. It works for services running on standard ports only but it 
> covers the vast majority of cases. On the other hand, I find it quite 
> confusing to get both that warning and some real reports
> simultaneously

The warning is issued by the first detection script, and the second
detect the web server.

> and I am tempted to ignore the warning as irrelevant noise.

Not any more, now you know :-)

> Joe Average Luser's temptation to ignore the warning would probably
> be much higher. 

I agree.

> Perhaps such warnings should be promoted to "Nessus Alerts"?

Not the 1st one. But the 2nd one could be:
"A web server was detected on this port but was missed by the 1st
detector. Your report might be incomplete. You should re-run your scan
with high timeouts"
This way, we can even issue warnings on all ports, not only standard
ports.

I can fix find_service2 & its brothers.

> But what's the point of repeated attempts to grab the banner in every
> plugin that needs it? It might slow the test down quite noticeably (esp.  
> if the problem does not disappear spontaneously), and I'll have to rerun
> it anyway if the problem was caused by a transient/fixable communication
> glitch.
>
> I still think it makes more sense to try harder to get the banner at the 
> same beginning of the test rather than to retry in every individual 
> plugin.

> Well, yes, there is one reason not to make pure kb-checking plugins:
> the ability to run plugins in a standalone mode (esp. when the standard 
> nasl is still unable to load and provide kb data).

This could be changed by using the new COMMAND_LINE pre-defined
variable.
For example:
port = get_kb_item("Services/www");
if (! port) { if (COMMAND_LINE) port = 80; } else exit(0)

> Lowering CPU usage is pointless unless you want 1. to run other CPU 
> intensive tasks on the same machine, or 2. to save some joules of 
> electric energy, or 3. want to "speed things up" and CPU is the 
> bottleneck. :)

If I understand well, CPU might be an issue on huge parallel scans.
Fortunately, 1. there are quite powerful processors now, 2. Nessus run
well on a multiprocessor machine.

[HTTP cache]
> How much memory did it consume?

I did not remember, but it was supposed to speed up web tests and did
not.

> Do you need more than 3 syscalls to read the whole file: open(), read(),
> and close()?

For most scripts, no. For bigge scripts, maybe a couple of read

>> If anybody finds a way to benchmark such a thing without writing a
>> new interpretor, that would be great.

> Put one "start timer" call at the beginning of the interpreter, one "stop
> timer" plus "report timer value" at the end, and a pair of "stop" and
> "start" around all I/O procedures. It will reveal how much time is spent
> interpreting the code.

We already have this in exec.c (it prints the result of getresources)
What I need is a way to estimate the speed gain between the current
interpretor and a VM based interpretor without rewriting the whole
interpretor with the VM. i.e., I don't want to do it and discover that
it wasn't worth the effort.

> BTW: One obvious optimization: rewrite recv_line() to read input in bigger
> chunks rather than sucking it by single characters.

This is done indirectly by buffered network IO. I considered it as an
experimental feature and it is enabled only by http_open_socket
Should we generalize it?

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