Job for ospd openvas service failed because the control process exited with error code

ProgrammerAH

Programmer Guide, Tips and Tutorial

[Solved] Job for network.service failed because the control process exited with error code. See “systemctl st

Job for network.service failed because the control process exited with error code. See “systemctl status network.service” and “journalctl -xe” for details.

1、 The xshell is down and the reconnection failed. First Ping to see if the network is connected. Second, restart the network service and find an error. Third, view the error information according to the prompt. Fourth, solutions. First, check whether the configuration file is wrong. Second, there may be a conflict with the network manager service. Just close the service directly

3. If the two methods 1 and 2 still fail, try to delete all the other irrelevant network card location files under/etc/sysconfig/network scripts to avoid unnecessary influence. 5. Verify the network

Standby for a while, found that xshell connection failed, found that network connection failed, and restart failed.

1、 The xshell is down and the reconnection failed. Ping first to see if the network is connected

2、 Restart the network service and find an error

3、 Check the error information according to the prompt

1. Check whether the configuration file is wrong

2. There may be a conflict with the NetworkManager service. Just close the service directly

3. If both methods 1 and 2 fail after verification, try to delete all other irrelevant network card location files under/etc/sysconfig/network scripts to avoid unnecessary influence

Источник

greenbone / ospd-openvas Goto Github PK

ospd-openvas is an OSP server implementation to allow GVM to remotely control an OpenVAS Scanner

License: GNU Affero General Public License v3.0

Python 90.79% Dockerfile 0.61% Go 7.43% NASL 0.76% C++ 0.02% Shell 0.14% Makefile 0.25%

ospd-openvas’s People

Contributors

Stargazers

Watchers

Forkers

ospd-openvas’s Issues

Feature Request: Align Tasks UUID between gvmd / ospd-openvas

Environment:

Current behaviour:
Gvmd use one UUID for a task; while ospd-openvas use a different one for the same task.This make issues & bug tracking very difficult in a master / slave architecture when you have multiple scans running.

Expected behaviour:
Share the same tasks UUIDs between gvmd and ospd-openvas.

Kali linux : every scan aborted since last update — ospd-openvas error

Hello.
Since last update on kali (system and greenbone components), every scan are automatically aborted after ashort period of activity.
ospd.openvas.log report this :

OSPD[1841762] 2022-10-26 14:12:06,550: INFO: (ospd.command.command) Scan cb56381e-60fb-4dcf-b9d7-c9fe61a255a6 added to the queue in position 1.
OSPD[1841762] 2022-10-26 14:12:12,013: INFO: (ospd.ospd) Currently 1 queued scans.
OSPD[1841762] 2022-10-26 14:12:12,397: INFO: (ospd.ospd) Starting scan cb56381e-60fb-4dcf-b9d7-c9fe61a255a6.
OSPD[1841762] 2022-10-26 14:22:39,614: ERROR: (ospd.ospd) While handling client command:
Traceback (most recent call last):
File «/usr/lib/python3.10/multiprocessing/managers.py», line 810, in _callmethod
conn = self._tls.connection
AttributeError: ‘ForkAwareLocal’ object has no attribute ‘connection’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File «/usr/lib/python3/dist-packages/ospd/ospd.py», line 484, in handle_client_stream
self.handle_command(data, stream)
File «/usr/lib/python3/dist-packages/ospd/ospd.py», line 1223, in handle_command
response = command.handle_xml(tree)
File «/usr/lib/python3/dist-packages/ospd/command/command.py», line 453, in handle_xml
self._daemon.check_scan_process(scan_id)
File «/usr/lib/python3/dist-packages/ospd/ospd.py», line 1448, in check_scan_process
status = self.get_scan_status(scan_id)
File «/usr/lib/python3/dist-packages/ospd/ospd.py», line 670, in get_scan_status
status = self.scan_collection.get_status(scan_id)
File «/usr/lib/python3/dist-packages/ospd/scan.py», line 358, in get_status
status = self.scans_table[scan_id].get(‘status’)
File «», line 2, in get
File «/usr/lib/python3.10/multiprocessing/managers.py», line 814, in _callmethod
self._connect()
File «/usr/lib/python3.10/multiprocessing/managers.py», line 801, in _connect
conn = self._Client(self._token.address, authkey=self._authkey)
File «/usr/lib/python3.10/multiprocessing/connection.py», line 507, in Client
c = SocketClient(address)
File «/usr/lib/python3.10/multiprocessing/connection.py», line 635, in SocketClient
s.connect(address)
ConnectionRefusedError: [Errno 111] Connection refused
OSPD[1841762] 2022-10-26 14:22:40,428: WARNING: (ospd.ospd) Error sending data to the cli ent while executing a scan cb56381e-60fb-4dcf-b9d7-c9fe61a255a6.
OSPD[1866096] 2022-10-26 14:25:38,841: INFO: (ospd.main) Starting OSPd OpenVAS version 21 .4.5.dev1.

Dont’t know if related, but all the memory is occupied by Redis (8 gb + 3gb of swap) (openvas running, but no scan runnin) and a /24 «normal» scan use 100% of CPU.

feed-update.lock issues

GVM versions

gsa: 9.0.0 git-87b20cb24-gsa-9.0
gvm: 9.0.1 git-7518695a-gvmd-9.0

Environment

Ubuntu 18.04 TLS
Greenbone build from git

We notice that after some days the auto download of NVT’s does no longer work properly. When running greenbone-nvt-sync under the gvm user gives no return, it exits immediately. I think it’s because the feed-update.lock lock file is present in the run directory which should not be there.

When I remove ‘feed-update.lock’, I can successfully run greenbone-nvt-sync .

Also, when I reboot the server, the gvmd complains that the ospd.sock isn’t present. This is true, because ospd-openvas process seems to be locked when starting. Again, when I manually remove ‘feed-update.lock’, the ospd scanner continue’s its start and after it’s loaded the gvmd can read its socket.

