RE: [Full-Disclosure] Nessus experience
Few thoughts: 1) Often it is only a few vulnerability checks consuming the majority of the overall time to complete a scan of a single device. I wrote a script which parses nessusd.messages to help me find which vulnerability checks were taking all the time - below is a snippet of the output: # ./parseNessusdMessages.pl 10 === 192.168.2.19: completed checks = 1548: Time to complete host scan = 497.39 (8:17) Seconds | % of total time consumed | plugin name 184.069 (%37.007) mydoom_virus.nasl 176.551 (%35.495) synscan.nes 81.061 (%16.297) X.nasl 46.808 (%9.411) snmp_default_communities.nasl 30.119 (%6.055) vnc_http.nasl 25.462 (%5.119) relative_field_vulnerability.nasl 20.381 (%4.098) netscape_pop_auth.nasl 20.290 (%4.079) vnc.nasl 20.122 (%4.046) girlfriend.nasl 20.052 (%4.031) mysql_auth_bypass_zeropass.nasl 20.044 (%4.030) proxy_use.nasl not showing remaining list... (only showing 10) === 192.168.2.18: completed checks = 1548: Time to complete host scan = 503.25 (8:23) Seconds | % of total time consumed | plugin name 179.172 (%35.603) synscan.nes 176.109 (%34.994) mydoom_virus.nasl 46.662 (%9.272) snmp_default_communities.nasl 45.017 (%8.945) benhur_ftp_firewall.nasl 44.176 (%8.778) X.nasl 29.305 (%5.823) vnc_http.nasl 25.628 (%5.092) relative_field_vulnerability.nasl 21.680 (%4.308) dangerous_cgis.nasl 20.214 (%4.017) netscape_pop_auth.nasl 20.120 (%3.998) girlfriend.nasl 20.045 (%3.983) proxy_use.nasl not showing remaining list... (only showing 10) Now I know the SYN scan is listed above; the point here is I often see one or a few vulnerability checks consuming 80+% of the total scan time. If I know the environment, I can often exclude the offending checks (i.e. not important to me) or I can delay checking those vulnerabilities until a later time. 2) A mix of tuning the following variables can also change the overall scan time by more than 90%: From knowing the environment details (available bandwidth, latency, etc.) you can 'optimize' the scan and attempt to balance accuracy and speed. 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 you didn't allow enough time for a client to respond. If I know I'm scanning on a high-bandwidth and low latency network, I'll use small values because I can make an assumption I will not lose accuracy by going too fast. On the other hand, if I'm scanning over a T1 with latency above 300ms, I may inflate those values to something like 60 seconds for checks_read_timeout and maybe 300 seconds for plugins_timeout. This will extend the scan time a huge amount - but what are you looking for, speed or accuracy. That is the trade-off. Speed = missed vulnerabilities. Accuracy = slower scans. In one example at a client, I tried different values of checks_read_timeout in order to illustrate to the client that speed is the wrong thing to focus on: If I set checks_read_timeout to small values, I could scan multiples of devices in less than 10 minutes. If I increased the value, nessus would find 3x as many vulnerabilities. They choose to go slower for obvious reasons. As already mentioned, there are several other available tuning parameters which all alter the speed/accuracy trade-off: - optimize_test is also one of those variable if you set to yes, you have the potential to miss vulnerabilities. For that, you get to scan faster. Turn off and you potentially increase accuracy, but scan slower if additional checks are executed. - delay_between_test: number of seconds to pause between successive vuln. checks - unscanned_closed, max_threads, max_hosts, etc. 3) Lastly, another variable which has affected several of my attempts to speed up nessus scanning is the actual scan targets themselves. In test labs with 100s of fast 'scan targets', the overall scan times were respectable. Going into the real world and scanning 100s of slow desktops (i.e. old hardware) would often seemingly double scan time even though my .nessusrc tuning configuration was the same. Of course, the type of systems and number of open ports only exaggerates this issue: slow windows boxes with 40 open ports takes a lot longer to scan versus a UNIX box with 4 open ports. Knowing the environment, again, helps tremendously. HTH -Tate Tate Hansen Principal InfoSec Engineer ClearNet Security e-mail: [EMAIL PROTECTED] Greetings, full-disclosure! >From time to time I find myself needing to estimate the time it takes to run Nessus against various network ranges. For some reason, it always seems to take longer than I expect,
RE: [Full-Disclosure] Nessus experience
>>- Original Message -
>>From: "Tate Hansen" <[EMAIL PROTECTED]>
>>
>> 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.
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
