I’m new to Greenbone. I have successfully built a scanner from source and for the most part all seems well. One issue I’m struggling with is the update process.
I’m running the community edition and found this post helpful and (it seems) to be the latest on updating?
I configured my daemons to run under the user ‘gvm’ but I don’t login with that user interactively. However, the user I login with is a member of the gvm user group. I’m not sure if that is sound from a security perspective but was hoping that would allow things to work at least. It doesn’t.
Three of the update commands work fine as long as I run them under sudo, those are the SYNC, CERT, and GVMD_DATA updates. The one that is alluding me is the NVT update. When I run that script I get this error right away:
chmod: changing permissions of '/var/lib/openvas/feed-update.lock': Operation not permitted
then a bunch of files download and all else seems fine until the end which looks like this:
sent 4,867,693 bytes received 8,794,010 bytes 41,842.89 bytes/sec
total size is 358,762,464 speedup is 26.26
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1819) [generator=3.2.3]
Checking the UI feed status page I can see that the NVT section stays out of date.
Could this have something to do with the processes running under gvm while I’m using a different acct to launch the updates? Something else?
That post is outdated and related to a very old version of our software.
Sadly this doesn’t work. The sync scripts need to run as the same user as the daemons are started with. If you use Kali this user is called _gvm. Our source build guide uses the user gvm.
I did follow the build guide (though a complex process it worked well) so my processes are running as gvm user. I tried to su into that account but got an error ‘This account is currently not available.’. I will try that again.
When I am successful loging in as the gvm user are these the scripts that need to be run?
if you followed the source build guide then please follow the source build guide completely. It mentions the feed sync and the todos in detail. I’ve the feeling you are mixing up different installation methods.
Thank you for pointing me back to the source build docs.
I’d like to tell you that I found the layout of your documentation to be quite easy to follow. Also, the imbedded links to the GB glossary, which in turn references authoritative sources (such as NIST or CVE) makes it even more effective. Well done on that.
After reviewing the build documentation I do recall following the Feed Synchronization section when I first built the scanner. What is not clear in there to me is whether or not the feed sync process needs to be repeated to keep things in sync or if that is handled automatically after the first run. It has been 5 months and I just recently realized the feed was out of date. It is not happening automatically on the system I built, what I don’t know is if that is because it has a problem or if that is how it is designed. Do I need to run that process on a regular basis or is it supposed do that automatically in the background? Also, you mentioned todo’s, is there a specific section of the guide for that (I’m not seeing one) or are you just referring to the actions needed in the Feed Sync section?
Oh sorry, for me it is very obvious that you have to re-run the sync scripts to download updates of the feed. That’s why it is called feed synchronization. Some times you get a little blind about such information. But you are right this is completely missing from the source build guide and should be added.
Yes you need to do that. Just setup a cron job and run the greenbone-feed-sync script. The script will download the newest data and our daemons (if they are running) will pick up this data afterwards. The feed itself gets updated once itself. Therefore you should run the greenbone-feed-sync script at least once a week. Please be aware that you should not run a scan during a feed synchronization. That means you should run the cron job when there is no load on your machine.
With your help and the docs I was able to get updates applied except for the NVT’s. For some reason that I don’t understand I am getting access denied errors, however it is not clear to me where the access permission is wrong.
Here is a snipped output of the command showing the first few lines and the last few lines. I believe everything in between is a repeat of the same errors, just on different files. It seems to be an rsync error from within the script.
$ sudo -u gvm /usr/local/bin/greenbone-nvt-sync
Greenbone community feed server - http://feed.community.greenbone.net/
This service is hosted by Greenbone Networks - http://www.greenbone.net/
All transactions are logged.
If you have any questions, please use the Greenbone community portal.
See https://community.greenbone.net for details.
By using this service you agree to our terms and conditions.
Only one sync per time, otherwise the source ip will be temporarily blocked.
receiving incremental file list
rsync: [generator] failed to set times on "/var/lib/openvas/plugins/2016/matrixssl": Operation not permitted (1)
rsync: [generator] failed to set times on "/var/lib/openvas/plugins/2016/riello": Operation not permitted (1)
2016/matrixssl/
rsync: [receiver] mkstemp "/var/lib/openvas/plugins/2016/matrixssl/.gb_matrixssl_mult_vuln.nasl.iNnVoQ" failed: Permission denied (13)
4,174 100% 3.98MB/s 0:00:00 (xfr#1, ir-chk=3144/49041)
2016/riello/
rsync: [receiver] mkstemp "/var/lib/openvas/plugins/2016/riello/.gb_netman_204_http_default_credentials.nasl.SHXqEP" failed: Permission denied (13)
...
3,646 100% 4.46kB/s 0:00:00 (xfr#1508, ir-chk=1013/84266)
rsync: [receiver] mkstemp "/var/lib/openvas/plugins/2023/zoom/.gb_zoom_mult_vuln_mar23_win.nasl.RvauEP" failed: Permission denied (13)
3,638 100% 4.45kB/s 0:00:00 (xfr#1509, ir-chk=1012/84266)
sent 71,406 bytes received 3,642,848 bytes 87,394.21 bytes/sec
total size is 359,483,978 speedup is 96.78
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1819) [generator=3.2.3]
You could check the permissions on /var/lib/openvas/plugins/2016/matrixssl with a ls -la /var/lib/openvas/plugins/2016/matrixssl. Personally I guess you did run greenbone-feed-sync once without sudo -u gvm.
Easiest way to fix this is by deleting the /var/lib/openvas/plugins/ directory and run sudo -u gvm /usr/bin/greenbone-feed-sync again.