indie49

CSF Firewall is unmaintained (as of 2025): What to do & how to install v15

· Blog

It happened. As of September 1, 2025, ConfigServer (Way to the Web) has officially stopped maintaining CSF (ConfigServer Security & Firewall).

For those of us who’ve been managing servers for years, this hits hard. CSF was the standard. It was free, rock-solid, worked perfectly with cPanel/WHM, and it was the first thing we all installed on a fresh box.

Now we’re all facing two big issues:

  1. We spin up a new server and… what do we install?
  2. We look at existing servers and the auto-update cron just makes noise (or worse, fails).

The Indie49 team manages many servers across other projects (mostly cPanel), and this caught all of us mid-workflow. But don’t panic. There’s a short-term solution — a “lesser evil” — that buys everyone some breathing room.

Let’s get into it.

😱 So, why did ConfigServer abandon CSF?

That’s the million-dollar question. Why would they abandon such a beloved, universally used project?

The truth is, there was no big official announcement from “Way to the Web” beyond shutting down their products and support.

My dev-to-dev take? Maintaining a free project of that magnitude — one that became a de facto industry standard — must be absolutely exhausting. It was probably a business decision or simply burnout.

The good news: They published a final GPL tarball (v15.00) on GitHub.
The bad news: There will be no more updates. No security patches. The traditional auto-update is broken.

The community is already talking about forks and new maintainer groups, but for now that’s just talk. We need something that works today.

🤔 Okay, what’s the game plan?

We can’t wait for a community fork. We have to act now.

The most practical, hands-on plan is to use the “lesser evil”: install the final, stable CSF v15 (GPL) release.

A repo with that final version was published on GitHub before it was removed from the official repo. Here it is.

This lets you keep the same firewall you know and love. Your cPanel hooks, CC_DENY rules, and LFD scripts will continue to work. This is the approach we’re taking for new cPanel/AlmaLinux 8 & 9 servers, and it’s working perfectly.

In parallel, you should be thinking about your long-term strategy:

  • Imunify360 + CSF: The combo we’ll discuss below.
  • Imunify360 Only: A great, commercially supported “all-in-one” suite.
  • The “Artisan” Stack: firewalld/nftables + Fail2ban/CrowdSec. More hands-on, zero vendor lock-in.

But for now, let’s get v15 installed.

🛠️ How to Install CSF v15 (GPL) on a New Server

This is the new copy-paste-friendly process for a fresh server (cPanel, AlmaLinux, CloudLinux 8/9, etc.).

Important: Run these as root.

0) Pause Imunify360 (If it’s running)

CSF and Imunify’s installers can sometimes bicker. Let’s pause Imunify just in case.

Bash

systemctl stop imunify360-agent imunify360 imunify360-webshield imunify360-pam 2>/dev/null || true
systemctl disable imunify360-agent imunify360 imunify360-webshield imunify360-pam 2>/dev/null || true

1) Download and Install CSF v15 (GPL)

We’ll grab the final tarball, extract, and run the cPanel installer.

Bash

cd /usr/src
wget https://github.com/waytotheweb/scripts/raw/refs/heads/main/csf.tgz
tar -xzf csf.tgz
cd csf
./install.cpanel.sh

2) Disable “Testing” Mode & Start LFD

By default, CSF installs in “testing” mode (it doesn’t block anything). We’ll use sed to fix that.

Bash

# Backup first, just in case
cp -a /etc/csf/csf.conf /etc/csf/csf.conf.bak.$(date +%F)

# Set TESTING = 0
sed -ri 's/^TESTING *= *"1"/TESTING = "0"/' /etc/csf/csf.conf

# Reload and enable the Login Failure Daemon (LFD)
csf -r
systemctl enable --now lfd

3) Disable Auto-Updates of csf firewall (CRITICAL!)

This is the most important step. We don’t want CSF trying to update itself from a dead server.

Bash

sed -ri 's/^AUTO_UPDATES *= *"[^"]*"/AUTO_UPDATES = "0"/' /etc/csf/csf.conf
rm -f /etc/cron.d/csf_update 2>/dev/null || true

4) (Optional) Reduce LFD Spam from PHP/WP-Cron

If you’re tired of LFD alerting you every time a PHP script runs for a long time (like WP-Cron), add these common executables to the process ignore list.

Bash

cat >> /etc/csf/csf.pignore <<'EOF'
exe:/usr/bin/php
exe:/usr/local/bin/php
pexe:/opt/cpanel/ea-php\d+/root/usr/bin/php
pexe:/opt/cpanel/ea-php\d+/root/usr/bin/lsphp
EOF

# Restart LFD to apply
systemctl restart lfd

5) Quick Sanity Check

Let’s make sure it’s running and see what it’s logging.

Bash

csf -v
csf -l | head
tail -n 50 /var/log/lfd.log

You’re all set! You have a fully functional CSF v15.

🔄 I Already Have CSF. What Now?

