Linux Malware Detect



Malware, short for malicious software, is software designed to infiltrate or damage a computer system without the owner's informed consent.

The context which malware applies to this article is any malicious software, scripts or content that may have found its way onto a Linux system by means of a user account, such as in a shared hosted environment.

Linux Malware Detect (LMD)

Linux Malware Detect (LMD) is a malware scanner for Linux released under the GNU GPLv2 (free, open source) license, that is designed around the threats faced in shared hosted environments. It uses threat data from network edge intrusion detection systems to extract malware that is actively being used in attacks and generates signatures for detection. In addition, threat data is also derived from user submissions with the LMD checkout feature, threats found on the TCH network of over 30,000 hosted domains and from malware community resources.

The result, is a malware scanner with over 2,200 signatures and growing, that detects a varied assortment of malware from the infamous Yellsoft Darkmailer CGI Mailer to the more common r57 PHP Command Shell to BASE64 Encoded file injection strings.

What makes LMD different?

There is currently limited availability of open source, restriction free, tools for Linux systems that focus on malware detection and more importantly, that get it right. Many of the AV products that perform malware detection on Linux have a very poor track record of detecting threats, especially those targeted at shared hosted environment.

The threat landscape on shared web hosting servers is unique from that of the standard AV products detection suite in that they are detecting primarily trojans / rootkit content but missing the ever increasing malware on the account level which serves as an attack platform.

Using the cymru.com malware hash repository, which provides malware data for Microsoft, Google, Trend Micro, F-Secure, Symantec and more; we can demonstrate this short coming in current threat detection.

The following is an analysis of the core MD5 hashes (725) in LMD 1.3 and the percentage of major AV products that currently detect the hashes, averaged, from the time of this writing (May 15th, 2010):

% AV DETECT (AVG):  59
% AV DETECT (LOW):  58

What this information means, is that of the of the 725 hashes, 461 are not known, 264 are known / detected and of those known items there is an average of a 59% detection rate among major AV products with a low / high margin of detection at 58 and 71 percent respective.

In short, that means on average, other AV products will miss 40% of what LMD catches. This clearly demonstrates the lacking capacity in currently available tools and why it is important that something fill the void, especially in the Linux web hosting niche.

LMD Features

