How to Keep ConfigServer Firewall (CSF) Running After the Shutdown

When news broke that ConfigServer (Way to the Web Ltd.) would shut down on August 31, 2025, it sent shockwaves through the hosting community. Like many longtime users, I was both surprised and disappointed by how this shutdown was handled.

The announcement gave us barely a month’s notice to scramble for solutions. As someone who has deployed ConfigServer Firewall (CSF) on countless StackLinux client servers, I felt this news personally. Our cPanel servers use CSF and its companion tools. The abruptness (and lack of a clear transition plan) left a bitter taste. Other admins voiced similar frustrations and hopes that the software might live on via open-source forks.

In this article, I’ll share how I’ve navigated the post-ConfigServer landscape: keeping CSF running safely, obtaining the final version, adjusting configurations, and finding replacements for deprecated tools like CXS. This is a guide born from my own experience and due to urgent necessity. Feedback and suggestions are welcome.

CSF Still Works, But It’s Stranded

First, some good news: CSF continues to run on servers even after the vendor’s closure. The firewall and login failure daemon (LFD) didn’t suddenly stop on September 1. ConfigServer’s own FAQ (and cPanel’s advisory) confirmed that the free scripts “will continue to run after August 31, but they will not receive updates or be available for new installs.” I can confirm that all our servers’ existing CSF installations kept right on blocking brute-force attempts and sending alerts.

However, CSF is now essentially stranded. Its update services have gone dark, and any attempt to update or install it via the old channels will fail. If your system ran the automatic updater, you probably saw errors like:

Cron <root@web> /usr/sbin/csf -u
Oops: Unable to download: Can’t connect to download.configserver.com:443 (Connection timed out)

That’s because the official download server is offline, and all official mirrors were shut down on August 31. In short, CSF is frozen in time at its last version from ConfigServer.

For us at StackLinux, this was a relief in one sense: our firewalls didn’t suddenly die. But it also raised immediate concerns: How do we keep them updated going forward? And what about new servers that need a firewall? In the next sections, I’ll explain the steps we took to address these questions.

Upgrading to the Final Open-Source CSF (v15.00)

Thankfully, ConfigServer gave the community a parting gift: they released CSF as open-source (GPLv3) before shutting down. This final open-source release is CSF version 15.00, which supersedes the last closed-source v14.24. The source code is available on ConfigServer’s GitHub repository, meaning we can download and install CSF without the official website.

Where to get CSF v15.00: You can obtain the CSF 15.00 tarball (csf.tgz) from the official GitHub repo:

1. Backup your current CSF configuration:
   (Also back up any custom files like csf.allow, csf.deny if needed.)
   

   cp /etc/csf/csf.conf /etc/csf/csf.conf.backup

2. Download the v15.00 package from GitHub:

   cd /usr/src
   wget https://raw.githubusercontent.com/waytotheweb/scripts/refs/heads/main/csf.tgz

3. Install the new version:
   

   tar -xzf csf.tgz
   cd csf
   sh install.sh

   This will upgrade or install CSF 15.00 on your system. The installer should retain your existing firewall rules and config where possible (it usually backs up the old config to /var/lib/csf/backup/ automatically).

4. Verify the version: Run csf -v or check /etc/csf/version.txt to ensure it shows v15.00. At this point, you’re running the final open-source CSF release.

In my case, upgrading to 15.00 was straightforward on several cPanel servers. We immediately had peace of mind knowing we have the latest and now-community-owned version of CSF. (For reference, v14.24 was the last proprietary release, and v15.00 is the open-source one.) The changes between them were minimal. Mostly license-related and housekeeping, so don’t expect new features, but it’s a clean base for future community updates.

New installs: If you need to install CSF on a fresh server now, you can use the same tarball from GitHub. Essentially, the manual installation method (as shown above) is the way to go, since the old curl|sh installer scripts that fetched from configserver.com no longer work. Keep a copy of the csf.tgz in your toolkit or internal mirrors for safety.

Note: Beyond CSF firewall community contributors like Eva2000 have published migration guides and scripts for Way to the Web Limited Products. 

