Documentation

Linux Malware Detect v1.6.6 (C) 2002-2025, R-fx Networks <proj@r-fx.org> (C) 2025, Ryan MacDonald <ryan@r-fx.org> This program may be freely redistributed under the terms of the GNU GPL v2

::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::

.: 1 [ 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.

Using the CYMRU malware hash registry, which provides malware detection data for 30 major AV packages, we can demonstrate this short coming in current threat detection. The following is an analysis of 8,882 MD5 hashes that ship in LMD 1.5 and the percentage of major AV products that currently detect the hashes.

KNOWN MALWARE: 1951 % AV DETECT (AVG): 58 % AV DETECT (LOW): 10 % AV DETECT (HIGH): 100 UNKNOWN MALWARE: 6931

What this information means, is that of the 8,883 hashes, 78% or 6,931 malware threats are NOT detected by top-30 AV products. The 1,951 detected malware threats that are known have an average detection rate of 58% among top-30 AV products with a low and high detection rate of 10% and 100% respectively. This clearly demonstrates the significant lapse in user space malware detection that top-30 AV products currently provide. It is for this reason LMD was created, to fill a void, specifically for shared hosted environments.

.: 2 [ FEATURES ]

• MD5 file hash detection for quick threat identification
• HEX based pattern matching for identifying threat variants
• statistical analysis component for detection of obfuscated threats (e.g: base64)
• integrated detection of ClamAV to use as scanner engine for improved performance
• integrated signature update feature with -u|--update
• integrated version update feature with -d|--update-ver
• 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
• full reporting system to view current and previous scan results
• quarantine queue that stores threats in a safe fashion with no permissions
• quarantine batching option to quarantine the results of a current or past scans
• 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
• HTTP upload scanning through mod_security2 inspectFile hook
• e-mail alert reporting after every scan execution (manual & daily)
• path, extension and signature based ignore options
• background scanner option for unattended scan operations
• verbose logging & output of all actions

.: 3 [ THREAT 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.

The network I manage hosts over 35,000 web sites and as such receives a large amount of daily abuse, 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.

.: 4 [ RELEASE 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: http://www.rfxn.com/appdocs/CHANGELOG.maldetect

.: 4.1 [ SIGNATURE UPDATES ]

The LMD signatures 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.

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

.: 5 [ DETECTED THREATS ]

LMD 1.6 has a total of 11,061 (9,121 MD5 / 1940 HEX) signatures (before updates), below is a listing of the top 60 threats by prevalence detected by LMD.

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

.: 6 [ THREAT SHARING ]

I am a firm believer in not reinventing the wheel, for my own sanity or that of others. As such all unique threat data is submitted to CYMRU & ClamAV so that the open source and anti-malware community at large can grow from this project.

.: 7 [ CONFIGURATION ]

The configuration of LMD is handled through /usr/local/maldetect/conf.maldet and all options are well commented for ease of configuration.

By default LMD has the auto-quarantine of files disabled, this will mean that YOU WILL NEED TO ACT on any threats detected or pass the SCANID to the '-q' option to batch quarantine the results. To change this please set quarantine_hits=1 in conf.maldet.

.: 8 [ IGNORE OPTIONS ]

There are four ignore files available and they break down as follows:

/usr/local/maldetect/ignore_paths A line spaced file for paths that are to be excluded from search results Sample ignore entry: /home/user/public_html/cgi-bin

/usr/local/maldetect/ignore_file_ext A line spaced file for file extensions to be excluded from search results Sample ignore entry: .js .css

/usr/local/maldetect/ignore_sigs A line spaced file for signatures that should be removed from file scanning Sample ignore entry: base64.inject.unclassed

/usr/local/maldetect/ignore_inotify A line spaced file for regexp paths that are excluded from inotify monitoring Sample ignore entry: ^/home/user$ ^/var/tmp/#sql_.*\.MYD$

.: 9 [ CLI USAGE ]

Once LMD is installed it can be run through the 'maldet' command, the '--help' option gives a detailed summary of usage options:

-b, --background Execute operations in the background, ideal for large scans e.g: maldet -b -r /home/?/public_html 7

-u, --update [--force] Update malware detection signatures from rfxn.com

-d, --update-ver [--force] Update the installed version from rfxn.com

-m, --monitor USERS|PATHS|FILE Run maldet with inotify kernel level file create/modify monitoring If USERS is specified, monitor user homedirs for UID's > 500 If FILE is specified, paths will be extracted from file, line spaced If PATHS are specified, must be comma spaced list, NO WILDCARDS! e.g: maldet --monitor users e.g: maldet --monitor /root/monitor_paths e.g: maldet --monitor /home/mike,/home/ashton

-k, --kill Terminate inotify monitoring service

-r, --scan-recent PATH DAYS Scan files created/modified in the last X days (default: 7d, wildcard: ?) e.g: maldet -r /home/?/public_html 2

-a, --scan-all PATH Scan all files in path (default: /home, wildcard: ?) e.g: maldet -a /home/?/public_html

-c, --checkout FILE Upload suspected malware to rfxn.com for review & hashing into signatures

-l, --log View maldet log file events

-e, --report SCANID email View scan report of most recent scan or of a specific SCANID and optionally e-mail the report to a supplied e-mail address e.g: maldet --report e.g: maldet --report list e.g: maldet --report 050910-1534.21135 e.g: maldet --report SCANID user@domain.com

-E, --dump-report SCANID Similar to -e/--report except dumps the report to stdout instead. e.g: maldet --dump-report e.g: maldet --dump-report 050910-1534.21135

-s, --restore FILE|SCANID Restore file from quarantine queue to orginal path or restore all items from a specific SCANID e.g: maldet --restore /usr/local/maldetect/quarantine/config.php.23754 e.g: maldet --restore 050910-1534.21135

-q, --quarantine SCANID Quarantine all malware from report SCANID e.g: maldet --quarantine 050910-1534.21135

-n, --clean SCANID Try to clean & restore malware hits from report SCANID e.g: maldet --clean 050910-1534.21135

-U, --user USER Set execution under specified user, ideal for restoring from user quarantine or to view user reports. e.g: maldet --user nobody --report e.g: maldet --user nobody --restore 050910-1534.21135

-co, --config-option VAR1=VALUE,VAR2=VALUE,VAR3=VALUE Set or redefine the value of conf.maldet config options e.g: maldet --config-option email_addr=you@domain.com,quarantine_hits=1

-p, --purge Clear logs, quarantine queue, session and temporary data.

.: 10 [ CRON DAILY ]

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 a variety of control panel systems or standard Linux /home*/user paths.

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 use one of the customization hook files, such as '/usr/local/maldetect/cron/custom.cron', to write in custom scanning execution. For configuration based cron changes, you can redefine any conf.maldet variables at '/etc/sysconfig/maldet' or '/usr/local/maldetect/cron/conf.maldet.cron'.

.: 11 [ INOTIFY 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: 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. e.g: maldet --monitor users e.g: maldet --monitor /root/monitor_paths e.g: maldet --monitor /home/mike,/home/ashton

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.

.: 12 [ MODSECURITY2 UPLOAD SCANNING ]

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

The convenience script to facilitate this is called hookscan.sh and is located in the /usr/local/maldetect installation path. 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 hookscan.sh file if so desired, the default scan options are as follows: --config-option quarantine_hits=1,quarantine_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 enable upload scanning with mod_security2 you must set enable the scan_user_access option in conf.maldet (scan_user_access=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 appropriate 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/hookscan.sh" \ "id:'999999',log,auditlog,deny,severity:2,phase:2,t:none"

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 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 quarantine_hits=1,quarantine_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 quarantine_hits=1,quarantine_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 scan_user_access variable is enabled in conf.maldet. As such, it is important to make sure the scan_user_access 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 executes 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.

e.g: maldet -q SCANID e.g: maldet --clean SCANID

Advanced Policy Firewall (APF) v2.0.1 (C) 2002-2026, R-fx Networks <proj@rfxn.com> (C) 2026, Ryan MacDonald <ryan@rfxn.com>

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Advanced Policy Firewall (APF) is an iptables(netfilter) based firewall system designed around the essential needs of today's Internet deployed servers and the unique needs of custom deployed Linux installations. The configuration of APF is designed to be very informative and present the user with an easy to follow process, from top to bottom of the configuration file. The management of APF on a day-to-day basis is conducted from the command line with the 'apf' command, which includes detailed usage information and all the features one would expect from a current and forward thinking firewall solution.

The technical side of APF is such that it embraces the latest stable features put forward by the iptables(netfilter) project to provide a very robust and powerful firewall. The filtering performed by APF is three fold: 1) Static rule based policies (not to be confused with a "static firewall") 2) Connection based stateful policies 3) Sanity based policies

The first, static rule based policies, is the most traditional method of firewalling — an unchanging set of rules for how traffic should be handled. For example, allowing/denying an address via the trust system or opening a port in conf.apf.

The second, connection based stateful policies, distinguishes legitimate packets by tracking known connections. For example, FTP data transfers are dynamically permitted by relating port 21 control connections to the data channel — no complex static rules needed.

The third, sanity based policies, matches traffic against known attack methods and Internet standards. Forged source addresses are discarded, malformed packets from broken routers are dropped or replied to with TCP Reset.

For a detailed description of all APF features, review conf.apf (under your install path) which has well outlined captions above all options. Below is a point form summary of most APF features:

- detailed and well commented configuration file - granular inbound and outbound network filtering - user id based outbound network filtering - application based network filtering - trust based rule files with an optional advanced syntax - global trust system where rules can be downloaded from a central management server - reactive address blocking (RAB), in-line intrusion prevention with automatic address blocking on sanity violations and port scan detection - debug mode provided for testing new features and configuration setups - fast load feature that allows for 1000+ rules to load in under 1 second - inbound and outbound network interfaces can be independently configured - global tcp/udp port & icmp type filtering with multiple methods of executing filters (drop, reject, prohibit) - configurable policies for each ip on the system with convenience variables to import settings - packet flow rate limiting that prevents abuse on the most widely abused protocol, icmp - prerouting and postrouting rules for optimal network performance - dshield.org block list support to ban networks exhibiting suspicious activity - spamhaus Don't Route Or Peer List support to ban known "hijacked zombie" IP blocks - any number of additional interfaces may be configured as firewalled (untrusted) or trusted (not firewalled) - additional firewalled interfaces can have their own unique firewall policies applied - intelligent route verification to prevent embarrassing configuration errors - advanced packet sanity checks to make sure traffic coming and going meets the strictest of standards - filter attacks such as fragmented UDP, port zero floods, stuffed routing, arp poisoning and more - configurable type of service options to dictate the priority of different types of network traffic - intelligent default settings to meet every day server setups - dynamic configuration of your servers local DNS resolvers into the firewall - optional filtering of common p2p applications - optional filtering of private & reserved IP address space - optional implicit blocks of the ident service - configurable connection tracking settings to scale the firewall to the size of your network - configurable kernel hooks (ties) to harden the system further to syn-flood attacks & routing abuses - advanced network control such as explicit congestion notification and overflow control - special chains that are aware of the state of FTP DATA and SSH connections to prevent client side issues - control over the rate of logged events, want only 30 filter events a minute? 300 a minute? - you are the boss - logging subsystem that allows for logging data to user space programs or standard syslog files - logging that details every rule added and a comprehensive set of error checks to prevent config errors - if you are familiar with netfilter you can create your own rules in any of the policy files - pluggable and ready advanced use of QoS algorithms provided by the Linux kernel - IPv6 dual-stack support: automatic ip6tables rules alongside iptables when USE_IPV6 is enabled, including ICMPv6 filtering and NDP - input validation on all trust system entries (IPv4, IPv6, CIDR, FQDN) - nft backend detection with safe fast load across iptables backend changes - Docker/container compatibility mode for coexistence with Docker, Podman, Kubernetes, and containerd without destroying external chains - ipset block list support for kernel-level high-performance IP matching with O(1) lookup; one iptables rule per list instead of one rule per IP - GRE tunnel management with dedicated chains, protocol 47 rules, lifecycle controls (--gre-up/--gre-down/--gre-status), and persist-across-flush support - automatic dependency checking at startup with OS-aware install hints for missing packages (apt-get, yum, dnf) - ICMPv6 type filtering (IG_ICMPV6_TYPES/EG_ICMPV6_TYPES) with automatic NDP protection for types 133-136 - adaptive connection tracking scaling that auto-grows conntrack_max when usage exceeds 80%, with configurable ceiling and hash table sizing - IPv6 sysctl hardening: disables accept_source_route, accept_redirects, and accept_ra when USE_IPV6=1 - systemd service unit for modern init management

1.1) Introduction: Supported Systems & Requirements The APF package is designed to run on Linux based operating systems that have an operational version of the iptables (netfilter) package installed. Both the traditional iptables-legacy and the newer iptables-nft backends are supported. You can find out more details on the netfilter project at:

https://www.netfilter.org/

Most modern Linux distributions include all required iptables/netfilter modules by default. If you are building a custom kernel, ensure the following modules are available (built-in or modular):

iptable_filter iptable_mangle nf_conntrack nf_conntrack_ftp nf_conntrack_irc xt_state (or nf_conntrack with CT target) xt_multiport xt_limit xt_recent xt_LOG (or nf_log_syslog) xt_REJECT (ipt_REJECT / ip6t_REJECT) xt_ecn xt_length xt_mac xt_owner xt_TCPMSS

For IPv6 support (USE_IPV6=1), also ensure: ip6table_filter ip6table_mangle nf_conntrack_ipv6 (on kernels < 4.19; merged into nf_conntrack on 4.19+)

APF will attempt to load each module at startup and report any that are missing. You can check available modules with:

APF is tested and supported on the following platforms:

RHEL / Rocky Linux / AlmaLinux 8, 9 CentOS 7 (legacy support) Debian 10, 11, 12 Ubuntu 20.04, 22.04, 24.04 Fedora (current releases)

APF will generally run on any Linux distribution that provides iptables (legacy or nft backend) and a bash shell with standard GNU utilities (grep, awk, sed, etc.).

APF includes automatic dependency checking at startup. Critical dependencies (iptables, ip, modprobe, ip6tables when USE_IPV6=1) will prevent the firewall from starting if missing. Optional dependencies (wget, iptables-save, iptables-restore, diff, ipset) produce warnings but allow startup to continue. Install hints are OS-aware and suggest the correct package manager command (apt-get, yum, or dnf) for your distribution.

BFD (Brute Force Detection) 1.5-2 [bfdr-fx.org] Copyright (C) 1999-2008, R-fx Networks <proj@r-fx.org> Copyright (C) 2008, Ryan MacDonald <ryan@r-fx.org>

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

BFD is a modular shell script for parsing application logs and checking for authentication failures. It does this using a rules system where application specific options are stored including regular expressions for each unique auth format. The regular expressions are parsed against logs using the 'sed' tool (stream editor) which allows for vastly superior performance as opposed to perl based regular expressions or using other tools such as grep/egrep.

Although some will argue that perl based stream processing is far more flexible than unix tools, I argue that perl is a bloated framework to depend upon and unix tools such as sed are universal across *nix. Further, perl is only more flexible with regular expression based stream 'editing', such as in place editing etc.., if you are only processing a data stream (as bfd does) then sed wins hands down.

In addition to the benefits of parsing logs in a single stream, BFD also uses a log tracking system so logs are only parsed from the point which they were last read. This greatly assists in extending the performance of BFD even further as we are not constantly reading the same log data. The log tracking system is compatible with syslog/logrotate style log rotations which allows it to detect when rotations have happened and grab log tails from both the new log file and the rotated log file.

You can also leverage BFD to block attackers using any number of tools such as APF, Shorewall, raw iptables, ip route or execute any custom command. There is also a fully customizable e-mail alerting system with an e-mail template that is well suited for every day use or you can open it up and modify it.

The attacker tracking in BFD is handled using simple flat text files that are size-controlled to prevent space constraints over time, ideal for disk less devices. There is also an attack pool where trending data is stored on all hosts hat have been blocked including which rule the block was triggered by.

In the execution process, there is simply a cron job that executes BFD once every 3 minutes by default. An embedded lock file system makes sure that no two instances ever run at the same time, preventing messy and potentially load heavy results. The cronjob can be run more frequently for those that desire it and doing so will not cause any performance issues (no less than once a minute).

The included install.sh script does as it says, it will install bfd to the '/usr/local/bfd' path and place a 3-minute cronjob in '/etc/cron.d/bfd'. The setup script will also execute an included 'importconf' script if you have a previous version of bfd installed, which will import your previous settings.

Although it is supported to customize the default installation layout of BFD, it is not something I recommend or have done much testing with so do so as you see fit :-)

