Both tools read logs and ban addresses, and at first glance CrowdSec is Fail2ban with a newer codebase. The difference between them is more substantial than that, and it lies not in the age of the code but in where the decision to block comes from.

How they are built

Fail2ban is a single process that reads logs, counts regular-expression matches and calls a firewall command. Every decision is made on your machine from your counters. Nothing is sent anywhere, there are no dependencies, and configuration is text files.

CrowdSec is split into two parts, and that is the main thing to understand before installing it. The agent itself only detects: it parses logs, applies scenarios and writes decisions into its own database. Decisions are enforced by a separate program, the bouncer. Without a bouncer installed, CrowdSec runs, shows alerts, maintains a list of decisions — and blocks nothing.

This is the most common disappointment on first acquaintance: the tool is installed, the attacks are visible, and the traffic flows exactly as before.

sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers list

That last command must show at least one registered entry. An empty list means there is no blocking.

The second difference: shared reputation

Fail2ban knows only what happened at your place. An address that spent yesterday breaking into a hundred other servers is clean to it until it knocks on your door — and its first five attempts are free.

CrowdSec sends signals about what fired into a shared network and receives back a list of addresses seen at other people's servers. The practical effect: a noticeable share of the guessing is cut off before the first attempt. That matters especially against distributed attacks — thousands of addresses with one attempt each, where local counters are powerless by definition.

And here is the thing to know beforehand: the exchange goes both ways. What leaves your server is the offending addresses and the types of scenario that fired. Running fully locally is possible — without enrolling in the cloud console — but then the shared list is unavailable to you too, and the main advantage disappears. That is a deliberate choice, not a configuration detail.

Everyday commands

sudo cscli metrics
sudo cscli alerts list
sudo cscli decisions list
sudo cscli decisions delete --ip 203.0.113.25

metrics answers the question of whether the logs are being read at all: if the number of parsed lines is zero, then the collection for your web server is not installed or the log path is wrong. That is the second most common case of "it is installed and does not work".

sudo cscli collections list
sudo cscli collections install crowdsecurity/nginx

Resources

CrowdSec is written in Go and keeps its state in a database. Memory use is on the order of a hundred megabytes, plus the bouncer. On a server with a gigabyte of memory that is noticeable; from two upwards it is not. Fail2ban is lighter, and does less.

Is it worth running both

They do not conflict: one writes its rules into the firewall, the other writes its own, and banning the same address twice harms nothing. A sensible division looks like this.

CrowdSec takes on the mass traffic: SSH guessing, web server scanning, known bad addresses from the shared list. Fail2ban stays where you have your own log in your own format, for which writing a regular expression is easier than writing a scenario — a home-grown application, a rare service, a specific login form.

If you have to choose one, the guideline is this: on a server with a website that is constantly being probed, CrowdSec gives more thanks to the shared list. On a server reachable only by you over SSH with keys, the difference between them is small — most of the work there has already been done by turning passwords off.

A limitation they share

Neither protects against a vulnerability in an application. Both work with request frequency and address reputation, and a request that exploits a hole in a plugin on the first try from a clean address will pass both by. That is the work of other tools — a WAF at the request level and timely updates. Blocking addresses removes the background, not the cause.

The practical value of either depends on somebody looking at the result. A rising number of decisions, a scenario firing for the first time, a change in the countries the attempts come from — that is the information the tool was installed for. What it looks like on one page is on the demo below.