# fail2ban, explained and automated

> Independent fail2ban guide: what fail2ban is and how it works, install on any Linux, jail.local examples, every fail2ban-client command, filters and free tools.
>
> Source: https://fail2ban.dev/ · Updated 2026-10-26 · Checked against fail2ban 1.1.1
> fail2ban.dev is an independent guide, not the official fail2ban project.

## What is fail2ban?

**fail2ban** is a free, open-source intrusion-prevention tool for Linux and other Unix-like systems. It watches log files — or the systemd journal — for signs of brute-force attacks, such as repeated failed SSH logins, and temporarily bans the offending IP addresses by adding firewall rules. Out of the box it protects SSH; with its 96 bundled filters it also guards web servers, mail servers, VPNs, databases and many self-hosted apps.

fail2ban is written in Python and released under the GNU GPL v2. It was created by Cyril Jaquier in 2004 and is maintained today by a community of contributors on [GitHub](https://github.com/fail2ban/fail2ban). The current release is **fail2ban 1.1.1**. It is packaged by every major distribution, so `apt install fail2ban` or `dnf install fail2ban` is usually all it takes to [install it](/install/).

## What does fail2ban do, exactly?

Every internet-facing server is scanned constantly. Bots try thousands of username and password combinations against SSH, hammer WordPress `wp-login.php`, and probe for `phpMyAdmin`. fail2ban turns the evidence those bots leave in your logs into action:


1. **Read** — a *backend* follows a log file (`/var/log/auth.log`, `/var/log/nginx/error.log`…) or the systemd journal in real time.
2. **Match** — a *filter* of regular expressions (`failregex`) recognises failure lines and extracts the client address from the `<HOST>` tag.
3. **Count** — the *jail* counts failures per IP. When an address reaches `maxretry` failures within `findtime`, it is banned.
4. **Ban** — an *action* runs, usually adding the IP to an nftables or iptables set. After `bantime` the action is reversed automatically.

A jail is simply the combination of one filter, one or more actions and those three numbers. The stock defaults are `maxretry = 5`, `findtime = 10m` and `bantime = 10m`; most admins raise the ban time and enable [incremental bans](/config/bantime-increment/) or the [recidive jail](/config/recidive/) for repeat offenders. The full picture is in [how fail2ban works](/how-it-works/).

## Is fail2ban still worth using in 2026?

Yes, for most single servers. Key-only SSH already stops password guessing, but fail2ban still cuts log noise and wasted CPU, blocks scanners before they find a weak service, and protects things that *do* take passwords — web logins, mail, VPN and admin panels. It needs no external service and sends no data anywhere. If you run many servers and want shared threat intelligence, compare it with [CrowdSec](/alternatives/crowdsec/); fail2ban and CrowdSec can even run side by side.

What fail2ban is **not**: it isn't a firewall (it drives yours), it isn't a WAF (it doesn't inspect requests, only logs), and it can't stop a large distributed DDoS. See the [alternatives](/alternatives/) for the tools that cover those layers.

## Where to go next


- [Install fail2ban](/install/) — Ubuntu, Debian, Rocky/Alma, Fedora, Arch, Docker, Raspberry Pi
- [jail.local example](/config/jail-local/) — a complete, commented production config
- [fail2ban-client commands](/commands/) — every command with real output
- [Filter library](/filters/) — all 96 built-in filters with test lines
- [Integration guides](/guides/) — nginx, Apache, Nextcloud, Vaultwarden, Proxmox and more
- [Troubleshooting](/troubleshooting/) — not banning, no log file, socket errors, Docker

<!-- faq -->

### What is fail2ban used for?

fail2ban protects servers from brute-force and abuse by banning IP addresses that show malicious behaviour in logs — most often repeated failed SSH logins, but also failed web, mail, FTP or VPN logins and vulnerability scans. It bans them through the firewall for a set time.

### Is fail2ban still used?

Yes, widely. It is actively maintained — version 1.1.0 came out in April 2024 and 1.1.1 in August 2026 — and packaged by Debian, Ubuntu, Fedora/EPEL, Arch, FreeBSD and OpenWrt. Hosting panels such as Plesk and HestiaCP build on it. Newer tools like CrowdSec add shared blocklists, but fail2ban remains the default first line of defence on single Linux servers.

### How effective is fail2ban?

Very effective against brute force from individual addresses, which is most of what hits a server. A bot guessing one password every 6 seconds makes 14,400 attempts a day; with `maxretry = 5` and `bantime = 1h` it gets at most about 120, and [incremental bans](/config/bantime-increment/) cut that to a handful. It is weak against botnets that spread guesses over thousands of IPs, does nothing for unlogged exploits, and can't stop DDoS — so pair it with key-only SSH and strong passwords.

### Where is fail2ban on GitHub?

The source code, issue tracker and releases are at github.com/fail2ban/fail2ban. Releases are tagged there (the latest is 1.1.1) with a `.deb` attached; the `master` branch is the development version. This site is independent of the project — see [fail2ban versions](/versions/#upgrade-fail2ban) for installing a release from GitHub.