Incremental Rsync (IRSYNC) is an incremental backup utility built on rsync with integrated Linux traffic control (tc) shaping to regulate bandwidth consumption during transfers.

IRSYNC creates incremental snapshots using hard links, enabling storage-efficient point-in-time restore without duplicating unchanged files. It includes native MySQL backup support through mysqldump and mysqlhotcopy, making it suitable for backing up both file systems and databases on production servers.

Install from tarball:

  $ wget https://www.rfxn.com/downloads/irsync-current.tar.gz
  $ tar xfz irsync-current.tar.gz
  $ cd irsync-*/
  $ sudo ./install.sh

Verify download integrity:

  $ wget https://www.rfxn.com/downloads/irsync-current.tar.gz.md5
  $ md5sum -c irsync-current.tar.gz.md5

Linux Environment Security (LES) provides an increased level of local environment security with the goal of preventing environment-based attacks.

Such attacks include compromised system binaries, tainting the $PATH variable to point to invalid paths where trojan or malicious binaries are located, alterations to user profile scripts to activate key loggers or process-based hijacking, and traversal exploration of system paths. The possible attack trends are numerous, underscoring the importance of hardening the local environment space.

Install from tarball:

  $ wget https://www.rfxn.com/downloads/les-current.tar.gz
  $ tar xfz les-current.tar.gz
  $ cd les-*/
  $ sudo ./install.sh