If I leave the ‘feed-update.lock’ in place, it never ever gets deleted. There seems to be an issue with the ‘feed-update.lock` not being correctly handled/deleted. I have this in three separate setups with the exact same behavior.

Feature Request: Align logging timezone with gvmd, gsad and openvas (UTC)

Environment:

Expected behaviour:
Use same timezone for logging than gvmd, gsad and openvas.

Current behaviour:
Currently ospd-openvas use a specific time zone for events logging. This would be perfect if gsad, gvmd and openvas would use it as well. Unfortunately, gsad, gvmd and openvas uses UTC for events logging; so it becomes difficult to track issues between gvmd, openvas and ospd-openvas because timezones are not the same, especially since none of those time zones are the local time zone.

It would be nice if all tools could use the same time zone, and preferably the local time zone of the machine.

This feature request is complimentary of #287

openvas.service error on systemctl start openvas

Hi.
When running systemctl start openvas i got this error. I’ve tried different branch and tags and now i’m on 20.8.2 branch oldstable for ospd-openvas and also for ospd.

`openvas.service — Control the OpenVAS service
Loaded: loaded (/etc/systemd/system/openvas.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-12-13 13:04:05 UTC; 35s ago
Process: 7261 ExecStartPre=/usr/bin/rm -rf /opt/gvm/var/run/ospd-openvas.pid /opt/gvm/var/run/ospd.sock /opt/gvm/var/run/gvmd.sock (code=exited, status=0/SUCCESS)
Process: 7262 ExecStart=/usr/bin/python3 /opt/gvm/bin/ospd-openvas —pid-file /opt/gvm/var/run/ospd-openvas.pid —log-file /opt/gvm/var/log/gvm/ospd-openvas.log —lock-file-dir /opt/gv>
Main PID: 7262 (code=exited, status=1/FAILURE)

Dec 13 13:04:05 openvas python3[7262]: return self.execute_command(«KEYS», pattern, **kwargs)
Dec 13 13:04:05 openvas python3[7262]: File «/opt/gvm/lib/python3.8/site-packages/redis-4.1.0rc2-py3.8.egg/redis/client.py», line 1156, in execute_command
Dec 13 13:04:05 openvas python3[7262]: conn = self.connection or pool.get_connection(command_name, **options)
Dec 13 13:04:05 openvas python3[7262]: File «/opt/gvm/lib/python3.8/site-packages/redis-4.1.0rc2-py3.8.egg/redis/connection.py», line 1240, in get_connection
Dec 13 13:04:05 openvas python3[7262]: connection = self.make_connection()
Dec 13 13:04:05 openvas python3[7262]: File «/opt/gvm/lib/python3.8/site-packages/redis-4.1.0rc2-py3.8.egg/redis/connection.py», line 1280, in make_connection
Dec 13 13:04:05 openvas python3[7262]: return self.connection_class(**self.connection_kwargs)
Dec 13 13:04:05 openvas python3[7262]: TypeError: init() got an unexpected keyword argument ‘redis_connect_func’
Dec 13 13:04:05 openvas systemd[1]: openvas.service: Main process exited, code=exited, status=1/FAILURE
Dec 13 13:04:05 openvas systemd[1]: openvas.service: Failed with result ‘exit-code’.`

Exception when start daemon when empty pid file existed

Expected behavior

Daemon can start normally.

Actual behavior

Daemon can’t start if there is an empty pid file existed.

Steps to reproduce

1. Create an empty pid file.
2. Start ospd-openvas with the pid_file parameter points to the empty pid file

Logfiles

[1.0.0] Socket permissions will reset during startup

When the log message «DEBUG: (ospd_openvas.daemon) Loading vts in memory.» comes, the socket permission are as request by —socket-mode. But after the message «DEBUG: (ospd_openvas.daemon) Finish loading up vts.» the socket permission are reset to 0755.

ospd-openvas/config/ospd.conf

Theres a mistake (duplicate «unix_socket» section) in ospd-openvas/config/ospd.conf which will produce:

RuntimeError: Error while parsing config file [..]ospd.conf. Error was While reading from ‘[..]ospd.conf’ [line 5]: option ‘unix_socket’ in section ‘OSPD — openvas’ already exists

Second section should be «pid_file», of course.

[1.0.0] Error while connecting to redis is not catched.

When the daemon can’t read/write to the redis socket, then an python exception is thrown, but not catched.

File «/usr/bin/ospd-openvas», line 11, in
load_entry_point(‘ospd-openvas==1.0.0’, ‘console_scripts’, ‘ospd-openvas’)()
File «/usr/lib/python3.6/site-packages/ospd_openvas/daemon.py», line 1454, in main
daemon_main(‘OSPD — openvas’, OSPDopenvas)
File «/usr/lib/python3.6/site-packages/ospd/main.py», line 159, in main
daemon.init()
File «/usr/lib/python3.6/site-packages/ospd_openvas/daemon.py», line 283, in init
self.openvas_db.db_init()
File «/usr/lib/python3.6/site-packages/ospd_openvas/db.py», line 139, in db_init
self.max_db_index()
File «/usr/lib/python3.6/site-packages/ospd_openvas/db.py», line 117, in max_db_index
ctx = self.kb_connect()
File «/usr/lib/python3.6/site-packages/ospd_openvas/db.py», line 195, in kb_connect
‘Redis Error: Not possible to connect to the kb.’
ospd_openvas.errors.OspdOpenvasError: Redis Error: Not possible to connect to the kb.

KeyError: ‘vt_groups’ on command ‘start_scan’

I’m trying to create an independent scanner with openvas 7.0, ospd-openvas and gvm-cli to control it.

This error happened in a Debian 10, with everything installed from the latest stable release. More precisely, in the case of ospd-openvas, I installed it from pip.

When I try the examples of OSP API and send the «start_scan» command, the server responds with status code 200, but in the backend the scan fails with the following stacktrace:

In the scan report appears an error, Host process failure (‘vt_groups’) .

Any ideas about this error? I was unable to discover the reason for this error.

Setup.py, is it missing the notus module?

In setup.py, should it be:
packages=[‘ospd_openvas’,’ospd_openvas.notus’], ??

v20.4.1 sudoers problem

Just upgraded to tag version v20.4.1 . When running a task I get permissions problems. I’ve got my sudoers in place, just like with V20.4.0 .

visudo
Defaults secure_path=»/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/opt/gvm/sbin»

/etc/sudoers.d/gvm
gvm ALL = NOPASSWD: /opt/gvm/sbin/openvas
gvm ALL = NOPASSWD: /opt/gvm/sbin/gsad

Root dir is ‘/opt/gvm/’.

Has anything changed with v20.4.1? Dont understand whats the case here.

Undefined variables in wrapper.py

Both scan_id and target are undefined.

self . add_scan_error ( scan_id , host = target ,

ospd.errors.RequiredArgument: set_redisctx: Argument ctx is required

I was just testing the new ospd-openvas scanner and encounter the following errors when running a scan:

[21.4.0] Digital signature for the source code missing

The gpg sign for the source code is missing.

SSL Handshake error doing mutual authentication

i am having issues connecting my gvmd setup to a remote scanner using the certificates created with gvmd-manage-certs. Adding the scanner via GSAD and hitting the «Verify» button, i get the following error on the remote box:

on the remote i copied the following certifcates:

for the local scanner credentials, i’ve used the following certs:

Versions on the local side :

Versions on the remote side:

All binaries / scripts are grabbed from github and compiled on the latest «KALI LINUX» version (rolling).

Appreciate any input / suggestions

[1.0.0] discrepancy between help output and man page

ospd-openvas —help states:

while docs/ospd-openvas.8 tells:

and also
-p PORT, —port PORT TCP Port to listen on. Default: 0
vs.
TCP Port to listen on. Default: 1234

[21.4.1] release missing on PyPI

ospd-openvas pip package is not up to date and contains a bug

@jjnicola have fixed the bug on August 13: 9ff3e0c

The pip package still contains the bug fixed in that commit.

Error associated with the bug:
ospd_openvas.errors.OspdOpenvasError: Error setting nvticache. Incompatible nvticache version 20.8.0

git-a03eec19-HEAD. Supported versions are >=11.0.

TypeError: lrem() got an unexpected keyword argument ‘count’

With ospd-openvas 1.0.0

2020-01-14 13:05:29,249 OSPD — openvas: ERROR: (ospd.ospd) While scanning aa,bb,cc,dd/xx:
Traceback (most recent call last):
File «/usr/lib/python3/dist-packages/ospd/ospd.py», line 777, in parallel_scan
ret = self.exec_scan(scan_id, target)
File «/usr/lib/python3/dist-packages/ospd_openvas/daemon.py», line 1441, in exec_scan
self.openvas_db.remove_list_item(‘internal/dbindex’, i)
File «/usr/lib/python3/dist-packages/ospd_openvas/db.py», line 291, in remove_list_item
ctx.lrem(key, count=LIST_ALL, value=value)

unable to change socket_mode

I have tried to specify in both config file /etc/openvas/ospd.conf and command line via —socket-mode=0o777 but none worked.

Would you have any ideas?

I’m using the latest version 1.0.0

AttributeError: ‘NoneType’ object has no attribute ‘pop’

With ospd-openvas 1.0.0 — might be related to the timeout change — worked around this by calling continue if None == _custom

jan 14 12:59:55 openvas ospd-openvas[25014]: Traceback (most recent call last):
jan 14 12:59:55 openvas ospd-openvas[25014]: File «/usr/bin/ospd-openvas», line 11, in
jan 14 12:59:55 openvas ospd-openvas[25014]: load_entry_point(‘ospd-openvas==1.0.0’, ‘console_scripts’, ‘ospd-openvas’)()
jan 14 12:59:55 openvas ospd-openvas[25014]: File «/usr/lib/python3/dist-packages/ospd_openvas/daemon.py», line 1454, in main
jan 14 12:59:55 openvas ospd-openvas[25014]: daemon_main(‘OSPD — openvas’, OSPDopenvas)
jan 14 12:59:55 openvas ospd-openvas[25014]: File «/usr/lib/python3/dist-packages/ospd/main.py», line 159, in main
jan 14 12:59:55 openvas ospd-openvas[25014]: daemon.init()
jan 14 12:59:55 openvas ospd-openvas[25014]: File «/usr/lib/python3/dist-packages/ospd_openvas/daemon.py», line 293, in init
jan 14 12:59:55 openvas ospd-openvas[25014]: self.load_vts()
jan 14 12:59:55 openvas ospd-openvas[25014]: File «/usr/lib/python3/dist-packages/ospd_openvas/daemon.py», line 413, in load_vts
jan 14 12:59:55 openvas ospd-openvas[25014]: _name = _custom.pop(‘name’)
jan 14 12:59:55 openvas ospd-openvas[25014]: AttributeError: ‘NoneType’ object has no attribute ‘pop’

[20.8.0] Service unavailable when verifying ospd-openvas scanner over tcp

Problem: When running an ospd-openvas scanner on a TCP socket, gvmd fails to connect to it even though the certificates handshake is correct. Both GVMD and OSPD are running on the same system. Obviously same problem happens if ospd is run on a different IP. See below

Scanner is launched with the following command:

/opt/gvm/bin/ospd-scanner/bin/python3.7 /opt/gvm/bin/ospd-scanner/bin/ospd-openvas -s /opt/gvm/etc/openvas/ospd.conf —log-file /opt/gvm/var/log/gvm/ospd-scanner-remote.log -p 9392 -b 127.0.0.1 —pid-file /opt/gvm/var/run/ospd-openvas-remote.pid —lock-file-dir /opt/gvm/var/run/ -k /opt/gvm/var/lib/gvm/private/CA/serverkey.pem -c /opt/gvm/var/lib/gvm/CA/servercert.pem —ca-file /opt/gvm/var/lib/gvm/CA/cacert.pem -L DEBUG -f

On Gvmd, scanner is added using:

gvmd —create-scanner=TestRemoteScanner —scanner-type=OpenVAS —scanner-port=9392 —scanner-host=127.0.0.1 —scanner-ca-pub=/opt/gvm/var/lib/gvm/CA/cacert.pem —scanner-key-priv=/opt/gvm/var/lib/gvm/private/CA/clientkey.pem —scanner-key-pub=/opt/gvm/var/lib/gvm/CA/clientcert.pem

Scanner is created successfully. Now If I try to verify the scanner:

If I manually check the certificate handshake using:

openssl s_client -connect 127.0.0.1:9392 -cert /opt/gvm/var/lib/gvm/CA/clientcert.pem -key /opt/gvm/var/lib/gvm/private/CA/clientkey.pem -CAfile /opt/gvm/var/lib/gvm/CA/cacert.pem -reconnect -showcerts -debug

connects and sending manually with openssl gets answered with

So the cert infrastructure created with gvm-manage-certs is correct and the initial dialog seems to work fine.

However, on GVMD side, I have the following logs:

scanner still running after stop it on GSA Web UI.

Environment

• openvas: 21.10.0 dev1 git-0b879efc-master
• gvm-libs 21.10.0 dev1 git-55465356-master
• ospd: 21.10.0.dev1
• ospd-openvas: 21.10.0.dev1

Issue

Hello, I have noticed that after stopped the running full and fast scan task,
the scanner process still keep running in the background.

Then, I read the code and noticed these following code snippets of ospd-openvas:

It seems ospd never send any signal to the scanner when stopping,
and just waiting for the process to finish its current job.

Does it has some other mechanism to notify the scanner process?

Or, this behavior is by design?

Working installation of GVM11 stops working on ospd-openvas

I am getting the following error from ospd-openvas when issuing the command ospd-openvas —help

The installation that this is happening on was totally stable and this change has come from day to day. How to address this?

NVT updates won’t finish properly in case openvas scan is finished, but still running for gsad / gvmd and so will stuck new scans requests

Environment:

Current behaviour:
If you have a scan shown as completed on openvas / ospd-openvas side, but still in Running state on gvmd / gsad side, and a NVT update start; then the update won’t finish properly preventing new scans to start.

In the following example; scan has terminated properly and later a NVT update is launched:

On ospd-openvas side; scan is seen has finished but update never finish:

However; the update is still considered as pending, even hours after last logged event, and the following update log never show up:
OSPD — openvas: INFO: (ospd_openvas.daemon) Finish loading up vts.

As a consequence, further scan requests will automatically fails since ospd-openvas still consider there is a pending update:
2020-07-25 10:56:50,170 OSPD — openvas: INFO: (ospd_openvas.daemon) c6ccea2a-3ca3-47a2-be89-d6319fb8f9d3: There is a pending feed update. The scan can not be started.

Expected behaviour:
When a scan is done on openvas / ospd-openvas side; NVT updates shouldn’t be stuck and should finish properly.

How to reproduce:

1. Start a scan on somehow important tasks, so that results calculation by gvmd will keep running after ospd-openvas complete
2. When openvas / ospd-openvas side has completed task scan; run a feed update on the scanner
3. After a reasonable delay, where feed update should be finished, launch a new scan
4. Scan will be automatically set in «Done» state with report set in «Error» as a pending update is stuck forever.

Pulling the active scans with gvm-cli

Environment:
Greenbone Vulnerability Manager 20.08.0git-c04cad16-gvmd-20.08
Greenbone Security Assistant 20.08.0git-d26e061f9-gsa-20.08
OSP Server for openvas: 20.8.0
OSP: 20.8.1
OSPd OpenVAS: 20.8.1
gvm-cli 20.10.2.dev1 (API version 20.11.3)
Ubuntu 20.04

I have an issue where gvmd believes that running scans are terminating, often «interrupted», and I’ve yet to figure out quite why.
In the meantime, I am also using the «max scans» setting in ospd-openvas to type and keep things trimmed down to 2 parallel scans, and also often find that although gvmd says the scans are not running, ospd thinks they are; scans queue and I often get «(ospd.ospd) Not possible to run a new scan. Max scan limit set to 2 reached.» in the logs. I realise I could just remove this limit, but I’d like to have things a bit more exact:

I was trying to make it all a bit more «closed-loop» by using gvm-cli to pull a list of known running scans using

gvm-cli —protocol OSP socket —socketpath /opt/gvm/var/run/ospd.sock —xml=» «

but unlike the gmp protocol, this does not produce a list, just an error ; «Response Error 400. No scan_id attribute».
Is there a way of simply pulling the number of running scans on the ospd side without knowing the «scan_id», so I can equate them to the number of running scans within gvm and restart the service if different? Even more ideally I’d also know the uuids or some other attribute which could be used to match task to scan so I can selectively cull stuff in the scanner.
I realise the uuids are dissimilar so I can’t query a specific scan without scouring logs to see what’s running and get the uuids, more difficult and hacky to script whilst rotating logs and so on behind the scenes.

It’s my first delve into the use of gvm-cli with the OSP protocol so I may have missed something!

Kind Regards
Andy

Start ospd-openvas — socket + port

When not specified «-b 0.0.0.0 -p 51234», the .sock file is created.

When «-b 0.0.0.0 -p 51234» is specified, the .sock file is not created.

Is it possible to start the service by listening on the port, and the socket?

TypeError: int() argument must be a string, a bytes-like object or a number, not ‘NoneType’

In ospd-openvas 1.0.0, i worked around it with if None == timeout: timeout = 120 to continue testing

jan 14 10:50:24 openvas ospd-openvas[16659]: Traceback (most recent call last):
File «/usr/bin/ospd-openvas», line 11, in
load_entry_point(‘ospd-openvas==1.0.0’, ‘console_scripts’, ‘ospd-openvas’)()
File «/usr/lib/python3/dist-packages/ospd_openvas/daemon.py», line 1454, in main
daemon_main(‘OSPD — openvas’, OSPDopenvas)
File «/usr/lib/python3/dist-packages/ospd/main.py», line 159, in main
daemon.init()
File «/usr/lib/python3/dist-packages/ospd_openvas/daemon.py», line 293, in init
self.load_vts()
File «/usr/lib/python3/dist-packages/ospd_openvas/daemon.py», line 410, in load_vts
_vt_params = self.nvti.get_nvt_params(vt_id)
File «/usr/lib/python3/dist-packages/ospd_openvas/nvticache.py», line 82, in get_nvt_params
if int(timeout) > 0:
TypeError: int() argument must be a string, a bytes-like object or a number, not ‘NoneType’

UnicodeDecodeError: ‘ascii’ codec can’t decode

The lastest version: 20.8.0
when I started ospd service, error occured

It should be utf-8 instead of ascii.

[22.4.0] Test test_port_convert fails

The test tests/test_port_convert.py fails with:
==================================== ERRORS ====================================
_________________ ERROR collecting tests/test_port_convert.py __________________
tests/test_port_convert.py:46: in
logging.disable()
E TypeError: disable() missing 1 required positional argument: ‘level’
. Interrupted: 1 errors during collection .
=========================== 1 error in 0.30 seconds ============================
Reading the python doc’s:
https://docs.python.org/3/library/logging.html#module-logging
It will requires an options.

Resumed tasks may generate invalid target value error on ospd-openvas side

Environment:

Expected behaviour:
Tasks resumed shouldn’t produce any target errors on ospd-openvas side.

Actual behaviour:
If a task stop while running for whatever reason; resuming it may generated continuous Invalid target value errors on ospd-openvas side. Target has not been changed, and starting the task again (without resuming it) will not produce those errors:

It is not clear if this bug has any effect on scans results, since openvas logs doesn’t show any errors and resume the scans without problem; while no error is reported on gsad / gvmd side.

How To reproduce:

• Start a task
• After at least 50-60% achieved; stop the task.
• Once stopped; resume the task.
• Look at ospd-openvas logs for the upon errors.

Note: The issue do not always occurs; but is likely to occurs on big tasks (/22 or higher)

Container «greenbone/ospd-openvas:stable» does not start

I followed the manual on https://greenbone.github.io/docs/latest/21.04/container to use the Greenbone Docker containers.
The container «greenbone/ospd-openvas:stable» does not start. It’s restarting all the time

Expected behavior

It should start

Actual behavior

It’s restarting everytime

Steps to reproduce

Just start the Containers from the compose file

GVM versions

Latest stable docker containers

Environment

Operating system:
Ubuntu 20.04.4 LTS

Installation method / source: (packages, source installation)
Docker-compose

Logfiles

[20.8.0] Unexpected interrupted return code

The scanner self will exits fine, but ospd-openvas will interpret it as an error.
ospd-openvas log:

(ospd.ospd) aae6b036-7a1c-47d4-8866-0e07c8799b48: Host scan finished.
(ospd.ospd) aae6b036-7a1c-47d4-8866-0e07c8799b48: Scan interrupted.
(ospd.ospd) aae6b036-7a1c-47d4-8866-0e07c8799b48: Scan stopped with errors.
(ospd.ospd) aae6b036-7a1c-47d4-8866-0e07c8799b48: Scan interrupted.

Vulnerability scan d667271d-11ef-4e68-bc0c-39fa0659e778 finished for host XXXXX in 993.56 seconds
Vulnerability scan d667271d-11ef-4e68-bc0c-39fa0659e778 finished in 1000 seconds: 1 hosts

No error was logged by openvas.

Most new code since 2005: (C) 2020 Greenbone Networks GmbH
Nessus origin: (C) 2004 Renaud Deraison [email protected]
License GPLv2: GNU GPL version 2
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[22.4.2] — raise Exception(«GPG verification of notus sha256sums failed»)

Running into an error with the latest version 22.4.2 (downgrading back to 22.4.0 resolves the problem).

Expected behavior

Starting up and running without any issues (like 22.4.0 did and still does for me).

Actual behavior

Running into the following error since upgrading from 22.4.0 to 22.4.2.

Steps to reproduce

1. upgrade ospd-openvas from the previously working 22.4.0 to 22.4.2
2. start service
3. run into error

GVM versions

gsa: Greenbone Security Assistant 22.04.0

gvm: Greenbone Vulnerability Manager 22.4.0

openvas-scanner: OpenVAS 22.4.0

gvm-libs: gvm-libs 22.4.0

Environment

Operating system: Exherbo Linux

Installation method / source: source-based packages

Logfiles

Note for the MQTT broker WARNING: I’ve not yet setup MQTT & packaged notus-scanner, so I already had that warning with 22.4.0 previously as well of course.

I also tried adding notus-feed-dir = /var/lib/notus/advisories to the ospd-openvas.conf as I’ve seen it’s also passed in your systemd file suggestion at https://greenbone.github.io/docs/latest/22.4/source-build/index.html#setting-up-services-for-systemd but it didn’t make any difference.

openvas finishes task, ospd-openvas keeps looking elsewhere.

OpenVAS 7.0.1
gvm-libs 11.0.1
OSP Server for openvas: 1.0.1
OSP: 1.2
OSPd: 2.0.1
python2.6
Ubuntu 18.04 LTS
Redis 4.09 with GVMd tuned configuration file

I have a scan running on a somewhat important task (3642 IP, with many dead hosts). When I run this task, openvas is launched by ospd-openvas without problems. Both are located on the same machine.
After some times, openvas finish scanning the task as it’s suppose to:

sd main:MESSAGE:2020-05-14 20h42.23 utc:6675: Test complete
sd main:MESSAGE:2020-05-14 20h42.23 utc:6675: Total time to scan all hosts : 115770 seconds

However ospd-openvas seems to have lost communication in the middle with openvas & gvmd, as the last log entry reads 2020-05-13 (while openvas last log is 2020-05-14). No error logged. Process is still running and loaded:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6669 gvm 20 0 725872 537896 5744 R 87.5 3.2 829:27.94 python3.6
6666 gvm 20 0 375068 178548 5120 S 6.2 1.1 8:30.31 python3.6

On gvmd side, task is still running but stuck at 7% since more than one day. The problem is not systematic; out of 10 launches it occurs around 5-6 times. Other 4-5 times scan will finish successfully.

My ospd-openvas process is still running, in case I can do anything to help investigating wha’s going on.

OpenVAS does not clear stale pid files when current pid matches old pid

Expected behavior

When starting ospd-openvas in Docker after a hard shutdown, OpenVAS recognizes that the PID file at /run/ospd/ospd-openvas.pid is stale, removes it, and continues to start.

Actual behavior

OpenVAS displays the following error:

Steps to reproduce

1. Follow the instructions at https://greenbone.github.io/docs/latest/22.4/container/index.html to set up the Greenbone Community Containers.
2. Kill the ospd-openvas suddenly with docker compose kill ospd-openvas
3. Attempt to restart the container with docker compose up ospd-openvas

GVM versions

gsa: 22.04.0

gvm: 22.4.0

openvas-scanner: 22.4.1

gvm-libs: 22.4.1

Environment

Operating system:

Installation method / source: Official docker-compose.yml file on https://greenbone.github.io/docs/latest/22.4/container/index.html

Proposed fix

There was already an attempt to fix this in 200079a. The fix doesn’t work in a docker environment because with docker OpenVAS runs in a pid namespace where it always sees its pid as 1. Therefore the check at

if process_name == new_process_name :

That line should be updated to also check if the pid in the file matches the pid of the current process, and clear the file if it does.

ospd.openvas [21.4.3] — randomely stay stuck in INIT phase when a new scan is launched

Expected behavior

1. Launch a scan
2. Scan will pass the normal phases; QUEUED, INIT, RUNNING
3. Scan will exit once completed successfully
4. In case a scan is stuck for whatever reason on the scanner side, GSA should allow the user to force stop of the task. There should be some time out for the REQUESTED status, at least as a workaround for the current bug.

Actual behavior

1. Run a scan via GSA 21.4.3 against a slave ospd.openvas daemon, hosted on the network
2. Scan will occasionaly remains stucks in INIT phase on ospd.openvas, and will therefore stays stuck forever in «REQUESTED» state on GSA
3. Only way to force GSA to recover control of the scan is to kill the related ospd.openvas process, which will force the scan task as Stopped.

Steps to reproduce

None, as this unfortunately happens randomely.

GVM versions

gsa: Greenbone Security Assistant 21.4.3

gvm: Greenbone Vulnerability Manager 21.4.3
Manager DB revision 242

openvas-scanner: OpenVAS 21.4.3
gvm-libs 21.4.3

Environment

Operating system:
Linux ov-slave-kolding 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[email protected]:

$ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=19.1
DISTRIB_CODENAME=tessa
DISTRIB_DESCRIPTION=»Linux Mint 19.1 Tessa»

Installation method / source: source installation

Logfiles

[ 1.0.1] Source file signature is missing

For the last release, then signature of source tar file is missing.

failure when starting a remote scan, KeyError: ‘end_time’

I’m attempting to set up a distributed scan environment with gvmd and gsa running on a central system and ospd-openvas instances spread around to execute the tasks and send them back to the central system. I found a super convenient docker implementation of this environment that handles the setup and connection of these instance here https://github.com/Secure-Compliance-Solutions-LLC/GVM-Docker. I’m able to get both an instance of the gvm controller and an instance of the ospd-openvas scanner running and connected. My problem comes when I try to initiate my first remote scan. When I queue the scan to start, it is sent to the remote scanner and immediately prints out the stack error pasted below in openvas.log.

OSPD[50] 2020-12-10 16:49:28,867: INFO: (ospd.command.command) Scan 37dda0d5-cb26-4f33-a238-88216a587923 added to the queue in position 1.

Traceback (most recent call last):
File «/usr/local/bin/ospd-openvas», line 11, in
load_entry_point(‘ospd-openvas==20.8.0’, ‘console_scripts’, ‘ospd-openvas’)()
File «/usr/local/lib/python3.8/dist-packages/ospd_openvas-20.8.0-py3.8.egg/ospd_openvas/daemon.py», line 1383, in main
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/main.py», line 160, in main
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/ospd.py», line 1255, in run
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/ospd.py», line 1398, in clean_forgotten_scans
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/ospd.py», line 1487, in get_scan_end_time
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/scan.py», line 424, in get_end_time
File «», line 2, in getitem
File «/usr/lib/python3.8/multiprocessing/managers.py», line 850, in _callmethod
raise convert_to_error(kind, result)
KeyError: ‘end_time’
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File «/usr/lib/python3.8/multiprocessing/managers.py», line 827, in _callmethod
conn = self._tls.connection
AttributeError: ‘ForkAwareLocal’ object has no attribute ‘connection’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/main.py», line 81, in exit_cleanup
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/ospd.py», line 438, in daemon_exit_cleanup
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/scan.py», line 242, in clean_up_pickled_scan_info
File «/usr/local/lib/python3.8/dist-packages/ospd-20.8.1-py3.8.egg/ospd/scan.py», line 340, in get_status
File «», line 2, in get
File «/usr/lib/python3.8/multiprocessing/managers.py», line 831, in _callmethod
self._connect()
File «/usr/lib/python3.8/multiprocessing/managers.py», line 818, in _connect
conn = self._Client(self._token.address, authkey=self._authkey)
File «/usr/lib/python3.8/multiprocessing/connection.py», line 502, in Client
c = SocketClient(address)
File «/usr/lib/python3.8/multiprocessing/connection.py», line 629, in SocketClient
s.connect(address)
FileNotFoundError: [Errno 2] No such file or directory
connect to /data/ospd.sock port -2 failed: Connection refused
connect to /data/ospd.sock port -2 failed: Connection refused

I’m unsure if the docker environment I’m using could be causing this, but it seems to just be an error when starting a remotely initiated scan. Any help would be appreciated.

python 3.9 support, importlib.metadata.PackageNotFoundError: ospd-openvas

Environment: Fedora 33

I believe the format for python 3.9 handling metadata has changed. So my guess is that python setup isnt installing things if you declare PYTHONPATH 3.9:

export PYTHONPATH=/opt/atomicorp/lib/python3.9/site-packages
python3 setup.py install —prefix=/opt/atomicorp/

This does however work just fine if you are not declaring the PYTHONPATH, and write (or overwrite in this case) to the system site-packages at /usr/lib/python3.9/site-packages.

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.

Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

TensorFlow

An Open Source Machine Learning Framework for Everyone

Django

The Web framework for perfectionists with deadlines.

Laravel

A PHP framework for web artisans

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

Some thing interesting about web. New door for the world.

server

A server is a program made to process requests and deliver data to clients.

Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

Visualization

Some thing interesting about visualization, use data art

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.

Microsoft

Open source projects and samples from Microsoft.

Источник

• Перейти на CTF площадку Игры Кодебай

  Выполняйте задания по кибербезопасности в формате CTF и получайте бесценный опыт. Ознакомиться с подробным описанием можно тут.

• B правой части каждого сообщения есть стрелки ⇧ и ⇩. Не стесняйтесь оценивать ответы. Чтобы автору вопроса закрыть свой тикет, надо выбрать лучший ответ. Просто нажмите значок ✔ в правой части сообщения.

Job for ospd-openvas.service failed because the control process exited with error code.
See "systemctl status ospd-openvas.service" and "journalctl -xe" for details.

При вводе команди systemctl status ospd-openvas.service виводит

ospd-openvas.service - OpenVAS Wrapper of the Greenbone Vulnerability Management (ospd-openvas)
     Loaded: loaded (/lib/systemd/system/ospd-openvas.service; disabled; vendor preset: disabled)
     Active: activating (auto-restart) (Result: exit-code) since Fri 2021-09-17 14:37:36 EEST; 30s ago
       Docs: man:eek:spd-openvas(8)
             man:eek:penvas(8)
    Process: 4476 ExecStart=/usr/bin/ospd-openvas --unix-socket /run/ospd/ospd.sock --pid-file /run/ospd/ospd-openvas.pid --log-file /var/log/gvm/ospd-openvas.log --lock-fi>
        CPU: 187ms

При вводе  journalctl -xe

The unit redis-server@openvas.service has entered the 'failed' state with result 'exit-code'.
вер 17 14:38:37 cors-tobefilledbyoem systemd[1]: Failed to start Advanced key-value store (openvas).
░░ Subject: A start job for unit redis-server@openvas.service has failed
░░ Defined-By: systemd
░░ Support: Debian -- Support
░░
░░ A start job for unit redis-server@openvas.service has finished with a failure.
░░
░░ The job identifier is 5964 and the job result is failed.
вер 17 14:38:37 cors-tobefilledbyoem systemd[1]: redis-server@openvas.service: Scheduled restart job, restart counter is at 5.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: Debian -- Support
░░
░░ Automatic restarting of the unit redis-server@openvas.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
вер 17 14:38:37 cors-tobefilledbyoem systemd[1]: Stopped Advanced key-value store (openvas).
░░ Subject: A stop job for unit redis-server@openvas.service has finished
░░ Defined-By: systemd
░░ Support: Debian -- Support
░░
░░ A stop job for unit redis-server@openvas.service has finished.
░░
░░ The job identifier is 6048 and the job result is done.
вер 17 14:38:37 cors-tobefilledbyoem systemd[1]: redis-server@openvas.service: Start request repeated too quickly.
вер 17 14:38:37 cors-tobefilledbyoem systemd[1]: redis-server@openvas.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: Debian -- Support
░░
░░ The unit redis-server@openvas.service has entered the 'failed' state with result 'exit-code'.
вер 17 14:38:37 cors-tobefilledbyoem systemd[1]: Failed to start Advanced key-value store (openvas).
░░ Subject: A start job for unit redis-server@openvas.service has failed
░░ Defined-By: systemd
░░ Support: Debian -- Support
░░
░░ A start job for unit redis-server@openvas.service has finished with a failure.
░░
░░ The job identifier is 6048 and the job result is failed.
вер 17 14:38:40 cors-tobefilledbyoem gvmd[4583]: (process:4583): libgvm base-WARNING (recursed) **: Failed to create log file directory /var/log/gvm: Permission denied
вер 17 14:38:40 cors-tobefilledbyoem gvmd[4616]: (process:4616): libgvm base-WARNING (recursed) **: Failed to create log file directory /var/log/gvm: Permission denied
вер 17 14:38:50 cors-tobefilledbyoem gvmd[4613]: (process:4613): libgvm base-WARNING (recursed) **: Failed to create log file directory /var/log/gvm: Permission denied
вер 17 14:38:50 cors-tobefilledbyoem gvmd[4625]: (process:4625): libgvm base-WARNING (recursed) **: Failed to create log file directory /var/log/gvm: Permission denied

export LC_ALL="C" &&
ldconfig &&
cp /etc/redis/redis.conf /etc/redis/redis.orig &&
cp /opt/gvm/src/openvas/config/redis-openvas.conf /etc/redis/ &&
chown redis:redis /etc/redis/redis-openvas.conf &&
echo "db_address = /run/redis-openvas/redis.sock" > /opt/gvm/etc/openvas/openvas.conf &&
systemctl enable redis-server@openvas.service &&
systemctl start redis-server@openvas.service
sysctl -w net.core.somaxconn=1024 &&
sysctl vm.overcommit_memory=1 &&
echo "net.core.somaxconn=1024" >> /etc/sysctl.conf &&
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf
systemctl daemon-reload &&
systemctl start disable-thp &&
systemctl enable disable-thp &&
systemctl restart redis-server

It’s time to cover some vulnerability scanning! What better way to start this than with the installation of OpenVAS? Today I will show you how to install OpenVAS on Kali Linux in a step-by-step guide for you to follow along.

Table of Contents

• What is OpenVAS?
• Step 1 – Install OpenVAS on Kali Linux
• Step 2 – Configuring OpenVAS
• Step 3 – Running your first Scan
• Finding Exploits with OpenVAS
• Troubleshooting
  • PostgreSQL Version Errors v13 and v14
  • PostgreSQL Version Errors v14 and v15
  • OpenVAS failed to find config
• Conclusion

⚠️ Kali Linux Wiki
➡️ Download Kali Linux Safe & Easy
➡️ Install Kali Linux on VirtualBox
➡️ Install Kali Linux on VMWare Workstation
➡️ Dual Boot Kali Linux with Windows
➡️ Install Kali Linux on WSL 2
➡️ Install Kali Linux on a Laptop
➡️ Install VSCode on Kali Linux
➡️ Install OpenVAS on Kali Linux
➡️ Install Docker on Kali Linux
➡️ WiFi Adapter for Kali Linux

What is OpenVAS?

OpenVAS is an open-source vulnerability scanner. OpenVAS started under the name of GNessUs, a fork of the previously open-source Nessus scanning tool (which costs you money now). OpenVAS is also under the GNU General Public License (GPL).

I personally used this software in many different kinds of assessments and was always satisfied with the results I got (keeping in mind that it is completely free).

Of course, tools like Nessus and NeXpose are more feature-rich, but they come with a high price tag too.

For starters, OpenVAS is simply perfect and gives you a good idea of how a vulnerability scanner works. I also found it very intuitive to work with.

So without further ado, let’s dive right into the installation.

The first thing we want to do is to make sure that our Kali installation is up-to-date. So open a terminal window and run:

sudo apt update && sudo apt upgrade -y
Code language: Bash (bash)

This will update your repository and upgrade your Kali, the -y at the end saves you a press of the button “Y” in the process.

The next thing we want to do is to install OpenVAS. Again in the Terminal type:

sudo apt install openvas
Code language: Bash (bash)

Confirm that you are aware that an additional ~1,2 Gigabyte of Disk Space will be used by pressing Y.

Now this will take a good while. Grab a coffee or prepare some Yerba Mate while we are waiting 🙂

Once that is done we will run another command in the terminal window:

sudo gvm-setup
Code language: Bash (bash)

Note: In case you run into a PostgreSQL error – check out the troubleshooting section at the end of this article.

This is going to take very long.

Phew… That took about 2 hours for me to finish. I still didn’t get why it takes so long, but just go for a long walk and come back later…

After the setup process is finished, don’t forget to note down your password that was generated at the end, you need it to log in for the first time.

Step 2 – Configuring OpenVAS

The installation is now finished. Next, we verify if our installation is working.

sudo gvm-check-setup
Code language: Bash (bash)

I got an error (SCAP DATA are missing), but if you look through the error message, you can see that you can fix it by running:

sudo runuser -u _gvm -- greenbone-feed-sync --type SCAP
Code language: Bash (bash)

This fixed my issue.

First, we are starting the OpenVAS Service.

sudo gvm-start
Code language: Bash (bash)

Now your OpenVAS Service should be up and running. OpenVAS listens on the Ports: 9390, 9391, 9392, and on Port 80. Your web browser should automatically open and lead to the OpenVAS Login Page.

If not, open a web browser manually and enter the URL

https://127.0.0.1:9392
Code language: Bash (bash)

The first time you want to open this URL you will get a security warning. Click on Advanced and Add an Exception.

Remember the password you noted down before? Now we are going to need it.

Forgot your Admin Password?

Reset it by typing: sudo gvmd --user=admin --new-password=passwd;

Log in to OpenVAS with admin // your password

First things first – Navigate to To your User Profile / My Settings / Click on Edit and change the password.

This is basically all you need to do. OpenVAS is now running and ready for use.

Step 3 – Running your first Scan

Now it’s time to run our first scan.

As this is just the installation part I won’t go into details, but I will show you quickly how to run your first scan. There will be more articles covering OpenVAS and we will continue looking into all of the different options we have and how to process scan results.

So the easiest way is simply to Navigate to Scans / Tasks and click on the little Magic Wand icon and start the Task Wizard.

Now you can enter either a single IP, a whole subnet, a range of IP Addresses, or a domain.

This will start a default-depth scan. Depending on the scale of the Network you want to scan this can take from a few minutes up to several hours or even days if the network is large enough and you choose a deep scan.

This and more will be covered in the next article for OpenVAS, which is coming soon.

Finding Exploits with OpenVAS

I created a video a while ago on how to find Exploits using OpenVAS, which basically goes through the whole process of scanning and then finding Exploits for your findings. The video is a bit older but still valid. Give it a watch if you want to learn how to use OpenVAS in-depth.

Troubleshooting

There is a lot that can go wrong during the installation of OpenVAS as some of our readers has pointed out, therefore, we decided to create a little extra section here, covering the most common errors.

PostgreSQL Version Errors v13 and v14

There are multiple possible version errors for PostgreSQL. As our reader Tom has pointed out, the first one is:

[>] Starting PostgreSQL service
[-] ERROR: The default PostgreSQL version (13) is not 14 that is required by libgvmd
[-] ERROR: Use pg_upgradecluster to update your PostgreSQL cluster

Solution:

Open the postgresql.conf file of version 14 and change the port to 5432:

sudo nano /etc/postgresql/14/main/postgresql.conf

Then open the postgresql.conf file of version 13 and check if the port is the same as in version 14. If it is the same – change it to 5433:

sudo nano /etc/postgresql/13/main/postgresql.conf

Restart the PostgreSQL service:

sudo systemctl restart postgresql

PostgreSQL Version Errors v14 and v15

During my installation, I got the following error affecting v14 and v15 of PostgreSQL:

[>] Starting PostgreSQL service
[-] ERROR: The default PostgreSQL version (14) is not 15 that is required by libgvmd
[-] ERROR: Use pg_upgradecluster to update your PostgreSQL cluster

Gladly, the solution to this problem was easier than the one above and might as well work for the problem above:

sudo systemcctl stop postgresql@14-main
sudo /usr/bin/pg_dropcluster --stop 14 main
Code language: CSS (css)

OpenVAS failed to find config

Another common error is the failed to find config ‘long-string-value’ message. There are multiple possible solutions for this issue. The one that worked for me is the following:

sudo runuser -u _gvm – gvmd --get-scanners
Code language: JavaScript (javascript)

Note down the scanner ID.

Then run:

sudo runuser -u _gvm – gvmd --get-users --verbose
Code language: JavaScript (javascript)

This gives you the users, including their IDs. You are probably an admin. To solve the issue, enter:

sudo runuser -u _gvm – gvmd --modify-scanner [scanner id] --value [user id]
Code language: CSS (css)

Conclusion

This is how easy it is to install OpenVAS on Kali Linux and start a basic scan. There is a lot more to learn about OpenVAS, but this should get you up and running in no time!

👀 This Tutorial has some related Articles!
👉 How to get started in Cyber Security – The Complete Guide
👉 How to get started with Bug Bounties
👉 Terminal Customization Series
👉 Best Ethical Hacking Books
👉 Download Kali Linux Safe & Easy
👉 Best Ethical Hacking Tools
👉 Install VSCode on Kali Linux
👉 Dual Boot Kali Linux with Windows
👉 Install Kali Linux on VirtualBox – Complete Beginner Guide
👉 Top Things to do after installing Kali Linux
👉 WiFi Adapter for Kali Linux – The Ultimate Guide
👉 Nmap Beginner Guide Series
👉 Metasploit Tutorial Series
👉 Burp Suite Beginner Guide

TASK [robertdebock.openvas : install openvas (package)] ********************************************************************************************
ok: [localhost] => {"attempts": 1, "changed": false, "msg": "Nothing to do", "rc": 0, "results": ["Installed: openvas-cli", "Installed: openvas-scanner"]}

TASK [robertdebock.openvas : enable openvas] *******************************************************************************************************
failed: [localhost] (item=openvas-scanner) => {"changed": false, "item": "openvas-scanner", "msg": "Unable to start service openvas-scanner: Job for openvas-scanner.service failed because the control process exited with error code.nSee "systemctl status openvas-scanner.service" and "journalctl -xe" for details.n"}

$ sudo journalctl -xe
Dec 29 21:30:02 192.168.254.59 systemd[1]: Starting OpenVAS Scanner...
-- Subject: Unit openvas-scanner.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit openvas-scanner.service has begun starting up.
Dec 29 21:30:02 192.168.254.59 openvassd[2696]: /usr/sbin/openvassd: symbol lookup error: /usr/sbin/openvassd: undefined symbol: nvticache_free
Dec 29 21:30:02 192.168.254.59 systemd[1]: openvas-scanner.service: Control process exited, code=exited status=127
Dec 29 21:30:02 192.168.254.59 systemd[1]: openvas-scanner.service: Failed with result 'exit-code'.
Dec 29 21:30:02 192.168.254.59 systemd[1]: Failed to start OpenVAS Scanner.
-- Subject: Unit openvas-scanner.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit openvas-scanner.service has failed.
--
-- The result is failed.