H. Charles Tang wrote: > Hi, our customers have been running Nessus to get an overall report, > and then I use NASL to run single plugin to verify each vuln > reported.
Wow, that's a lot of invoking 'nasl'. Can you be more specific on what your customers are doing? Are you an MSP, selling Nessus 2 on an appliance, accepting Nessus reports from your customers? Is is Nessus 2 or Nessus 3? Knowing the environment Nessus is run in (and run from) is important when diagnosing results. > To my surprise, for quite some vulns, NASL did NOT confirm > them at all. I searched the archive, and noticed some dated arguments > about KB stuff. However, I think in the NASL (eg 3.0.5) I tried, if it > can't get_kb_item(), then from the trace one can see it simply exits > without firing off the attack packets. Yes. Many NASLs depend on data discovered from other NASLs. If you can recevie or set the KB for your NASLs, you can get the ones that need KB entries to execute. I have written a blog entry on the topic here: http://blog.tenablesecurity.com/2007/06/using-the-nasl-.html > For one particular plugin 11759, it doesn't involve KB stuff (when > it's running in non safe_check mode). Then NASL and Nessus yield opposite > results repetitively. So I don't know to trust which one now? It's not a matter of trusting the NASL, it's a matter of understanding safe checks. With safe checks, plugin 11759 does a non-intrusive banner comparison however without safe checks an actual DOS is performed. With safe checks, you have no impact but since you aren't actually performing the test, you need to rely on the banner. If a system has been patched and the banner still matches, this could be a false positive. There may be other systems vulnerable to this DOS attack. Without safe checks the actual DOS is performed and what the system actually is is irrelevant. > I have been getting the feeling that different runs of Nessus can actually > yield somewhat different results. If you are using Nessus 2 or an underpowered system this could happen. Also, if you are scanning through a firewall, IPS, web proxy, .etc, this can really alter the results of a port scan. And lastly, if the system you are scanning is underpowered (or 100% CPU) you won't get the responses Nessus is waiting for. > So I'm inclined to believe what NASL > is telling me. It is the difference between scanning with one plugin through NASL and scanning with many plugins at the same time with Nessus. > Here's the result from NASL on 11759: > (TRACE) call safe_checks() > (TRACE) ret -> 0 > (TRACE) call get_port_state(4000 ) > (TRACE) ret -> 1 > (TRACE) call start_denial() > (TRACE) ret -> > (TRACE) call open_sock_tcp(, , , , 4000 ) > (TRACE) ret -> 1000000 > (TRACE) call raw_string(128 ) > (TRACE) ret -> . > (TRACE) call send(.dupa , , , 1000000 ) > (TRACE) ret -> 5 > (TRACE) call close(1000000 ) > (TRACE) ret -> 0 > (TRACE) call end_denial() > (TRACE) ret -> 1 > Did your 'nasl' tool output something like: ./cajun_switch_dos.nasl: Success If it didn't, the return code of '1' does not indicate a vuln was found, just that the exit code returned 0. You can put an 'exit(0);' at the end of that NASL to get a 'ret -> 0' in the trace. Ron Gula Tenable Network Security _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