- MD5 file hash detection for quick threat identification
- HEX based pattern matching for identifying threat variants
- integrated signature update feature, executes through cron.daily and –update
- integrated version update feature with –update-ver, must run manual
- scan-recent option to scan only files that have been added/changed in X days
- scan-all option for full path based scanning
- checkout option to upload suspected malware to rfxn.com for review / hashing
- report option to view past or recent scan results
- quarantine queue that stores threats in a safe fashion with no permissions
- quarantine batching option to quarantine the results of a past or recent scan
- quarantine restore option to restore files to original path, owner and perms
- quarantine suspend account option to Cpanel suspend or shell revoke users
- cleaner rules to attempt removal of malware injected strings
- cleaner batching option to attempt cleaning of previous scan reports
- cleaner rules to remove base64 and gzinflate(base64 injected malware
- daily cron based scanning of all changes in last 24h in user homedirs
- daily cron script compatible with stock RH style systems, Cpanel & Ensim
- kernel based inotify real time file scanning of created/modified/moved files
- kernel inotify monitor that can take path data from STDIN or FILE
- kernel inotify monitor convenience feature to monitor system users
- kernel inotify monitor can be restricted to a configurable user html root
- kernel inotify monitor with dynamic sysctl limits for optimal performance
- kernel inotify alerting through daily and/or optional weekly reports
- e-mail alert reporting after every scan execution (manual & daily)
- path and signature based ignore options
- verbose logging & output of all actions

Detected Threats

LMD 1.3 has a total of 2208 (725 MD5 / 1483 HEX) signatures (before updates), below is a listing of the top 60 threats by prevalence detected by LMD:

base64.inject.unclassed     perl.ircbot.xscan
bin.dccserv.irsexxy         perl.mailer.yellsoft
bin.fakeproc.Xnuxer         perl.shell.cbLorD
bin.ircbot.nbot             perl.shell.cgitelnet
bin.ircbot.php3             php.cmdshell.c100
bin.ircbot.unclassed        php.cmdshell.c99
bin.pktflood.ABC123         php.cmdshell.cih
bin.pktflood.osf            php.cmdshell.egyspider
bin.trojan.linuxsmalli      php.cmdshell.fx29
c.ircbot.tsunami            php.cmdshell.ItsmYarD
exp.linux.rstb              php.cmdshell.Ketemu
exp.linux.unclassed         php.cmdshell.N3tshell
exp.setuid0.unclassed       php.cmdshell.r57
gzbase64.inject             php.cmdshell.unclassed
html.phishing.auc61         php.defash.buno
html.phishing.hsbc          php.exe.globals
perl.connback.DataCha0s     php.include.remote
perl.connback.N2            php.ircbot.InsideTeam
perl.cpanel.cpwrap          php.ircbot.lolwut
perl.ircbot.atrixteam       php.ircbot.sniper
perl.ircbot.bRuNo           php.ircbot.vj_denie
perl.ircbot.Clx             php.mailer.10hack
perl.ircbot.devil           php.mailer.bombam
perl.ircbot.fx29            php.mailer.PostMan
perl.ircbot.magnum          php.phishing.AliKay
perl.ircbot.oldwolf         php.phishing.mrbrain
perl.ircbot.putr4XtReme     php.phishing.ReZulT
perl.ircbot.rafflesia       php.pktflood.oey
perl.ircbot.UberCracker     php.shell.rc99
perl.ircbot.xdh             php.shell.shellcomm

Download & More info

The home page for LMD is located at:

The current version of LMD is always available at the following URL:

Related reading:

Installation & Configuration

Installing LMD is a very easy process, lets get right into it:

root@praxis [~]# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
2010-05-15 23:34:05 (148 MB/s) - `maldetect-current.tar.gz' saved [268031/268031]

root@praxis [~]# tar xfz maldetect-current.tar.gz
root@praxis [~]# cd maldetect-*
root@praxis [~]# ./install.sh
Linux Malware Detect v1.3.4
            (C) 1999-2010, R-fx Networks <proj@r-fx.org>
            (C) 2010, Ryan MacDonald <ryan@r-fx.org>
inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au>
This program may be freely redistributed under the terms of the GNU GPL

installation completed to /usr/local/maldetect
config file: /usr/local/maldetect/conf.maldet
exec file: /usr/local/maldetect/maldet
exec link: /usr/local/sbin/maldet
cron.daily: /etc/cron.daily/maldet

maldet(32517): {sigup} performing signature update check...
maldet(32517): {sigup} local signature set is version 2010051510029
maldet(32517): {sigup} latest signature set already installed

Now that LMD is installed, take note of the file locations as that is the next thing we need to do. Lets go ahead and open the configuration file located at /usr/local/maldetect/conf.maldet:

root@praxis [~]# nano -w /usr/local/maldetect/conf.maldet

The configuration file is fully commented so you should be able to make out most options but lets take a moment to review the more important ones:

This is a top level toggle for the e-mail alert system, this must be turned on if you want to receive alerts.

This is a comma spaced list of e-mail addresses that should receive alerts.

This tells LMD that it should move malware content into the quarantine path and strip it of all permissions. Files are fully restorable to original path, owner and permission using the --restore FILE option.

This tells LMD that it should try to clean malware that it has cleaner rules for, at the moment base64_decode and gzinflate file injection strings can be cleaned. Files that are cleaned are automatically restored to original path, owner and permission.

Using this option allows LMD to suspend a user account that malware is found residing under. On CPanel systems this will pass the user to /scripts/suspendacct and add a comment with the maldet report command to the report that caused the users suspension (e.g: maldet --report SCANID). On non-cpanel systems, the users shell will be set to /bin/false.

This is the minimum user id that will be evaluated for suspension, the default should be fine on most systems.

The rest of the options in conf.maldet can be left as defaults unless you clearly understand what they do and how they may influence scan results and performance.

Usage & Manual Scans

The usage of LMD is very simple and there is a detailed --help output that provides common usage examples, I strongly recommend you check the --help output and spend a few minutes reviewing it.

The first thing most users are looking to do when they get LMD installed is to scan a certain path or series of paths. An important note is that LMD uses the '?' character for wildcards instead of the '*' char. In the below examples I will be using the long form flags but they are interchangable with the short form flags (i.e: --scan-recent = -r).

If we wanted to scan all user public_html paths under /home*/ this can be done with:

maldet --scan-all /home?/?/public_html

If you wanted to scan the same path but scope it to content that has been created/modified in the last 5 days you would run:

maldet --scan-recent /home?/?/public_html 5

If you performed a scan but forget to turn on the quarantine option, you could quarantine all malware results from a previous scan with:

maldet --quarantine SCANID

Similarly to the above, if you wanted to attempt a clean on all malware results from a previous scan that did not have the feature enabled, you would do so with:

maldet --clean SCANID

If you had a file that was quarantined from a false positive or that you simply want to restore (i.e: you manually cleaned it), you can use the following:

maldet --restore config.php.2384
maldet --restore /usr/local/maldetect/quarantine/config.php.2384

Once again, I encourage you to fully review the --help output for details on all options and the README file for more details on how LMD operates.

Daily Scans

The cronjob installed by LMD is located at /etc/cron.daily/maldet and is used to perform a daily update of signatures, keep the session, temp and quarantine data to no more than 14d old and run a daily scan of recent file system changes.

The daily scan supports Ensim virtual roots or standard Linux /home*/user paths, such as Cpanel. The default is to just scan the web roots daily, which breaks down as /home*/*/public_html or on Ensim /home/virtual/*/fst/var/www/html and /home/virtual/*/fst/home/*/public_html.

If you are running monitor mode, the daily scans will be skipped and instead a daily report will be issued for all monitoring events. If you need to scan additional paths, you should review the cronjob and edit it accordingly.

Release & Signature Updates

Updates to the release version of LMD are not automatically installed but can be installed using the --update-ver option. There is good reasons that this is not done automatically and I really dont feel like listing them so just think about it a bit.

The latest changes in the release version can always be viewed at:

The LMD signatures are updated typically once per day or more frequently depending on incoming threat data from the LMD checkout feature, IDS malware extraction and other sources. The updating of signatures in LMD installations is performed daily through the default cron.daily script with the --update option, which can be run manually at any time.

An RSS & XML data source is available for tracking malware threat updates:
RSS: http://www.rfxn.com/api/lmd
XML: http://www.rfxn.com/api/lmd?id=recent
XML: http://www.rfxn.com/api/lmd?id=all

Real-Time Monitoring

The inotify monitoring feature is designed to monitor users in real-time for file creation/modify/move operations. This option requires a kernel that supports inotify_watch (CONFIG_INOTIFY) which is found in kernels 2.6.13+ and CentOS/RHEL 5 by default. If you are running CentOS 4 you should consider an inbox upgrade with:

There are three modes that the monitor can be executed with and they relate to what will be monitored, they are USERS|PATHS|FILES.

      e.g: maldet --monitor users
e.g: maldet --monitor /root/monitor_paths
e.g: maldet --monitor /home/mike,/home/ashton

The options break down as follows:
USERS - The users option will take the homedirs of all system users that are above inotify_minuid and monitor them. If inotify_webdir is set then the users webdir, if it exists, will only be monitored.
PATHS - A comma spaced list of paths to monitor
FILE - A line spaced file list of paths to monitor

Once you start maldet in monitor mode, it will preprocess the paths based on the option specified followed by starting the inotify process. The starting of the inotify process can be a time consuming task as it needs to setup a monitor hook for every file under the monitored paths. Although the startup process can impact the load temporarily, once the process has started it maintains all of its resources inside kernel memory and has a very small userspace footprint in memory or cpu usage.

The scanner component of the monitor watches for notifications from the inotify process and batches items to be scanned, by default, every 30 seconds. If you need tighter control of the scanning timer, you can edit inotify_stime in conf.maldet.

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.

Terminating the inotify monitoring is done by passing the '-k|--kill-monitor' option to maldet, it will touch a file handle monitored by maldet and on the next waking cycle of the monitor service, it will terminate itself and all inotify processes.

Web Hosting Wiki article text shared under a Creative Commons License.

Personal Tools