How to Write Custom CSF/LFD Regex Trigger Rules in Perl to Block Brute-Force Attacks on cPanel Servers in Pakistan

On high-density cPanel hosting servers in Pakistan, ConfigServer Security & Firewall (CSF) and its companion Login Failure Daemon (LFD) form the front line of defense against network intrusion. Out of the box, LFD monitors standard system logs to detect and block brute-force password guessing against SSH, FTP (Pure-FTPd / ProFTPD), cPanel WHM ports (2083/2087), and mail daemons (Exim, Dovecot).

However, modern threat actors rarely attack standard administrative ports directly. Instead, botnets target application-level authentication endpoints:

• WordPress REST API and xmlrpc.php brute-forcing.
• Custom e-commerce login endpoints (WooCommerce, Magento, Laravel, OpenCart).
• Customer portal login forms and API token endpoints.

When bots pound these PHP scripts, standard LFD rules ignore the traffic because the failures are recorded in Apache/LiteSpeed web access logs (access_log or error_log) rather than system auth logs.

To automatically detect and ban these IP addresses via iptables at line rate, sysadmins must write custom Perl regular expressions inside /etc/csf/regex.custom.pm. In this guide, we show you how to structure, test, and deploy production LFD regex triggers on bare-metal Dedicated Servers and Dedicated Servers in Pakistan.

---

1. How LFD Processes Custom Log Files

LFD executes as a resident Perl daemon. In addition to system logs, CSF allows you to bind arbitrary log paths using the CUSTOMx_LOG directives in /etc/csf/csf.conf:

+--------------------------------------------------------------+
|                 Apache / LiteSpeed Web Traffic               |
|                 Customer App: /api/v1/login                  |
+------------------------------+-------------------------------+
                               |
                               v
+--------------------------------------------------------------+
|        Log Entry written to /var/log/apache2/access_log      |
+------------------------------+-------------------------------+
                               |
                               v (Tailed in real-time)
+--------------------------------------------------------------+
|                 LFD Daemon (regex.custom.pm)                 |
|  - Matches IP address ($1) and failure pattern               |
|  - Increments failure counter in /var/lib/csf/lfd.bans       |
|  - If failures > threshold: Executes IPTables Kernel Drop    |
+--------------------------------------------------------------+

Directives in /etc/csf/csf.conf

Edit /etc/csf/csf.conf to declare which log file LFD should tail:

# Path to the log file to monitor
CUSTOM1_LOG = "/etc/apache2/logs/access_log"

# Max login failures within the tracking window
CUSTOM1_MAX = "5"

# Window interval in seconds to track failures (e.g., 300s = 5 mins)
CUSTOM1_INTERVAL = "300"

# Permanent ban (1) or temporary ban duration in seconds (e.g., 3600 = 1 hour)
CUSTOM1_PERM = "3600"

---

2. Anatomy of /etc/csf/regex.custom.pm

LFD provides the Perl module /etc/csf/regex.custom.pm specifically for user-defined pattern matching. The function custom_line() receives each incoming log line as my $line = shift;.

If the regular expression matches an authentication failure, it must return a 3-element tuple:

1. $ip: The remote offending IP address (mandatory, IPv4 or IPv6).
2. $acc: The target username/account being attacked (or empty string "").
3. $text: A descriptive identifier logged in /var/log/lfd.log.

If the line does not match, it must return "".

Real-World Example: Catching WordPress XML-RPC & Login Flood

Open /etc/csf/regex.custom.pm:

nano /etc/csf/regex.custom.pm

Locate the section after my $line = shift; and add your custom Perl block:

# -------------------------------------------------------------------
# Custom Rule: Block WordPress XML-RPC Brute Force via Apache Access Log
# Matches: 192.0.2.45 - - [04/Oct/2026:17:30:12 +0500] "POST /xmlrpc.php HTTP/1.1" 200 ...
# -------------------------------------------------------------------
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /^(\S+)\s+\S+\s+\S+\s+\[[^\]]+\]\s+"POST\s+\/(?:xmlrpc\.php|wp-login\.php)\s+HTTP\/[0-9\.]+"\s+(?:200|401|403)\s+/)) {
    my $ip = $1;
    my $acc = "";
    my $text = "WordPress XML-RPC / wp-login Brute Force Attempt";
    return ($ip, $acc, $text);
}

# -------------------------------------------------------------------
# Custom Rule: Block Laravel / Nextcloud Failed API Auth
# Matches: 198.51.100.12 - - [04/Oct/2026:17:31:00 +0500] "POST /api/v1/auth/login HTTP/1.1" 401 ...
# -------------------------------------------------------------------
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /^(\S+)\s+\S+\s+\S+\s+\[[^\]]+\]\s+"POST\s+\/api\/v1\/auth\/login\s+HTTP\/[0-9\.]+"\s+401\s+/)) {
    my $ip = $1;
    my $acc = "";
    my $text = "Failed REST API Authentication Flood";
    return ($ip, $acc, $text);
}

---

3. Testing and Validating Regex Without Service Disruption

Before reloading LFD on a live production server, verify your Perl regular expressions using Perl’s command-line interpreter:

# Verify syntax of the Perl script
perl -c /etc/csf/regex.custom.pm

If it prints Syntax OK, test your pattern against a synthetic log line:

perl -e '
my $line = q(203.0.113.88 - - [04/Oct/2026:18:00:00 +0500] "POST /xmlrpc.php HTTP/1.1" 200 450);
if ($line =~ /^(\S+)\s+\S+\s+\S+\s+\[[^\]]+\]\s+"POST\s+\/(?:xmlrpc\.php|wp-login\.php)\s+HTTP\/[0-9\.]+"\s+(?:200|401|403)\s+/) {
    print "SUCCESS: Matched IP $1\n";
} else {
    print "FAIL: No match\n";
}
'

Once confirmed, restart LFD to apply the new rules:

# Restart LFD and reload CSF rules
csf -ra

---

4. Monitoring Live Bans & Avoiding False Positives

Check /var/log/lfd.log to watch your custom rules actively capturing and dropping malicious traffic:

tail -f /var/log/lfd.log | grep "WordPress XML-RPC"

When an attacker trips the threshold (CUSTOM1_MAX = 5), LFD logs:

Oct  4 18:05:12 web1 lfd[14820]: (CUSTOM1) WordPress XML-RPC / wp-login Brute Force Attempt 203.0.113.88 (PK/Pakistan): 5 in the last 300 secs - *Blocked in iptables* [csf.deny]

Whitelisting Trusted IPs

To prevent office networks or monitoring bots from being banned:

• Add trusted IP subnets to /etc/csf/csf.ignore and /etc/csf/csf.allow.
• Re-run csf -ra to reload the whitelist.

For comprehensive server-side hardening, pair your CSF configuration with our operational guides on cPanel ChkServd Auto-Healing and cPanel ProFTPD Hardening.

---