Any server with SSH or a web app on the internet sees a constant stream of login attempts and probes. Two tools dominate the job of automatically blocking the sources: Fail2ban, the long-time standard, and CrowdSec, a newer design built around shared threat intelligence.

Neither replaces getting the basics right. Key-only SSH stops brute force outright; these tools cut the noise and slow attackers down.

How Fail2ban works

Fail2ban is simple and entirely local:

1. It watches log files (or the systemd journal)
2. Filters, regular expressions, match failures such as “Failed password for root from 203.0.113.5”
3. Jails count matches per IP over a window
4. When an IP crosses the threshold, an action bans it, usually with an nftables or iptables rule, for a set time

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Our Fail2ban setup guide covers it in full.

Strengths: tiny, mature, no network dependencies, filters for almost every service, and nothing leaves your machine.

Limits: it only reacts to what it sees on this server. An IP has to attack you before you block it. Regex filters can break when log formats change, and Python regex matching on very busy logs costs CPU.

How CrowdSec works

CrowdSec splits the job into parts:

Component	Job
Security engine (agent)	Reads logs, parses them, and runs scenarios (detection rules)
Local API	Stores decisions: which IPs to block, and for how long
Bouncers	Enforce decisions: at the firewall, the reverse proxy, or a CDN
Central API	Receives signals from all users and distributes the community blocklist

The key idea is crowd-sourced blocking. When your agent detects an attack, it shares a signal (the IP, which scenario fired, and when) with CrowdSec’s central service. IPs reported by many users become part of a community blocklist that every participant receives. So an IP that has been brute-forcing thousands of other servers can be blocked before it ever touches yours.

Setting it up for SSH

# Add the repository (see the CrowdSec docs for your distribution), then:
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-nftables

sudo cscli collections install crowdsecurity/sshd
sudo systemctl reload crowdsec

Collections bundle parsers and scenarios for a service. Others cover Nginx, Traefik, Caddy, Nextcloud, WordPress, and many more apps.

sudo cscli metrics              # what it is parsing and detecting
sudo cscli decisions list       # current bans
sudo cscli alerts list          # recent detections
sudo cscli decisions delete --ip 203.0.113.5   # unban

Bouncers

Because detection and enforcement are separate, one agent can feed several bouncers:

• Firewall bouncer (nftables/iptables) blocks at the host
• Reverse proxy bouncers for Nginx, Traefik, Caddy, and HAProxy can block or show a CAPTCHA to web visitors only
• Cloudflare bouncer pushes blocks to the edge

That flexibility is a big advantage for self-hosters behind a reverse proxy.

Privacy

CrowdSec does not upload your logs. Parsing happens locally. What it shares is the attacking IP address, the scenario, and a timestamp. You can turn sharing off, but the community blocklist is given in exchange for contributing, so you lose it.

Fail2ban shares nothing at all.

Side by side

	Fail2ban	CrowdSec
Detection	Regex filters on logs	Parsers + scenarios, including behavioural ones
Knowledge	Local only	Local + community blocklist
Enforcement	Built-in actions	Separate bouncers (firewall, proxy, CDN)
Language	Python	Go
Multi-server	One install per server	Agents can share one Local API
Data shared	None	Attacker IPs and scenarios (optional)
License	GPL-2.0	MIT (engine), paid console optional

Which should you run?

Fail2ban if you want the simplest, fully local option, run a single small server, or prefer that nothing leave your machine.

CrowdSec if you run web services behind a reverse proxy, manage several servers, or want to block known attackers proactively. For most self-hosted setups exposed to the internet, the community blocklist is a real advantage.

Not both. Two tools editing the firewall can conflict. To migrate, install CrowdSec, confirm with cscli metrics and cscli decisions list that it detects and blocks, then disable Fail2ban.

Whichever you choose, combine it with key-only SSH and two-factor authentication, and do not expose admin panels to the internet at all; a VPN such as WireGuard is the better gate.

Frequently Asked Questions

What is the main difference between CrowdSec and Fail2ban?

Fail2ban works entirely on its own machine: it reads logs, matches failures with regular expressions, and bans offending IPs locally. CrowdSec also detects attacks from logs, but it shares anonymised attack signals with a central service and receives a community blocklist in return, so it can block IPs that attacked other servers before they reach yours.

Is CrowdSec free?

The CrowdSec security engine and its bouncers are open source under the MIT license and free to use, including the community blocklist. A paid console offers premium blocklists, longer history, and fleet management, but it is optional.

What is a bouncer in CrowdSec?

A bouncer is the component that enforces decisions. The CrowdSec agent decides that an IP should be blocked, and bouncers act on it: the firewall bouncer adds nftables or iptables rules, while others block at Nginx, Traefik, Caddy, or Cloudflare. Detection and enforcement are separate, so one agent can feed many bouncers.

Does CrowdSec send my logs to the cloud?

No. Logs are parsed locally. When it detects an attack, CrowdSec shares a signal containing the attacking IP, the scenario that triggered, and a timestamp. You can disable sharing, but then you also lose access to the community blocklist.

Can I run CrowdSec and Fail2ban together?

You can, but there is little benefit, and two tools editing the firewall can conflict. Pick one. If you migrate, install CrowdSec, confirm it detects and blocks correctly, then disable Fail2ban.

Does either one replace SSH key authentication?

No. Both reduce noise and stop repeated attempts, but they do not prevent a correct password from working. Key-only SSH authentication is the real defence against brute force, and banning tools are an extra layer on top.