ConfigServer Closed, but CSF Refused to Die

We have been working with hosting infrastructure long enough to remember the first revisions of ConfigServer Security & Firewall. Apparently, that means we have also been doing this long enough to forget exactly when we first installed it.

Fortunately, GitHub has a better memory: CSF dates back to 2005. For roughly two decades, it was one of those quiet utilities that appeared on a Linux server, blocked several thousand unpleasant login attempts, sent a few alarming emails, and became part of the furniture.

Then Way to the Web Ltd, the company behind ConfigServer, announced that it would close permanently on August 31, 2025. Development and support ended not only for CSF, but also for its commercial and free companion tools. The original download and update infrastructure went offline.

For administrators who had CSF installed across fleets of hosting servers, this was not a small notification to dismiss after lunch. It was the end of the original product and its original team.

But it was not quite the end of CSF.

Why CSF became a hosting standard

CSF was never a new firewall inside the Linux kernel. It provided a practical management layer over iptables and, in later work, nftables. Its real achievement was turning a collection of packet-filtering rules, log parsers, scripts, alerts, and hosting-panel integrations into one understandable toolkit.

Its basic model was reassuringly sensible: deny traffic that should not be there, permit the services the server actually needs, track connections, and make common changes without manually composing every iptables rule. Administrators could manage allow and deny lists, temporary blocks, port filtering, connection limits, IP sets, blocklists, IPv6 rules, and clustering from familiar configuration files and a concise command-line interface.

Then there was Login Failure Daemon, or LFD. It watched logs for repeated authentication failures and other suspicious behaviour, then applied temporary or permanent blocks. It could monitor SSH, mail, FTP, control-panel logins, excessive processes, suspicious files, and several other signs that a server was having a bad day.

None of those ideas was unique on its own. The useful part was having them together, with sensible defaults for hosting servers and direct interfaces inside cPanel, DirectAdmin, and other control panels. A hosting administrator could open ports, investigate a blocked address, search iptables rules, inspect LFD events, or remove a temporary block without building a security platform from six unrelated projects.

CSF was also free, transparent enough to troubleshoot, extensively configurable, and familiar across distributions and providers. Its main configuration file was enormous, but it explained itself. This is an underrated quality in infrastructure software. A long file full of comments is often friendlier than a beautiful dashboard whose only diagnostic message is “Something went wrong.”

What actually ended in August 2025

Way to the Web permanently closed and stopped maintaining its products on August 31, 2025. Existing CSF installations did not suddenly stop filtering packets; local firewall rules do not require emotional support from the original developer. However, the software lost its trusted upstream, update service, documentation website, and official support.

That distinction matters. A firewall can continue running for years, but security software without a maintained update path becomes less comfortable with every passing kernel, distribution, control-panel, and Perl change. Bugs remain bugs, new compatibility problems arrive, and an abandoned web interface is not something we want running as root merely because it still opens in a browser.

The user reaction reflected that tension. Discussions in the cPanel, DirectAdmin, CloudLinux, web-hosting, and sysadmin communities contained plenty of genuine affection for CSF, followed immediately by the practical question: what can replace all of it without turning one familiar tool into a weekend integration project? Many administrators found that firewalld, nftables, Fail2ban, CrowdSec, or commercial security suites could replace parts of CSF, but there was no universal drop-in replacement with the same hosting-panel workflow.

There was also frustration that such widely deployed security software could lose its upstream almost overnight. At the same time, users began preserving the final release, comparing versions, discussing forks, and asking control-panel vendors to step in. This is where CSF’s final gift became important: the code was released under GPLv3.

The Aetherinox community fork

The most visible platform-independent continuation is the Aetherinox CSF Firewall fork. It describes itself as the successor to the original application and continues development with bug fixes and new features.

The fork retains the familiar CSF and LFD model while supporting Debian- and RHEL-based distributions, iptables and nftables, control-panel presets, multiple interfaces, IP sets, external blocklists, and the traditional web interface. It has new documentation, its own download service, active issue tracking, and continued commits. This makes it particularly interesting outside cPanel, where the other major continuation is not available.

It is not merely an archive of the final ConfigServer tarball. The maintainers are developing the project, rebuilding its documentation and release infrastructure, and providing stable and early-access release channels. That is encouraging.

It is still a community fork, though, and should be evaluated accordingly. Check release notes, signatures or checksums where available, open issues, package compatibility, and the project’s maintenance activity before deploying it across production. Test upgrades on one non-critical server first and keep a copy of /etc/csf. A firewall update is a poor place to discover that optimism was the entire rollback plan.

The project also warns about unrelated repositories and websites presenting themselves as commercial or official CSF editions. Use the links published by the project itself, not whichever download button search results place nearest your mouse.

cPanel has its own maintained CSF fork

cPanel and its parent company WebPros chose a different route. In February 2026 they began distributing a public CSF fork for cPanel & WHM, focused on critical security and stability fixes. Supported cPanel installations receive it through cPanel’s signed package and update system rather than the former ConfigServer update servers.

This is not a general-purpose CSF distribution. The package requires cPanel & WHM, uses cPanel’s Perl environment, and has removed support for non-cPanel platforms. cPanel also states that it maintains the code but does not provide assistance with individual firewall configuration or troubleshooting.

The fork is nevertheless real maintenance, not a ceremonial mirror. Releases in 2026 fixed web-interface XSS problems, improved HTML encoding, added a substantial test suite, corrected IPv6 and log-parsing issues, and addressed further LFD and configuration bugs. For supported cPanel servers, this is currently the most conservative path: retain the familiar interface and configuration while receiving updates through the same managed pipeline as the panel.

The cPanel and Aetherinox editions should be treated as separate products from this point onward. Do not casually install one over the other or point an existing installation at a different update source without reading its migration instructions. They share ancestry, not necessarily packaging, version numbers, defaults, or future direction.