Verify download integrity:

  $ wget https://www.rfxn.com/downloads/les-current.tar.gz.md5
  $ md5sum -c les-current.tar.gz.md5

Linux Socket Monitor (LSM) is a network socket monitor designed to track changes to both network sockets and Unix domain sockets, effectively serving as a port monitor.

LSM works by performing differential-based comparison of current and new server sockets — it records a base set of active sockets on install, then compares current socket information against these base comparison files. It uses cron to schedule scans at configurable intervals and sends email alerts when differences are detected, highlighting otherwise unknown services.

Install from tarball:

  $ wget https://www.rfxn.com/downloads/lsm-current.tar.gz
  $ tar xfz lsm-current.tar.gz
  $ cd lsm-*/
  $ sudo ./install.sh

Verify download integrity:

  $ wget https://www.rfxn.com/downloads/lsm-current.tar.gz.md5
  $ md5sum -c lsm-current.tar.gz.md5

Network Socket Inode Validation (NSIV) validates network socket inodes to detect security anomalies by correlating processes to their network sockets at the kernel inode level.

NSIV identifies potentially compromised or suspicious network activity by verifying that the inodes reported by network-facing processes match expected values, exposing hidden or injected sockets that may indicate rootkit activity, process hijacking, or unauthorized network access.

Install from tarball:

  $ wget https://www.rfxn.com/downloads/nsiv-current.tar.gz
  $ tar xfz nsiv-current.tar.gz
  $ cd nsiv-*/
  $ sudo ./install.sh

