Hi all, I am using a GVM 11 docker version based on securecompliance/gvm. I have managed to install an ssh server on the container along with the GVM (using supervisord). GVM and ssh play along very well so far. I want to remotely control the scanner through an other container with a python client (python-gvm). I am trying to connect the python client with an ssh connection by I get a “Remoteclosed the connection” error.
This is the python code:
from gvm.protocols.ospv1 import Osp
from gvm.connections import SSHConnection
from gvm.xml import pretty_print
connection = SSHConnection(hostname='localhost', port=2222, username='root', password='root')
osp = Osp(connection)
version = osp.get_version()
pretty_print(version)
I think I must inject a configuration file to the gvm container…but I am not sure how and where.
The dockerfile installs all gvm components from source. I wonder if I can add any installation option to enable some service or something…
Any thoughts???
This is the dockerfle source:
FROM ubuntu:18.04
ENV DEBIAN_FRONTEND=noninteractive
ENV LANG=C.UTF-8
RUN apt-get update
RUN apt-get install -y openssh-server supervisor
RUN mkdir -p /var/run/sshd /var/log/supervisor
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY install-pkgs.sh /install-pkgs.sh
COPY gvm-tools.conf /temp/gvm-tools.conf
############################## GVM #############################################
RUN bash /install-pkgs.sh
ENV gvm_libs_version="v11.0.0" \
openvas_scanner_version="v7.0.0" \
gvmd_version="v9.0.0" \
gsa_version="v9.0.0" \
gvm_tools_version="v2.0.0" \
openvas_smb="v1.0.5" \
open_scanner_protocol_daemon="v2.0.0" \
ospd_openvas="v1.0.0" \
python_gvm_version="v1.0.0"
RUN echo "Starting Build..." && mkdir /build
#
# install libraries module for the Greenbone Vulnerability Management Solution
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/gvm-libs/archive/$gvm_libs_version.tar.gz && \
tar -zxf $gvm_libs_version.tar.gz && \
cd /build/*/ && \
mkdir build && \
cd build && \
cmake -DCMAKE_BUILD_TYPE=Release .. && \
make && \
make install && \
cd /build && \
rm -rf *
#
# install smb module for the OpenVAS Scanner
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/openvas-smb/archive/$openvas_smb.tar.gz && \
tar -zxf $openvas_smb.tar.gz && \
cd /build/*/ && \
mkdir build && \
cd build && \
cmake -DCMAKE_BUILD_TYPE=Release .. && \
make && \
make install && \
cd /build && \
rm -rf *
#
# Install Greenbone Vulnerability Manager (GVMD)
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/gvmd/archive/$gvmd_version.tar.gz && \
tar -zxf $gvmd_version.tar.gz && \
cd /build/*/ && \
mkdir build && \
cd build && \
cmake -DCMAKE_BUILD_TYPE=Release .. && \
make && \
make install && \
cd /build && \
rm -rf *
#
# Install Open Vulnerability Assessment System (OpenVAS) Scanner of the Greenbone Vulnerability Management (GVM) Solution
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/openvas-scanner/archive/$openvas_scanner_version.tar.gz && \
tar -zxf $openvas_scanner_version.tar.gz && \
cd /build/*/ && \
mkdir build && \
cd build && \
cmake -DCMAKE_BUILD_TYPE=Release .. && \
make && \
make install && \
cd /build && \
rm -rf *
#
# Install Greenbone Security Assistant (GSA)
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/gsa/archive/$gsa_version.tar.gz && \
tar -zxf $gsa_version.tar.gz && \
cd /build/*/ && \
mkdir build && \
cd build && \
cmake -DCMAKE_BUILD_TYPE=Release .. && \
make && \
make install && \
cd /build && \
rm -rf *
#
# Install Greenbone Vulnerability Management Python Library
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/python-gvm/archive/$python_gvm_version.tar.gz && \
tar -zxf $python_gvm_version.tar.gz && \
cd /build/*/ && \
python3 setup.py install && \
cd /build && \
rm -rf *
#
# Install Open Scanner Protocol daemon (OSPd)
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/ospd/archive/$open_scanner_protocol_daemon.tar.gz && \
tar -zxf $open_scanner_protocol_daemon.tar.gz && \
cd /build/*/ && \
python3 setup.py install && \
cd /build && \
rm -rf *
#
# Install Open Scanner Protocol for OpenVAS
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/ospd-openvas/archive/$ospd_openvas.tar.gz && \
tar -zxf $ospd_openvas.tar.gz && \
cd /build/*/ && \
python3 setup.py install && \
cd /build && \
rm -rf *
#
# Install GVM-Tools
#
RUN cd /build && \
wget --no-verbose https://github.com/greenbone/gvm-tools/archive/$gvm_tools_version.tar.gz && \
tar -zxf $gvm_tools_version.tar.gz && \
cd /build/*/ && \
python3 setup.py install && \
echo "/usr/local/lib" > /etc/ld.so.conf.d/openvas.conf && ldconfig && cd / && rm -rf /build
COPY scripts/* /
RUN chmod +x /*.sh
#RUN gvm-cli -c /gvm-tools.conf
################################## SSHD ##########################################
#RUN mkdir /var/run/sshd
RUN echo 'root:root' |chpasswd
RUN sed -ri 's/^#?PermitRootLogin\s+.*/PermitRootLogin yes/' /etc/ssh/sshd_config
RUN sed -ri 's/UsePAM yes/#UsePAM yes/g' /etc/ssh/sshd_config
RUN mkdir /root/.ssh
RUN apt-get clean && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
EXPOSE 22
#ENTRYPOINT /usr/sbin/sshd -D && bash
######################### SUPERVISORD #########################################################
#CMD '/start.sh'
CMD ["/usr/bin/supervisord"]
You need to configure your docker container to provide the Greenbone Management Protocol via SSH. This means you need some forwarding from ssh to gvmd. Howto do this exactly is out of scope for this forum.
Dear bricks,
thank you for your prompt answer. But let me Understand…
The python client has a gvm.connections.SSHConnection() method. You mean that this just does not work? I would imagine that developing a function would mean that it somehow should work. Moreover, the documentation you mentioned, does not really give any usable information concerning how to connect either with TLS or SSH.
Anyways, do you know if there is any other way to connect to a GVM scanner remotely with an IP … other than SSH…? I would imagine it would be TLS, but again The documentation is not very descriptive on how to do it. I know that I must create a config file. gvm-tools.conf. When I edit the file, should I restart the service (if yes how)?
Any info at this point would be very helpful.
Thank you!
What I want to express is that it does not work out of the box for users of the Greenbone Source Edition. For TLS you have to create certificates and change the configuration for the management daemon gvmd. For SSH you have to create some custom sshd config that forwards a port to a socket of gvmd. The TLS connection was our standard in the Greenbone OS <= 3.1. The SSH connection is used in Greenbone OS since version 4 now. Both setups needs some thinking and adjustments. But it’s feasible and no rocket science. If you want remote API access out-of-the box you should buy one of our products.
Dear Bricks,
again thank you very much for your very prompt answer, I really appreciate it!
d change the configuration for the management daemon gvmd.
can you tell me how? or just point me to the corresponding documentation?
For SSH you have to create some custom sshd config that forwards a port to a socket of gvmd.
can you tell me how? or just point me to the corresponding documentation?
I understand that it is feasible, and of course, it is not rocket science. But I think that even if the GVM now is the best product in vulnerability assessment, it really lacks thorough documentation. And this is a pitty!
If you watch this forum for some time, you see many people coming by complaining about many things who didn’t spend much time to search and find things in this forum, asking the same questions over and over again. There is a nice search function which gives many answers, although not all, that’s where new questions become interesting.
Downloading unvetted software and just running it, especially in a security context, is not the wisest thing to do. So this might warrant some research into how the tools actually work, especially at the point of entrance beyond security barriers, which is clearly the case in the topic you launched, and that point is one you need to defend and which is your responsibility if you administer or even just audit the network you want to use this tool in.
The sequence “download and shoot” might well end up shooting oneself in one’s foot, because “point and shoot” needs some training with “pointing”.
There is only so much one can do in a day, and this is true for all of us. But we also know well that TANSTAAFL, which I’d like to apply at “training” / “pointing” here.
Of course it’s a pity that documentation might be “better”, but a pity for whom? For those who build all this stuff and present it for free (as in freedom and beer), or for “the community” which is just eating lunch over lunch over lunch, sometimes while just complaining about this and that, and then just go away?
There are indeed people out there who do write the documentation they were missing before, for the benefit of many, scratching their and others itch in a true community spirit. And for many things you just need the right google terms. If you can’t even figure out these, then maybe there is some more learning to do to diligently defend the network(s) you care for.
It’s quite some work to do, admittedly, but there also is some fun in there, fun of creativity and mastery of the environment for the benefit and maybe joy of the people we do this for.
Not having thorough documentation, is bad for the community who wants to support this effort. I, as a researcher, do not want you or anybody to chew the food for me. I would like forums like that to be descriptive and assistive to those who seek guidance. The purpose of this forum…or so I understand is to provide help. By providing vague answers does not help anyone. From your point of view, you can say, these features are not described because we have a monetary interest. Which is fairly logical! Playing smart with people is not very smart after all.
Thank you for your time. I hope I did not offend you in any way. This is not my intention. I just want to participate in opensource projects be a part of their progress. And since I am a big fan of this I get a bit more emotional.
First: I’m not a GB official.
Second: I also hope I didn’t offend you in any way. Be welcomed, of course!
I feel just like you do.
Of course, structured information also needs time to be created, and there is a lot here indeed. The tools are in heavy development – just follow (OBSD-Speak) “git pull”, if you want --, so maybe not everything is synchronized all the time; who knows, I didn’t check that (and how would anybody check that?). There were also architechtural changes which broke things. But we have the source!
And the effort to help the users is indeed real, in this forum, in the sources, we just need to look, help and extend!
The meat is in the “nasl’s”, anyway.
Creating these profusely might be the best the community can do to support the project.
And now, with the newer architecture, also creating connectors for all kinds of scanners.
In other words, the new architecture is also a big open up of the tool for many, many evolution and implication possibilities.
That will make GVM unix socket to be exposed to test user TTY.
Here is code snippet that works:
from gvm.protocols.latest import Gmp
from gvm.transforms import EtreeTransform
from gvm.xml import pretty_print
connection = SSHConnection(hostname='192.168.99.121',username='test',password='test', port=2222)
transform = EtreeTransform()
with Gmp(connection, transform=transform) as gmp:
gmp.authenticate("admin", "admin")
version = gmp.get_version()
pretty_print(version)