OpenVAS 5.0 Appliance Fixes

Spent some time today getting the OpenVAS downloadable appliance working today.  The first piece that is missing is the necessary step of fixing the timezone.  If the timezone of the client (most likely your host OS) and the server VM doesn't match, you will run into an issue where when you try to login to GSAD with a browser, you will receive the error "Session has expired, Please login again".  A quick Google search lead me to this post:

http://lists.wald.intevation.org/pipermail/openvas-discuss/2011-June/003128.html

The solution listed there used the ntpdate command to get the clock back in sync, however, it didn't entirely address my issue.  The other issue for me was that the timezone was EST, not MST like my client system, or UTC like my servers.  To fix that, run the following commands as root:

apt-get install ntp
cp /usr/share/zoneinfo/[country/city or timezone] /etc/localtime
reboot

where country/city for me was America/Denver, for example.

From there, it works "out of the box".  Well, sorta.  If you follow the advice on the download page:

"You should upgrade the base system immediately to install all security updates published meanwhile. The base system is Debian Squeeze, so you need to run "apt-get dist-upgrade" or other managament tools you might prefer."

it stops working again.

Two issues that arose with this.

First, the VM that was created for me by opening the OVA appliance image in VMware Workstation created a disk of 8GBs, which is fine until you decide to update it.  Upon running "apt-get dist-upgrade", the partition fills up before the update finishes.  Once I realized that was happening, I paused the "apt-get dist-upgrade" run with ctrl-z, and removed the filesystem reservation from the ext3 filesystem with the command "tune2fs -m0 /dev/sda1".  That freed up enough disk space to allow the process to finish.  Keep in mind, this is a quick fix, and may not be enough to get around this in the future.  In that case, you'll need to extend the disk size in the VM settings, and then resize the partition within the VM - no small task.

Update: Had some time to do some more digging, and found that the majority of the disk space is used by the /root/source directory, and one file in particular /root/source/dummy at 2.4GBs.  It's not clear if this file is important, or even what it is.  bzip2'd the file, and the resulting size was 1.8KB, so obviously not much real data in it.  If you need even more disk space, /root/source/debian has a lot of source tarballs that can probably be removed.

Second issue I ran into was that upon logging into gsad via a browser, the gsad process would max out the CPU, and nothing would happen.  Ran strace on the process, and it would just sit and spin in an infinite loop.  Back to Google, which turned up a string of mailing list posts, but the first response lead me down the right path:

http://lists.wald.intevation.org/pipermail/openvas-discuss/2012-November/004652.html

(Related to that email thread: People, stop whining about free services/software.  They are free.  Either help fix the problem, or shut up and go buy something.  Then complain to the folks you just paid.)

The issue is with the newer libmicrohttpd that was installed by "apt-get dist-upgrade" breaking gsad.  To fix this, run the following as root:

cd /root/libmicrohttpd/libmicrohttpd-0.9.15/

./configure && make && make check
cp ./src/daemon/.libs/libmicrohttpd.so.10.13.0 /usr/local/lib/
ln -s /usr/local/lib/libmicrohttpd.so.10.13.0 /usr/local/lib/libmicrohttpd.so.10
ldconfig -v

In the ldconfig output, you should see libmicrohttpd.so.10 listed in /usr/local/lib BEFORE the system installed libmicrohttpd.so.10 in /usr/lib. Reboot, and now gsad will use the new (older) version of libmicrohttpd, which works.

Enjoy.
-R

Register now for Cyber Defense Initiative 2012, December 7-16, Washington DC. Choose from 20+ courses; event includes dedicated digital forensics campus, NetWars Tournament of Champions, evening bonus sessions, and full vendor expo! http://www.sans.org/info/112329