DISCLAIMER - I'm not responsible if you break stuff. Read at your own risk.
I had a lot of "fun" the other day with OpenVAS.
If you're not aware, OpenVAS is a free, open source vulnerability scanning tool.
You may be familiar with commercial scanners (Qualys, Nessus, Retina, Nexpose...)
OpenVAS comes on Kali, and you can get the appliance and/or enterprise support from Greenbone. You can also install from the source code, or from packages for Linux flavors (Kali, Ubuntu, RHEL/Centos/Fedora).
I have also noticed that while the Greenbone appliance is very well documented, installing from the packages is not quite so. OpenVAS 9 was released earlier this year, so the documentation for Greenbone's 4.0 version of the appliance is still in "draft".
I needed LDAP support for centralized authentication & the community Greenbone appliance was not compiled with LDAP support (obviously, an enterprise would want that support, right? Which means pay for the enterprise appliance! I see what they did there).
Anyhoo.
I decided to install OpenVAS 9 on CentOS 7.
Hooking into LDAP and getting my domain certs in the appliance web application was a doozy. I mean, it took a couple days, but still. The appliance documentation makes it look easy, when the package installation is a bit different (did I mention it's like the wild west on the lack of documentation?).
Note: I'm using an Active Directory CA.
I followed this guide for my install. No problems.
1. Set up LDAP configuration in OpenVAS
Configure LDAP settings: Under administration, go to LDAP.
Under host, ensure you type the common name of your CA in the hostname. If it doesn't match Openvas won't communicate with LDAP!! When you view /var/log/openvas/openvasmd.log, it will NOT tell you this! You will see a bunch of "couldn't contact the LDAP server" errors. (which you can test that with openldap's ldapsearch, to determine this is literally just an openvas problem). Follow the Greenbone guides for the other fields... I used %s@domain for user accounts.
Pull the CA certificate (base 64) from your local domain https://adserver/certsrv
Upload the cert to the LDAP settings. It will register and you should see your info populate.
2. Create users
and make sure you click the checkbox for LDAP.
Now, for the SSL certs......... This is super simple with the appliance! but without it --- eeeee_eee. I couldn't find much on documentation at all. And that's why you get this lovely blog.
It comes with self-signed certs with the install, but I wanted a trusted cert for my domain.
1. Create your certs
openvas has a command called openvas-mkcert, which as it turns out is depreciated in v9.
openvas-manage-certs, is the new command. Buuut I figured it was easier to do it with openssl.
I used openssl, but in order to add subjectAltNames I had to modify openssl.cnf
nano /etc/pki/tls/openssl.cnf
under the [req] header,
uncomment
#req_extensions = v3_req
and then added the following on the line below the [v3_req] header
subjectAltName=IP:10.0.0.3,DNS:openvas.domain
You do not need to include the port, for openvas its like 9392 or something. but not necessary in the cert. (in case you were wondering).
Get private key:
openssl genrsa -out private.key
Once you have the private key, generate your CSR.
openssl req -new -key private.key -out server.csr
Copypasta the .csr (cat it) and then paste it into the create request field of your CA, and make sure you select web server cert!
Now download the base64 encoded certificate. It will be something like, yournewcert.cer
You can copypasta back to your putty window, scp, whatever.
Now you have your private AND public keys! yay! HTTPS might happen without Chrome bitching about it... eh not so fast.
I just took for granted that something like this would be running on an open source web platform, like nginx or httpd (apache). I was surprised to find out that it wasn't. I couldn't put my certs in those places. I did a little digging. I found out that the webserver is hardcoded in the openvas application (I creeped on some source code from greenbone's website). I noticed here that libmicrohttpd was listed as a "prerequisite". It was like verification that all my worst fears came to life.
LOL, maybe I'm exaggerating. Anyway, I went to check out this libicrohttpd to see more about how terrible this was going to be, and how to get HTTPS working with it. From what I read, you had to point the source code to the certificates. So, somewhere in openvas, the self signed certificates had a specific location and a specific name to be referenced by the code. For hints about the name, I recalled the greenbone instructions for certs, which state they use base64 encoded .pem files.
Since this is linux, I just did a find command to see where the .pem files lived on this machine.
find / -name *pem
which turned up with:
/var/lib/openvas/CA/servercert.pem
/var/lib/openvas/private/CA/serverkey.pem
Then, I was like DUH. /var/lib/openvas. microhttpd is a library in C, which uses a hardcoded path to certs. it makes sense they put them here.
2. Move your Certs to the right places!
So, you want to move the current servercert.pem & serverkey.pem.
mv /var/lib/openvas/CA/servercert.pem /var/lib/openvas/CA/servercert.pem.old
mv /var/lib/openvas/private/CA/serverkey.pem /var/lib/openvas/private/CA/serverkey.pem.old
and then copy the newly created certs to the old location, with the SAME name as the ones that just moved. I copied them just to make sure I had the originals if I messed up typing somewhere. You can mv these, if you want. I just rm'd them after I verified everything was working.
cp /path/to/the/server.cer /var/lib/openvas/CA/servercert.pem
cp /path/to/the/private.key /var/lib/openvas/private/CA/serverkey.pem
3. Reboot!
shutdown -r
and then wait for it to come back up with your shiny new, trusted certs. (:
Something you may also want to check is permissions on your directories with your keys. - Make sure they're not world-readable/writable.
annd that's it. Not so bad when you're not digging for answers. hahaha
-m.
