fail2ban vs CrowdSec

Pick fail2ban if you protect one or a few Linux servers and want a local, file-configured tool with ready-made filters for almost every service. Pick CrowdSec if you want a community blocklist that stops known attackers before they try, one detection engine feeding many enforcement points (firewall, Nginx, Traefik, Cloudflare), a web dashboard, or native Kubernetes support. Both are free and open source, and they can run side by side.

The core difference is architecture. fail2ban is one daemon that reads logs and runs a ban command on the same machine. CrowdSec splits the job: a detection engine produces decisions, a local API stores them, and separate remediation components (still widely called bouncers) enforce them wherever you install one. That split is what makes CrowdSec good at sharing — and what makes it more to set up.

fail2ban vs CrowdSec at a glance#

How fail2ban works#

fail2ban tails the logs you point it at. Each jail pairs a filter (regular expressions that find failed logins and pull out the IP) with one or more actions. When an address matches maxretry times within findtime, fail2ban runs the action — usually adding the IP to an nftables or iptables set — and removes it after bantime. Everything happens on the local machine, configured in plain INI files, with no external service involved. The full walk-through is on how fail2ban works.

[sshd]
enabled  = true
maxretry = 5
findtime = 10m
bantime  = 1h

fail2ban can send what it sees to shared lists — the abuseipdb and blocklist_de actions report attackers — but it doesn't download a blocklist and pre-emptively ban addresses on its own.

How CrowdSec works#

CrowdSec is made of several pieces:

• Security Engine / Log Processor (the "agent"): reads logs through acquisition configs (/etc/crowdsec/acquis.yaml and acquis.d/), normalizes them with parsers, and feeds events into scenarios.
• Scenarios: YAML behaviour rules, mostly "leaky buckets". The Hub's crowdsecurity/ssh-bf scenario, for example, groups events by source IP with capacity: 5 and leakspeed: 10s — roughly "more than five failures faster than one every ten seconds".
• Local API (LAPI): stores alerts and decisions, and is what bouncers poll. Several engines on several hosts can share one LAPI.
• Remediation components (bouncers): enforce decisions. The firewall bouncer adds IPs to nftables or iptables sets; others plug into Nginx, Traefik, HAProxy, Cloudflare and more.
• Hub: the catalogue of parsers, scenarios, collections (bundles per service, such as crowdsecurity/sshd or crowdsecurity/nginx) and bouncers, installed with cscli.
• Central API and blocklists: if you enroll, your engine shares signals and receives a community blocklist of addresses other users have caught.
• Console: an optional web dashboard (app.crowdsec.net) for alerts, multiple engines and extra blocklists. A free tier exists; more features are paid.
• AppSec: a built-in WAF component (based on Coraza, compatible with ModSecurity rules and the OWASP Core Rule Set) that inspects HTTP requests passed to it by a supported bouncer.

On Debian or Ubuntu, a minimal install is the CrowdSec repository, the engine and a firewall bouncer:

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec crowdsec-firewall-bouncer-nftables

The engine alone detects but does not block — without a bouncer, nothing is banned. Day-to-day commands look like this:

sudo cscli decisions list                       # current bans
sudo cscli decisions delete --ip 203.0.113.42   # unban
sudo cscli collections install crowdsecurity/nginx
sudo cscli metrics                              # what is being parsed

The community blocklist and what you share#

The community blocklist is CrowdSec's main selling point: an IP that brute-forces another user's server can be blocked on yours before it ever connects. According to CrowdSec's documentation (checked October 2026):

• Free users who regularly share signals receive the Community blocklist (about 15,000 IPs, tailored to the behaviours you report).
• Free users who don't contribute get a Lite list capped at 3,000 IPs.
• Paying users get Premium lists of up to 60,000 IPs.
• Only signals from official, unmodified Hub scenarios count as contributions. Custom or edited scenarios don't.

Privacy: CrowdSec says each signal contains the attacking IP, the scenario that triggered and a timestamp — not your log lines. That is still data about third parties leaving your server, so if you operate under GDPR or a strict internal policy, read CrowdSec's privacy terms and decide before enrolling. You can run CrowdSec without sharing; you then lose the full community list. fail2ban, by contrast, sends nothing anywhere unless you configure a reporting action.

Resource use#

There is no fair universal benchmark, and we won't invent one. What is true structurally:

• fail2ban is Python. Its CPU use scales with the number of log lines and the number of regexes tried on each line. On quiet servers it is negligible; on busy web logs with many jails it can become noticeable — see fail2ban high CPU for the usual fixes (journal matches, fewer jails per file, mode = normal).
• CrowdSec is a Go binary plus at least one bouncer process. Its baseline footprint is higher than an idle fail2ban, but parsing is compiled code and scales well. The community blocklist adds tens of thousands of firewall set entries, which nftables and ipset handle efficiently.

