CSF is being discontinued

Third Party News
21

I think Fail2Ban parses the logs so it shouldn’t be affected. Not too hard to test though. I see little on SSH because changing the port doesn’t stop the standard port attempts but they never make it as far as the login.

1 Like
22

Thanks! I will test it.

23

I really like CSF. I’m just not using it right now because about 8/9 months ago I lost access with my then provider. Then I reinstalled and continued with Firewalld because I believed I would have the same problems. It would be wonderful if you could adjust CSF by Webmin/Virtualmin. It would be an excellent sub-product for everyone.

24

There is already a module for CSF, and Ilia has spent quite a lot of time on it. I don’t use it, but people seem to like it.

1 Like
25

can you think of any potential downside or disadvantage to making it GPL?

26

Its documented here

27

Correct, except it won’t know which is the new SSH port and which port to block.

1 Like
28

You had me checking since it’s been well over a year since I did this. The GUI has ‘ports to block’ and lists ssh. I renamed the service in /etc/services when I changed the port. But it almost never gets an attempt on the new port anyhow.

29

They have changed a bit the communicate:

To allay some fears, we are actively working on releasing csf (ConfigServer Security & Firewall) under the GPLv3 license. If we do this, it will be before we close for business and the software will be made available via our GitHub repository.

Good news!

2 Likes
30

I hope this happens - CSF is excellent. I wonder if the Virtualmin team might be interested in approaching them and offer to take over as its maintainers on the basis it will always remain OS? Could be a nice way to get exposure for Virtualmin as lots of people I know use CSF..

31

It’s written in Perl (and pretty nice Perl from what I’ve seen), so it wouldn’t be a big stretch, but I’m not overly fond of the way firewalls like CSF work. They’re useful in their place, but quite heavy and complicated for a web hosting environment (then again, so is fail2ban, I wish I’d known about sshguard back when making the call to use fail2ban but for a long time sshguard only worked with ssh).

Ilia loves CSF, though, so maybe he’d be interested. I wouldn’t want to volunteer him for something, though, as he’s already extremely busy.

That said, I would expect there are people more invested in CSF than we’ve historically been who might be interested in carrying it forward.

I mean, sure, it is an opportunity, I’m sure having the reins of CSF handed over to some entity would be good marketing for that entity, but I’m not opportunistic about stuff like this. This was someone’s work for many years, and if our experience is any indicator, they probably didn’t make a lot of money doing it. I hope they do what they feel good about doing with it. If that includes handing it off to someone they trust, that’s great. If it involves just adding a GPL license to the existing repo and letting a thousand forks bloom (and see who survives), that’s also great.

In short: I think Ilia has communicated with them in the past, and he’s done a lot of work making using it nice in Webmin, but I don’t think they’d think of us anywhere near the top of the list of possible adopters of the project, and I’d want them to make decisions based on what they want to see happen.

5 Likes
32

I would expect cPanel/WHM to pick it up and if it is GPL then others can benefit etc…

1 Like
33

I’ve said this before. A proper firewall goes in front of the server. Unless you have a machine that is WAY over what you need things like DDOS attacks will bring you down anyhow by eating up the server resources. Basically having DDOS protection on your server is a losing proposition.

34

I’m guessing the reason for closure may be due to ill-health - CSF has been around a long time and so I imagine its creator is probably getting on a bit now. I hope I am wrong and I hope the person behind it is ok. (Just checked and it looks like it’s a husband-wife team with them being almost 60 years old - I hope they’re both ok).

Looks like someone has started this to keep copies of the old scripts:

2 Likes
35

Not seen this mentioned here: For those of you still intending to use CSF beyond August it was pointed out (at a rival product’s forum I’m unsure if I can mention) that the automatic updates feature could be exploited to gain root access or deploy backdoors to any system it’s installed on, if (or rather when) the “configserver.com” domain name gets taken over by a malicious actor.

The domain name is due to expire January 2027, though who knows what could happen after August.

