Linux Malware Detect

Description
Linux Malware Detect (LMD) is a malware scanner for Linux released under the GNU GPLv2 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 and from malware community resources. The signatures that LMD uses are MD5 file hashes and HEX pattern matches, they are also easily exported to any number of detection tools such as ClamAV.

The driving force behind LMD is that there is currently limited availability of open source/restriction free tools for Linux systems that focus on malware detection and more important 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 environments.

The threat landscape in shared hosted environments is unique from that of the standard AV products detection suite in that they are detecting primarily OS level trojans, rootkits and traditional file-infecting viruses but missing the ever increasing variety of malware on the user account level which serves as an attack platform.

The commercial products available for malware detection and remediation in multi-user shared environments remains abysmal. An analysis of 8,883 malware hashes, detected by LMD 1.5, against 30 commercial anti-virus and malware products paints a picture of how poorly commercial solutions perform.

Using the Team Cymru malware hash registry, we can see that of the 8,883 malware hashes shipping with LMD 1.5, there was 6,931 or 78% of threats that went undetected by 30 commercial anti-virus and malware products. The 1,951 threats that were detected had an average detection rate of 58% with a low and high detection rate of 10% and 100% respectively. There could not be a clearer statement to the need for an open and community driven malware remediation project that focuses on the threat landscape of multi-user shared environments.

Source Data:
The defining difference with LMD is that it doesn’t just detect malware based on signatures/hashes that someone else generated but rather it is an encompassing project that actively tracks in the wild threats and generates signatures based on those real world threats that are currently circulating.

There are four main sources for malware data that is used to generate LMD signatures:
– Network Edge IPS: Through networks managed as part of my day-to-day job, primarily web hosting related, our web servers receive a large amount of daily abuse events, all of which is logged by our network edge IPS. The IPS events are processed to extract malware url’s, decode POST payload and base64/gzip encoded abuse data and ultimately that malware is retrieved, reviewed, classified and then signatures generated as appropriate. The vast majority of LMD signatures have been derived from IPS extracted data.
– Community Data: Data is aggregated from multiple community malware websites such as clean-mx and malwaredomainlist then processed to retrieve new malware, review, classify and then generate signatures.
– ClamAV: The HEX & MD5 detection signatures from ClamAV are monitored for relevant updates that apply to the target user group of LMD and added to the project as appropriate. To date there has been roughly 400 signatures ported from ClamAV while the LMD project has contributed back to ClamAV by submitting over 1,100 signatures and continues to do so on an ongoing basis.
– User Submission: LMD has a checkout feature that allows users to submit suspected malware for review, this has grown into a very popular feature and generates on average about 30-50 submissions per week.

Signature Updates:
The LMD signature are updated typically once per day or more frequently depending on incoming threat data from the LMD checkout feature, IPS 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.

Real-Time Monitoring:
The inotify monitoring feature is designed to monitor paths/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:http://www.rfxn.com/upgrade-centos-4-8-to-5-3/

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

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 monitorFILE: 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.

Funding:
Funding for the continued development and research into this and other projects, is solely dependent on public contributions and donations. If this is your first time using this software we ask that you evaluate it and consider a small donation; for those who frequent and are continued users of this and other projects we also ask that you make an occasional small donation to help ensure the future of our public projects.

211 Replies to “Linux Malware Detect”

As for the problem with Modsec 2.7, it seems this can be workaround by appending an unused Action ID (required for every rule since 2.7). So to integrate with Modsecurity the following works for an example:

Hi Ryan,
When running maldet in ionotify mode, it writes an empty file named “0” in the directory it’s executed from. It’s not a major problem, but i’m finding these “0” files all over the place.
I’m running this on Debian 6.x on a 64-bit system, and running maldet in monitor mode with a filelist.

I would be interested in running maldet in real-time mode and have it watch the folder that contains all www apache roots on my server (Debian) namely: /var/www but I read up a bit on Inotify and found this statement which I think means that it does not recursively monitor all folders within.

Inotify does not support recursively watching directories, meaning that a separate inotify watch must be created for every subdirectory.

Did I understand this right? If I get it right, this will not work: maldet –monitor /var/www right?

So if I would i.e. add every single www root it still would not monitor subdirectories so what is the point? I mean most CMS out there have several subfolders and I certainly can’t add every single folder/subfolder for every web site I host.

If this is the case, I would have to rely on the cron scan but here again, I am unsure about how to edit the cronjob to only scan /var/www and /tmp as those are the only folders where the users the web processes run under can access.
So I’ll wait for your next version which I understand will include na easier way to specify the scan paths for the cron job.

Great product.
Is there any way to put maldet into update-only mode for automation? I want it to keep it up-date in terms of definitions, etc, but not run any scans at all unless they’re run on command-line (no inotify monitoring, etc).
At the moment if I manually make changes to the cron job that sometimes seems to get overwritten and reactivate regular scanning again.

You can empty the contents of /etc/cron.daily/maldet and then set it chattr +i so that it will not get overwritten on updates. That said, in the next release I will add a configuration variable and/or variable to the cronjob to control execution.

Is it possible to check the directory that is going to be checked for possible directories that are out of scope of the maxdepth setting and then warn or even error if the found depth is higher then maxdepth?
Otherwise we’d not be checking parts of our directories without us knowing..
( find .|awk -F/ ‘{print NF}’|sort -n|tail -1)