From: tate at ClearNetSec.com (Tate Hansen)
Subject: Nessus experience

>>----- Original Message -----
>>From: "Tate Hansen" <tate@...arNetSec.com>
>>
>> checks_read_timeout:  maximum number of seconds to wait for a probe
>> response:  wait doing a recv()
>> plugins_timeout:  the maximum number of seconds of lifetime for a 
>> vulnerability check
>>
>> If you set checks_read_timeout to 1 second and plugins_timeout to 5
seconds,
>> you'll blaze through the scan.  The problem is you may lose accuracy
because
>>

>That is quite interesting.
>Correct me if I am wrong, but it looks like if the target interface 
>that one is scanning is blocked/down for some reasons, nessusd does not 
>learn about it. (I guess it might be too much to expect). That is, 
>every one of the plugins will get delayed leading to a huge time. 
>Usually I haven't had the patience to wait for the whole scan in such 
>cases; I guess it could take days, am I right ?
>
>regards,
>Samir Kelekar

I'm not sure if I understand your question, but I'll try to expand a little
and see if I can answer it.

checks_read_timeout and plugins_timeout allow you to specify the maximum
amount of time you want any one check to consume (*see Note at bottom).  If
the target host is down or blocked, then it really depends on how you
configured nessus.

For example, if you configure nessus to perform the port scan and you have
the parameters 'unscanned_closed' and 'optimize_test' set to 'yes', then the
only vulnerability checks that should get executed are checks in which the
dependencies have been satisfied:  this typically means nessus found a port
in an open state and determined the protocol in use.  Most scripts define
dependency requirements like:

script_dependencie("find_service.nes","http_version.nasl");
script_require_ports("Services/www",80)
script_require_keys("www/apache")  

The above implies a vulnerability check would only run if:
1)	find_service.nes and http_version.nasl were executed before this
script
2)	a port is in the open state using the http protocol 

If those dependencies are not met, then the vulnerability check is not
supposed to be executed.  So, hopefully to answer your question, if the host
is blocked or down, that would imply nessus did not find any open ports -
which causes most vulnerability check dependencies not to be satisfied and
the vulnerability check not be executed.  

You can verify this in your case by watching the nessusd.messages log file
while you are running a nessus vulnerability scan:
If the dependencies are satisfied, but the plugin_timeout is exceeded, you
should see messages like:
[...] httpver.nasl (pid 2441) is slow to finish - killing it
(FYI:  I do notice the reported time of some vulnerability checks exceed the
value specified for the plugins_timeout; I'm not sure if this is due to
server load, latency, or particularly code paths traversed, but overall it
seems to work okay)

If the dependencies are not satisfied for whatever reason, you should see:
[.] : Not launching http_login.nasl against [.] none of the required tcp
ports are open (this is not an error)
[.] : Not launching DDI_Directory_Scanner.nasl against [.] none of the
required tcp ports are open (this is not an error)

*Note:  I don't remember for sure, but I think plugin_timeout only affects
certain categories of vulnerability checks:  ACT_ATTACK, ACT_DENIAL,
ACT_GATHER_INFO, etc. (there are more categories in NASL2):  Not
ACT_SCANNER, ACT_PASSIVE.

Powered by blists - more mailing lists