Closed sc-pulsion closed 7 years ago
Hi @sc-pulsion, thanks for your feedback! I'm going to look into this a bit tomorrow and see what we can do. I really appreciate you giving back to the project. I'd like to do a bit of testing with your work.
As you probably sensed, alot of this project was built up over time to make things "just work" so I'm always open to others suggestions and help! I haven't heard of the GPG issue before so that's new to me. That issue may be unique to Hyper-V virtualization but regardless, that could be something useful for the docs.
Anyway, I'll post back more tomorrow with what I find, hopefully some changes, then we could talk about you contributing back some more of yours as well!
Hi @mikesplain thanks for getting back to me!
Please test all you can but can you try with my latest commit rather than the one I linked above? I have made quite a few changes again. You can see everything in the commit history.
I have also tested database persistence using my new build which seems to work fine so far at least, although much more testing is required. We only need to mount the database folder e.g.
docker run -d -p 443:443 -p 9390:9390 -p 9391:9391 -v ~/openvasDB:/var/lib/openvas/mgr --name openvas openvas
@mikesplain I've added a new branch today that also includes the w3af scanner.
https://github.com/sc-pulsion/openvas-docker/tree/enable_w3af_scanner_test
The only issue I have right now is that even though the scanner shows up in OpenVAS as a separate scanner, I don't get the option to use it when creating a new scan. Have you seen that behaviour before?
edit: Its okay I added a new scanner config and I could use it. The issue now is I run a w3af scan and can see it hitting the target box but after a while it errors on OV.
Thanks for your additions. For now I'm going to close this as we've moved to OpenVAS 9. Please reopen if you have any issues!
Great work so far. Can I hopefully add something worthwhile? Please let me know.
https://github.com/sc-pulsion/openvas-docker/commit/99b4095f2ea9a918fa7505a0af739fd563eeff62
Initially I was annoyed when I ran the container then added a credential using Greenbone. I am running my Ubuntu 16.04 Docker Hyper-V VM on a Windows server 2012 R2 host if that makes any difference. It seems that GPG takes HOURS in this situation due to entropy. When I left it overnight, the GPG process on the container was finally complete.
The 'fix' for my initial issue was to add the '-v /dev/urandom:/dev/random' to the test.sh file. It seems that mapping the entropy(?) of the host to the container means that something that took hours and hours previously takes less than a second and has no impact on performance any more. (yes, urandom and random are different - this just worked). We are mapping the host to the container here so no doubt there is some security issues
The rest of the changes are just optimisation and bug fixing. Hopefully they make sense.
Summary
Add smbclient package to Dockerfile - allows SMB test Make setup.sh and start.sh executable in Dockerfile - this is why nothing was updated previously Remove port 80 binding from Dockerfile - not used Remove rebuild from setup.sh - not required Remove admin user creation from setup.sh - not required Remove openvassd kill from setup.sh - oh the humanity - and not required Map the hosts urandom to the containers /dev/random - used to speed up the initial GPG stuff majorly
Next?
Next up, assuming you agree, would be to incorporate setup.sh into the Dockerfile, then (as I have seen in the issue tracker) to persist data. We need to remember old information especially when we report stuff as false positives.