It might be interesting, though, to have Nessus call it indirectly, via a
wrapper such as the following:
I did as you told, nothing happened. I ran the wrapper alone. It worked fine
and the log output the scan results. I edited nikto.nasl, and changed all
default add preferences value from "no" to "yes", but the client didn't update
the change (two different clients). I've tried to restart the server and the
client, it still didn't. One more thing, nessus serve often doesn't stop
cleanly. Sometimes it leaves a process hanging. I usually have to kill nessus
processes to have it run properly again. Thank you.
YanYan
"George A. Theall" <theall@tenablesecurity.com> 3/19/2008 11:50 AM >>>
11213, 10916, 10915
11213 == xst_http_trace.nasl
10916 == smb_localusers_pwexpiry.nasl
10915 == smb_localusers_neverloggedon.nasl
If you're sure the only configuration change between 2 and 3 was the
"Enable Nikto" preference, is it possible resource congestion issues
on the network or target host could be affecting your results? The
second two here are local checks, so I find it odd they'd be
influenced by whether the Nikto plugin is enabled or not.
I start thinking that it wasn't Nikto that made difference on the
report from step 2 to 3. I scanned a different host today, but the
reports are exactly the same with or without nikto wrapper or with
the "Enable Nikto" preference. Nikto.nasl lauched even without
"Enable Nikto" preference.
Ok. That's not unexpected -- the plugin would start and then exit when
it finds the plugin preference has not been set.
I searched the entire reports for both hosts, but 14260 does not
appear any where.
I assume you've tested Nikto outside of Nessus and know that it runs.
It might be interesting, though, to have Nessus call it indirectly,
via a wrapper such as the following:
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
