=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 code 406 (phase 2). File "/tmp/20121120-....-file" rejected by
the approver script "/usr/local/maldetect/hookscan.sh": 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 hookscan.sh 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 email_addr=you@domain.com
to the --config-option values:
--config-option quar_hits=1,quar_clean=0,clamav_scan=0,email_addr=you@domain.com
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 10 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 10 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
.: 13 [ 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:
YOUR_COMMAND MALWARE_FILE
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 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.
e.g: maldet -q SCANID
e.g: maldet --clean SCANID