{"id":13550165,"url":"https://github.com/rfxn/linux-malware-detect","last_synced_at":"2025-05-14T13:08:08.273Z","repository":{"id":38454882,"uuid":"12685470","full_name":"rfxn/linux-malware-detect","owner":"rfxn","description":"Linux Malware Detection (LMD)","archived":false,"fork":false,"pushed_at":"2025-02-26T14:29:58.000Z","size":1927,"stargazers_count":1251,"open_issues_count":105,"forks_count":237,"subscribers_count":67,"default_branch":"master","last_synced_at":"2025-04-14T05:53:38.165Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://www.rfxn.com/projects/linux-malware-detect/","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rfxn.png","metadata":{"files":{"readme":"README","changelog":"CHANGELOG","contributing":null,"funding":null,"license":"COPYING.GPL","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2013-09-08T18:41:01.000Z","updated_at":"2025-04-11T22:25:28.000Z","dependencies_parsed_at":"2023-01-19T15:35:09.510Z","dependency_job_id":"88c00116-b10d-43df-abc8-4b2b59e02593","html_url":"https://github.com/rfxn/linux-malware-detect","commit_stats":null,"previous_names":[],"tags_count":15,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rfxn%2Flinux-malware-detect","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rfxn%2Flinux-malware-detect/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rfxn%2Flinux-malware-detect/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rfxn%2Flinux-malware-detect/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rfxn","download_url":"https://codeload.github.com/rfxn/linux-malware-detect/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254149960,"owners_count":22022851,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T12:01:29.666Z","updated_at":"2025-05-14T13:08:03.262Z","avatar_url":"https://github.com/rfxn.png","language":"Shell","funding_links":[],"categories":["Shell","Tools"],"sub_categories":["Malware / AV"],"readme":"Linux Malware Detect v1.6.6\n            (C) 2002-2025, R-fx Networks \u003cproj@r-fx.org\u003e\n            (C) 2025, Ryan MacDonald \u003cryan@r-fx.org\u003e\nThis program may be freely redistributed under the terms of the GNU GPL v2\n\n::::::::::::::::::::::::::::::::::\n\n:: CONTENTS ::\n.: 1 [ DESCRIPTION ]\n.: 2 [ FEATURES ]\n.: 3 [ THREAT SOURCE DATA ]\n.: 4 [ RELEASE UPDATES ]\n.: 4.1 [ SIGNATURE UPDATES ]\n.: 5 [ DETECTED THREATS ]\n.: 6 [ THREAT SHARING ]\n.: 7 [ CONFIGURATION ]\n.: 8 [ IGNORE OPTIONS ]\n.: 9 [ CLI USAGE ]\n.: 10 [ CRON DAILY ]\n.: 11 [ INOTIFY MONITORING ]\n.: 12 [ MODSECURITY2 UPLOAD SCANNING ]\n.: 13 [ CLEANER RULES ]\n\n::::::::::::::::::::::::::::::::::\n\n.: 1 [ DESCRIPTION ]\n\nLinux Malware Detect (LMD) is a malware scanner for Linux released under the \nGNU GPLv2 license, that is designed around the threats faced in shared hosted \nenvironments. It uses threat data from network edge intrusion detection \nsystems to extract malware that is actively being used in attacks and \ngenerates signatures for detection. In addition, threat data is also derived \nfrom user submissions with the LMD checkout feature and from malware \ncommunity resources. The signatures that LMD uses are MD5 file hashes and HEX \npattern matches, they are also easily exported to any number of detection \ntools such as ClamAV.\n\nThe driving force behind LMD is that there is currently limited availability \nof open source/restriction free tools for Linux systems that focus on malware \ndetection and more important that get it right. Many of the AV products that \nperform malware detection on Linux have a very poor track record of detecting \nthreats, especially those targeted at shared hosted environments.\n\nThe threat landscape in shared hosted environments is unique from that of the \nstandard AV products detection suite in that they are detecting primarily OS \nlevel trojans, rootkits and traditional file-infecting viruses but missing \nthe ever increasing variety of malware on the user account level which serves \nas an attack platform.\n\nUsing the CYMRU malware hash registry, which provides malware detection data \nfor 30 major AV packages, we can demonstrate this short coming in current \nthreat detection. The following is an analysis of 8,882 MD5 hashes that ship \nin LMD 1.5 and the percentage of major AV products that currently detect \nthe hashes.\n\nKNOWN MALWARE:      1951\n % AV DETECT (AVG):  58\n % AV DETECT (LOW):  10\n % AV DETECT (HIGH): 100\nUNKNOWN MALWARE:    6931\n\nWhat this information means, is that of the 8,883 hashes, 78% or 6,931 malware threats\nare NOT detected by top-30 AV products. The 1,951 detected malware threats that are known\nhave an average detection rate of 58% among top-30 AV products with a low and high\ndetection rate of 10% and 100% respectively. This clearly demonstrates the significant\nlapse in user space malware detection that top-30 AV products currently provide. It is for\nthis reason LMD was created, to fill a void, specifically for shared hosted environments.\n\n.: 2 [ FEATURES ]\n\n- MD5 file hash detection for quick threat identification\n- HEX based pattern matching for identifying threat variants\n- statistical analysis component for detection of obfuscated threats (e.g: base64)\n- integrated detection of ClamAV to use as scanner engine for improved performance\n- integrated signature update feature with -u|--update\n- integrated version update feature with -d|--update-ver\n- scan-recent option to scan only files that have been added/changed in X days\n- scan-all option for full path based scanning\n- checkout option to upload suspected malware to rfxn.com for review / hashing\n- full reporting system to view current and previous scan results\n- quarantine queue that stores threats in a safe fashion with no permissions\n- quarantine batching option to quarantine the results of a current or past scans\n- quarantine restore option to restore files to original path, owner and perms\n- quarantine suspend account option to Cpanel suspend or shell revoke users\n- cleaner rules to attempt removal of malware injected strings\n- cleaner batching option to attempt cleaning of previous scan reports\n- cleaner rules to remove base64 and gzinflate(base64 injected malware\n- daily cron based scanning of all changes in last 24h in user homedirs\n- daily cron script compatible with stock RH style systems, Cpanel \u0026 Ensim\n- kernel based inotify real time file scanning of created/modified/moved files\n- kernel inotify monitor that can take path data from STDIN or FILE\n- kernel inotify monitor convenience feature to monitor system users\n- kernel inotify monitor can be restricted to a configurable user html root\n- kernel inotify monitor with dynamic sysctl limits for optimal performance\n- kernel inotify alerting through daily and/or optional weekly reports\n- HTTP upload scanning through mod_security2 inspectFile hook\n- e-mail alert reporting after every scan execution (manual \u0026 daily)\n- path, extension and signature based ignore options\n- background scanner option for unattended scan operations\n- verbose logging \u0026 output of all actions\n\n\n.: 3 [ THREAT SOURCE DATA ]\n\nThe defining difference with LMD is that it doesn't just detect malware based \non signatures/hashes that someone else generated but rather it is an \nencompassing project that actively tracks in the wild threats and generates \nsignatures based on those real world threats that are currently circulating.\n\nThere are four main sources for malware data that is used to generate LMD \nsignatures:\n- Network Edge IPS: Through networks managed as part of my day-to-day job,\nprimarily web hosting related, our web servers receive a large amount of daily\nabuse events, all of which is logged by our network edge IPS. The IPS events\nare processed to extract malware url's, decode POST payload and base64/gzip\nencoded abuse data and ultimately that malware is retrieved, reviewed, classified\nand then signatures generated as appropriate. The vast majority of LMD signatures\nhave been derived from IPS extracted data.\n\nThe network I manage hosts over 35,000 web sites and as \nsuch receives a large amount of daily abuse, all of which is logged by our \nnetwork edge IPS. The IPS events are processed to extract malware url's, \ndecode POST payload and base64/gzip encoded abuse data and ultimately that \nmalware is retrieved, reviewed, classified and then signatures generated as \nappropriate. The vast majority of LMD signatures have been derived from IPS \nextracted data.\n - Community Data: Data is aggregated from multiple community malware websites \nsuch as clean-mx and malwaredomainlist then processed to retrieve new \nmalware, review, classify and then generate signatures.\n - ClamAV: The HEX \u0026 MD5 detection signatures from ClamAV are monitored for \nrelevant updates that apply to the target user group of LMD and added to the \nproject as appropriate. To date there has been roughly 400 signatures ported \nfrom ClamAV while the LMD project has contributed back to ClamAV by \nsubmitting over 1,100 signatures and continues to do so on an ongoing basis.\n - User Submission: LMD has a checkout feature that allows users to submit \nsuspected malware for review, this has grown into a very popular feature and \ngenerates on average about 30-50 submissions per week.\n\n.: 4 [ RELEASE UPDATES ]\nUpdates to the release version of LMD are not automatically installed but can\nbe installed using the --update-ver option. There is good reasons that this is\nnot done automatically and I really dont feel like listing them so just think\nabout it a bit.\n\nThe latest changes in the release version can always be viewed at:\nhttp://www.rfxn.com/appdocs/CHANGELOG.maldetect\n\n.: 4.1 [ SIGNATURE UPDATES ]\n\nThe LMD signatures are updated typically once per day or more frequently\ndepending on incoming threat data from the LMD checkout feature, IPS malware\nextraction and other sources. The updating of signatures in LMD installations\nis performed daily through the default cron.daily script with the --update\noption, which can be run manually at any time.\n\nAn RSS \u0026 XML data source is available for tracking malware threat updates:\nRSS Recent Signatures: http://www.rfxn.com/api/lmd\nXML Recent Signatures: http://www.rfxn.com/api/lmd?id=recent\nXML All Signatures:    http://www.rfxn.com/api/lmd?id=all\n\n.: 5 [ DETECTED THREATS ]\n\nLMD 1.6 has a total of 11,061 (9,121 MD5 / 1940 HEX) signatures (before updates),\nbelow is a listing of the top 60 threats by prevalence detected by LMD.\n\nbase64.inject.unclassed    bin.dccserv.irsexxy      bin.fakeproc.Xnuxer\nbin.ircbot.nbot            bin.ircbot.php3          bin.ircbot.unclassed\nbin.pktflood.ABC123        bin.pktflood.osf         bin.trojan.linuxsmalli\nc.ircbot.tsunami           exp.linux.rstb           exp.linux.unclassed\nexp.setuid0.unclassed      gzbase64.inject          html.phishing.auc61\nhtml.phishing.hsbc         perl.connback.DataCha0s  perl.connback.N2\nperl.cpanel.cpwrap         perl.mailer.yellsoft     perl.ircbot.atrixteam\nperl.ircbot.bRuNo          perl.ircbot.Clx          perl.ircbot.devil\nperl.ircbot.fx29           perl.ircbot.magnum       perl.ircbot.oldwolf\nperl.ircbot.putr4XtReme    perl.ircbot.rafflesia    perl.ircbot.UberCracker\nperl.ircbot.xdh            perl.ircbot.xscan        perl.shell.cbLorD\nperl.shell.cgitelnet       php.cmdshell.c100        php.cmdshell.c99\nphp.cmdshell.cih           php.cmdshell.egyspider   php.cmdshell.fx29\nphp.cmdshell.ItsmYarD      php.cmdshell.Ketemu      php.cmdshell.N3tshell\nphp.cmdshell.r57           php.cmdshell.unclassed   php.defash.buno\nphp.exe.globals            php.include.remote       php.ircbot.InsideTeam\nphp.ircbot.lolwut          php.ircbot.sniper        php.ircbot.vj_denie\nphp.mailer.10hack          php.mailer.bombam        php.mailer.PostMan\nphp.phishing.AliKay        php.phishing.mrbrain     php.phishing.ReZulT\nphp.pktflood.oey           php.shell.rc99           php.shell.shellcomm\n\n.: 6 [ THREAT SHARING ]\n\nI am a firm believer in not reinventing the wheel, for my own sanity or that\nof others. As such all unique threat data is submitted to CYMRU \u0026 ClamAV so\nthat the open source and anti-malware community at large can grow from this\nproject.\n\n.: 7 [ CONFIGURATION ]\n\nThe configuration of LMD is handled through /usr/local/maldetect/conf.maldet\nand all options are well commented for ease of configuration.\n\nBy default LMD has the auto-quarantine of files disabled, this will mean that\nYOU WILL NEED TO ACT on any threats detected or pass the SCANID to the '-q'\noption to batch quarantine the results. To change this please set\nquarantine_hits=1 in conf.maldet.\n\n.: 8 [ IGNORE OPTIONS ]\n\nThere are four ignore files available and they break down as follows:\n\n/usr/local/maldetect/ignore_paths\nA line spaced file for paths that are to be excluded from search results\n Sample ignore entry:\n /home/user/public_html/cgi-bin\n\n/usr/local/maldetect/ignore_file_ext\nA line spaced file for file extensions to be excluded from search results\n Sample ignore entry:\n .js\n .css\n\n/usr/local/maldetect/ignore_sigs\nA line spaced file for signatures that should be removed from file scanning\n Sample ignore entry:\n base64.inject.unclassed\n\n/usr/local/maldetect/ignore_inotify\nA line spaced file for regexp paths that are excluded from inotify monitoring\n Sample ignore entry:\n ^/home/user$\n ^/var/tmp/#sql_.*\\.MYD$\n\n.: 9 [ CLI USAGE ]\n\nOnce LMD is installed it can be run through the 'maldet' command, the '--help'\noption gives a detailed summary of usage options:\n\n    -b, --background\n      Execute operations in the background, ideal for large scans\n      e.g: maldet -b -r /home/?/public_html 7\n\n    -u, --update [--force]\n       Update malware detection signatures from rfxn.com\n\n    -d, --update-ver [--force]\n       Update the installed version from rfxn.com\n\n    -m, --monitor USERS|PATHS|FILE\n       Run maldet with inotify kernel level file create/modify monitoring\n       If USERS is specified, monitor user homedirs for UID's \u003e 500\n       If FILE is specified, paths will be extracted from file, line spaced\n       If PATHS are specified, must be comma spaced list, NO WILDCARDS!\n       e.g: maldet --monitor users\n       e.g: maldet --monitor /root/monitor_paths\n       e.g: maldet --monitor /home/mike,/home/ashton\n\n    -k, --kill\n       Terminate inotify monitoring service\n\n    -r, --scan-recent PATH DAYS\n       Scan files created/modified in the last X days (default: 7d, wildcard: ?)\n       e.g: maldet -r /home/?/public_html 2\n\n    -a, --scan-all PATH\n       Scan all files in path (default: /home, wildcard: ?)\n       e.g: maldet -a /home/?/public_html\n\n    -c, --checkout FILE\n       Upload suspected malware to rfxn.com for review \u0026 hashing into signatures\n\n    -l, --log\n       View maldet log file events\n\n    -e, --report SCANID email\n       View scan report of most recent scan or of a specific SCANID and optionally\n       e-mail the report to a supplied e-mail address\n       e.g: maldet --report\n       e.g: maldet --report list\n       e.g: maldet --report 050910-1534.21135\n       e.g: maldet --report SCANID user@domain.com\n\n    -E, --dump-report SCANID\n       Similar to -e/--report except dumps the report to stdout instead.\n       e.g: maldet --dump-report\n       e.g: maldet --dump-report 050910-1534.21135\n\n    -s, --restore FILE|SCANID\n       Restore file from quarantine queue to orginal path or restore all items from\n       a specific SCANID\n       e.g: maldet --restore /usr/local/maldetect/quarantine/config.php.23754\n       e.g: maldet --restore 050910-1534.21135\n\n    -q, --quarantine SCANID\n       Quarantine all malware from report SCANID\n       e.g: maldet --quarantine 050910-1534.21135\n\n    -n, --clean SCANID\n       Try to clean \u0026 restore malware hits from report SCANID\n       e.g: maldet --clean 050910-1534.21135\n\n    -U, --user USER\n       Set execution under specified user, ideal for restoring from user quarantine or\n       to view user reports.\n       e.g: maldet --user nobody --report\n       e.g: maldet --user nobody --restore 050910-1534.21135\n\n    -co, --config-option VAR1=VALUE,VAR2=VALUE,VAR3=VALUE\n       Set or redefine the value of conf.maldet config options\n       e.g: maldet --config-option email_addr=you@domain.com,quarantine_hits=1\n\n    -p, --purge\n       Clear logs, quarantine queue, session and temporary data.\n\n.: 10 [ CRON DAILY ]\n\nThe cronjob installed by LMD is located at /etc/cron.daily/maldet and is used\nto perform a daily update of signatures, keep the session, temp and quarantine\ndata to no more than 14d old and run a daily scan of recent file system changes.\n\nThe daily scan supports a variety of control panel systems or standard Linux\n/home*/user paths. \n\nIf you are running monitor mode, the daily scans will be skipped and instead a\ndaily report will be issued for all monitoring events. \n\nIf you need to scan additional paths, you should review the cronjob and use one\nof the customization hook files, such as '/usr/local/maldetect/cron/custom.cron',\nto write in custom scanning execution. For configuration based cron changes, you\ncan redefine any conf.maldet variables at '/etc/sysconfig/maldet' or \n'/usr/local/maldetect/cron/conf.maldet.cron'.\n\n.: 11 [ INOTIFY MONITORING ]\n\nThe inotify monitoring feature is designed to monitor users in real-time for\nfile creation/modify/move operations. This option requires a kernel that\nsupports inotify_watch (CONFIG_INOTIFY) which is found in kernels 2.6.13+\nand CentOS/RHEL 5 by default. If you are running CentOS 4 you should consider\nan inbox upgrade with: http://www.rfxn.com/upgrade-centos-4-8-to-5-3/\n\nThere are three modes that the monitor can be executed with and they relate\nto what will be monitored, they are USERS|PATHS|FILES. \n       e.g: maldet --monitor users\n       e.g: maldet --monitor /root/monitor_paths\n       e.g: maldet --monitor /home/mike,/home/ashton\n\nThe options break down as follows:\nUSERS -  The users option will take the homedirs of all system users that are\n         above inotify_minuid and monitor them. If inotify_webdir is set then\n         the users webdir, if it exists, will only be monitored.\nPATHS -  A comma spaced list of paths to monitor\nFILE  -  A line spaced file list of paths to monitor\n\nOnce you start maldet in monitor mode, it will preprocess the paths based on\nthe option specified followed by starting the inotify process. The starting of\nthe inotify process can be a time consuming task as it needs to setup a monitor\nhook for every file under the monitored paths. Although the startup process can\nimpact the load temporarily, once the process has started it maintains all of\nits resources inside kernel memory and has a very small userspace footprint in\nmemory or cpu usage.\n\nThe scanner component of the monitor watches for notifications from the inotify\nprocess and batches items to be scanned, by default, every 30 seconds. If you\nneed tighter control of the scanning timer, you can edit inotify_stime in\nconf.maldet.\n\nThe alerting of file hits under monitor mode is handled through a daily report\ninstead of sending an email on every hit. The cron.daily job installed by LMD\nwill call an --alert-daily flag and send an alert for the last days hits. There\nis also an --alert-weekly option that can be used, simply edit the cron at\n/etc/cron.daily/maldet and change the --alert-daily to --alert-weekly.\n\nTerminating the inotify monitoring is done by passing the '-k|--kill-monitor'\noption to maldet, it will touch a file handle monitored by maldet and on the\nnext waking cycle of the monitor service, it will terminate itself and all\ninotify processes.\n\n.: 12 [ MODSECURITY2 UPLOAD SCANNING ]\n\nThe support for HTTP upload scanning is provided through mod_security2's inspectFile hook.\nThis feature allows for a validation script to be used in permitting or denying an upload. \n\nThe convenience script to facilitate this is called hookscan.sh and is located in the\n/usr/local/maldetect installation path. The default setup is to run a standard maldet scan\nwith no clamav support, no cleaner rule executions and quarantining enabled; these options\nare set in the interest of performance vs accuracy which is a fair tradeoff. \n\nThe scan options can be modified in the hookscan.sh file if so desired, the default\nscan options are as follows:\n--config-option quarantine_hits=1,quarantine_clean=0,clamav_scan=0 --modsec -a \"$file\"\n\nThere is a tangible performance difference in disabling clamav scanning in this usage\nscenario. The native LMD scanner engine is much faster than the clamav scanner engine\nin single file scans by a wide margin. A single file scan using clamav takes roughly\n3sec on average while the LMD scanner engine takes 0.5sec or less.\n\nTo enable upload scanning with mod_security2 you must set enable the scan_user_access option\nin conf.maldet (scan_user_access=1) then add the following rules to your mod_security2 \nconfiguration. These rules are best placed in your modsec2.user.conf file on cpanel servers\nor at the top of the appropriate rules file for your setup.\n\n/usr/local/apache/conf/modsec2.user.conf (or similar mod_security2 rules file):\nSecRequestBodyAccess On\nSecRule FILES_TMPNAMES \"@inspectFile /usr/local/maldetect/hookscan.sh\" \\\n                \"id:'999999',log,auditlog,deny,severity:2,phase:2,t:none\"\n\nIf using ModSecurity \u003e=2.9, you should set 'SecTmpSaveUploadedFiles On' before the\n'SecRule FILES_TMPNAMES' line.\n\nA restart of the Apache service is required following these changes.\n\nWhen an upload takes place that is determined to be malware, it will be rejected and an\nentry will appear in the mod_security2 SecAuditLog file. On cpanel servers and most\nconfigurations this is the modsec_audit.log located under /usr/local/apache/logs or \n/var/log/httpd.\n\nThe log entry will appear similar to the following:\nMessage: Access denied with code 406 (phase 2). File \"/tmp/20121120-....-file\" rejected by\nthe approver script \"/usr/local/maldetect/hookscan.sh\": 0 maldet: {HEX}php.cmdshell.r57.317\n/tmp/20121120-....-file [file \"/usr/local/apache/conf/modsec2.user.conf\"] [line \"3\"]\n[severity \"CRITICAL\"]\n\nThe default alerting options will apply and an e-mail will be sent when hits are found. This\ncan be changed in the hookscan.sh script by editing the --config-option values.\n\nTo disable alerts append email_alert=0 to the --config-option values:\n--config-option quarantine_hits=1,quarantine_clean=0,clamav_scan=0,email_alert=0\n\nTo change the e-mail address for alerts on upload hits, append email_addr=you@domain.com\nto the --config-option values:\n--config-option quarantine_hits=1,quarantine_clean=0,clamav_scan=0,email_addr=you@domain.com\n\nThe nature of uploads is such that they are performed either under the user that the HTTP\nservice is running as or under that of a system user in an suexec style setup (i.e: phpsuexec).\nThis required a change to the way LMD stores session, temporary and quarantine data to allow\nfor non-root users to perform scans.\n\nGiven that the maldetect installation path is owned by user root, we either need to set a pub\npath world writable (777) or populate the pub path with user owned paths. It was undesirable\nto set any path world writable and as such a feature to populate path data was created. This\nfeature is controlled with the --mkpubpaths flag and is executed from cron every 10 minutes,\nit will only execute if the scan_user_access variable is enabled in conf.maldet. As such, it is\nimportant to make sure the scan_user_access variable is set to enabled (1) in conf.maldet and it is\nadvised to run 'maldet --mkpubpaths' manually to prepopulate the user paths. There after, the\ncron will ensure new users have paths created no later than 10 minutes after creation.\n\nAll non-root scans, such as those performed under mod_security2, will be stored under the\n/usr/local/maldetect/pub/username directory tree. The quarantine paths are relative to the user\nthat executes the scan, so user nobody would be under pub/nobody/quar/. The actual paths\nfor where files are quarantined and the user which executed the scan, can be verified in the\ne-mail reports for upload hits.\n\nTo restore files quarantined under non-root users, you must pass the -U|--user option to LMD,\nfor example if user nobody quarantined a file you would like to restore, it can be restored as\nfollows:\nmaldet --user nobody /usr/local/maldetect/pub/nobody/quar/20121120-file-SFwTeu.22408\n\nOr, as always the scan ID can be used to restore\nmaldet --user nobody 112012-0032.13771\n\n.: 13 [ CLEANER RULES ]\n\nThe cleaner function looks for signature-named rules under the clean/ path,\nthese rules can consist of any command that is designed to clean a file of\nmalware. A cleaner rule must result in a file being able to pass a scan\nwithout tripping a HIT otherwise it will classify the clean action as FAILED.\n\nLet us assume for a moment we have malware that we want to clean and it trips\nwith the signature \"{HEX}php.cmdshell.r57.89\". The actual signature string in\nthis is \"php.cmdshell.r57\", the \"{HEX}\" just defines the format and \".89\" is\nthe variant number. So, to create a clean rule for php.cmdshell.r57 we would\nadd a file 'clean/php.cmdshell.r57' and this would be executed against any\nfile that hits on the signature of the same name.\n\nThe actual contents of the rule should be a single line command that will be\nexecuted against the hit file, for example the execution looks something like:\n\nYOUR_COMMAND MALWARE_FILE\n\nSo, for a string based malware injection you could easily throw in a 'sed -i'\ninto the rule file with the appropriate pattern to strip the string(s) from\nthe file. Once the clean command has run, a rescan will be performed on the\nfile and if it causes causes a hit, the clean will be marked as FAILED. A\nsuccessful clean ALWAYS results in the file being restored if possible to\nits original path, owner and mode.\n\nAn important note is that the cleaner function is a subfunction of the\nquarantine, so if the quarantine is disabled then by default, malware hits\nwill not have clean attempts made. There are two ways around this, apart from\nthe obvious of turning on quarantine and rescanning (which is a waste of time).\nThe best way is to enable the quarantine and then use the -q|--quarantine flag\nto batch through the scan results, which will quarantine and clean files. The\nsecond is to use the -n|--clean flag which will try to clean files in place,\nbe that in the quarantine or the files original path, wherever it can be found.\n\ne.g: maldet -q SCANID\ne.g: maldet --clean SCANID\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frfxn%2Flinux-malware-detect","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frfxn%2Flinux-malware-detect","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frfxn%2Flinux-malware-detect/lists"}