search

immauss / openvas

Containers for running the Greenbone Vulnerability Manager. Run as a single container with all services or separate single applications containers via docker-compose.
GNU Affero General Public License v3.0
354 stars 102 forks source link

immauss/openvas: #57

Closed grisno closed 3 years ago

grisno commented 3 years ago

docker run -e RSYNC_PROXY -p 9392:9392 -p 9390:9390 -e GMP=9390 --name immauss-openvas -v openvas:/data immauss/openvas:latest

The login on the web with the user admin: admin does not work:

website message

The Greenbone Vulnerability Manager service is not responding. This could be due to system maintenance. Please try again later, check the system status, or contact your system administrator.

log message

==> /usr/local/var/log/gvm/gsad.log <==
gsad  gmp:WARNING:2021-08-11 02h59.37 utc:985: Failed to connect to server at /usr/local/var/run/gvmd.sock: No such file or directory
gsad  gmp:WARNING:2021-08-11 02h59.37 utc:985: Authentication failure for 'admin' from 172.168.1.23. Status was 1.

linux version

Linux CentoOS 7.9 - 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

docker version

Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:55:49 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:54:13 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
orhpeus commented 3 years ago

I had tried this, and it worked.

image

immauss commented 3 years ago

Thanks. That makes total sense. I've been a bit out of touch the last month or so. (vacation then catch up from vacation) It seems there were some permissions changes I missed along the way. I'll try to get this ironed out in the next week or so.

immauss commented 3 years ago

I rebuilt everything with the latest updates yesterday. It all looks good, but I haven't given it a great deal of testing yet. If you want to see if it gives you the same issue, I'd appreciate it. Use the "21.4.3" tag.

Thanks, Scott

tedher commented 3 years ago

I still encounter the same issue (unable to login using user admin: admin) even after using the "21.4.3" image.

immauss commented 3 years ago

Could you please send the the exact command used to start the container and the output of the following:

docker info docker logs

Thanks, Scott

tedher commented 3 years ago

Hi @immauss, here is the information.

The command I run:

docker run --detach --publish 8080:9392 -e HTTPS=true --volume openvas:/data --name openvas immauss/openvas:21.4.3

Output from docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
 Containers: 11
  Running: 5
  Paused: 0
  Stopped: 6
 Images: 173
 Server Version: 20.10.8
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e25210fe30a0a703442421b0f60afac609f950a3
 runc version: v1.0.1-0-g4144b63
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.19.0-17-amd64
 Operating System: Debian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 7.792GiB
 Name: buster
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

Output from docker logs

==> /usr/local/var/log/gvm/gsad.log <==
gsad  gmp:WARNING:2021-08-20 06h53.56 utc:349: Failed to connect to server at /run/gvm/gvmd.sock: No such file or directory
gsad  gmp:WARNING:2021-08-20 06h53.56 utc:349: Authentication failure for 'admin' from aa.bb.cc.dd. Status was 1.
cybermcm commented 3 years ago

I have the same issue as described in OP. I tried 21.4.3 but according to docker this is the same image as latest. @immauss: Is 21.4.3 really a new image?

immauss/openvas                               21.4.3          15d1b1f53b8f   25 hours ago    1.71GB
immauss/openvas                               latest          15d1b1f53b8f   25 hours ago    1.71GB
immauss commented 3 years ago

OK .... I think I finally got this one worked out. I still don't get why I wasn't seeing this on my production build, but after creating some fresh clean builds, I started seeing it there. I hard coded the sockets on gvmd and on gsa and it all looks good now.

cybermcm commented 3 years ago

@immauss: the initial error is gone, but now a new one is here, at least for me_

today at 1:15:02 PM md manage:WARNING:2021-08-21 13h15.02 CEST:610: Could not connect to Scanner at /var/run/ospd/ospd.sock
today at 1:15:02 PM md manage:WARNING:2021-08-21 13h15.02 CEST:610: OSP start_scan 07d97358-9082-4de8-9507-1a0b36e5e85b: Could not connect to Scanner

Can anyone confirm? I'm currently using a fresh latest image

tedher commented 3 years ago

It's working on my side using the latest image. I am able to login.

immauss commented 3 years ago

There is definitely something wrong here. Seems it's time I go through all the start.sh and work out this socket mess.

cybermcm commented 3 years ago

@tedher: I should have added, login is OK, but scanning is not. The new error occurs when starting a scan. But it seems that @immauss already stumbled across this.

dkade commented 3 years ago

Hi guys. Yeah login is working but there is a problem with scans, latest image /var/run/gvmd.sock is not present..

To fix this:

docker exec -i openvas bash -c "ln -s /usr/local/var/run/gvmd.sock /var/run/gvmd.sock"

After this you can use the product but when you start a scan it will quickly change to interrupted, it a problem with ospd.sock I found it in /tmp/ospd.sock .