This is the other key scenario. You have servers with CSF already running. Your goal is to get to v15 and disable auto-updates.

1) Check Your Version

Bash

csf -v

If it’s not v15.00, proceed.

2) Install v15 (In-Place Upgrade)

This will install the new version right on top of the old one, keeping your settings.

Bash

cd /usr/src
wget -O csf.tgz https://github.com/waytotheweb/scripts/raw/refs/heads/main/csf.tgz
tar -xzf csf.tgz && cd csf
./install.cpanel.sh

3) Ensure Settings are Correct

Run these commands to make sure TESTING is off and AUTO_UPDATES is disabled.

Bash

sed -ri 's/^TESTING *= *"[^"]*"/TESTING = "0"/' /etc/csf/csf.conf
sed -ri 's/^AUTO_UPDATES *= *"[^"]*"/AUTO_UPDATES = "0"/' /etc/csf/csf.conf
rm -f /etc/cron.d/csf_update 2>/dev/null || true

4) Restart Everything

Bash

csf -r && systemctl restart lfd

Done. Your existing server is now on the final, stable version and will no longer try to call home.

🤝 CSF + Imunify360: Still a Good Idea?

We get asked this a lot. Our recommendation: Absolutely, YES.

They work together beautifully. The killer feature is the ModSecurity integration. Here’s the flow:

  1. An attacker tries a SQL injection.
  2. Imunify360’s ModSecurity rules detect the “bad” request.
  3. Imunify tells LFD/CSF about the “naughty” IP.
  4. CSF (via LFD) bans the IP at the firewall (iptables) level.

The result? That attacker can’t even reach Apache or your WAF anymore. They can’t scan your ports, try FTP, or anything. This saves a massive amount of server resources and keeps your load averages low during an attack.

How to check the integration: Make sure these are set in your /etc/csf/csf.conf:

  • LF_MODSEC = "1" (Tells LFD to watch the ModSec log)
  • LF_MODSEC_PERM = "1" (Makes the block permanent)
  • LF_MODSEC_LOG should point to your ModSec log (on cPanel, it’s usually /usr/local/apache/logs/modsec_audit.log)

💡 A Quick Tech Note: What Does LF_MODSEC = "1" vs. "5" Mean?

Pay attention here! This setting is more important than it looks and is a common point of confusion.

The number in LF_MODSEC = "N" is not a simple “1 = on / 0 = off”. It’s a tolerance threshold.

It defines how many “strikes” (ModSecurity events) a single IP address must generate before LFD (the daemon) decides to ban it.

  • LF_MODSEC = "1": This is “Zero Tolerance Mode.” As soon as an IP generates ONE (1) single attack event, it’s banned (permanently, if LF_MODSEC_PERM = "1").
    • Pros: Stops the attacker on their first shot. Maximum security.
    • Cons: Higher risk of false positives! If a ModSec rule is too “sensitive” and a legitimate customer triggers it by accident, they’re banned.
  • LF_MODSEC = "5": This is “Conservative Mode” (and often a safer bet). LFD will wait until that same IP has generated FIVE (5) attack events within the configured time period.
    • Pros: Protects you from almost all false positives. It’s very rare for a legitimate user to trigger a rule 5 times in a row.
    • Cons: You’re giving the attacker 4 “free” attempts before the ban hits.

Our Recommendation? Imunify360’s rules are very good and produce few false positives. Starting with a low value like "3" is an excellent balance between security and reliability. If you want to play it 100% safe, use "5".

What about Imunify360-only? That’s also a perfectly valid (and great) choice if you prefer a simpler, all-in-one commercial stack. It’s not a drama. We just like the resource-saving efficiency of the combo.

🚀 Final Thoughts: The King is Dead… Long Live the Patch?

Look, it’s a pain. We all loved CSF, and this messes up our flow. But it’s not the end of the world.

Here’s your TL;DR:

  1. Don’t panic. Your v15 install is stable and secure for now.
  2. DISABLE AUTO-UPDATES on all your existing servers. Do this today.
  3. For new servers, use the GPL v15 install script above.
  4. The CSF v15 + Imunify360 combo remains our top-recommended stack for cPanel.

We’ll all be watching the community forums to see if a proper, maintained fork emerges. Until then, this v15 “patch” gives us the breathing room we need.

Now, go update those servers!

 

⚠️ A Quick Disclaimer (From Dev to Dev)

Hey, before you start copying and pasting commands. Everything we’re sharing in this article is what we have personally tested on our own servers (mostly cPanel, AlmaLinux, and CloudLinux) and found to work great.

We’re sharing this because, honestly, we think it’s the best short-term fix for this mess and we want to help the community.

But please, use your common sense: everything you run on your server is 100% your responsibility. Every environment is different. We are not responsible if something breaks, if a command fails on your specific setup, or if you ban your own IP (we’ve all been there).

Test in a staging environment first if you can. And if not, at least don’t do this on a Friday at 5 PM. 😉