[Openvas-discuss] My damn fault

Whit Blauvelt whit at transpect.com
Wed Aug 8 00:07:29 CEST 2012


Got it working (sort of)! This is what I get from getting "too familiar"
with variant recipes. I'd been using several prior recipes that put the gsad
web support on port 9392. Forgot the exact port, but was looking for it up
there, so figured it to be the 9393 from the command line - and that's where
the GnuTLS library was getting into error. Obviously I was starting to
connect to the wrong component (which nonetheless presented an encyrption
cert the browser, which of course I should have spotted was wrong for
--http-only anyhow). Port 80, okay it's there. Whew. Sorry for being dumb.

The "(sort of)" is because the resulting scanner, when running its default
"Full and Fast" scan against the same port range I'd been testing with the
Fedora installs (16, which segfaulted, and 15, which looked much better)
still comes up without finding any of the open ports except for the on NTP
port on the one system (which happens to be the ISP's router). Now, I see
in this instance the newer VM doesn't have nmap on it (the others did), so
I'll try installing that and see if it adds capability ... nope. OpenVAS is
still blind.

While the target /27 is the same, this latest instance is in an entirely
different location - a small cloud provider, while the prior attempts were
on one of my own networks (a separate one from the /27 scanned).

When you run scans your scans do your scans find the obvious stuff, the
things that nmap can see right away? Is the "Full and fast" scan profile as
distributed not really ready for use? Am I expecting too much that it should
show off an ability to find the obvious stuff?

There's nothing weird about the /27 I'm scanning. I'm responsible for
whatever defenses are there, and there's not any tripwire to stealth it from
scans. I've run Nessus against it, and everything's obvious, just as to nmap
- but not OpenVAS yet.

Thanks again,
Whit



More information about the Openvas-discuss mailing list