Disabling Auto-Updates (No More Phone Home)

One critical thing every CSF user should do now is disable the broken auto-update mechanism. By default, CSF’s LFD cronjob tries to check for updates daily. With ConfigServer’s servers offline, those update checks not only spam your root inbox with errors, but they also pose a security concern.

We don’t know what will happen with the configserver.com domain in the future; a malicious actor could acquire it and potentially serve trojaned “updates” to any servers still pinging that domain. In other words, leaving auto-update enabled is both useless and risky!

Here’s how to turn it off and make CSF completely self-contained:

Remove or disable the CSF update cron jobs: On many systems, CSF’s auto-update is triggered via cron. Check for files like /etc/cron.d/csf_update or /etc/cron.daily/csget. If present, delete them (or comment out their contents) to stop the automatic checks. For example:

rm -v /etc/cron.d/csf_update
rm -v /etc/cron.daily/csget

This ensures your server won’t attempt to contact the now-defunct update servers.

Update the CSF config to disable auto updates: In /etc/csf/csf.conf, set:

AUTO_UPDATES = "0"

This prevents CSF from even trying to phone home for updates from within the LFD process. Without this, you may continue to get “No Host option provided” error emails after moving to v15. So it’s good practice to explicitly turn it off in the config. After editing, run csf -r to reload the firewall and apply changes.

Point update checks to a safe place (optional): CSF determines where to fetch updates from by reading /etc/csf/downloadservers. By default this file contains download.configserver.com and mirrors. Since those are gone (and could be repurposed maliciously), you can replace the contents of downloadservers with a non-routable host like download.localhost. This way, even if someone stood up a fake update server, your CSF wouldn’t reach it.

In my case, I chose to fully disable auto-updates. We removed the cron jobs and set the config option to off. I also went a step further and added an override in DNS for download.configserver.com to resolve to 127.0.0.1 on our servers. A paranoid measure to null-route any stray update attempts. The bottom line is that CSF should not be phoning home anymore. It’s now our responsibility to handle any future “updates” (likely via community forks or manual interventions, as discussed later).

Keeping Blocklists and Threat Feeds Alive

If you use Cloudflare, read my Recommended Cloudflare Performance and Security Settings (Guide).

One of CSF’s most powerful features is its ability to consume external blocklists. Essentially feeding the firewall known bad IPs from community sources. Even though ConfigServer is gone, this functionality can be kept alive using external feeds.

CSF comes with a file /etc/csf/csf.blocklists which lists numerous public blocklists (Spamhaus, DShield, TOR exit nodes, blocklist.de, etc.). If you haven’t used this before, now is a great time to leverage it. These blocklists are maintained by third parties and can be updated by CSF on a schedule (typically daily). They don’t depend on ConfigServer at all. By enabling them, you ensure your firewall continues to get fresh threat intelligence about malicious IPs on the internet.

What you should do:

Open the csf.blocklists file and review the available feeds. Uncomment the ones that are relevant to you (each line has the format Name|Interval|Max|URL). For example, you might enable Spamhaus DROP, Spamhaus EDROP, CIArmy (CI Bad Guys list), blocklist.de’s all.txt, and the FireHOL aggregated list. Here’s a copy of the csf.blocklists that I use:

SPAMDROP|86400|1000|https://www.spamhaus.org/drop/drop.txt
DSHIELD|86400|1000|https://www.dshield.org/block.txt
TOR|3600|1000|https://check.torproject.org/torbulkexitlist
BOGON|14400|1000|https://team-cymru.org/Services/Bogons/fullbogons-ipv4.txt
CIARMY|86400|1000|https://cinsscore.com/list/ci-badguys.txt
BFB|86400|1000|https://danger.rulez.sk/projects/bruteforceblocker/blist.php
BDE|3600|0|https://api.blocklist.de/getlast.php?time=3600
BDEALL|86400|1000|https://lists.blocklist.de/lists/all.txt
STOPFORUMSPAM|86400|1000|http://www.stopforumspam.com/downloads/listed_ip_1.zip
GREENSNOW|86400|1000|https://blocklist.greensnow.co/greensnow.txt

