Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maldet monitoring daemon causes ClamAV to think that signatures have changed forcing them to be constantly reloaded #397

Open
Gazoo opened this issue Dec 6, 2021 · 1 comment

Comments

@Gazoo
Copy link
Contributor

Gazoo commented Dec 6, 2021

When the maldet daemon is running the ClamAV daemon always thinks that signature databases have changed (according to the SelfCheck interval) and forces a reload of signatures (even though signatures haven't actually changed).

After looking at the maldet code it looks like the problem is that the maldet monitor_cycle() function calls -> gensigs() -> clamav_linksigs(). This causes the rfxn.hdb rfxn.ndb rfxn.yara files to be constantly deleted and re-copied with every single monitor cycle. The ClamAV daemon detects the database file modification changes in /var/lib/clamav which forces all signatures to be reloaded.

You can see that the file modification times change every minute on the rfxn database files in the /var/lib/clamav directory when the maldet monitoring daemon is running.

@Gazoo
Copy link
Contributor Author

Gazoo commented Dec 8, 2021

@rfxn I'm going to have some free time over the holidays and I'm willing to spend some time fixing some of these
linux-malware-detect bugs. Maybe it would be a good time to get some of the contributors together and see if we can put out another release. A holiday bug hunt?

rfxn added a commit that referenced this issue Oct 15, 2022
…h scan (/home); #407

[Change] default scoped scan adjusted from /var/www/html to /var/www to make sure we scope all www content; #404
[Fix] compare md5 on ignore_sigs between monitor mode cycles and only regenerate signatures on file changes; #397
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant