CrowdSec vs Fail2ban

The choice is not which tool detects brute force better. Both read log lines, both match patterns, both end up producing a temporary ban. The choice is whether you want a single daemon whose rules you write and maintain on your own box, or a system where detection and enforcement are deliberately separate processes and the detection half is fed by patterns other people maintain and by a blocklist built from other people's incidents.

Fail2ban is the first shape. One Python daemon, one config directory, one SQLite file, nothing on the network. Since 2004. CrowdSec is the second: a Go engine that parses logs, matches scenarios pulled from a hub, and writes decisions into a local database behind an API, plus at least one bouncer that reads that API and actually blocks. Since 2020.

Everything that follows, including the argument about privacy that dominates every forum thread on this, comes out of that structural difference.

What the spec table is telling you#

Watch two rows. Container count is 2 against 0: CrowdSec is an engine plus a bouncer, Fail2ban is a host package with no service to publish. Idle RAM is 120 MB against 40 MB, which on any machine worth defending is not the deciding factor, though it matters on a 512 MB VPS. Both score 2 on ops load, for opposite reasons: Fail2ban because your regexes rot silently, CrowdSec because its two halves can drift apart and nothing tells you.

Exactly what CrowdSec sends off the box#

This is the real objection, so here is the specific answer instead of reassurance.

A signal pushed to the Central API contains: the offending IP address with geolocation, the name of the scenario that fired plus its version or hash, the timestamp of the decision, your machine ID, and the list of scenarios you have enabled. That last one is a mild fingerprint of what you run. It does not contain your log lines, your URLs, your usernames or your request bodies, because share_context is off.

The shipped console.yaml defaults are:

share_manual_decisions: false
share_custom: true
share_tainted: true
share_context: false

Manual bans you type yourself are not shared. Custom and tainted scenario results are shared by default, though only unmodified hub scenarios are pushed as signals, so a scenario you have edited stops feeding the community. If any of that is unacceptable in your environment, change it before you enroll, not after.

You can also opt out completely: delete the credentials in /etc/crowdsec/online_api_credentials.yaml and the engine never contacts the Central API. Local parsing, hub scenarios already on disk, decisions and bouncers all keep working. What you lose is the community blocklist, which is the main thing CrowdSec offers over a well-tuned Fail2ban. Offline CrowdSec is a legitimate configuration, but be honest that you have chosen a heavier Fail2ban with better-maintained rules.

The mistake almost everyone makes with CrowdSec#

The engine blocks nothing. It parses, it decides, it stores. Enforcement lives in a bouncer, which is a different package with its own API key generated by cscli bouncers add <name> and printed exactly once. People install the engine, see alerts accumulate, and believe they are protected. cscli decisions list can be full of bans that no packet has ever encountered.

Test end to end, on install and again after every upgrade:

cscli decisions add --ip 1.2.3.4 --duration 1m
sudo nft list ruleset | grep 1.2.3.4     # firewall bouncer: expect a match
curl -sI -H 'X-Forwarded-For: 1.2.3.4' https://your.site/   # L7 bouncer: expect 403

If neither shows anything, you have a detection system and no defense. A rotated or lost API key fails exactly this quietly, which is why the check belongs in your documented upgrade routine rather than in your memory.

Fail2ban's defaults are close to useless#

Out of the box: bantime = 10m, findtime = 10m, maxretry = 5. Five failures inside ten minutes buys a ten minute ban. A botnet cycling thousands of source addresses does not notice, and you get the feeling of protection without much of it.

Minimum viable /etc/fail2ban/jail.local:

[DEFAULT]
ignoreip  = 127.0.0.1/8 ::1 10.0.0.0/8 192.168.1.0/24
bantime   = 1w
findtime  = 1h
maxretry  = 3
backend   = systemd
banaction = nftables-multiport

[sshd]
enabled = true

[recidive]
enabled = true

Three things in that file are load bearing. Never edit jail.conf: the package replaces it on upgrade and your changes vanish months later without a word. backend = systemd is mandatory on distributions that no longer write /var/log/auth.log, and getting it wrong is the single most common reason a fresh install detects nothing while reporting itself healthy. And banaction defaults to iptables-multiport, which is wrong on nftables-only systems.