Uncommenting a line enables that feed. After saving the file, restart CSF/LFD (csf -r or service lfd restart). CSF will then download those lists periodically and block any IPs listed. For instance, by enabling Spamhaus DROP, your server will automatically block the IP ranges Spamhaus deems the worst offenders (often hijacked or malicious hosts). This keeps your firewall effective against new threats, even though the CSF software itself isn’t getting vendor updates.

Start with a few well-known lists: Each list adds processing overhead and consumes memory (especially if not using ipset). I found Spamhaus DROP and blocklist.de’s list to be valuable and not too large. You can always add more if needed.

Consider enabling IPset mode: If you’re on a modern system that supports ipset and/or nftables, CSF can use ipset to handle large lists more efficiently. In csf.conf, setting LF_IPSET = 1 will put blocklist entries into kernel IP sets (faster lookups, less strain on iptables).

Even without official updates, your CSF can continue to pull in crowd-sourced threat data. This has become even more important now that we can’t rely on vendor updates for new blocking heuristics.

Community Forks and the Future of CSF

Aetherinox builds on the official open-source CSF. v15 now available.

Stay wary of unofficial new versions. With an open-source project, anyone can release a modified version. Be cautious about what you install or whom you trust. Verify the source of any CSF “update” you apply. The best scenario is a well-known, trusted group (perhaps a coalition of control panel vendors or a GitHub organization of experienced contributors) picks up maintenance.

Until that happens, I’m personally sticking to the official v15.00 code and applying only minimal necessary tweaks for my environment. I’ll evaluate community patches on a case-by-case basis. In other words, don’t blindly auto-update from a random fork unless you’re confident in it. Treat your firewall software with the same scrutiny you would any critical security component.

Prepare for eventual changes (like nftables): CSF was built around iptables. The Linux world is slowly moving to nftables as the default firewall subsystem. ConfigServer had started adding some nftables compatibility in recent versions, but it’s not fully there. One likely task for community forks will be to ensure CSF can interface with nftables properly (or even support firewalld).

There are already community discussions about this need, and even some experimentation in progress. This is something to keep in mind as you plan your infrastructure’s future. If you upgrade to an OS release where iptables is deprecated, you might eventually need a modified CSF or an alternative firewall solution. Being aware of these trends will help you stay ahead.

Aetherinox / csf-firewall

Aetherinox builds on the official open-source CSF v15.00, but introduces practical enhancements. This fork isn’t positioning itself as an “official” successor, but it’s an excellent early example of how CSF can adapt to modern infrastructure. If you’re exploring feature upgrades or a UI makeover for CSF, it’s worth checking out. More details: Future ConfigServer Firewall Development by Aetherinox.

CentminMod’s CSF Scripts

This GitHub repo includes CSF-related tooling beyond the firewall, that the CentminMod community is actively maintaining. Contributors have used this to strip out hardcoded update URLs and tailor CSF for ongoing use with community-friendly mirrors and custom tweaks—exactly the kind of proactive adaptation many admins are looking for.

Replacing ConfigServer Exploit Scanner (CXS) and Other Tools

While CSF was thankfully open-sourced, the same cannot be said for ConfigServer’s commercial products. Notably, ConfigServer Exploit Scanner (CXS) (a popular malware scanner for web hosting servers) is no longer available or supported.

If you had a CXS license, you were required to update it to the latest version before Aug 31, after which the license can no longer be moved or reinstalled. Even if you keep an existing CXS installation running, it will receive no signature updates or bug fixes going forward. Essentially, CXS has reached end-of-life, and continuing to rely on it long-term would be risky.

At StackLinux, we used CXS on a few cPanel servers where customers requested it. Our approach has been to evaluate and implement alternatives:

Linux Malware Detect (Maldet)

This is a well-known open-source malware scanner. It uses threat data from network edge IDS systems and user submissions to identify malware. Maldet (sometimes called LMD) can scan file systems for malware and even quarantine or clean infections. The big difference is that, out of the box, Maldet doesn’t do real-time inotify scanning like CXS did. It’s more of an on-demand or scheduled scanner unless you integrate it with something like ClamAV’s fanotify.