If memory is tight (a 512 MB VPS or a Raspberry Pi Zero), measure both on your own workload.

Docker, Traefik and Kubernetes#

Docker. Both run in containers. fail2ban needs host networking and NET_ADMIN, read access to the logs, and bans in the DOCKER-USER chain so they apply to published container ports — covered in fail2ban with Docker. CrowdSec ships an official image, can read container logs straight from the Docker socket, and its firewall bouncer runs on the host.

Traefik. This is where many "traefik fail2ban vs crowdsec" threads end up favouring CrowdSec. A Traefik middleware plugin listed on the CrowdSec Hub checks every request against the LAPI and blocks at the proxy, which also works when Traefik sits behind Cloudflare and the firewall only ever sees Cloudflare's IPs. fail2ban can protect Traefik too — read the access log with a filter and ban through the firewall or the Cloudflare API — but you have to get the real client IP into the log first. See the fail2ban Traefik guide.

Kubernetes. CrowdSec has a Helm chart, a Kubernetes data source (added in 1.8.0) and bouncers for ingress controllers. fail2ban was not designed for pods that move between nodes; if you live in Kubernetes, CrowdSec is the more natural fit.

Configuration side by side#

The same SSH protection in both tools:

[sshd]
enabled  = true
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 4h

# CrowdSec: install the collection; the firewall bouncer enforces
sudo cscli collections install crowdsecurity/sshd
sudo systemctl reload crowdsec

With fail2ban you tune numbers in one file. With CrowdSec you mostly install Hub content and change behaviour through scenarios and profiles.yaml (where the 4-hour default ban lives). Writing your own detection is a regex in fail2ban (test it with the regex tester) versus a parser plus a scenario in CrowdSec.

When fail2ban is the better choice#

• One server, or a handful, with SSH, mail, a web app or a game server to protect.
• You need a filter for something niche — fail2ban ships 96 filters, from Asterisk to Vaultwarden.
• You want zero external dependencies: no enrollment, no API, no data leaving the host.
• You're on an older or minimal distribution where fail2ban is already packaged.
• You want behaviour you can read in one INI file.

When CrowdSec is the better choice#

• You want pre-emptive blocking from a community list, not only reactive bans.
• You run many hosts and want one decision store and one dashboard.
• You need enforcement in places fail2ban can't easily reach: a Traefik or Nginx middleware, a Kubernetes ingress, a CDN.
• You also want a WAF layer from the same vendor (AppSec).

Can you run fail2ban and CrowdSec together?#

Yes, and it is a common migration path. Both read logs without modifying them, and their firewall rules live in separate nftables tables or iptables chains. A few rules keep it sane:

FAQ#

Is CrowdSec better than fail2ban?#

Not universally. CrowdSec is better if you want a shared community blocklist, many hosts managed from one place, or enforcement in a reverse proxy or Kubernetes. fail2ban is better for simple, fully local protection of a few servers and has more ready-made filters. Many single-server admins stay with fail2ban and add nothing else.

Does CrowdSec replace fail2ban?#

It can. CrowdSec detects brute-force attacks from logs and bans through its firewall bouncer, so it covers fail2ban's main use. Check that the Hub has collections for every service you protect today; for anything it lacks you'd write a parser and scenario, or keep fail2ban for that service.

Does CrowdSec send my logs to the cloud?#

No. According to CrowdSec, enrolled engines share signals made of the attacker IP, the triggered scenario and a timestamp, not raw log lines. Sharing is what earns the full community blocklist; you can run CrowdSec without it and get a much smaller list. fail2ban sends nothing unless you add a reporting action.

Can I use fail2ban and CrowdSec at the same time?#

Yes. They read the same logs independently and can each manage their own nftables table or iptables chain. Give each tool its own firewall set, whitelist your IPs in both, and check both when someone reports being blocked. Many people run both during a migration.

Which is lighter on resources, fail2ban or CrowdSec?#

An idle fail2ban uses less memory because it is one process, while CrowdSec runs an engine plus bouncers. Under heavy log volume CrowdSec's compiled parsing scales well and fail2ban's regex matching can use more CPU. There is no fair universal benchmark; measure both on your own workload.

Should I use fail2ban or CrowdSec with Traefik?#

CrowdSec's Traefik middleware blocks at the proxy and works even behind Cloudflare, which is why many Traefik users choose it. fail2ban works too: log the real client IP in Traefik's access log, add a filter, and ban through the host firewall or the Cloudflare action.