To avoid this problem you essentially need to prevent your CSF systems from contacting the web servers at FQDNs “download.configserver.com” and “download2.configserver.com”.

Options to avoid this:

  1. Confidently block or redirect those two FQDNs (or “*.configserver.com” completely),
  2. Modify the software to get rid of updates entirely,
  3. Prevent updates by configuring CSF to look for them at non-existent “download.localhost”,
  4. Or host your own authentic version of the download package and configure CSF to use that.

For option 3 simply create/replace file “/etc/csf/downloadservers” containing “download.localhost” followed by a new line. This will cause CSF updates to simply fail. Test that with csf -u.

For option 4 to host your own updates web repository:
(Credit to zEitEr)

  1. Setup some web space. You can make this private by limiting this to your server IP addresses if you like, but authentication (HTTP basic/digest) will not be available.
  2. On your CSF systems create/replace text file at “/etc/csf/downloadservers”, containing a list (NL delimited) of your web space FQDNs.
  3. Relative to your web space htdocs root, create a “csf” directory, containing 2 files:
  • A copy of the latest download package “csf.tgz”.
  • A text file “version.txt”, which must contain only “14.24”, no new line.

The resulting URLs must be accessible at “https://download[...]/csf/csf.tgz” and “https://download[...]/csf/version.txt”. Test this on a CSF system by running csf -u.

  • Do not have “/etc/csf/downloadservers” empty.
  • HTTP FQDN must begin with “download”. (E.g. “download.example.com” or “download5.csf.example.net”.) Anything else will be ignored.
  • Importantly if CSF doesn’t find any valid FQDNs in this file it will revert to the official “download.configserver.com”.
2 Likes
36

only a couple of days now.

1 Like
37

Looks like they managed to release them:

38

See also configserver-scripts/README-gpl-csf.md at main · centminmod/configserver-scripts · GitHub.

1 Like
39

Are they going to take over it?

1 Like
40

Nice, copying the install/migration guide here for easy reference:

:rocket: Migration Guide

For Existing Users (v14.x → v15.00)

  1. Backup Current Configuration
cp -R /etc/csf /etc/csf.backup
cp /usr/local/csf/version.txt /usr/local/csf/version-backup.txt
  1. Update CSF
# Use manual updates from GitHub
cd /usr/src
wget https://github.com/waytotheweb/scripts/raw/refs/heads/main/csf.tgz
# Extract and run install.sh
tar -xzf csf.tgz
cd csf
sh install.sh
  1. Disable Auto Updates

In /etc/csf/csf.conf disable auto updates variable setting it to 0. CSF v15.00 disabled auto update and version check in code, but AUTO_UPDATES if enabled, will still try to auto update - leading to download error which is just cosmetic and won’t impact CSF Firewall operations.

# Enabling auto updates creates a cron job called /etc/cron.d/csf_update which
# runs once per day to see if there is an update to csf+lfd and upgrades if
# available and restarts csf and lfd
AUTO_UPDATES = "0"
  1. Verify Installation
csf -v  # Should show v15.00
csf -r  # Restart CSF
  1. Configure Update Source (if desired)
  • Set up your own mirror in /etc/csf/downloadservers. Will need to restore CSF v15.00 disabled auto update routines and version checks first.
  • OR rely on manual updates from GitHub

:clipboard: Post-Upgrade Checklist

  • Verify CSF version shows 15.00: csf -v
  • Check firewall rules are intact: csf -l
  • Confirm LFD is running: systemctl status lfd
  • Test temporary IP blocking: csf -d 1.2.3.4 "test"
  • Remove test block: csf -dr 1.2.3.4
  • Review UI access (if applicable): Access CSF through your control panel
  • Set up alternative update method (GitHub watch, custom mirror, etc.)
  • Review /var/log/lfd.log for any errors

Why not create a fork for virtualmin @Ilia? I’m sure it would easily become one of the trusted forks…

1 Like