Advice on AlmaLinux 10: fail2ban instead of discontinued CSF?

[peps03]

I've been reading the discussion here and elsewhere concerning the discontinuation of CSF and the fact that AlmaLinux 10 uses nftables instead of iptables.

How will DirectAdmin go forward? Integrate fail2ban instead of CSF? Build its own LFD?

I need to set up some new servers, so I’m going with AlmaLinux 10. But I just read that CSF is discontinued, so I’m trying to figure out the best way to proceed at this point and what DirectAdmin's perspective is on this matter. What can we expect?

 

[Richard G]

It seems you can install iptables on Almalinux 10. I read from somebody that he did and he got CSF working. But I can't confirm it momentarily.
However, if this is correct then you could still keep using CSF.

At this moment DA is still thinking about what they are going to do, hope they will give an update soon.

 

[Ohm J]

Rhel10 still can using CSF and IPSET with iptables-nft, but in the future I don't know.... Like Rhel 11, 12, 13, 14 .

 

[peps03]

Thanks for the replies.
"but in the future I don't know.... Like Rhel 11, 12, 13, 14 ."
> Yeah, my concern as well.

And I did read nftables is much faster and more flexible than iptables. As fail2ban is nftables compatible, I'm thinking about swithching to it going forward, as i need to setup some new vpsses now. But it would indeed be great to know how DA will go forward on this topic.

 

[peps03]

I can confirm CSF still works on Almalinux 10:

 

[SEO Guru]

More people who can confirm? Im about to move from Almalinux 8 to 10.

 

[zEitEr]

[root@server ~]# cat /etc/redhat-release
AlmaLinux release 10.0 (Purple Lion)
[root@server ~]#
[root@server ~]# csf -v
csf: v15.05 (DirectAdmin)
[root@server ~]#
[root@server ~]# /etc/csf/csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK

RESULT: csf should function on this server
[root@server ~]#

 

[twhiting9275]

No dice. Fresh install of AlmaLinux 10:

[root@main csf]# cat /etc/redhat-release
AlmaLinux release 10.1 (Heliotrope Lion)
[root@main csf]#


