FAIL2BAN · TECH
Fail2ban: classic log-based IP banning for Linux servers
Fail2ban is the GPL-2 classic for intrusion detection since 2004. Simple, stable, no crowdsource layer. May 2026 v1.x stable, predecessor of CrowdSec.
Researched & fact-checked by: DuneDive LLC · As of: 2026-05
What is Fail2ban?
Fail2ban is a Python-based intrusion-prevention framework developed since 2004 under GPL-2 license by Cyril Jaquier and a maintainer community. It is the most classic tool in its category -- listed as standard recommendation in nearly every Linux server hardening tutorial of the past two decades, included in Debian/Ubuntu/CentOS repos, with minimal learning curve.
The concept is simple: Fail2ban reads log files in real time (typically /var/log/auth.log, /var/log/nginx/error.log, /var/log/fail2ban.log), matches lines against regex patterns in INI configuration files (called filters), and triggers an action on threshold breach (typically an iptables DROP rule). The default action blocks the attacking IP for a configured duration (default 10 minutes, often raised to 1 to 4 hours).
As of May 2026 Fail2ban is available in stable version 1.x, with an active maintainer community and regular patches. It runs as systemd service (fail2ban.service), consumes minimal resources (around 30-50 MB RAM, hardly any CPU at idle), and needs no external data connection -- everything runs locally. Exactly that makes Fail2ban the default for compliance-strict or mini-VPS setups where CrowdSec would be overkill or regulatorily problematic.
Configuration structure is clear: jails.local defines per service a jail (sshd, nginx-http-auth, postfix-sasl) with path to log file, filter name, maxretry threshold, bantime, and findtime. Filter files in /etc/fail2ban/filter.d/ contain regex patterns. Action files in /etc/fail2ban/action.d/ define block commands (iptables-multiport, nftables-multiport, ufw, route-block). With fail2ban-client status and fail2ban-client status sshd active bans and statistics can be checked.
CrowdSec is the conceptual successor since 2020 -- with collaborative blocklist and clean agent-bouncer separation. But Fail2ban remains productively valuable in 2026 for setups where simplicity, local processing, and minimal footprint take priority.
Why Fail2ban remains relevant for Swiss SMEs and fiduciaries
Despite CrowdSec dominance in new installations, Fail2ban remains the right choice in three scenarios as of May 2026.
Compliance-strict offline setups: FINMA high-risk mandates, certain law-firm constellations with absolute professional secrecy under Art. 321 SCC, or bank-related fiduciaries with strict data-room duty cannot allow external telemetry -- not even anonymised. Fail2ban runs entirely offline, without API calls, without cloud console. That makes it the right choice when compliance cannot sacrifice the crowdsource advantage.
Mini VPS and edge setups: a 512 MB RAM VPS at a Swiss hoster (Cyon, Hostpoint Cloud, Infomaniak minimal tier) handles the 30-50 MB of Fail2ban easily, while CrowdSec with AI Bouncer already takes 250 MB. For solo fiduciaries running a small client portal on such a setup, Fail2ban is the pragmatic choice.
Legacy hardening of existing servers: anyone taking over an old Ubuntu 20.04 or Debian 11 server that already has Fail2ban configured does not necessarily need to migrate. A well-configured Fail2ban stack with sshd, nginx-http-auth, postfix-sasl, and recidive jail (lifetime ban after multiple ban cycles) blocks 80-90 percent of automated attacks -- enough in combination with UFW, public-key SSH, and 2FA for the revFADP minimum standard.
Regulatory assessment is unambiguous: Art. 8 revFADP requires state-of-the-art protective measures -- and Fail2ban is still considered state of the art for brute-force protection in 2026, even if no longer the most modern representative. The FDPIC guideline lists Fail2ban and CrowdSec equally as examples of intrusion-detection tooling. Cyber insurance accepts Fail2ban as a mandatory measure.
Configuration and example setup
Fail2ban configuration runs across three file levels. /etc/fail2ban/jail.conf provides defaults (do not edit). /etc/fail2ban/jail.local overrides defaults (own adjustments). /etc/fail2ban/jail.d/*.conf adds service-specific jails.
A productive jail.local setup for a Swiss SME server:
```ini [DEFAULT] bantime = 4h findtime = 10m maxretry = 5 banaction = nftables-multiport ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 10.0.0.0/8 destemail = security@treuhand-müller.ch sender = fail2ban@treuhand-müller.ch action = %(action_mwl)s
[sshd] enabled = true port = 2847 logpath = /var/log/auth.log maxretry = 3 bantime = 24h
[nginx-http-auth] enabled = true logpath = /var/log/nginx/error.log maxretry = 5
[postfix-sasl] enabled = true logpath = /var/log/mail.log maxretry = 3
[recidive] enabled = true logpath = /var/log/fail2ban.log bantime = 1w findtime = 1d maxretry = 5 ```
The recidive jail is the most important trick: it reads Fail2ban's own logs and bans IPs that have already been banned 5 times within a day for an entire week. That fights persistent attackers using re-IP tricks to reset the maxretry threshold.
Filter file /etc/fail2ban/filter.d/nginx-http-auth.conf typically contains: ``` [Definition] failregex = ^ \[error\] \d+#\d+: \*\d+ user "(?:[^"]+|.*?)":? (?:password mismatch|was not found in ".*"), client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"$ ```
The nftables-multiport action is in May 2026 the recommended choice for modern Linux distributions (nftables is the kernel successor of iptables). On older systems use iptables-multiport. UFW integration via ufw action possible but slower in block.
Important fail2ban-client commands: fail2ban-client status shows active jails. fail2ban-client status sshd shows current bans in the sshd jail. fail2ban-client set sshd unbanip <ip> manually unbans. fail2ban-client reload after jail.local change. fail2ban-client get sshd findtime shows current value.
For Loki/Grafana integration: Fail2ban logs to /var/log/fail2ban.log; promtail collector reads, dashboard with bans per hour, top attacker IPs, jail distribution. Telegram alert on BAN lines via simple bash pipe.
Fail2ban setup in 5 steps
- 01Installation: apt install fail2ban; systemctl enable --now fail2ban; check status with systemctl status fail2ban.
- 02Base configuration: /etc/fail2ban/jail.local with bantime 4h, findtime 10m, maxretry 5, banaction nftables-multiport, ignoreip whitelist for own IPs.
- 03Activate service jails: sshd, nginx-http-auth, postfix-sasl per stack; set enabled=true and logpath per jail.
- 04Activate recidive jail: persistent attackers with bantime=1w after 5 bans within 1 day; prevents re-IP bypass.
- 05Monitoring: fail2ban-client status as daily routine; Loki/Grafana dashboard for trend; Telegram alert on recidive BAN; install filter updates monthly via apt.
When Fail2ban is the right choice
In May 2026, Fail2ban is the right choice in four concrete constellations.
Single-service setup on mini VPS: a solo fiduciary with a single server (Nextcloud plus Bitwarden), 1-2 GB RAM, who does not want to invest in multi-server threat sharing. Fail2ban covers sshd, nginx-http-auth, and own web auth; the missing crowd blocklist is tolerable since Cloudflare WAF can take over layer-7 pre-filtering.
Compliance-strict offline duty: law firm with professional secrecy under Art. 321 SCC that must prohibit every outbound connection from production servers. Fail2ban runs entirely offline, without telemetry. Combine with Loki/Grafana for audit trail, with Wazuh for SIEM layer.
Legacy server with existing configuration: taking over an existing Linux server (Debian 11, Ubuntu 20.04) with working Fail2ban configuration. Re-configuration to CrowdSec causes 4-8 hours of effort and a test window that is expensive in production. Keep Fail2ban running, check monthly updates, activate recidive jail if not yet present.
Training setups and sandbox environments: training VMs for internal employee hardening trainings. Fail2ban has a lower learning curve and transparent regex filters explainable in a training. CrowdSec acquis and YAML scenarios are more powerful but conceptually more demanding.
For all other May 2026 scenarios (multi-server SME, online setup, new Hetzner deployment, fiduciary with multiple client apps): CrowdSec is the better choice. Migration from Fail2ban to CrowdSec is well documented -- run in parallel for 7 days, compare logs, then remove Fail2ban.
When Fail2ban is not enough
Three cases where Fail2ban is insufficient in May 2026.
Multi-server setups with heterogeneous workloads: a Swiss SME with web server, mail server, API server, and worker nodes -- 4-8 machines -- needs threat sharing between nodes. Whoever attacks the n8n server should be banned on the web server immediately. Fail2ban has no sync mechanism. Custom solutions with central log aggregator and push scripts are possible but fragile. CrowdSec delivers that out of the box via Console.
Modern attack patterns beyond brute force: layer-7 attacks staying under maxretry thresholds (1 request per minute, slow login attempts, distributed botnet attacks across 10000 IPs) are not detected by Fail2ban. Only a WAF (ModSecurity, Cloudflare WAF) or ML-based detection (CrowdSec AI Bouncer) provides protection here.
ISO 27001 or PCI-DSS compliance with documented threat-intel duty: PCI-DSS v4.0 has required documented threat-intel sources in the SIEM since 2024. Fail2ban delivers only local detection; a threat-intel layer (CrowdSec Console, AlienVault OTX, MISP) must be added. Anyone needing a SIEM solution like Wazuh anyway can integrate threat-intel feeds there.
General pitfalls in Fail2ban setups: (a) keeping default bantime at 10 minutes -- much too short, should be raised to 4 to 24 hours per service. (b) Forgetting recidive jail -- persistent attackers with re-IP bypass simple bans. (c) Forgetting ignoreip whitelist for office VPN -- self-lockout threatens. (d) Not handling logrotate -- after log rotation Fail2ban sometimes sticks on the old file and does not see new entries.
Trade-offs
STRENGTHS
- Very stable and mature since 2004, included in all Linux repos
- Minimal footprint 30-50 MB RAM, suitable for mini VPS and edge setups
- Fully offline, no external telemetry -- ideal for FINMA high-risk
- Transparent regex filters, easy to explain in trainings and audits
WEAKNESSES
- No crowd blocklist -- 90 percent of botnet IPs go unrecognised
- No agent-bouncer separation, all in one Python process
- Regex in INI files harder to maintain than YAML configuration
- No multi-server sync without custom scripts and central log aggregator
FAQ
Is migration from Fail2ban to CrowdSec worthwhile?
For multi-server setups clearly yes -- the crowd blocklist with 4-6 million IPs blocks attacks Fail2ban never sees. For single-server setups: only if the effort (4-8 hours) is justifiable and no offline duty exists. Run migration in parallel for 7 days, compare logs, then remove Fail2ban. AI Bouncer in CrowdSec delivers additional 15 percent detection rate without false-positive increase.
Which bantime values are sensible in 2026?
SSH 24 hours (bots are persistent), HTTP auth 4 hours, mail SASL 4 hours, recidive 1 week. Default 10 minutes is much too short -- bots try again 6 hours later. Permanent ban (-1) only on manual confirmation, otherwise false positives become a business risk. ignoreip whitelist for office, monitoring, and VPN exit is mandatory.
How do I combine Fail2ban with UFW or nftables?
banaction in jail.local determines the backend. nftables-multiport is the right choice in May 2026 for Ubuntu 22.04+/Debian 12+. ufw action works but is slower at adding the block. iptables-multiport remains valid for older systems. nftables also allows set-based bans, noticeably more efficient than individual iptables rules at 1000+ bans.
What is the recidive jail and why is it important?
The recidive jail reads Fail2ban's own logs and bans IPs that have already been banned in other jails multiple times within a day. This catches persistent attackers who reset the maxretry threshold with short pauses between attempts but are recognisable long-term. Default values: bantime 1 week, findtime 1 day, maxretry 5 -- means 5 bans in 24 hours lead to 1 week ban.