How to Install CrowdSec (Fail2ban That Shares Attackers with Everyone Else)

Fail2ban bans an address after it attacks you. CrowdSec does that too, and then shares the attacker's address with every other CrowdSec installation — and receives theirs. The result is a blocklist of tens of thousands of currently active malicious IPs that your firewall drops before they've sent a single login attempt. It reads the same logs, installs in minutes, and can run alongside Fail2ban or replace it.

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec -y

The installer looks at what's running (SSH, Nginx, etc.) and installs matching collections — parsers plus attack scenarios. Check:

sudo cscli collections list
sudo cscli metrics

Within a minute metrics shows lines being read from /var/log/auth.log or the journal and nginx/access.log.

The agent only decides; a bouncer enforces:

sudo apt install crowdsec-firewall-bouncer-iptables -y
sudo systemctl status crowdsec-firewall-bouncer

It adds an ipset to iptables that drops every banned address, ahead of UFW. From now on, decisions are real blocks. (On Ubuntu with nftables, use the -nftables package instead.)

sudo cscli capi status

Enrolled by default: the agent pulls the community list of active attackers several times a day and the bouncer drops them. Check how many:

sudo cscli decisions list --origin CAPI | wc -l

Typically tens of thousands. That's addresses blocked before they ever knock.

sudo cscli alerts list
sudo cscli decisions list
sudo cscli alerts inspect 42 -d

Alerts are detections on your logs ("ssh bruteforce from 203.0.113.5"); decisions are the resulting bans (4 hours by default, longer for repeat offenders). Nothing to tune — the scenarios cover SSH brute force, Nginx scanning, WordPress login abuse, HTTP floods and more out of the box.

sudo cscli collections install crowdsecurity/wordpress
sudo cscli collections install crowdsecurity/nextcloud
sudo cscli collections install LePresidente/jellyfin
sudo systemctl reload crowdsec

The hub (cscli hub list) has scenarios for most things in this series. For apps logging to Docker rather than files, add the Docker log source: sudo cscli parsers install crowdsecurity/docker-logs and an acquisition entry in /etc/crowdsec/acquis.d/docker.yaml with the container names.

Sign up at app.crowdsec.net (free for personal use), then:

sudo cscli console enroll YOUR_KEY
sudo systemctl reload crowdsec

A dashboard of your alerts, where attackers come from, and the option to subscribe to extra blocklists.

sudo cscli allowlists create home -d "home network"
sudo cscli allowlists add home 192.168.1.0/24 10.8.0.0/24

(Older versions: a whitelists.yaml parser with the same ranges.) Test by checking cscli decisions list never shows your own addresses.

They can coexist — both just add firewall drops. Most people switch: CrowdSec does everything Fail2ban did, plus the shared intelligence, with less config. Keep Fail2ban only for a custom filter CrowdSec has no scenario for.

cscli metrics shows 0 lines read. Log path isn't being watched — /etc/crowdsec/acquis.yaml. Ubuntu 24.04 logs SSH to the journal; the installer handles it, but check journalctl is listed as a source.

Bans in decisions list but the attacker still connects. The bouncer isn't running or isn't registered: cscli bouncers list should show it as valid.

Blocked a legitimate service (a CDN, a monitoring provider). cscli decisions delete --ip, then allowlist it.

High CPU on a Pi. Reduce the community blocklist refresh or disable scenarios you don't need (cscli scenarios remove ...).

Install script, the firewall bouncer, enrolled in the community list. Your server blocks the addresses that attacked someone else last night before they try you this morning, detects attacks on your own logs with no filters to write, and the console shows you the whole picture. It's Fail2ban with ten thousand friends.