❓ Question: LF_CUSTOMTRIGGER, LF_CUSTOMBLOCK and LF_CLOUDFLARE: Where did these settings go?

[Martinqws]

Question

What happened with this settings in csf.conf?

Custom trigger settings

LF_CUSTOMTRIGGER = "1" # Enable custom regex
LF_CUSTOMBLOCK = "1" # Block from custom triggers

CloudFlare integration

LF_CLOUDFLARE = "1" # CloudFlare IP header detection

Without the line LF_CLOUDFLARE = "1" in csf.conf and with the Apache mod_remoteip installed the real IP from the visitors are displayed in the logfiles. So it looks like this setting is enabled by default and can no longer be configured?

The same seems to be the case with the LF_CUSTOMTRIGGER and LF_CUSTOMBLOCK settings.

Screenshots

No response

[Aetherinox]

All settings currently in CSF have remained since the last release by the original developer (v15.00). The only edits have been the introduction of some new ones (unrelated to the LF_* group.

I took a quick glance back at v15.00 released by the original developer, and I see no mention anywhere in the code for a reference to the setting LF_CLOUDFLARE, as well as CLOUDFLARE in general. The same goes for CUSTOMBLOCK as well.

However, the setting CUSTOMTRIGGER is still in the code. Along with LF_CUSTOMTRIGGER_PERM as a dynamic variable.

I went and dug through the old code for CSF going back to v14.x, and found the same thing.

Can you reference what version you last report these actually functioning in?

In terms of true CF headers, are you referring to CF_ENABLE = "0"?

###############################################################################
# SECTION:CloudFlare
###############################################################################
# This features provides interaction with the CloudFlare Firewall
#
# As CloudFlare is a reverse proxy, any attacking IP addresses (so far as 
# iptables is concerned) come from the CloudFlare IP's. To counter this, an
# Apache module (mod_cloudflare) is available that obtains the true attackers
# IP from a custom HTTP header record (similar functionality is available
# for other HTTP daemons
#
# However, despite now knowing the true attacking IP address, iptables cannot
# be used to block that IP as the traffic is still coming from the CloudFlare
# servers
#
# CloudFlare have provided a Firewall feature within the user account where
# rules can be added to block, challenge or whitelist IP addresses
#
# Using the CloudFlare API, this feature adds and removes attacking IPs from
# that firewall and provides CLI (and via the UI) additional commands
#
# See /etc/csf/readme.txt for more information about this feature and the
# restrictions for its use BEFORE enabling this feature
CF_ENABLE = "0"

[Martinqws]

Good question. I checked an old backup from 2020 with CSF 14.02, and even in that version the parameter LF_CLOUDFLARE was already not present in csf.conf. This might be related to mod_cloudflare, which has been deprecated since 2021. In my config, I have CF_ENABLE = "0" and mod_remoteip installed. And that is working perfect.

Regarding other settings, I’m a bit more confused. I’m implementing some custom block rules in regex.custom.pm. Most guides and examples I found still reference these directives, so I manually added them to csf.conf. After the most recent CSF update, I noticed that these manually added directives were removed, while the custom regex rules continue to work as expected.

Before the update, my relevant settings looked like this:

# Custom trigger settings
LF_CUSTOMTRIGGER = "1"           # Enable custom regex
LF_CUSTOMBLOCK = "1"             # Block from custom triggers

I also configured BLOCK_REPORT, pointing to a custom Perl script for handling block reports.

So I’m wondering: are these directives now deprecated, or are they simply no longer required for regex.custom.pm functionality?

[Aetherinox]

I noticed that these manually added directives were removed, while the custom regex rules continue to work as expected.

Do you mean by this that you had them actually in your csf.conf, and then they disappeared upon update? If so, I may have a reason for that I can look into. Recently we switched over to a new system which migrate a user's settings from an old config over to a new config, and it ensures that there are no invalid settings within the file, but allows for custom comments to be stickied.

So if that's what you mean by LF_CUSTOMTRIGGER and LF_CUSTOMBLOCK I can add the ability for them to be kept in the config.

Paste me your example configs of how you have it set up (your regex.custom.pm, and your exact lines in your csf.conf, and I'll apply them to mine and add a whitelist so that it doesn't clean them out. And also how you expect them to behave.

As for CF_ENABLE, I'll go dig back further, I have saved copies all the way back to v7. I can at least review the code and see what the original intentions were by the developer, but yes, you are correct that mod_cloudflare was deprecated in favor of mod_remoteip.

Once I finish up some code, I'll go dig around a bit and see.

[Martinqws]

Do you mean by this that you had them actually in your csf.conf, and then they disappeared upon update?

Yes, that's what I mean. After updating to v15.10, these settings disappeared.

Settings on 09-02:

#CUSTOM9_LOG = "/var/log/customlog"

# For REGEX.CUSTOM.PM
LF_CUSTOMTRIGGER = "1"
LF_CUSTOMBLOCK = "1"

# For Cloudflare IP headers
LF_CLOUDFLARE = "1"

# # 
#   The following are comma separated lists used if LF_SELECT is enabled,
#   otherwise they are not used. They are derived from the application returned
#   from a regex match in /usr/local/csf/bin/regex.pm

Current settings, date 28-02:

CUSTOM9_LOG = "/var/log/customlog"

# # 
#   The following are comma separated lists used if LF_SELECT is enabled,
#   otherwise they are not used. They are derived from the application returned
#   from a regex match in /usr/local/csf/bin/regex.pm
#   

As you can see, these rules are now gone.

For me, you don't need to look for CF_ENABLE anymore, it just works fine now.

regex.custom.pm.txt

[Aetherinox]

Alright, go ahead for your current install, add the two settings back to the csf.conf, save the file, restart csf with sudo csf -ra.

I'll add a whitelist for these optional settings to remain in the file.

[Aetherinox]

As far back as CSF v14.x, the developer has performed updates using auto scripts which look at your current config, and compare it with the shipped config for that version.

It would leave your existing changes in place for settings, but comments would get over-written, and also any settings that were not in the official shipped csf.conf would get removed. Since LF_CUSTOMTRIGGER does not ship with the csf.conf, it is one of the settings that gets wiped.

I even went back and installed a fresh copy of v14.20 just to double check and confirm the intended functionality.

I've added on to the automatic upgrade system to now allow comments, and also support adding the LF_* settings so that they are not replaced on the next upgrade.

Any settings started with LF|PT|LT|RT will be allowed. And also comments starting with #.

[Martinqws]

I've put them back. And I'll keep you posted on whether they'll be saved after a future update.

I'd also like to thank you for continuing this great firewall! And also for the excellent manual on your website.