ClamAV disabled in WHM, but still running hourly scans
Answered
Every few hours this ClamAV process (see below) runs using 60-80% CPU resources.
/usr/local/cpanel/3rdparty/bin/clamscan --max-filesize=6947618 --max-scansize=13895236 -d /usr/local/maldetect/tmp/.runtime.user.5653.hdb -d /usr/local/maldetect/tmp/.runtime.user.5653.ndb -d /var/clamav/ -r --infected --no-summary -f /usr/local/maldetect/tmp/.monitor.scan.317416470
We have ClamAV and LMD configured to run as a cron job nightly at 1am.
0 1 * * * /usr/local/cpanel/3rdparty/bin/clamscan -i -r /home/myhomedir/public_html/
0 1 * * * /usr/local/maldetect/maldet -a /home/myhomedir > /dev/null 2>&1
In WHM, ClamAV Scanner Configuration has no directories selected and the ClamAV Daemon is disabled in Service Configuration > Service Manager. Additionally, the /usr/local/maldetect/conf.maldet file has the following settings:
cron_daily_scan="0" (disabled because we run it as a scheduled cron jobs)
scan_cpunice="19"
scan_ionice="7"
scan_cpulimit="100"
Can any provide suggestions to stop the clamscan process from running outside of the scheduled cron job?
--
CentOS v7.9.2009 STANDARD kvm
cPanel Version 110.0.31
ClamAV 0.104.4/27366
-
Hey there! That's an interesting one - if you look inside /var/log/cron do you see it being fired additional times outside of your one scheduled run? If not, is it possible it's just running for a long time and you're seeing the process reappear?
1 -
/var/log/cron shows the 'clamscan' job only running during its scheduled time at 01:00. However, it shows LMD ('maldetect') running precisely every 5 minutes!
Aug 14 14:10:01 server CROND[14287]: (root) CMD (/usr/local/maldetect/maldet --mkpubpaths >> /dev/null 2>&1)
Aug 14 14:15:01 server CROND[14870]: (root) CMD (/usr/local/maldetect/maldet --mkpubpaths >> /dev/null 2>&1)
Aug 14 14:20:02 server CROND[15390]: (root) CMD (/usr/local/maldetect/maldet --mkpubpaths >> /dev/null 2>&1)
Aug 14 14:25:01 server CROND[16047]: (root) CMD (/usr/local/maldetect/maldet --mkpubpaths >> /dev/null 2>&1)0 -
I looked inside /etc/cron.d/maldet_pub and the following cron job was there:
*/5 * * * * root /usr/local/maldetect/maldet --mkpubpaths >> /dev/null 2>&1
0 -
Well there you go - so someone configured maldet to run a bit too often to be useful it would seem.
0 -
I just glanced at the maldet readme file and it seems intentional. The odd thing is the scan_user_access setting is disabled in the conf file.
Given that the maldetect installation path is owned by user root, we either need to set a pub path world writable (777) or populate the pub path with user owned paths. It was undesirable to set any path world writable and as such a feature to populate path data was created. This feature is controlled with the --mkpubpaths flag and is executed from cron every 10 minutes, it will only execute if the scan_user_access variable is enabled in conf.maldet. As such, it is important to make sure the scan_user_access variable is set to enabled (1) in conf.maldet and it is advised to run 'maldet --mkpubpaths' manually to prepopulate the user paths. There after, the cron will ensure new users have paths created no later than 10 minutes after creation.
0 -
Solved by commenting out the cron job in /etc/cron.d/maldet_pub! Thanks cPRex!
0 -
I'm glad that thought got you pointed in the right direction!
0 -
I may have spoken too soon... I just looked at the process log and it shows that same one as before even though the cron that ran every 5 min is now disabled... Any other ideas?
ps aux | grep maldet
root 21994 104 28.2 1415140 1097880 ? RN 15:14 0:14 /usr/local/cpanel/3rdparty/bin/clamscan --max-filesize=6947618 --max-scansize=13895236 -d /usr/local/maldetect/tmp/.runtime.user.5653.hdb -d /usr/local/maldetect/tmp/.runtime.user.5653.ndb -d /var/clamav/ -r --infected --no-summary -f /usr/local/maldetect/tmp/.monitor.scan.1398024600 -
Did you restart cron after you made that adjustment to ensure the new changes are loaded?
0 -
Yes
0 -
Well that's just odd then, as that should be all that needs to happen to in order to stop that from running. Could you create a ticket so this can be examined?
0 -
Are there any other logs you would suggest looking at to make sure it's not a fluke?
0 -
You said you looked at the process log - is the PID changing every 5 minutes in that log? If you check /var/log/cron again and don't see any new crons firing, it could be that it is just taking some time to run and that is why it's showing up in the process log.
0 -
yes, the PID is changing with each instance when it runs. /var/log/cron stopped showing the maldet cron after commenting it out in the .conf file earlier.
0 -
The only random thought I have would be to try this command
pstree PID
and see if another process is calling that tool. At least we know it isn't cron, though.
0 -
this was the result:
pstree 28901
clamscan0 -
That's good info - so that confirms that the parent clamscan process called maldet, and it's not maldet itself being called from the cron. That would seem like expected behavior according to the server's configuration, correct?
0 -
That would seem like expected behavior according to the server's configuration, correct?
What is triggering it to run that process every 5 minutes if clamscan is only set to run a 1:00am as a cron?
0 -
That's the part we don't know. I'd still think a ticket would be the best option if you're not seeing anything that is obviously calling clamscan at a specific interval.
1
Please sign in to leave a comment.
Comments
19 comments