openvas
openvas copied to clipboard
immauss
Support for passing TLS certs to openvas
In the current implementation the start.sh script generates a CA and TLS certs for Openvas. It would be very beneficial if I could provide my own ca-cert and TLS cert/key for the service, as an alternative to the script generating the certs for me.
Another place that would need to be changed for this to work is here:
if [ $HTTPS == "true" ]; then
su -c "gsad --mlisten 127.0.0.1 -m 9390 --verbose --timeout=$GSATIMEOUT \
--gnutls-priorities=SECURE128:+SECURE192:-VERS-TLS-ALL:+VERS-TLS1.2 \
--no-redirect \
--port=9392" gvm
else
su -c "gsad --mlisten 127.0.0.1 -m 9390 --verbose --timeout=$GSATIMEOUT --http-only --no-redirect --port=9392" gvm
fi
Looking at the manpage for gsad it supports the following:
-k, --ssl-private-key=FILE
Use FILE as the private key for HTTPS
-c, --ssl-certificate=FILE
Use FILE as the certificate for HTTPS
The simple way to do this would be to use "-v" statements to map your certs into the container. Coming up with a better solution has been on my TODO list for a while now.
The leading ideas are using a squid/nginx proxy that incorporates Let's Encrypt. This is for the moment on my schedule for after I resolve all of the bits for separating out all of the process into separate containers. At that point, adding another container to the pod for the proxy will be easier/smoother.
Yeah, I could definitely use NGINX for this. I would have to Google any caveats for using NGINX in front of OpenVAS.
I use NGINX in front and works fine. I use NGINX along with dockergen and letsencrypt as a 3 component microservice. Works mint. However, I can see the need for being able to directly do it,since it has the capability of it.
The simple way to do this would be to use "-v" statements to map your certs into the container. Coming up with a better solution has been on my TODO list for a while now.
The leading ideas are using a squid/nginx proxy that incorporates Let's Encrypt. This is for the moment on my schedule for after I resolve all of the bits for separating out all of the process into separate containers. At that point, adding another container to the pod for the proxy will be easier/smoother.
As an addition if you do add nginx to the multi-container. I would recommend making that optional as some folks like myself have a central nginx host they use for all of their reverse proxying / certs in place already :)
@gaby any advice/configs you could share would be greatly appreciated.
Thanks, Scott
I've made some pretty good progress with this. I'm planning to have it as a second repo/add on to create a reverse proxy container with Let's Encrypt in as simple a fashion as possible. Right now, it works with a very short and simple config file. Need to have it spit out commands to run a single container, or a docker-compose fragment to add to any project.
@immauss Thank you! I'm using a simple config from here: https://ssl-config.mozilla.org/
I dont use lets encrypt since my openvas is not internet facing.
I guess we can close this ticket now, specially with the rev-proxy config you are providing.
From a hardening perspective please do test your nginx config against ssl-labs. Your current config leaves much to be desired from that point. Need to set ciphers, HSTS, ssl stapling, couple other things. There are a few pre existing repo's that have a good config. Also still need to have a reference reverse proxy setup config in this repo for those that don't wish to spin up a separate container / have their own reverse proxy and internal certificate authorities.
@arcreigh YES! Thank you. I've heavily modified the template config. If you see any room for improvement, please let me know. I'm now getting an A+ at SSL Labs. :)
-Scott
That is much better! Thats a great baseline. Now for this specific repo you may need to tinker with websockets I don't know all the ins and outs for openvas and what path's use websockets. But I would definitely make that recommendation if applicable.
I may need to steal your configuration and update mine :D
An additional minor note, disable the nginx version output for all error codes. Security through obscurity sure but some scripts do use that for scanning for vulnerable versions of web servers.
Closing this out now with https://github.com/immauss/rev-prox as the easy solution.