Verify download integrity:

  $ wget https://www.rfxn.com/downloads/nsiv-current.tar.gz.md5
  $ md5sum -c nsiv-current.tar.gz.md5

Process Resource Monitor (PRM) is a CPU, memory, process count, and run time resource monitor for Linux and BSD systems.

PRM supports both global-scoped limits and granular rule-based limits on a per-process or per-user basis. When resource thresholds are exceeded, PRM can terminate offending processes with optional parent/child tree termination and trigger service restarts post-termination to maintain availability.

Install from source:

  $ git clone https://github.com/rfxn/process-resource-monitor.git
  $ cd process-resource-monitor
  $ sudo ./install.sh

Install from tarball:

  $ wget https://www.rfxn.com/downloads/prm-current.tar.gz
  $ tar xfz prm-current.tar.gz
  $ cd prm-*/
  $ sudo ./install.sh

Verify download integrity:

  $ wget https://www.rfxn.com/downloads/prm-current.tar.gz.md5
  $ md5sum -c prm-current.tar.gz.md5

SIM (System Integrity Monitor) version 3.0 [sim@r-fx.org]

Copyright (C) 1999-2005, R-fx Networks <sim@r-fx.org> Copyright (C) 2005, Ryan MacDonald <ryan@r-fx.org>

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

