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" <[EMAIL PROTECTED]> 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 [email protected] http://mail.nessus.org/mailman/listinfo/nessus
