On Mon, Aug 06, 2012 at 04:12:30PM -0400, bb.boogie wrote: > This tutorial for openvas on backtrack 5 works like a champ every time we > bring > up a new pentest host, by ax0n: > > http://www.h-i-r.net/2011/08/installing-openvas-on-backtrack-5.html
Hey bb, In the interest of documenting what works... Tried those instructions, and ended up with this breakage per /var/log/messages: Aug 13 14:53:33 bt openvasad: Libgcrypt warning: missing initialization - please fix the application And in the /usr/local/var/log/openvas/openvasad.log lib auth:WARNING:2012-08-13 14h53.03 EDT:7280: Authentication configuration could not be loaded. But happily "gsad --http-only" produces a working system, to a point. It runs nmap! But it stalls out at 1% - a problem which was discussed at length a year ago, and which most likely doesn't apply to OpenVAS 5? The topic is here: http://seclists.org/openvas/2011/q2/356. The reporter eventually blames it on running iptables as the remote firewall. But that's crazy. It can't be a remote firewall's fault that a vulnerability scanner stalls. Wouldn't it be a happy world if merely running Netfilter meant nobody could scan you? The stall, as with his report, is at: open_stream_connection(): unsupported transport layer 3 The stall is kind of ugly ... leaves an instance of openvasmd running at +-90% of CPU, with nothing at all being logged from it. But that of course is OpenVAS 4, which I wouldn't expect any support on now. That nmap runs before thing stall out gives me hope that need to symlink different installation directories to get the various components actually talking with each other, which is the central fix in that recipe, might in some variation apply to OpenVAS 5 - and may be what's required to get nmap to run there? Best, Whit _______________________________________________ Openvas-discuss mailing list [email protected] http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
