On Wed, Aug 08, 2012 at 07:37:34PM +0100, Matthew Mundell wrote: > > The GSA help section says to edit scan configs by choosing the wrench icon. > > Those are all greyed out. It says "A scan config can be edited if it's not > > currently used by a task." But only one has ever been on this system. > > They're all greyed out. Is this a bug, or the lack of a feature? > > It's a feature. If the config is in use, then editing is prohibited. This > keeps the reports comparable. You have to make a new config if you want to > edit it.
So all the 4 configs that come with GSA are "in use," even if a person has never assigned them to tasks? That's an unusual meaning for "in use." No matter. From what you say below nmap should run on the default config, so that's not what needs fixing at present. Or do I misinterpret you? > Just to be clear that you correctly understand the reports: have you > figured out the filtering on the "Report Summary" page in the GSA? The > open ports will all be hidden in the report until you enable the "Log" > threat level. They still aren't displayed after checking the "Log" threat level box on that screen. For IPs where I variously have FTP, SSH, DNS, HTTP and HTTPS services, the entiretly of the report, at "Log" level is: - Port Summary Service (Port) Threat general/CPE-T Log general/HOST-T Log general/tcp Log - Security Issues reported Log (CVSS: 0.0) NVT: CPE Inventory (OID: 1.3.6.1.4.1.25623.1.0.810002) Details Add Note Add Override xx.xxx.xx.xxx|cpe:/o:linux:kernel then a traceroute (fairly worthless here) along with: TCP ports: UDP ports: that's right - blank an OS fingerprint guessing HP printer or Linux (fairly worthless) Information about the scan (a list of all the ports assigned for scanning, which really shouldn't be there for each IP unless that IP has a custom assignment, IMHO - clutters the report otherwise). And another traceroute! (from the Department of Redundancy Department). That's it. Nothing about the obvious open ports being discovered. And this results comes up the same from an install of the most recent OpenVAS from source on Ubuntu 12.04, and from an Atomicorp package install on Fedora 15. Run from completely different places against the same target. A target that nmap itself, as well as Nessus, have no problem seeing at all, coming from the same origins. > If nmap is on your path OpenVAS should find it. I think you'll get a > message in the report otherwise. Any version of nmap should handle the > port scan part of the scan just fine. It's reassuring to know that nmap should be used. But I see no nmap processes run during the scan. And receive no error messages. Nor did I get an error message on the Ubuntu instance in the run done before nmap was on that system. Please don't take this as a hostile review. I'm trying to help. I want to get this running, not just for myself but so there's a complete recipe others can follow dependably. I've heard from people off list about similar experiences. It would be nice to figure out what's going wrong, and make this into something that just works for everyone. Regards, Whit _______________________________________________ Openvas-discuss mailing list [email protected] http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