What can replace CSF?

Calling UFW, firewalld, or nftables a replacement for CSF is not very useful. They can manage the underlying packet-filtering rules, but CSF also supplied login-failure detection, automatic temporary bans, blocklists, alerts, process monitoring, configuration helpers, and control-panel integration. Replacing it with firewalld alone is rather like replacing a car with an engine. The important component is present, but the first trip may be inconvenient.

The closest replacements are therefore maintained CSF forks. They preserve the familiar CSF and LFD workflow while continuing to manage rules through iptables or nftables.

For a supported cPanel & WHM server, the cPanel/WebPros CSF fork is the safest conservative choice. It is delivered through cPanel’s signed package system and receives critical security, compatibility, and stability fixes. Existing rules and familiar management screens remain, but this edition is deliberately restricted to cPanel and is not intended for DirectAdmin or generic Linux installations.

For a broader selection of Linux distributions and hosting panels, the Aetherinox CSF Firewall is currently the most ambitious community continuation. It retains CSF and LFD, supports iptables and nftables, and targets Debian- and RHEL-based systems rather than one commercial panel. It is the first project we would evaluate when the requirement is “keep using something recognisably CSF.” As with any young community fork of security software, test its update path and your custom rules before fleet-wide deployment.

Sentinel Firewall is another GPL-based CSF fork. It presents itself as a compatible upgrade for existing installations and retains the SPI firewall, CSF-style rule management, LFD intrusion detection, automatic IP blocking, alerts, and web interface. OpenPanel officially integrates it. Sentinel may suit users who want minimal workflow changes, although its smaller development footprint and release activity should be reviewed carefully before production adoption. Several forks can share the same ancestor without sharing the same maintenance capacity.

Pyxsoft Firewall takes a different approach. It is not a CSF fork, but a replacement built specifically for cPanel & WHM on RHEL-family systems. It manages nftables directly, offers iptables compatibility, provides a WHM interface, handles port and IP rules, and includes automatic login-failure blocking similar to LFD. This makes it much closer to the job CSF performed than firewalld alone. It must be the only active firewall manager on the server, so migration means removing or disabling CSF and firewalld rather than installing it beside them for moral support.

If retaining the CSF interface is not important, CrowdSec can replace much of the detection and automatic-blocking layer. Its security engine analyses logs and behaviour, while its firewall remediation component places decisions into iptables, nftables, or IP sets. CrowdSec also adds shared threat intelligence and can enforce decisions at a reverse proxy or web application layer. It does not provide the same all-in-one hosting firewall configuration experience, so the base port policy still needs to be managed separately.

Fail2ban offers a simpler version of that modular approach. It watches logs and asks iptables, nftables, or firewalld to block repeated offenders. Together with a carefully managed base firewall and configuration automation, it can reproduce the most important LFD behaviour. It does not reproduce CSF’s complete management interface, process monitoring, blocklist workflow, or panel integration. It is a component in a replacement design, not a drop-in replacement by itself.

Commercial server-security platforms such as Imunify360 and BitNinja go further by combining network blocking with reputation data, malware detection, web protection, and centralized fleet management. They are reasonable candidates for hosting providers that want a supported security suite rather than a familiar CSF configuration file. They are not identical products, cost money, and may change how traffic and security telemetry are processed, so compare their actual modules, privacy model, and panel support against the CSF features your servers use.

In practical terms, start with the cPanel fork on cPanel, and evaluate Aetherinox or Sentinel when a cross-panel CSF continuation is required. Consider Pyxsoft when building a new cPanel firewall workflow rather than preserving the old one. Use CrowdSec or Fail2ban when you deliberately want a modular security stack and are prepared to own the base firewall configuration. UFW, firewalld, iptables, and nftables remain important underneath these solutions, but they are the mechanism, not the whole replacement.

What existing CSF users should do

First, identify which CSF build and update source each server uses. An old installation may still enforce rules perfectly while repeatedly contacting infrastructure that no longer exists. Do not assume that “service active” also means “software maintained.”

Back up /etc/csf, document custom regular expressions and scripts, export allow and deny lists, and record control-panel dependencies before changing anything. Then choose one maintained path and test it on a representative server. Verify inbound and outbound rules, IPv6, Docker or container networking, mail services, passive FTP ranges, panel ports, temporary bans, trusted monitoring addresses, and reboot behaviour.

Be especially careful not to run several firewall managers as if more daemons automatically produce more security. CSF, firewalld, UFW, Docker, CrowdSec bouncers, and configuration-management scripts can all alter Netfilter rules. Without a deliberate design, they may overwrite, duplicate, or bypass each other’s work. The resulting ruleset will certainly be layered; whether it will be secure is a separate question.

Finally, keep console access available during migration. The traditional method of testing a new firewall exclusively through the SSH connection it may block remains popular, but popularity has never made it wise.

An ending, and a continuation

The original CSF product and the small team behind it are gone. That deserves recognition. For twenty years, CSF gave Linux and hosting administrators a practical security layer that was powerful without demanding that every server owner become a Netfilter specialist. It made good firewall hygiene accessible, integrated it with the panels people actually used, and solved a thoroughly unglamorous problem very well.

Yet saying “CSF no longer exists” is no longer completely accurate. Its original development ended, but GPLv3 allowed the code to continue. cPanel now maintains a focused edition for its own ecosystem, while the Aetherinox project is attempting the more ambitious job of keeping CSF useful across panels and general Linux servers.

Perhaps that is a suitable ending for infrastructure software. The company closed, the original website disappeared, administrators briefly imagined rewriting twenty years of firewall habits over the weekend, and then somebody forked the code. Open source can be untidy, but it is remarkably difficult to bury.