Confirm detection with a log file rather than by locking yourself out:

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
fail2ban-client status sshd

Containers break Fail2ban twice#

If your services run in containers and log to stdout, there is no file to tail without extra plumbing. And even when you solve that, published container ports are diverted in the nat table before reaching the INPUT chain where iptables-multiport writes bans. Fail2ban reports the ban, the traffic arrives anyway. The fix is an action targeting the chain Docker leaves free for you, for example action = iptables-allports[chain=DOCKER-USER], or moving enforcement in front of Docker entirely.

CrowdSec handles this better by design. It reads container logs directly:

source: docker
container_name:
  - my-nginx
labels:
  type: nginx

And its layer 7 bouncers for Traefik and Caddy enforce at the proxy, above the whole iptables problem. If you already run one of those, that is the strongest single argument for CrowdSec. Caddy vs Traefik covers picking between them; Dozzle is worth having alongside for reading what the containers actually logged.

Both tools will ban your reverse proxy#

If your web server logs the proxy's address instead of the client's, every scenario and every jail fires against that one address and blackholes your entire front end. It looks like a proxy failure and it is a total outage. Fix real-IP logging first (see Reverse proxy and TLS), then whitelist the proxy anyway.

The uncomfortable truth: on a closed server, neither one does anything#

Say your box has no ports forwarded. You reach it over WireGuard or a Tailscale-style overlay. Services sit behind Nginx Proxy Manager or Traefik on a LAN-only listener.

In that setup, CrowdSec and Fail2ban are both ceremony. There is no unauthenticated internet traffic reaching a log they can read. The alerts you do see will be your own devices, your own monitoring, and the occasional LAN scan. Installing either buys you a dashboard, some CPU cost, and a new way to lock yourself out.

What is actually doing the work:

• Not exposing the port. An unreachable service cannot be brute forced. Remote access without port forwarding is the whole answer, and Headscale or wg-easy are the two usual implementations. Headscale vs wg-easy picks between them.
• Key-only SSH. PasswordAuthentication no plus PubkeyAuthentication yes makes password guessing arithmetically pointless. A banning tool then only trims log noise.
• A reverse proxy that publishes only what you meant to publish. Most accidental exposure is a container binding 0.0.0.0 rather than an attacker being clever.
• Patching. Nothing in either tool stops an authenticated exploit against an out of date application. An update strategy that does not lose data matters more than either of these.
• Auth in front of anything public. Authelia or an equivalent forward-auth portal removes the login form from the internet entirely. See Single sign-on for self-hosters.

That whole list is A security baseline for a home server, and it outranks this comparison. Run one of these tools if you publish something; do not run one as a substitute for the list.

Is Fail2ban still maintained?#

1.1.0 shipped April 2024. 1.1.1 shipped August 2026. Two years and four months between point releases on a project that tails logs and shells out to a firewall command reads as finished rather than abandoned. It still ships in every distribution, still works, and still needs nothing from the network.

The maintenance risk is not the daemon, it is your filters. When an upstream service changes its log format, a jail stops matching and reports zero failures forever without complaint. Nobody alerts you. That is the failure mode CrowdSec's hub exists to remove, and it is a fair pitch. Pair either tool with something that notices absence, such as an Uptime Kuma push check that fires if your ban counts flatline.

Which one for your situation#

What to do next#

If you publish anything to the internet, pick by enforcement point. Proxy at layer 7 with Traefik or Caddy, use CrowdSec and install the matching bouncer the same hour you install the engine, then run the cscli decisions add test above before you believe it works. Firewall enforcement on a plain VPS with SSH exposed, use Fail2ban, write jail.local with bantime = 1w and maxretry = 3, set backend = systemd, and verify with fail2ban-regex rather than by failing logins.

If you are not sure your server is exposed at all, find that out first. Run A security baseline for a home server end to end, close what does not need to be open, and read Remote access without port forwarding. The rest of the Security category covers what to do once the ports are closed and a banning tool has stopped being the interesting problem.