[root@main csf]# perl csftest.pl
Testing ip_tables/iptable_filter...FAILED [FATAL Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for csf to function
Testing ipt_LOG...FAILED [FATAL Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for csf to function
Testing ipt_multiport/xt_multiport...FAILED [FATAL Error: Warning: Extension multiport revision 0 not supported, missing kernel module?] - Required for csf to function
Testing ipt_REJECT...FAILED [FATAL Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for csf to function
Testing ipt_state/xt_state...FAILED [FATAL Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for csf to function
Testing ipt_limit/xt_limit...FAILED [FATAL Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for csf to function
Testing ipt_recent...FAILED [Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for PORTFLOOD and PORTKNOCKING features
Testing xt_connlimit...FAILED [Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for CONNLIMIT feature
Testing ipt_owner/xt_owner...FAILED [Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for SMTP_BLOCK and UID/GID blocking features
Testing iptable_nat/ipt_REDIRECT...FAILED [Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for MESSENGER feature
Testing iptable_nat/ipt_DNAT...FAILED [Error: Warning: Extension tcp revision 0 not supported, missing kernel module?] - Required for csf.redirect feature

[root@main csf]# dnf list | grep iptables
iptables-libs.x86_64 1.8.11-11.el10 @baseos
iptables-nft.x86_64 1.8.11-11.el10 @appstream
golang-github-coreos-iptables-devel.noarch 0.5.0-13.el10_0 epel
iptables-devel.x86_64 1.8.11-11.el10 appstream
iptables-nft-services.noarch 1.8.11-11.el10 appstream
iptables-utils.x86_64 1.8.11-11.el10 appstream
sshguard-iptables.x86_64 2.5.1-1.el10_1 epel
[root@main csf]

CSF simply does not work any longer. Hasn't for a while, really

DA needs to stop trying to install a dead piece of software into systems

 

[Active8]

Try to edit /etc/csf/csf.conf
to
CSF_NFT = "1"

and restart CSF

 

[romans]

My test AL10 looks like and CSF is OK there:

[root@daalmalinux10 ~]# dnf list | grep iptables
iptables-libs.x86_64_v2                                                                  1.8.11-11.el10                                                        @baseos
iptables-nft.x86_64_v2                                                                   1.8.11-11.el10                                                        @appstream
golang-github-coreos-iptables-devel.noarch                                               0.5.0-13.el10_0.alma_altarch                                          epel
iptables-devel.x86_64_v2                                                                 1.8.11-11.el10                                                        appstream
iptables-legacy.x86_64_v2                                                                1.8.11-7.1.el10_0.alma_altarch                                        epel
iptables-legacy-devel.x86_64_v2                                                          1.8.11-7.1.el10_0.alma_altarch                                        epel
iptables-legacy-libs.x86_64_v2                                                           1.8.11-7.1.el10_0.alma_altarch                                        epel
iptables-nft-services.noarch                                                             1.8.11-11.el10                                                        appstream
iptables-services.noarch                                                                 1.8.11-7.1.el10_0.alma_altarch                                        epel
iptables-utils.x86_64_v2                                                                 1.8.11-11.el10                                                        appstream
sshguard-iptables.x86_64_v2                                                              2.5.1-1.el10_1.alma_altarch                                           epel
[root@daalmalinux10 ~]#

next:

[root@daalmalinux10 csf]# cat /etc/redhat-release
AlmaLinux release 10.1 (Heliotrope Lion)
[root@daalmalinux10 csf]#

and

[root@daalmalinux10 ~]# grep -i NFT /etc/csf/csf.conf
[root@daalmalinux10 ~]#
[root@daalmalinux10 ~]# cd /etc/csf/
[root@daalmalinux10 csf]#
[root@daalmalinux10 csf]# perl csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK

RESULT: csf should function on this server
[root@daalmalinux10 csf]#

 

[twhiting9275]

It could be simply that the iptables legacy modules need to be enabled. I'll have to retest once I can get access to the box again.
This isn't something that's going to be done by default, and is not a great idea overall. DA needs to up their game here, honestly.

CSF has been dead in the water development wise, for years, which is why a legitimate path forward needs to be come up with. Firewalld or ufw is a cleaner, better approach than relying on legacy garbage that may or may not continue operating as expected.

 

[Richard G]

Firewalld or ufw is a cleaner, better approach than relying on legacy garbage that may or may not continue operating as expected.

IMHO you're wrong here. CSF is just a iptables/nftables shell and dead in the water does not mean it's really dead. What new development is required when everything is working as designed?
It's a bit of a narrow minded idea to call an application garbage just because it's legacy. So the lifetime DA licenses are garbage now too then? They are also legacy.
I can show you a password application from 2003, very legacy, development wise also dead for 22 years but good luck hacking it. So calling legacy things garbage without really knowing how good it works is rather ignorant.

It still functions great, also on 10, then only thing not supported anymore or c.q. depcrecated is ipset, for the rest it works great.
So ipset can't be used by firewalld or ufw either.
Development should not be continued just for the sake of development. Development has to provide new -usefull- things to. So which new things did firewalld or ufw implement in the years CSF did nothing, which CSF did not have yet?
What did you expect CSF to develop over the past years?

Next to that, a firewall is not DA's task but system administrators task. They (just like cPanel) only integrated CSF because it was very good, easy and free.
And they already had their own BFM for years before CSF even got implement, as you should also now.
In those times we also had to instal our firewalling ourselves.

So now you had 1 little issue with CSF and now it's garbage? LoL.
It might be indeed that DA needs to change something in it's script to make sure some required modules are installed. However there are already various users here running on Alma 10 without reporting an isue once. No clue on what image you used to install DA on, maybe some module was missing there which is installed on other OS installations by default.
To fix things, the error must be reoccurable.

And if you like or trust firewalld or ufw so much better, feel free to use that firewall instead of CSF.

DA had already announce they will see if they will be developping their CSF mirror further and they won't let people use risky garbage.

 

[twhiting9275]

IMHO you're wrong here. CSF is just a iptables/nftables shell and dead in the water does not mean it's really dead. What new development is required when everything is working as designed?

Except, it doesn't. It does not function as designed. It hasn't functioned as designed for years.
You cannot keep putting a band-aid on something and expecting it to keep functioning

It's a bit of a narrow minded idea to call an application garbage just because it's legacy. So the lifetime DA licenses are garbage now too then? They are also legacy.

It's not 'narrow minded', it's factual. Software evolves. If you cannot keep up with that, then you have no place in the software industry, period.

So ipset can't be used by firewalld or ufw either.

So what? We're not talking about ipset here. We're talking about a piece of software that is installed by default on a server which people use daily

Development should not be continued just for the sake of development.

If you're not going to update your system to keep up with the industry you're in, your software is dead. It's just that simple. Yes, development SHOULD be continued to ensure that users are kept protected and secure. NO, it does not work out of the box with newer installs

Next to that, a firewall is not DA's task but system administrators task.

If your software literally bails and refuses to install because of a dependency, then that is on you. DA, on a fresh Alma 10.1 box, does not install. Why? Because CSF refuses to install. Why? Because modules are missing. Which ones? Good luck figuring that out.

So now you had 1 little issue with CSF and now it's garbage? LoL.

1 "little issue" ? This isn't a "little issue", and it's not the only one. I've been saying, for years now that this needs to be replaced, BECAUSE it's abandonware. It's been abandonware for years now.

If your software requires legacy garbage to work, it's time to stop. This is exactly what the devs did, knowing full well they COULDN'T keep it up. It hasn't been updated properly in years, and simply does not work in newer machines. This was inevitable, really

 

[Richard G]

Except, it doesn't. It does not function as designed. It hasn't functioned as designed for years.

Well... if you want to discuss, then come with arguments or proof. Becuse it has and still is working ad designed. Otherwise it would have rained complaints which it didn't. Also panels like cPanel (expensive) and DA were using it by default. For sure they would have not integrated it as it would not have been working as designed.
I'm using it since 2008 and never had complaints. The site is gone but I believe the latest version change was from 2023 if I'm not mistaken.
There is no band aid. It's working as expected. I don't see anything not working as expected.

NO, it does not work out of the box with newer installs

Yes it does. Only in your case and only on Alma 10 in your case it does not.
As said, you're the very first complaining that it would not install out of the box on Alma 10. And @romans instantly responded and tested and could not reproduce the issue.
So if it works with a lot of people and only not on 1 of your servers, then most likely the cause might be on your side. And then good luck finding that.
Otherwise, if you have a modern license, send in a ticket so DA can investigate why it's going wrong.
But don't just bluntly spread your irritation and accusations to DA when it's not even clear that it -is- a DA problem. Due the the fact nobody complained before.

It's been abandonware for years now.

Nonsense. Show proof. I've seen recent changelogs for CSF at least a couple of years ago. Proof why it would be abondonwear. What are the issues you're saying that are there for years, next to the installation issue you're having now.
As for the arguments you said before, I don't agree about that. Might be the case with other software but if you can't improve there is not a single reason to develop further.
Wow new development, at least we bought a new version, changelog: fixed a typo. Or something like that. That is just BS to develop for those kind of reasons.

Yes, development SHOULD be continued to ensure that users are kept protected and secure.

Yes if you can enter new things which can improve things. As to now I didn't see a single example, not even compared to firewalld or ufw which would be a necessary improvement.

That might only be necessary as of now, to improve more on nftables and find something to replace ipset, probably the same reason configserver decided to stop development now. But that is not for years as you say.
So well... we will keep disagreeing until I see some examples of your arguments, which imho are invalid as there is 0 proof.

But configserver stopped. DA did not throw in the blanket yet, so most likely they will develop it further, we will see.
Nobody is obligated to keep using CSF and the competition was just as surprised and unprepared as DA was, so we can't blaim DA for that either.

 

[twhiting9275]

You've got your head up your tail end, and won't believe anything anyone says that you don't agree with, so it's pointless even trying to say anything you don't like here.

CSF has been abandonware for years. Literally years. the only reason it barely functions right now is because of dependencies that mimic original iptables functionality. That's it.