----------------------------------------------- 1 ................ Introduction 1.1 .............. Features 2 ................ Setup 2.1 ............. Usage 3 ................ Extended Configuration 3.1 ............. Internal Functions 4 ................ License

SIM is a system and services monitor for `SysVinit` systems. It is designed to be intuitive and modular in nature, and to provide a clean and informative status system.

Fetch the latest version of sim3 from the sim home page at: http://www.rfxnetworks.com/sim.php

Current snapshot always available from below link: http://www.rfxnetworks.com/sim-current.tar.gz

Then simply extract the tar.gz archive as appropriate, ideally non-root user:

$ tar xvfz sim-current.tar.gz
$ ls

sim-3.0/

$ cd sim-3.0/

From this point once you have changed directory into the install package, the 'setup' or 'install.sh' script can be run. The different file names have no distinction, 'setup' is a symlink of 'install.sh' ('setup' remains in place for sim -u compat from 2.5.x vers).

$ ./setup

-i Install -q Quiet install -u Uninstall

In order to use any of the above options you will now be required to have root access; su to root or similar to gain a root shell. Then execute an appropriate option.

System Priority (SPRI) is a tool for managing system process priorities and CPU scheduling on Linux systems.

SPRI allows administrators to define priority rules for processes, ensuring that critical services receive appropriate CPU time while limiting the impact of resource-intensive or lower-priority tasks. It integrates with the Linux nice and scheduling subsystems to provide persistent, rule-based process priority management.

Install from tarball:

  $ wget https://www.rfxn.com/downloads/spri-current.tar.gz
  $ tar xfz spri-current.tar.gz
  $ cd spri-*/
  $ sudo ./install.sh

Verify download integrity:

  $ wget https://www.rfxn.com/downloads/spri-current.tar.gz.md5
  $ md5sum -c spri-current.tar.gz.md5