# fail2ban alternatives

> fail2ban alternatives compared: CrowdSec, SSHGuard, reaction, CSF, ufw limit, nftables rate limits, WAFs, Wazuh and IPBan for Windows. Status checked Oct 2026.
>
> Source: https://fail2ban.dev/alternatives/ · Updated 2026-10-25 · Checked against fail2ban 1.1.1
> fail2ban.dev is an independent guide, not the official fail2ban project.

The main fail2ban alternatives on Linux are **CrowdSec** (log-based detection plus a shared community blocklist), **SSHGuard** (a small C daemon with no Python dependency), **reaction** (a lightweight Rust log-reaction daemon) and plain **firewall rate limiting** (`ufw limit`, nftables, iptables). On Windows, which fail2ban doesn't support, the usual choice is **IPBan**. DenyHosts is effectively dead and CSF lost its original vendor in August 2025.

Most of these are not drop-in replacements. Before picking one, decide what you are trying to stop: password guessing against SSH and mail (any log-based tool works), floods of connections (a firewall rate limit is enough), attacks inside HTTP requests (you need a WAF), or known-bad IPs before they even try (you need shared threat intelligence). fail2ban covers the first case on a single host better than almost anything else, and you can read [how fail2ban works](/how-it-works/) if you want the mechanics before comparing.

## fail2ban alternatives at a glance

Status was checked against each project's own site or repository in October 2026.

| Tool | What it does | Platforms | License | Status (Oct 2026) |
|---|---|---|---|---|
| **fail2ban** | Reads logs, matches regex filters, bans IPs through the firewall | Linux, BSD, macOS | GPL-2.0+ | Active, 1.1.1 (Aug 2026) |
| **CrowdSec** | Log-based detection with YAML scenarios, separate "bouncers" enforce bans, optional shared blocklist | Linux, FreeBSD, Windows, Docker, Kubernetes | MIT (engine) | Active, 1.8.x (2026) |
| **SSHGuard** | C daemon that parses logs with a built-in grammar and blocks via the firewall | Linux, BSD, macOS, Solaris | ISC-style (OpenBSD) | Active, 2.6.0 tagged Oct 2026 |
| **reaction** | Runs commands when patterns repeat in any command's output | Linux, OpenBSD | AGPL-3.0 | Active, 2.7.0 (Oct 2026) |
| **DenyHosts** | Adds SSH attackers to `/etc/hosts.deny` | Linux | GPL-2.0 | No release since 2015 |
| **CSF / LFD** | iptables front-end plus a login-failure daemon, popular on cPanel | Linux | GPL-3.0 (since v15) | Vendor closed 31 Aug 2025; forks continue |
| **ufw limit** | Rejects an IP that opens 6+ connections in 30 seconds | Linux | GPL-3.0 | Active |
| **nftables / iptables rate limits** | Kernel-level per-IP connection limits (meters, `recent`, `hashlimit`) | Linux | Part of the kernel/userspace tools | Active |
| **WAF** (ModSecurity + OWASP CRS, Coraza) | Inspects HTTP requests and blocks attacks in them | Linux, others | Apache-2.0 | Active (ModSecurity now under OWASP) |
| **Cloudflare** | Filters traffic at the edge before it reaches you | Any (DNS/proxy) | Commercial, free plan | Active |
| **Wazuh** | SIEM/XDR whose "active response" can block IPs | Linux, Windows, macOS | GPL-2.0 | Active |
| **IPBan** | fail2ban-style banning for Windows (Event Log) and Linux | Windows, Linux | MIT (+ paid Pro) | Active, 4.1.0 (Jun 2026) |

## Compare fail2ban with each alternative


- [fail2ban vs CrowdSec](/alternatives/crowdsec/) — single-host log banning vs shared threat intelligence, Docker, Traefik and Kubernetes
- [fail2ban vs SSHGuard](/alternatives/sshguard/) — Python with regex filters vs a small C daemon with attack scores
- [fail2ban vs reaction](/alternatives/reaction/) — the newer Rust log-reaction daemon and when it fits
- [fail2ban vs DenyHosts](/alternatives/denyhosts/) — why DenyHosts is obsolete and how to migrate
- [fail2ban vs CSF/LFD](/alternatives/csf/) — the 2025 ConfigServer shutdown, the forks, and moving to fail2ban
- [fail2ban vs UFW limit](/guides/ufw/) — rate limiting vs log-based banning, and using both
- [fail2ban vs WAF / ModSecurity](/alternatives/waf/) — ModSecurity, Cloudflare, Anubis, Suricata, Snort and Wazuh
- [fail2ban for Windows](/alternatives/windows/) — IPBan, RdpGuard, account lockout and RDP hardening

