Hello!
Sorry if I am misplacing this post. I was tempted to place it on the Virtualmin forum, but then this is not strictly Virtualmin.
I installed LMD / Clamscan some years ago, which worked just fine on my Virtualmin (CentOS 6.9 at this time) machine ... until two or three weeks ago, when maldetect was automatically upgraded from version 1.5 into version 1.6
Now, whenever I start a malware scan, issuing, i.e.:
/usr/local/maldetect/maldet --scan-all /home
Maldet starts working, detecting clamAV and stating it will use it for faster scanning, and about 60 - 100 seconds into the scan, it just stops with a message stating that there was an error which could be seen in the log file.
Linux Malware Detect v1.6
(C) 2002-2017, R-fx Networks <proj@rfxn.com>
(C) 2017, Ryan MacDonald <ryan@rfxn.com>
This program may be freely redistributed under the terms of the GNU GPL v2
maldet(14040): {scan} signatures loaded: 12455 (9721 MD5 | 1951 HEX | 783 YARA | 0 USER)
maldet(14040): {scan} building file list for /home, this might take awhile...
maldet(14040): {scan} setting nice scheduler priorities for all operations: cpunice 19 , ionice 6
maldet(14040): {scan} file list completed in 2s, found 382025 files...
maldet(14040): {scan} found clamav binary at /usr/bin/clamdscan, using clamav scanner engine...
maldet(14040): {scan} scan of /home (382025 files) in progress...
maldet(14040): {scan} clamscan returned an error, check /usr/local/maldetect/logs/clamscan_log for more details!
maldet(14040): {scan} scan completed on /home: files 382025, malware hits 0, cleaned hits 0, time 98s
maldet(14040): {scan} scan report saved, to view run: maldet --report 170410-1126.14040
I open the /usr/local/maldetect/logs/clamscan_log file and I can't detect anything useful in there:
Apr 10 11:26:32 virtualmin01 clamscan start
Apr 10 11:26:32 virtualmin01 executed: /bin/nice -n 19 /usr/bin/ionice -c2 -n 6 /usr/bin/clamdscan --fdpass --infected --no-summary -f /usr/local/maldetect/tmp/.find.14040
Apr 10 11:28:07 virtualmin01 clamscan end
Apr 10 11:28:07 virtualmin01 clamscan end
Then, I do inspect the /var/log/messages log and I find a ton of error messages like this one:
Apr 10 10:43:31 virtualmin01 clamd[12297]: lstat() failed on: /home/xxxxxxx/public_html/xxxxxxxxxx
(being the xxx just each home dir and file inside there) And at the end:
Apr 10 10:43:31 virtualmin01 rsyslogd-2177: imuxsock begins to drop messages from pid 12297 due to rate-limiting
(which I suspect is the event that cuts short and finally stops the scanning attempt)
At this point, I navigate into /usr/local folder and I find /maldetect folder (with version 1.6 inside) and /maldetect.bkxxxx (with older version 1.5 and xxxx being a randomly generated number, I suppose ... at this time it was /maldetect.bk13491).
I rename the newest maldetect into another folder name, and then I rename maldetect backup 1.5 version folder into /maldetect and retry the scan, now using maldetect 1.5 instead of 1.6 ... and it works like a charm, just as before.
Hence, the problem seems to be maldetect 1.6 while interacting with clamAV and no useful error is being detected by me in order to fix this (my linux knowledge is very limited too). I would like very much to use latest maldetect version, since the CHANGELOG is nice and extensive.
But also, after about 24 hours, the system automatically updates (again) my renamed folder into the new maldetect 1.6 version. So even if I was ok with keep using 1.5 version, I need to rename those folders about each time I run the scan.
I did search the net for this kind of errors, but I could not find even ONE other instance. Maybe anyone in here can point me into the right direction.
Any help appreciated!
Enrique
Howdy,
Hmm, I do use maldet on my personal servers, but I hadn't noticed a problem recently.
Just to verify, when running the maldet command above, is it being run as root in that case?
-Eric
Hi Eric! Yeps, I run it as root.
Update, as usual, a new day, so again old maldetect folder gets automatically moved into a /maldetect.bkxxxx and new version 1.6 of maldetect is placed in /maldetect folder.
So when I run, even manually -as root- the scan, I get again the ...
maldet(9108): {scan} clamscan returned an error, check /usr/local/maldetect/logs/clamscan_log for more details!and when I inspect such log, nothing there.
Again, in messages log, there are tons of:
Apr 11 11:43:16 virtualmin01 clamd[12297]: lstat() failed on: /home/xxxxxxxxxxAs a sidenote: If I turn off the option for maldetect to use clamAV as the search / check engine for malware, then maldetect checks each file by itself and it works OK. BUT IT IS SLOWWW (like one file per second). Hence it is not practical.
Again I do not know much of LINUX, but it seems to me that maldetect 1.6 invokes clamAV differently than maldetect 1.5 (which works fine with clamAV).
This does NOT seem to be a simple "permissions based" problem, since there is no "permission denied" on each file error... just the enigmatic lstat() failed.
Maybe a linux Guru may want to jump into this mystery ? :)
Regards, Enrique
Yesterday, my Virtualmin had an "update alert" ... When I clicked in the update module, I found out that among other things, the update included a new version of clamAV ... I was excited about it, maybe my weird problem would be fixed. But no: ClamAV is still failing to access my /home file, with no explicit error, when commanded to scan by maldetect.
Hey all, This issue and thread was flagged to me by a user over on github. I would be happy to troubleshoot with ya'll and find a solution ASAP.
What I need however is a debug run of maldet in which this issue is taking place. This can be done as follows:
# sh -x maldet ... options ... 2> debug.maldetThen you can email me the debug.maldet file. In the email please describe the issue you are having as best possible and include OS type and release.
ryan [at] rfxn.com and rfxnryan [at] gmail.com
Thanks!
Hi Rfxn ... I am sorry I am late, reading this. I gave up on this. Buy just now my virtualmin installation received an update, and maldet now is 1.6.2 so I eagerly tested it in order to see if my situation was solved. It is not. Just the same problem.
So I googled again my problem, and lo and behold, I ended up here, on my own post, and just read your help offering.
I am doing what you ask, and I will send you an email, including a link to this post, in oder to refresh your memory, in case you are still interested on checking what is going on.
But again, it is exactly the same situation, with the same errors as explained in my first post.
I do go back to maldet v1.5 and everything works fine.
Regards,
Enrique