[How-To] Linux Malware Detect on Directadmin Powered server

I too have always wondered just how well maldet did, I have had my favorite WP plugin find something in a WP site that maldet never picked up on, that plugin , which many scorn because it hasnt been updated in over 2 years, BUT it still works as good as it did when it first was released, why it works is that it does Not depend on WP core to function :)

over the years I have had the pleasure or, misfortune of trying many themes that were encoded, many are just a credit link to the author and that is fine, its the ones that have embedded links to places that are not favorable. I know this because I have decoded some just to see what was going on, the protected author link is fine, the others are not acceptable, most of the time it is a simple task, even for me, to remove the footer code and or comment out the function that checks the footer, Is this ethical? No I dont recommend it but I was curious as to why a free theme would need to be protected.
the conclusion.... Stay Away From Free Themes that You cant trust with having been encoded some how, many ARE malicious and cause troubles.
As for maldet? Im still wondering if its even worth the troubles of using it
JMHO
 
Well in fact Maldet is indeed worth the trouble of using it. But I still wonder why it says only 7K files are present, when a lot more are present.
However, Maldetect -did- find cryptolock malware on a site in a deep link some time ago and other malware before that some time. So it does work. I just don't understand why it does not find these false positives on a cron scan and does find them on a manual scan.
I know people should be ware with encoded themes. However, the themes of this specific site are decoded several times and are not found to be malicious.
I also succeeded to decode the footer.php completely and it was just hiding some ad's which can be removed when you buy the key. But I don't want to advertise for that site.

I'm a hoster. Most users are not that smart and love free themes. So I hope somebody can explain the difference in scan results from Maldetect and knows a way how I can fix these issues.
 
By default maldet when running with nightly cron lists and scans only files modified during the last 2 days. So if you somehow uploaded a file with a malicious code in it and the file has time of modification far before than 2 days the file won't be checked. You probably know that when you upload a zip, gz, tar, etc archive with files and unpack it all the unpacked files will have their original mtime, ctime, etc. So they won't be checked with daily run.

maldet can monitor your directories and find all newly uploaded files despite on their mtime, ctime and scan. That's a separate process and might bring to your server additional load.

What we do is the following: we run daily scan for lately modified files (default 2 days) and have a weekly task to scan all the files in /home/?/domains/?/public_html/
 
Thank you for explaining Alex.
So if I understand correctly, the scan for all files (so find new files) is only once a week. So in the worst case scenario you can have a newly place file which is infected on the server for 7 days before it's detected, because the scan for new files is only weekly. Do I understand that part correctly?
If yes it explaines why a manual scan found the "infected" files and the automatic scan did not and also explains the difference in amount of files.

A full scan is taking already a lot of load, so I don't think we need this running more then once a week.

Do you have any clue if there is some kind of solution to my last issue? The false positives? Since we can't exclude specific files from being scanned?
 
Yes, we do a full scan once a week, of course you may run it more often.

To exclude files you may use:

/usr/local/maldetect/ignore_file_ext
/usr/local/maldetect/ignore_inotify
/usr/local/maldetect/ignore_paths
/usr/local/maldetect/ignore_sigs

I guess the file names are enough clear so to understand on how to use them. The easiest way would be to list full paths of your files in /usr/local/maldetect/ignore_paths.
 
No the easyest way might be the the ignore_inotify I guess (unless that's paths only too), because I don't want to exclude the complete path.
But I rather not, because malware is also used in functions.php and footer.php files. So I advised my customers not to use encrypted themes or otherwise be at risk that files might get deleted and their site won't work anymore if they do.

Thank you!
 
I've followed this thread and WANT to get a daily email from Maltet. I used to get them but they stopped. No errors in the Exim logs. Any ideas how I can get the daily email's (clean or infected)?

Thanks,
-Joe
 
I also specified my email and only get emails when something is infected.

Maybe you have to remove the ">> /dev/null 2>&1" from the cronjob?
 
Richard G said:
Maybe you have to remove the ">> /dev/null 2>&1" from the cronjob?
Click to expand...

All crontasks which maldet runs execute scanning a background mode, so it won't five any expected result. By default maldet does not send notifications if no threat was found (if I understand it correct). You can change its settings to send emails:


Code: 
# Ignore e-mail alerts for reports in which all hits have been cleaned.
# This is ideal on very busy servers where cleaned hits can drown out
# other more actionable reports.
email_ignore_clean=0
 
email_ignore_clean=0
Click to expand...
No that setting is not for getting emails. I have it like that.
That setting is only if some files have been cleaned, and you don't want an email about the cleaned files, then you can set it to 1.

So that won't send daily emails either.
 
Yes I set "email_ignore_clean=0" to "email_ignore_clean=1" several days ago but still no report via email. The strange thing is that I used to get them daily.

-Joe
 
Like I said, that is not the correct setting for getting daily mails, only for getting no mails when automatic cleaning occured of infected files. The instruction is very clear about that.

I found this in the readme:
The alerting of file hits under monitor mode is handled through a daily report
instead of sending an email on every hit. The cron.daily job installed by LMD
will call an --alert-daily flag and send an alert for the last days hits. There
is also an --alert-weekly option that can be used, simply edit the cron at
/etc/cron.daily/maldet and change the --alert-daily to --alert-weekly.
Click to expand...
So it looks like daily reports are only done in monitor mode.
 
Is there any chance of using maldet as on-demand-scanner?
I don't want to use it on cron basis, just if there is a need or request to scan user's files.
 
If you mean by "on demand" a manual scan, yes that can be done.
It's better to use it by cron, because it will create a small database and on newer scans it will not scan the complete system but only the newer files. So only the first time it takes long.

Anyway, for a manual scan you can issue this command (you find the commandline options in the README file):
Full forground scan:
Code: 
maldet -a /home?/?/domains/?/public_html

Full background scan:
Code: 
maldet -b -a /home?/?/domains/?/public_html

Update:
Code: 
maldet -u
or
Code: 
maldet --update-ver

As said, check README for more options.
 
I searched in this topic for information about ClamAV + Maldet side by side but i couldn't find any. Currently ClamAV is doing a nightly scan. Are there any problems if i run maldet for example weekly after the ClamAV scan is done? I assume there aren't but before i install and try it i would like to be sure :)
 
The maldet if clamdscan is installed and running uses clamav scanner engine:

Code: 
maldet(18957): {scan} found clamav binary at /usr/local/bin/clamdscan, using clamav scanner engine...
maldet(18957): {scan} scan of /usr/local/maldetect/ (44 files) in progress...

Alternatively you can load maldet's signatures dbs into Clamav. And use only Clamav without maldet.

Anyway they both do the almost same things, the difference is how maldet informs you about found malware.
 
You must log in or register to reply here.
Back
Top