The inotify monitoring feature is designed to monitor users in real-time for 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.

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

       maldet --monitor users
       maldet --monitor /root/monitor_paths
       maldet --monitor //mike,//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 . The cron.daily job installed by LMD will call an –alert-daily flag and send an alert for the last day’s 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.

ModSecurity2 Upload Scanning:

The support for HTTP upload scanning is provided through mod_2’s inspectFile hook. This feature allows for a validation script to be used in permitting or denying an upload. 

The convenience script to faciliate this is called and is located in the /usr/local/maldetect installation . The default setup is to run a standard maldet scan with no clamav support, no cleaner rule executions and quarantining enabled; these options are set in the interest of performance vs accuracy which is a fair tradeoff. 

The scan options can be modified in the file if so desired, the default scan options are as follows:

--config-option quar_hits=1,quar_clean=0,clamav_scan=0 --modsec -a "$file"

There is a tangible performance difference in disabling clamav scanning in this usage scenario. The native LMD scanner engine is much faster than the clamav scanner engine in single file scans by a wide margin. A single file scan using clamav takes roughly 3sec on average while the LMD scanner engine takes 0.5sec or less.

To upload scanning with mod_security2 you must set the public_scan option in conf.maldet (public_scan=1) then add the following rules to your mod_security2 configuration. These rules are best placed in your modsec2.user.conf file on cpanel servers or at the top of the appropraite rules file for your setup.

/usr/local/apache/conf/modsec2.user.conf (or similar mod_security2 rules file):

SecRequestBodyAccess On
SecRule FILES_TMPNAMES "@inspectFile /usr/local/maldetect/" 

If using ModSecurity >=2.9, you should set ‘SecTmpSaveUploadedFiles On’ before the

‘SecRule FILES_TMPNAMES’ line.

A restart of the Apache service is required following these changes.

When an upload takes place that is determined to be malware, it will be rejected and an entry will appear in the mod_security2 SecAuditLog file. On cpanel servers and most configurations this is the modsec_audit.log located under /usr/local/apache/logs or /var/log/httpd.

The log entry will appear similar to the following:

Message: Access denied with  406 (phase 2). File "/tmp/20121120-....-file" rejected by
the approver script "/usr/local/maldetect/": 0 maldet: {HEX}php.cmdshell.r57.317
/tmp/20121120-....-file [file "/usr/local/apache/conf/modsec2.user.conf"] [line "3"]
[severity "CRITICAL"]

The default alerting options will apply and an e-mail will be sent when hits are found. This can be changed in the script by editing the –config-option values.

To disable alerts append email_alert=0 to the –config-option values:

--config-option quar_hits=1,quar_clean=0,clamav_scan=0,email_alert=0

To change the e-mail address for alerts on upload hits, append to the –config-option values:

--config-option quar_hits=1,quar_clean=0,clamav_scan=0,

The nature of uploads is such that they are performed either under the user that the HTTP service is running as or under that of a system user in an suexec style setup (i.e: phpsuexec).

This required a change to the way LMD stores session, temporary and quarantine data to allow for non-root users to perform scans.

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 minutes, it will only execute if the public_scan variable is enabled in conf.maldet. As such, it is important to make sure the public_scan 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 minutes after creation.

All non-root scans, such as those performed under mod_security2, will be stored under the /usr/local/maldetect/pub/username directory tree. The quarantine paths are relative to the user that exectues the scan, so user nobody would be under pub/nobody/quar/. The actual paths for where files are quarantined and the user which executed the scan, can be verified in the e-mail reports for upload hits.

To restore files quarantined under non-root users, you must pass the -U|–user option to LMD, for example if user nobody quarantined a file you would like to restore, it can be restored as follows:

maldet --user nobody /usr/local/maldetect/pub/nobody/quar/20121120-file-SFwTeu.22408

Or, as always the scan ID can be used to restore

maldet --user nobody 112012-0032.13771

Cleaner Rules:

The cleaner function looks for signature-named rules under the clean/ path, these rules can consist of any command that is designed to clean a file of malware. A cleaner rule must result in a file being able to pass a scan without tripping a HIT otherwise it will classify the clean action as FAILED.

Let us assume for a moment we have malware that we want to clean and it trips with the signature {HEX}php.cmdshell.r57.89″. The actual signature string in this is “php.cmdshell.r57”, the “{HEX}” just defines the format and “.89” is the variant number. So, to create a clean rule for php.cmdshell.r57 we would add a file ‘clean/php.cmdshell.r57’ and this would be executed against any file that hits on the signature of the same name.

The actual contents of the rule should be a single line command that will be executed against the hit file, for example, the execution looks something like:


So, for a string based malware injection, you could easily throw in a ‘sed -i’ into the rule file with the appropriate pattern to strip the string(s) from the file. Once the clean command has run, a rescan will be performed on the file and if it causes a hit, the clean will be marked as FAILED. A successful clean ALWAYS results in the file being restored if possible to its original path, owner, and mode.

An important note is that the cleaner function is a subfunction of the quarantine, so if the quarantine is disabled then by default, malware hits will not have clean attempts made. There are two ways around this, apart from the obvious of turning on quarantine and rescanning (which is a waste of time). The best way is to enable the quarantine and then use the -q|–quarantine flag to batch through the scan results, which will quarantine and clean files. The second is to use the -n|–clean flag which will try to clean files in place, be that in the quarantine or the files original path, wherever it can be found.


   maldet -q SCANID
   maldet --clean SCANID

Source link

thanks you RSS link


Please enter your comment!
Please enter your name here