CSF and blocking OpenCart

[toplisek]

I try to secure login inside OpenCart. I kindly ask you to help me if code is the correct for CSF:

<!-- CSF/LFD to Block OpenCart Bruteforce Attacks ---->
<!-- 1. Edit the file -->
nano /usr/local/csf/bin/regex.custom.pm
<!-- Add the following code: -->
# XMLRPC
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/xmlrpc\.php.*" /)) {
return ("WP XMLPRC Attack",$1,"XMLRPC","5","80,443","1");
}

# OC-LOGINS Users
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/admin/index\.php.*" /)) {
return ("OC Login Attack",$1,"OCLOGIN","5","80,443","1");
}

# OC-LOGINS Administrator
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/admin/index\.php.*" /)) {
return ("OC Login Attack",$1,"OCLOGIN","5","80,443","1");
}
<!-- 2. Add the custom log that CSF/LFD will monitor -->
nano /etc/csf/csf.conf

[anon321]

The code you provided is a custom regex rules for the CSF (ConfigServer Security & Firewall) to detect certain patterns in the logs and potentially block offending IP addresses. Here’s a breakdown of your code and a few observations:

1. XMLRPC Attack:
   Your first rule aims to catch potential XMLRPC attacks, specifically requests to the /xmlrpc.php file, which is commonly associated with WordPress.

2. OC-LOGINS Users:
   Your second rule aims to catch login attempts to OpenCart’s admin portal (/admin/index.php). It looks like you’re trying to detect multiple login attempts.

3. OC-LOGINS Administrator:
   The third rule is identical to the second one. It doesn’t differentiate between users and administrators.

Observations and Recommendations:

1. Duplicate Rules: The rules for “OC-LOGINS Users” and “OC-LOGINS Administrator” are identical. If you want to differentiate between user and administrator logins, you need a distinct log pattern for each. If there’s no distinction in the logs, then having two identical rules is redundant.

2. Limiting Factor: Each rule returns an action after 5 matched patterns (“5”). This means after 5 detected attempts, CSF will take an action against the IP.

3. Target Ports: In your return action, you’ve specified ports 80 and 443 (“80,443”). This makes sense as these are the default HTTP and HTTPS ports.

4. Duration: The last parameter in your return statement (“1”) likely stands for the duration or action, which might mean to block the IP for a specified duration or permanently. The exact behavior depends on your CSF configuration.

5. /etc/csf/csf.conf: After adding custom regex rules, you typically also need to configure CSF to actually watch the specific log file where these patterns might appear. You hinted at editing /etc/csf/csf.conf, which is where you’d set this up. Inside that file, you’d specify something like:

CUSTOM1_LOG = "/path/to/your/logfile"

Final thoughts:

Ensure that your regex accurately matches the log patterns you’re trying to detect. Test your regex against actual log entries to confirm they match as expected. Additionally, monitor CSF’s behavior after implementation to ensure it’s not blocking legitimate traffic. Always have a method to access the server outside of the regular channels (e.g., via a whitelist or console access) in case of accidental self-lockout.

Also, while blocking on failed login attempts can be a good practice, ensure that the threshold is reasonable to prevent false positives and unintentionally blocking legitimate users who might make a few mistakes while logging in.

Good luck

[toplisek]

Thank you for the message!