Maldet is too slow

[sitespt]

Hi,

We have recently moved from a VPS to a Dedicated Server and we have the latest software installed (i.e. CentOS 6.4, cPanel 11.40.1.8, etc.) and maldet is now much slower than the usual.

Another abnormal situation on the scan is the counter which is now dynamic, i.e. it counts the file/total that is scanning looking something like "6313/382488 files scanned: 0 hits 0 cleaned" while before it wouldn't show this file counter and it would be much faster.

Is there anything I can do to make the scan much faster as before but efficient at the same time?

Thank you

 

[ThinIce]

Maybe stupid questions, but is the realworld disk throughput on the new server otherwise good (or at least comparable with the VPS you came from if you have these numbers)?

It would be a bit of a programming fail if a counter made a significant difference to the performance of the app (I'm not saying that it doesn't just I'd be surprised). The other thing to my knowledge that governs the speed of a maldet scan is whether you're scanning all files or just those recently modified

-r, --scan-recent PATH DAYS
Scan files created/modified in the last X days (default: 7d, wildcard: ?)
e.g: maldet -r /home/?/public_html 2

 

[cPanelMichael]

Hello

You could try comparing the disk I/O between the two servers when the scan is running if you still have access to the VPS. A dedicated server will not always automatically perform better than a VPS, so it's possible that the scan may take longer.

Thank you.

 

[quizknows]

Another abnormal situation on the scan is the counter which is now dynamic, i.e. it counts the file/total that is scanning looking something like "6313/382488 files scanned: 0 hits 0 cleaned" while before it wouldn't show this file counter and it would be much faster.

Is there anything I can do to make the scan much faster as before but efficient at the same time?

Thank you

It sounds like your new box is missing the clamav binary. Maldet runs faster when clamav is installed, as it uses that binary with its own definition set rather than the slow scanning method you're seeing now. Try to make sure you get clamav properly installed, which should just be a matter of installing it via WHM in 11.40. (Home » cPanel » Manage Plugins).

The exact binary it uses to speed up scanning is /usr/bin/clamscan in most cases. Maldet uses the output of this command to define which clamscan binary to use:

clamscan=`which clamscan 2> /dev/null`

When you have this fixed, you should be able to run the command "which clamscan" at root SSH without the quotes and get a response of the proper binary. Once that's there, you're good to go.

 

[rfxn]

The situation noted by quizknows is indeed correct, the output indicates you are running LMD without clamAV installed. The native LMD scanner engine is not great on very large file sets of over 100k files, it will complete if you fork it to the background in a somewhat reasonable amount of time. That said, there is no reason not to use ClamAV as LMD will leverage its own rules along with the added native ClamAV rules and provide an overall superior level of protection.

You can install cPanel's ClamAV connector or you can installed ClamAV from EPEL as follows:

rpm -ivh http://fedora.mirror.nexicom.net/epel/6/i386/epel-release-6-8.noarch.rpm
sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/epel.repo
yum --enablerepo=epel install -y clamav clamav-db

After you have completed installation of ClamAV you should run the freshclam command to update the ClamAV database to the latest version (this can take a few minutes on first run):

freshclam

 

[gowrann]

i found that LMD is looking for the binary which cpanel puts in a different place - you need to add a link:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

 

[visiba]

i found that LMD is looking for the binary which cpanel puts in a different place - you need to add a link:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

Thanks, that indeed did the trick for me. Maldet is now using the ClamAV connector instead of LMD.