# fail2ban vs CSF/LFD

> fail2ban vs CSF/LFD: what the 31 Aug 2025 ConfigServer shutdown means, the cPanel and community forks, and how to replace CSF with fail2ban and nftables.
>
> Source: https://fail2ban.dev/alternatives/csf/ · Updated 2026-10-25 · Checked against fail2ban 1.1.1
> fail2ban.dev is an independent guide, not the official fail2ban project.

**ConfigServer Security & Firewall (CSF) and its Login Failure Daemon (LFD) lost their developer when Way to the Web Ltd closed on 31 August 2025**, and the official download and update servers went offline. You have three options: on cPanel servers, move to **cPanel's own GPLv3 fork** (rolled out automatically from February 2026 to eligible servers); elsewhere, switch to a **community fork** such as the one documented at configserver.dev; or replace CSF with **fail2ban plus a plain nftables or firewalld ruleset**, which is what this page recommends for servers without a control panel.

CSF and fail2ban overlap only in part. CSF is a full firewall manager *and* an intrusion detector; fail2ban is only the detector-and-ban half and relies on whatever firewall you already have.

## What happened to CSF

- **31 August 2025**: Way to the Web Ltd (configserver.com) shut down. Existing CSF installs kept running, but updates stopped and `download.configserver.com` went offline, so the built-in updater fails.
- **Before closing**, the company released **CSF v15.00 under the GPLv3**, which made forks legally straightforward. Its original GitHub repository was later removed.
- **cPanel** published its own fork (`cpanel/cpanel-csf` on GitHub, GPLv3), focused on security and stability fixes. Its package installs only on cPanel & WHM servers. cPanel switched eligible servers — CSF 14.00–15.00 with `AUTO_UPDATES` enabled — to its mirrors in a rollout announced for February 2026.
- **Community forks** appeared for everyone else. The most visible one is maintained on GitHub as `Aetherinox/csf-firewall` with documentation at configserver.dev, and it advertises nftables support. It is a community project, not an official successor.

> **Turn off updates that point at the old domain**
If a server still runs the original CSF, its updater contacts a domain whose owner no longer exists. Set `AUTO_UPDATES = "0"` in `/etc/csf/csf.conf`, remove the CSF update cron job, and restart with `csf -r` until you have chosen a fork or a replacement. Only install updates from a source you have verified.

## fail2ban vs CSF/LFD at a glance

| Feature | fail2ban | CSF / LFD |
|---|---|---|
| Role | Log-based intrusion prevention; uses your existing firewall | Firewall manager (ports, allow/deny lists) + login failure daemon + extra checks |
| Detection source | Log files, systemd journal | Log files (SSH, FTP, mail, cPanel/WHM, DirectAdmin, web auth…) |
| Response | Pluggable actions: nftables, iptables, firewalld, ufw, pf, Cloudflare, mail… | Its own iptables rules (forks add nftables), temporary and permanent denies |
| Extras | Incremental bans, `recidive`, reporting to AbuseIPDB | Port-scan detection, connection limits, process and directory watching, country blocking, blocklists, web UI in cPanel/DirectAdmin/Webmin |
| Scope | Single host | Single host; optional cluster sync between CSF servers |
| Config style | INI files in `/etc/fail2ban/` | `csf.conf` with hundreds of options, `csf.allow`, `csf.deny` |
| IPv6 | Yes | Yes (`IPV6 = "1"`) |
| Docker | Works with the `DOCKER-USER` chain | Has Docker options, but rewrites iptables and is known to conflict |
| Language | Python 3 | Perl |
| License | GPL-2.0-or-later | GPL-3.0 since v15.00 (earlier versions had a custom license) |
| Maintenance | Active, 1.1.1 (Aug 2026) | Original vendor closed Aug 2025; cPanel fork and community forks |

## How CSF and LFD work

CSF generates the whole iptables ruleset from `csf.conf`: which ports are open (`TCP_IN`, `TCP_OUT`), who is always allowed (`csf.allow`) or always denied (`csf.deny`), connection-tracking limits, country blocks and external blocklists. LFD runs alongside it, tails the logs of the services on a typical hosting server, and calls CSF to block an address temporarily or permanently when it fails too often. Hosting control panels embed CSF's web UI, which is a big part of why it became the default on cPanel and DirectAdmin servers.

That design is also its weakness on non-panel servers: CSF wants to own the firewall. fail2ban's own [`csf` action](/actions/#action-csf) carries a warning that CSF has been seen removing bans created by other iptables-based actions — if you use CSF, use it for all bans.

## How fail2ban works