## Which alternative should you use?

**Keep fail2ban** if you run one to a few Linux servers, want to protect SSH, mail, web logins and dozens of other services with filters that already exist (fail2ban ships 96 of them), and prefer plain config files with no account or network dependency. It is packaged in every major distribution and is the reference the other tools compare themselves to.

**Choose CrowdSec** if you want attackers blocked *before* they hit you, using a community blocklist built from other users' detections, or you need one detection engine feeding many enforcement points (firewall, Nginx, Traefik, Cloudflare). It is also the more natural fit for Kubernetes.

**Choose SSHGuard** if you want something tiny for SSH and a few common services, especially on FreeBSD/OpenBSD or appliances where you'd rather not install Python. On an OpenWrt router, the native banIP package does the same job — see [fail2ban on OpenWrt](/guides/openwrt/#banip-the-lightweight-alternative).

**Choose reaction** if you like writing your own rules, want low CPU use on log-heavy hosts, and are comfortable with a younger project that has fewer ready-made filters.

**Use a firewall rate limit** (`ufw limit`, nftables) as a first layer: it costs nothing and stops connection floods, but it cannot tell a failed login from a successful one. Most people run it *with* fail2ban.

**Add a WAF or Cloudflare** for web applications. They inspect requests that fail2ban never sees, and fail2ban can still ban IPs that a WAF flags, using the [`apache-modsecurity`](/guides/apache/#filter-apache-modsecurity) filter or the [`cloudflare`](/actions/#action-cloudflare) action.

**On Windows**, use IPBan (open source) or a commercial tool such as RdpGuard, and don't expose RDP to the internet at all if you can avoid it. The Windows comparison card above has the details.

## Tools that are no longer a good choice

- **DenyHosts**: SSH only, relies on TCP wrappers (`/etc/hosts.deny`), which upstream OpenSSH removed in version 6.7 and RHEL 8 removed entirely. Its last tagged release is from 2015.
- **CSF/LFD from configserver.com**: the company behind it closed on 31 August 2025 and its download servers went offline. cPanel maintains a fork for cPanel servers and a community fork exists for everyone else, but a new deployment today should think twice.
- **wail2ban** (Windows): archived by its author in 2020.
- **EvlWatcher** (Windows): discontinued and archived by its author in September 2026.

## Is anything "better than fail2ban"?

Better at a specific job, yes. CrowdSec is better at sharing intelligence between hosts. A WAF is better at stopping SQL injection. A firewall rate limit is cheaper for connection floods. But for "watch this log and ban IPs that keep failing", nothing else matches fail2ban's breadth of filters, actions and documentation. If fail2ban isn't working for you, the cause is usually configuration — the jail is reading the wrong log or the ban isn't reaching the firewall — and [fixing fail2ban not banning](/troubleshooting/not-banning/) is faster than migrating.

## FAQ

### What is the best alternative to fail2ban on Linux?

CrowdSec is the most complete alternative: it detects attacks from logs like fail2ban, but also shares and receives a community blocklist and can enforce bans in firewalls, web servers and reverse proxies. For a minimal SSH-only setup, SSHGuard is lighter. For simple flood protection, `ufw limit` or an nftables rate limit is enough.

### Is fail2ban still maintained in 2026?

Yes. fail2ban 1.1.1 was released in August 2026 and the GitHub repository is actively developed. It remains packaged in Debian, Ubuntu, Fedora, EPEL, Arch and the BSDs. The tools that are no longer a good choice are DenyHosts and the original ConfigServer CSF, not fail2ban.

### Can I run fail2ban together with an alternative?

Usually, yes. fail2ban works well alongside a firewall rate limit, a WAF, Cloudflare or CrowdSec, because they act on different signals. Make sure two tools aren't managing the same firewall chain in conflicting ways, and whitelist your own addresses in each. Avoid combining fail2ban with CSF's iptables management or DenyHosts.