First of all, I dont know if I’m in the correct category, if not please tell me and I will update it / repost.
I’m currently using OpenVAS with GSA 22.9.1 on top of a Kali Linux with all the latest patches applied, the OpenVAS feed is updated to “Current” and I can’t see any error in the log files.
I was using this same OpenVAS installation for +6 months with 0 problems.
Recently I had an issue where OpenVAS couldn’t scan, by researching through internet I found that maybe the “Port Scanner” family was disabled in the scan “Full and Fast”, so I did a clone to check it and it was disabled. As I can’t change the configuration because it was in use for over 350 tasks what I did was edit the tasks scan config directly from the PostgreSQL database, I did set it to another scan config to let the “Full and Fast” empty, then I edited from the GSA the “Full and Fast” to enable the “Port Scanner” NVT and finally I updated all the tasks to use the original
“Full and Fast” scan config.
When I left work yesterday it was working properly, today when I arrived I found that the scans I launched were “Interrupted at 0%”, looked at error messages and said “Exiting because VT list is empty (e.g. feed not synced yet)”. The feed is still updated to current so I don’t know what’s causing this.
Went to look to the Scan Config section, found the “Full and Fast” with a value of 0 in the “Families” column and the value of “138819” in the “NVTs” column.
The clones in the screenshot were made before this change to 0.
Any idea on why this is happening now and how to solve it? If I do the same thing I did of editing the Scan Config I see the column of “Select all NVTs” marked in all lines.
It seems that the “Full and Fast” scan configuration was modified, or maybe better to use the term “corrupted”, since it is not editable. Perhaps it was due to some error such as bad sectors on your drive, but also perhaps other factors. I would suggest re-installing your system and Greenbone to ensure the integrity of the components, maybe using something like SpinRite to test your drive integrity. Greenbone Enterprise products come with a backup solution. Maybe my response would be a bit over the top, but, maybe someone else can weigh in with a more accurate answer.
Yes, it was modified by me.
When it happened the first error I modified the values from the database to make it editable so that I can enable the “Port Scanner” Family, that’s why it’s modified.
I can set it again to be a predefined one but I don’t know if it affects this error.
I know, but if the default is broken because of whatever reason and it has disabled the “Port Scanner”, what do I do with the +300 tasks that I already created and are immutable? Delete them and create new ones with the new scanner and losing all the time of creating them again? Thank you but no.
As I already said, the installation was working for +6 months completely fine and suddenly OpenVAS stopped scanning hosts, researching the problem I found the “Port Scanner” Family in the “Full and fast” Scan Config was disabled, no changes made, the failure was on a weekend so there was nobody working.
So yes, the Scan Config was broken, I don’t know the reason cause the logs didn’t have nothing. The hardware continues working properly so it’s not a hardware problem.
As you are constantly telling me to reinstall, at least say me how to do it without losing the +350 tasks and its reports.
If you alter manually the database, and the scan config, your system is no longer supportable … and then you need to re-install it and fixing it by cloning the scan-configuration. There is a reason why full and fast is readonly If the default values are getting corrupted you need to investigate why.
You already lost the tasks by manipulating the default values, and then you need to live with that.
I would start with hardware, do you use a filesystem with checksum per file to detect corruptions ?
Do you use ECC memory ?
System failure can happen from many causes, but your as the system owner need to mitigate those risks. The ext4 filesystem can use checksums to help prevent data corruption. Going forward, I would suggest keeping a complete dump of the gvm PostgreSQL database to allow recovery.
If the default values are getting corrupted you need to investigate why.