search

Secure-Compliance-Solutions-LLC / GVM-Docker

Greenbone Vulnerability Management Docker Image with OpenVAS
https://securecompliance.gitbook.io/projects/
MIT License
246 stars 91 forks source link

[Bug] Scanning finds nothing #255

Closed tmuncks closed 3 years ago

tmuncks commented 3 years ago

Describe the bug Deploying a docker instance leaves me with a working installation, but for whatever reason, I get no vulnerabilities in my scannings. Occationally a TCP timestamp "Low", but that's it...

Scanning the same set of hosts from an older, non docker installation yields 26 HIGH, 3 Medium and 9 Low issues. I have tried importing the Scan Config, but that doesn't change anything.

From the forums, it looks like similar issues are typically not being able to find "nmap", but that does not appear to be the issue here.

To Reproduce Steps to reproduce the behavior:

  1. Deploy docker instance
  2. Login
  3. Create a target
  4. Create a task, pointing to the target (Full and fast)

Expected behavior If there are known, detectable problems with the target host(s), I'd expect them to appear in the result.

Host Device:

Image in use:

Dexus commented 3 years ago

Please check in the WebUI if the https://gvm-host/feedstatus is not update anything.

I think you request to fast a scan - while the DB was fresh and needs to initialize.

Dexus commented 3 years ago

I have checked this already multiple times, and also on greenbone repos you can finde some notice about that. If your DB is not final initialized you will lose some reports and findings. So please check the WebUI FeedStatus and if this is up2date and not run a update - you will be ready to scan again.

tmuncks commented 3 years ago

It looks like the feeds are okay:

NVT: 20210806T1024 (3 days old) SCAP: 20210806T0130 (3 days old) CERT: 20210806T0030 (3 days old) GVMD_DATA: 20210727T0801 (13 days old)

Dexus commented 3 years ago

now? or also as you started the scan, please try again. This time it should work.

On a fresh install it takes up to 30-60 minutes based on the system also more or less time. I use the same container in production - our tests don't show any problems. But our jobs also first run when the gvm-cli --xml="<get_feeds/>" don't return any child with currently_syncing tag

tmuncks commented 3 years ago

I'm pretty sure the syncing was done a while back, but I have initiated a new scan to make sure. In the meantime, the container does not appear to include gvm-cli? I cannot find that command in the container.

tmuncks commented 3 years ago

Looking closer, perhaps it's just not acknowledging which hosts are up in the same way - due to scanner configuration changes or something... One host in particular is showing up on the old scanner, but not on the new docker one. Let me try to figure out exactly what's going on here.

Dexus commented 3 years ago

I'm pretty sure the syncing was done a while back, but I have initiated a new scan to make sure. In the meantime, the container does not appear to include gvm-cli? I cannot find that command in the container.

You are right, it is not available in the container, because we don't need it. But if you need it in the container you are able to install it via apk add --no-cache gvm-tools@custcom

If you have a complex build like me, you maybe like to use the apk build artefacts for alpine from the https://github.com/Secure-Compliance-Solutions-LLC/GVM-APK-build repo. Or build your own container based on this one.

Looking closer, perhaps it's just not acknowledging which hosts are up in the same way - due to scanner configuration changes or something... One host in particular is showing up on the old scanner, but not on the new docker one. Let me try to figure out exactly what's going on here.

I should currently be surprised if it is really a bug from our container. If then maybe more from the Greenbone upstream. If you do find something, we will try to solve it in a timely manner.

tmuncks commented 3 years ago

Thank you. I' sure you are right. Right now it looks like it's simply doing something a little differently from the older versions. I'll drop a hint here once I figure out what was going on. Thank you for your time.

tmuncks commented 3 years ago

Okay, so in this case, the problem was in figuring out which host was up. This used to work in earlier versions, or I could specify "assume up" on the default scanner config. I have not been able to do this on this newer version, but enabling alive test "consider alive" on the target solves the problem for me. Thanks again

Dexus commented 3 years ago

I know the default settings are not matching everytime. So good you found a solution for your problem.

I close here. Thanks.