CrowdSec 1.8 adds WAF bot detection and Kubernetes log collection.

What CrowdSec does differently

CrowdSec occupies roughly the same niche as fail2ban: parse logs, detect malicious behaviour, block the source. The difference is what happens after the block.

When a CrowdSec instance identifies an attacker, it reports the address to a central network. Other instances consume that intelligence and can block the address before it reaches them. The security of every participant improves with the number of participants.

That model has an obvious appeal and an obvious risk. The appeal is that an address which attacked someone else’s server an hour ago is blocked on yours before it arrives. The risk is poisoning: a system where anyone can report an address is a system where someone will try to get a legitimate address blocked. CrowdSec applies reputation weighting and consensus requirements to limit this, which mitigates rather than eliminates the concern.

The architecture also separates detection from enforcement. The agent parses logs and makes decisions; bouncers enforce them at whatever layer suits, iptables, nftables, nginx, Cloudflare, or your CDN. That separation is cleaner than fail2ban’s approach and makes it considerably easier to enforce at the edge rather than on the host.

What 1.8 adds

WAF bot detection. Distinguishing automated traffic from human traffic in a web application firewall, which matters considerably more than it did two years ago given the volume of scraping now hitting every public site. Kernel.org is currently spending about a fifth of its CPU capacity on exactly this problem, and most smaller sites have no instrumentation to even know how much of their traffic is automated.

Kubernetes log collection. Native collection from Kubernetes rather than requiring the log shipping to be assembled separately, which makes it usable in cluster deployments without custom plumbing.

CrowdSec against fail2ban

Both are legitimate choices.

fail2ban is simpler, has no external dependency, ships in every distribution, and is entirely self-contained. Nothing about your server is reported anywhere. For a single machine running SSH and a web server, it is sufficient and our fail2ban guide covers setting it up.

CrowdSec gives you the shared intelligence, better multi-host management, and a more flexible enforcement model. The cost is a dependency on a company’s service and the fact that participation means sending data about attacks against you to a third party.

If you are running one VPS, fail2ban. If you are running a fleet, or you are getting enough hostile traffic that pre-emptive blocking has value, CrowdSec earns its complexity.

Either way, the point that matters more than the choice: something should be watching your authentication logs. Our SSH hardening guide covers the configuration that reduces the problem in the first place, and key-only authentication removes most of what either tool would be blocking.