[Openvas-devel] Short test report on OpenVAS Desktop Live-CD RC1
geoff at galitz.org
Thu Apr 29 18:49:25 CEST 2010
> thanks for Geoff for the great work.
> I did a quick test of this version (0.0.14) and this is what occured to me
> prior to even the first scan:
> * it tool over 10 minutes to boot
> -> I will also look into this myself to find out whether there are any
> chances to get it faster
Additional eyes are certainly appreciated. Note that the boot scripts call
"service openvas-manager rebuild" which itself takes about 4 minutes in that
config... but that is a bug. It is not needed because the manager database
is prebuilt and I simply forgot to remove it. That will be fixed in the
Just as a note, part of the issue is that I had to make a choice. I can get
the system to boot faster, but the openvas-scanner will not be online and
listening on the needed TCP port before that 7 minutes or so time period is
over. If the scanner cannot talk to the manager then users are unable to
log in and there is no useful feedback to them on why that is happening.
Rather than that, I have the GUI wait before it starts until the scanner is
online. That can be changed easily.
The scanner (from what I can tell) is simply taking a long time reading from
the 17000 plugins in the filesystem... even when they are already cached.
If anyone does have good ideas on how to shorten this, I'll gladly take the
It seems to be this slow primarily in a desktop virtualization system or the
LiveCD where there are extra layers of IO (reading from a virtual disk which
itself is a file on your laptop or whatever, or the overlay functions of
live cdrom filesystems). The delay is not so bad when I run on the bare
metal hypervisors like Xen. It is almost normal.
I'm always up for the possibility I missed something and made a silly
mistake, so I certainly welcome more people looking at it.
> * There are a couple (I have seen 2) of
> "cat /srv/www/htdocs/pass.txt: no such file or directory"
> during the boot.
> However, later on the password works.
Another minor bug. Noted.
> * It it is still required to run thought the YaST config steps.
> -> Is this avoidable at all (e.g. by some autodetect)?
Autodetection is not possible when the audience is so wide. I can have a
German edition out at any time which has no yast config steps. I'll make
one tonight or tomorrow morning as time allows.
But for general purpose usage with German, English and French speakers (at
the least) autodetection of keyboards and the like is not possible.
> * "OpenVAS-Client" is not present as a shortcut on the Desktop.
> (Would make sense to me)
I'll add that. No problem.
> * The main info page in 0.0.12 (IIRC) opened a separate tab in the
> browser. That behaviour was good, but now it is directly jumping
> to GSA in the same window.
I'll look at that.
> * Because of the above problem (I needed to look at the passwords
> to login in) I pressed the "Home" button of the Browser and ended
> up on the SUSE Homepage.
> -> Is it possible to change the default "Home" of the browser to
> the main page that is opened at the beginning?
Yes. I can change that.
> * pass.txt: Why does this file recommend to create new passwords?
> IMHO, they are good enough. No?
> Also, it should say at the top something like "These passwords
> were automatically generated for this instance:"
The passwords are good enough.
If the passwords are not changed, then it is vulnerable to "shoulder
surfing" attacks where the passwords can be read by someone sitting near the
person operating the appliance. That is why I added the recommendation to
change the password.
The passwords also go to the console so someone could potentially just walk
up to the appliance and try to figure it out.
I'm open to alternate methods of delivering password data securely to the
operator of the appliance.
I'll go ahead and also note the passwords are random.
Thanks for the feedback!
More information about the Openvas-devel