mikhail at nessus
Nov 12, 2004, 4:02 AM
Views: 2553
Permalink
|
On Fri Nov 12 2004 at 00:43, Renaud Deraison wrote:
> This is actually a _slower_ alternative to the current banner matching
> plugins we have today - it's _way_ faster to write one plugin which
> connects to port N on the remote host, store the result in the KB, and
> run hundreds (if not thousands) of egrep() on it, than it is to test all
> the permutations of a given protocol like a generic plugin would.
Optimization is always a matter of compromise: CPU vs RAM, CPU vs
network.
Generic tests eat more resources on the network & target machines and
less on the scanner. Currently (and for a loooong time ahead), local
CPU is more abundant and cheaper, I admit.
> - They are very slow and most of the time unreliable. So you send
> "USER XXXX[...]XXXX" to a remote FTP server, and it cuts the connection
> down. How do you distinguish a segfault from an exit() ? You
> can't. If you run Nessus without safe checks _today_, most of the
> false positives come from such plugins ;
IIRC, we have made many improvements on them.
> - They are destructive. Crashing the remote service is not an option
It depends on what are your "security objectives". If reliability is
your priority, you certainly don't want to crash a service to verify
if it is vulnerable to a known DoS that might be exploited one day.
If confidentiality is your priority, then you don't care. That's the
case with many military systems that protect secret data: better dead
than caught.
I was told that a French defence "network cutter" was vulnerable to
the old ping o' death. I'm not sure that this is not a legend spread
by competitors, but anyway, the goal of the devise is to prevent
information leak, at *any* price.
As I said in my previous message, I'm quite sure that most users don't
need 99.99% reliability.
> - They are too fuzzy. When most users read that the remote server
> _might_ be vulnerable to a buffer overflow, without any reference to
> any BID or CVE, they just assume it's a false positive.
Maybe we might enhance the message and give more data so that the user
can investigate?
> In short, generic plugins are useful BUT unreliable, and I want to move
> most of them in the "thorough checks" section.
They are already in ACT_DESTRUCTIVE_ATTACK, no?
>> 2. Rewrite the NASL interpretor using a VM. According to gforth /
>> vmgen developers, such an interpretor might be 10 to 100 times quicker
> That would be good.
*If* the VM really speeds things up. Does anybody know how I could
benchmark it without full rewriting the interpretor? I don't want to
code during a month to discover that I save 3% of CPU time!
> I don't think they will attenuate your current fears.
I am more looking for enhancement than "fearing" anything. As I said,
the "sluggish Nessus" scenario is good for scifi.
<troll>
This is different with some other scanners that have sacrificed
completeness or reliability to get a reasonable speed.
</troll>
> This is also important. I introduced a very crude HTTP caching mecanism
> a while ago (now disabled)
IIRC, it did not really improved speed and ate much CPU and RAM :-]
However, we fixed a terrible memory leak since (I plead guilty for
this horror)
> and I want to re-do it (mostly, to only cache static pages)
Maybe in C?
--
arboi [at] alussinan http://arboi.da.ru
NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
|