fail2ban doesn't manage ports or policies. You keep a normal firewall (nftables, firewalld or ufw) and fail2ban adds a separate table or set for bans. Each service gets a jail that names a log, a filter and thresholds. On Debian 13 and Ubuntu 24.04 and later, the packaged default [ban action](/config/banaction/) is already nftables (Fedora and EPEL's `fail2ban-firewalld` package uses firewalld instead), so a basic setup is:

```ini
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24

[sshd]
enabled = true

[postfix]
enabled = true

[dovecot]
enabled = true

[recidive]
enabled = true
```

## Option 1: stay on CSF through a fork

This is the least disruptive choice, and the right one for **cPanel servers**: cPanel's fork is maintained by the panel vendor and keeps your `csf.conf`. Check that your server is on cPanel's mirror, and if it was skipped (for example because auto-updates were off), follow cPanel's support article to switch.

For **DirectAdmin, Webmin or bare servers** that depend on CSF's UI and features, a community fork keeps things familiar. Review who maintains it, how releases are signed and how quickly it responds to security issues before trusting it with root.

## Option 2: replace CSF with fail2ban and nftables

On a server without a control panel — or one whose panel doesn't need CSF — fail2ban with a plain firewall covers the important parts and has a large, long-lived community behind it. Map CSF features like this:

| CSF / LFD feature | Replacement |
|---|---|
| `TCP_IN` / `TCP_OUT` open ports | An nftables `input` chain (below), or firewalld/ufw |
| `csf.allow` | Firewall accept rules + fail2ban `ignoreip` |
| `csf.deny` permanent entries | An nftables set, or a jail with `bantime = -1` filled with `fail2ban-client set <jail> banip` |
| LFD login failure blocking | fail2ban jails: `sshd`, `postfix`, `dovecot`, `pure-ftpd`, `apache-auth`, `nginx-http-auth`… |
| `LF_PERMBLOCK` | `recidive` jail or `bantime.increment` |
| `CT_LIMIT` connection limits | nftables `ct count` or rate-limit meters ([see rate limiting](/guides/ufw/)) |
| Country blocking, blocklists | nftables sets loaded from a list you trust |
| Email alerts | fail2ban `action_mw` / `action_mwl` |

A minimal nftables base policy to replace CSF's port rules:

```nft
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept
        meta l4proto { icmp, ipv6-icmp } accept
        tcp dport { 22, 25, 80, 443, 465, 587, 993 } accept
    }
    chain forward {
        type filter hook forward priority filter; policy drop;
    }
}
```


1. Record your current policy: `TCP_IN`, `TCP6_IN`, `csf.allow` and any custom `csfpre.sh`/`csfpost.sh` rules.
2. Write and test the nftables ruleset above with your ports, keeping a console session open.
3. Configure fail2ban jails for every service LFD was watching.
4. Stop CSF and LFD: `sudo csf -x` disables them, then disable the `csf` and `lfd` services.
5. Enable nftables and fail2ban: `sudo systemctl enable --now nftables fail2ban`.
6. Check bans work: `sudo fail2ban-client status` and `sudo nft list table inet f2b-table`.

## Option 3: keep CSF and add fail2ban

If you keep CSF (for its UI or panel integration) but want fail2ban's filters for a service LFD doesn't cover, use fail2ban's [`csf` action](/actions/#action-csf) so bans go through CSF instead of fighting it:

```ini
[DEFAULT]
banaction = csf

[roundcube-auth]
enabled = true
```

## FAQ

### Is CSF firewall discontinued?

The original CSF from ConfigServer is. Way to the Web Ltd closed on 31 August 2025 and its update servers went offline. CSF v15.00 was released under the GPLv3 before the shutdown, and it continues as forks: cPanel maintains one for cPanel & WHM servers, and community forks exist for other systems.

### What is the best alternative to CSF?

On cPanel, cPanel's own CSF fork. On servers without a control panel, fail2ban with an nftables or firewalld ruleset replaces LFD's login-failure blocking and CSF's port rules, with the `recidive` jail standing in for permanent blocks. If you want shared threat intelligence as well, CrowdSec is another option.

### Can fail2ban work with CSF?

Yes. fail2ban ships a `csf` action that bans with `csf --deny` and unbans with `csf --denyrm`, so CSF stays in charge of the firewall. Use it for all jails: fail2ban's action file warns that CSF can remove bans created by other iptables-based actions.

### Should I run fail2ban and LFD at the same time?

Only if they watch different services. If both monitor SSH, each will block the same attacker through different mechanisms, and unbanning means checking both. Either let LFD handle what it covers and use fail2ban's `csf` action for the rest, or replace LFD with fail2ban entirely.

### Is it safe to keep running the original CSF?

It keeps working, but it receives no fixes and its updater points to a domain whose owner has closed. Disable `AUTO_UPDATES` and the update cron job, then plan a move to a maintained fork or to fail2ban with nftables. Don't install updates from unverified mirrors.