CSF future on DirectAdmin — Where do we stand 6 months after the shutdown?

castris

Verified User
Joined
Apr 16, 2021
Messages
163
Location
Arcenillas
CSF future on DirectAdmin — Where do we stand 6 months after the shutdown?

It's been almost six months since Way to the Web shut down (August 31, 2025), and I think the DirectAdmin community deserves some clarity on the CSF situation.

Here's what we know so far:

  • cPanel has acted. They announced a maintained GPLv3 fork back in November 2025, with auto-update migration scheduled for February 18, 2026. Clear timeline, clear commitment.
  • DirectAdmin has not. CustomBuild still installs CSF via
    Code:
    da build set csf yes
    , but there's no public statement about where those packages come from, who maintains them, or what happens next.

So the obvious question is: will DirectAdmin adopt the cPanel fork, or is there a separate plan?

Meanwhile, the community has moved. Several forks are actively maintained:

  • Aetherinox/csf-firewall — Already at v15.08, active development, nftables support in progress, proper documentation at configserver.dev. This is my personal choice for production servers right now.
  • Sentinel Firewall — Community-driven, backed by the OpenPanel team.
  • Centmin Mod and Black-HOST maintain their own mirrors as well.

As sysadmins running DA in production, we need answers to three specific questions:

  1. What is the current update source for CSF when installed via CustomBuild? Is it the original v15.00 frozen, the cPanel fork, or something else?
  2. Is there a commitment to keep CSF as a first-class citizen in DirectAdmin, or should we expect a transition to firewalld/nftables with BFM as the only DA-integrated option?
  3. Will DirectAdmin officially endorse or integrate one of the community forks? The Aetherinox fork in particular has shown serious commitment — signed releases, active bugfixes, and broad panel support (cPanel, DirectAdmin, CyberPanel, Webmin).

The silence is the problem. Those of us managing dozens of DA servers need to make infrastructure decisions now, not "early 2026 maybe." Every month without a clear answer is another month we're running security-critical software with no defined upstream.

I'd love to hear from the DA team, but also from fellow admins: what are you running today? Have you switched forks? Moved to an alternative stack entirely?


30 years in sysadmin. 65+ VPS across OVH and Hetzner. CSF on every single one. This matters.
 
Last edited:
cPanel has acted. They announced a maintained GPLv3 fork back in November 2025, with auto-update migration scheduled for February 18, 2026. Clear timeline, clear commitment.
DA was way before cPanel and cPanel did not even make it to the Februari 18 release as announced, so their RPM's will be updated later, see the corresponding thread at cPanel.

As you could have found on the forum, DA has forked only a few weeks after CSF stopped and also already has brought 2 minor updates.

1.) DA uses their own fork and already has version 15.02
2.) Not fully known yet, however without ipset the current CSF already works with nftables.
3.) Unknown yet, probably there will not be such big cooperation with others, which is also not to expect from other panels.
 
Thank you all for the replies — very helpful.

@Richard G


Good to know DA forked shortly after the shutdown and that 15.02 is already in CustomBuild. That answers the immediate concern about the update source.

A quick follow-up: is the DA fork available in a public repository? Right now we can see the result via da build csf, but not the source or the changelog. Having a repo would help with things like auditing changes, tracking what was patched, and keeping configurations consistent across servers.

For reference, cPanel published their fork on GitHub under GPLv3, and the community fork at Aetherinox/csf-firewall (also GPLv3, already at 15.08) has been quite active. Both allow users to see exactly what changed between versions.

@DrWizzle


Good pointer on the Configserver.dev Discord — I'll check it out.
 
For reference, cPanel published their fork on GitHub under GPLv3,
I don't know about that, I only know that cPanel creates their own RPM's for it.
And that the official release for their version is moved to the 25th this month as you can read in their announcement (click) and uses their own update mirrors.

As for others... that is nice but can those be trusted? Who knows and it's only 1 person so if something happens.....
We will keep using the one DA will provide for DA servers and see how it develops in the future. No hurry for us as all is still working as designed.
 
Regardless of what version the DA version is at for CSF, we are owed an explanation of what fork it is. Is it DA proprietary, the cPanel one or the configserver.dev fork Aetherinox...

Do I need to upgrade it to the configserver.dev version? Questions we ask ourselves.
 
Regardless of what version the DA version is at for CSF, we are owed an explanation of what fork it is.

I think it has already been explained that DA maintains its own fork. I guess we could call it the DA fork.
 
Regardless of what version the DA version is at for CSF, we are owed an explanation of what fork it is. Is it DA proprietary, the cPanel one or the configserver.dev fork Aetherinox...

In order to answer this question you might download the last official release:

- https://files.directadmin.com/services/csf-14.24.tar.gz or
- https://files.directadmin.com/services/csf-15.00.tar.gz

and one modified and maintained by DirectAdmin:

- https://files.directadmin.com/services/csf-15.01.tar.gz
- https://files.directadmin.com/services/csf-15.02.tar.gz
- https://files.directadmin.com/services/csf-15.03.tar.gz
- https://files.directadmin.com/services/csf-15.04.tar.gz
- https://files.directadmin.com/services/csf-15.05.tar.gz

and compare them by files

Or/and see the changelog:

ChangeLog:

15.05 - Updated ssh log parsing patterns to support OpenSSH 9.8 and newer

15.04 - Removed set-uid binary wrapper from DirectAdmin plugin

15.03 - Removed surplus iframe for CSF plugin in directAdmin Evolution skin

Added `/usr/bin/bwrap` to the `csf.directadmin.pignore` file

Updated `csf.directadmin.conf` to use LF_INTEGRITY=0 and PT_LIMIT=0

15.02 - Revert to TESTING=1 in the default config

15.01 - Update LFD faied login detection to be compatible with Dovecot 2.4

Update default csf configuration for DirectAdmin installations

Update csf.c wrapper to be compatible with modern gcc

15.00 - Changed license to GPLv3

14.24 - Fixed regression bug in v14.23 "Modified UI HTTP header checks to be
case agnostic"

You might see the tracking-changes-only repository here: https://github.com/poralix/da-csf/
 
You need to understand that CSF is no longer a reliable solution. It faces significant challenges, especially with modern kernels and compatibility issues with nftables and ipv6 cases. At this point, you should consider more mature solutions or experimental alternatives. CSF’s usability is under serious pressure, and its level of protection is now essentially equivalent to Fail2Ban—while being easier to use mainly for amateur users.
 
CSF was two tools.

The csf part was just a frontend that made managing iptables easier.

The other part was lfd, a daemon that monitored log files for login failures, brute force attempts, etc.

The two worked together so that when lfd thought an IP should be blocked, it essentially sent that to csf to do the actual blocking.

I see everyone clamoring to fail2ban and that's fine. But fail2ban is the contextual lfd equivalent to CSF. We still don't have an established go-to nftables frontend like csf that makes managing nftables easier. At least I'm not aware of the industry settling on any one nftables frontend management.

I'm somewhat surprised that there hasn't been a clear a nftables management system replacement for csf. That is what I think needs to happen. We don't need ten thousand forks of the same CSF code.

Much like how everyone was using APF until CSF came about. Now we're still waiting for THE replacement for CSF in the modern nftables era.
 
We still don't have an established go-to nftables frontend like csf that makes managing nftables easier. At least I'm not aware of the industry settling on any one nftables frontend management.
Didn't CSF work with nftables already? I thought it did and the only issue was that ipset would not be working anymore with CSF on newer OS.
Without ipset things are working fine.

So i also don't see any reason to change to fail2ban which (if I'm correct) didn't do any developping anymore since like 3 years or longer. CSF is still better even without ipset.
 
Didn't CSF work with nftables already? I thought it did and the only issue was that ipset would not be working anymore with CSF on newer OS.
Without ipset things are working fine.

So i also don't see any reason to change to fail2ban which (if I'm correct) didn't do any developping anymore since like 3 years or longer. CSF is still better even without ipset.
Support for "real" iptables is mostly over. I can't speak for every distro. CentOS 7 was the last OS (that I'm aware of) that utilized real iptables.

With Almalinux 8, Almalinux 9, Ubuntu 22.04 (that's really the only distributions I have used lately) they operate with nftables. iptables still works, but it's operating within a compatibility mode. In affect, it's simply taking old style iptables syntax and converting it to nftables syntax to be used by nftables.

Your statement about ipset may be true. But I know ipset still works on Almalinux 8.

I'm still using CSF as well, but most of my fleet is Almalinux 8 with just a couple of Almalinux 9 servers in production. As far as I know, CSF still works and functions as expected.

BUT... that doesn't mean that there is no need for a proper CSF replacement. I just keep waiting for something to grab the ram by horns and implement a full proper nftables system. You don't want to choose a CSF replacement and then have everyone else flock to another system 2 months later.

I can only assume that by using the legacy iptables compatibility mode with Almalinux 8 and 9 (and probably ever other modern Linux distribution) you're not fully utilizing all that nftables has to offer.
 
But I know ipset still works on Almalinux 8.
Also works with 9. I was talking about newer OS where CSF/LFD would work less and that is starting with RHEL10 (like Alma 10) where ipset does not work anymore.
I read from people here that also in RHEL10 CSF itself still works properly, same like in 8 and 9.

For older systems, there is currently no issue with CSF at all. So we agree on that.

BUT... that doesn't mean that there is no need for a proper CSF replacement.
Question is if there is indeed a need if DA will keep supporting and updating it themselves.
Real nftables implementation would be great indeed, so question is in fact how far DA will be going with the support and updates on their fork.

Will they implement fully nftables support in their CSF or is there indeed a need for proper replacement.
I'm following this here as well as on cPanel support forums, because for sure the question there will be the same about nftables.
 
Back
Top