However, Maldet is free, actively maintained, and has a decent signature database for web malware. We’ve deployed Maldet on servers as a replacement scanner to run daily or weekly scans, and it’s catching a lot of the same malicious files CXS did (though not as instantaneously). In combination with ClamAV (which Maldet can leverage for dual scanning), it’s a solid free alternative. The lack of real-time upload scanning is a drawback, but one we’re mitigating by running frequent cron-based scans.

ImunifyAV / Imunify360

CloudLinux’s Imunify360 is a comprehensive security suite that includes malware scanning similar to CXS, along with a web application firewall, intrusion detection, proactive defense, and more. It’s a commercial product (with a per-server monthly cost), but it’s arguably the closest thing to a “drop-in” replacement for what CXS provided and more.

The upside is a fancy web GUI and automatic malware cleanup, plus continued updates. The downside is cost and complexity. It’s heavier and more resource-intensive than CXS was, and you may not need all of its features.

ImunifyAV is the free tier of Imunify360; it provides on-demand scanning and malware detection (with a nice interface in cPanel), but automated cleaning and real-time protection require an upgrade. For many of our smaller clients, ImunifyAV (free) has been a good starting point: it at least gives them a way to scan their account for malware via cPanel. For our bigger shared hosting nodes, we are testing Imunify360 fully, because it adds things like a WAF and proactive PHP defense that could fill gaps left by CXS’s absence. By most accounts, Imunify’s malware detection is on par with CXS, so we feel confident in its efficacy.

ClamAV and clamscan

If you’re running cPanel, you likely have the option of the “Virus Scanner” (ClamAV). ClamAV alone isn’t great at catching webshells and CMS malware (CXS actually used ClamAV as one layer among many). However, ClamAV can be a piece of the puzzle. As mentioned above, it can be integrated with Maldet (Maldet can use ClamAV’s engine to broaden its detections). If nothing else, having ClamAV updated and scanning HTTP uploads is better than nothing. Just be aware it has many blind spots for web malware.

Other tools

There are other host-based malware scanners and WAF solutions: BitNinja, Sophos Antivirus for Linux, etc. You can also use extended ModSecurity rules to detect malicious uploads.

Another mention: for outbound spam monitoring (since ConfigServer’s OSM is gone), check out MailChannels or OX Guardian for external spam filtering, or use cPanel’s email tracking tools to catch senders.

For MailScanner (if you used their front-end), there are community MailScanner projects and other GUI front-ends one can install (or just manage MailScanner via command line). Each ConfigServer tool that vanished (CMQ, CMM, MSFE, etc.) might need its own replacement or manual procedure. But identify what you were using and seek alternatives accordingly.

The takeaway is that you should not ignore the loss of these security tools. If you simply leave CXS running indefinitely, it will become less effective as malware evolves (and if it breaks, you can’t reinstall it). The transition isn’t fun. There’s a reason many paid for CXS for years. It filled a niche, but there are other credible solutions available to fill the void. In fact, many hosting providers have been combining multiple tools (CSF + Maldet + Imunify, etc.) for defense-in-depth.

Conclusion

The shutdown of ConfigServer Ltd. was a wake-up call. It reminded me that even essential, “battle-tested” tools can vanish with little warning. As a result, I’ve had to become more proactive about firewall management and security on our Linux servers.

While I remain disappointed in how abruptly the shutdown was executed, with communication and engagement being sparse, dwelling on that won’t secure our servers. The onus is now on us as sysadmins to adapt. If you’re in the same boat, I encourage you to take the steps outlined above, make additional adjustments, and feel free to share how you have dealt with this blip.

The silver lining is that CSF firewall was set free, and its legacy can continue if we as a community pick up the torch. In the meantime, with some preparation and adjustments, you can continue using CSF confidently to protect your Linux servers. It’s still the same robust firewall we’ve trusted for years. Only that now it’s our responsibility to keep it going. Stay safe out there, and happy (secure) hosting!

Tags: cybersecurity, hosting, linux, security, server