But even symlinking it is not working.

immauss commented 3 years ago

Yeah .... it seems Greenbone changed a ton of default locations for files. So .. I've been trying to avoid it, but it looks like I need to go back through my build process, realign with their compile time options, and then go through my start script again .... again .... ugh ....

in the mean time, I've rolled back the latest to gvmd version 21.4.1. It's only the AMD version at the moment, but it does work.

immauss commented 3 years ago

So ... for the time being ... it looks like the solution @orhpeus proposed is the best answer. Using the file locations specified in the Greenbone docs horribly breaks EVERYTHING. Because the build process relies on everything being in /usr/local/ to get copied to the second stage image. I don't get why it no longer works with the sockets though. It should. I may have to ask Greenbone what's going on. I have it working, but from my current location, I can't fully test things. Hopefully I have a chance tonight to validate the fixes.

immauss commented 3 years ago

OMG!! In finally realized where the forest was hiding. Right next to the trees.

The problem was the permissions on the directory the socket was being created in! I managed to get it working, and I'm running the rebuilds now for the arm64 & amd64 image.

If you see a new latest tag with in the next few hours, that's it. I'll repost here when it's up.

cybermcm commented 3 years ago

first quick test with latest image -> looks good, scan completed... thanks

immauss commented 3 years ago

OK ... I'm going to try to close this again ... :) Feel free to re-open or create a new issue is if this returns.

dkade commented 3 years ago

Today just run a new instance with docker run --detach --publish 8080:9392 -v /home/ec2-user/openvas:/data/local-share/gvm/share -e PASSWORD=password --name openvas immauss/openvas after it became healthy tested my scripts and we have again gvm.errors.GvmError: Socket /var/run/gvmd.sock does not exist .

cybermcm commented 3 years ago

Can't confirm this with the latest image (which is 6 days old). Did you really use the latest image? to be safe use docker rm -lf openvas docker pull immauss/openvas start container again

dkade commented 3 years ago

@immauss and @cybermcm just tested again. For me is always a new server with docker freshly installed, I'm spawning a new AWS EC2 Instance and then run docker with OpenVAS. I can login to the Web interface but there is no gvmd.sock and when you run a python script you got the error: gvm.errors.GvmError: Socket /var/run/gvmd.sock does not exist and it is true as we can see:

[ec2-user@XXX ~]$ docker images
REPOSITORY        TAG       IMAGE ID       CREATED      SIZE
immauss/openvas   latest    b36536382a2b   7 days ago   1.71GB
[ec2-user@XXX ~]$ docker ps
CONTAINER ID   IMAGE             COMMAND                 CREATED          STATUS                    PORTS                                       NAMES
fa4f8ef79d22   immauss/openvas   "/bin/bash /start.sh"   26 minutes ago   Up 25 minutes (healthy)   0.0.0.0:8080->9392/tcp, :::8080->9392/tcp   openvas
[ec2-user@XXX ~]$ docker exec -ti --user gvm openvas bash
gvm@fa4f8ef79d22:/$ ls /var/run/
gvm  lock  ospd  ospd.pid  postgresql  redis  redis.pid  samba  utmp
gvm@fa4f8ef79d22:/$

Start command: docker run --detach --publish 8080:9392 -v /home/ec2-user/openvas:/data/local-share/gvm/share -e PASSWORD=$PASS --name openvas immauss/openvas

cybermcm commented 3 years ago

@dkade: I can confirm your "findings", it's the same in my environment. We are probably talking about another use case? I set up a task and this task runs (scanning a system for possible vulnerabilities) until finished and has a result. You are referring to a script. What is the purpose of this script?

dkade commented 3 years ago

@cybermcm I use the https://github.com/greenbone/gvm-tools && https://gvm-tools.readthedocs.io/en/latest/index.html .

My script creates targets, tasks, start them and in the end exports the report. So it's an automated process. It uses the sock to connect to GVM this is the default and recommended: https://gvm-tools.readthedocs.io/en/latest/connectiontypes.html#using-a-unix-domain-socket

Well with the lastest changes gvmd.sock doesn't exist:

root@a32a5611b731:~# find / -name "gvmd.sock"
root@a32a5611b731:~#
cybermcm commented 3 years ago

@dkade OK, so another use case, I never used cli and gvm-tools before. I think you should open another issue, perhaps @immauss can take a look at it. It seems that gvmd has to be started with a -c option to use sockets and it seems that this is currently not the case (I'm no expert but couldn't find that option in the image)

immauss commented 3 years ago

Ah .. after some testing with the scripts myself, I realize that I switch the connection between gvmd & gsa to the tls connection on port 9390. If you use the "tls" connection method for the scripts, it should work. (It did in my testing.)

dkade commented 3 years ago

The latest image has the correct socket. I use the socket because it's the default and recommended by Greenbone.