CrowdSec

CrowdSec parses logs, detects malicious behaviour through scenarios, and applies decisions through separate components called bouncers. Structurally it is fail2ban modernised, and it adds one thing fail2ban cannot do.

The collective signal

Participating installations report the addresses they block to a central network, and subscribers receive the aggregated blocklist. An address attacking someone else’s server can be blocked on yours before it makes its first request.

This changes the defensive position in a way per-host detection cannot. Local detection is inherently reactive — an attacker gets their threshold of attempts before being blocked, on every host separately. Shared reputation means the attempts spent against one participant protect all of them.

The obvious objection is poisoning: if reports drive blocking, false or malicious reports could block legitimate traffic. CrowdSec addresses this with consensus requirements and trust scoring for reporters, and it remains the part of the design that deserves scrutiny rather than assumption. It is a real trade — you are accepting a dependency on other people’s detection quality — and for most internet-facing hosts I think it is clearly worth it.

Separating detection from enforcement

The other structural improvement is that the detection engine does not touch the firewall. It produces decisions; bouncers act on them. A bouncer can be a firewall integration through nftables, a web server module returning a challenge page, or an application-level check.

This matters because the right response is not always a network block. For a web application, serving a CAPTCHA to a suspicious address is far better than dropping it — a false positive becomes a mild inconvenience rather than an outage for a legitimate user. Enforcing that distinction architecturally is a genuine improvement over fail2ban’s single hammer.

Practical notes

Scenarios are YAML describing behaviour patterns, and collections bundle parsers and scenarios for common services. Coverage of standard software is good; anything custom needs its own parser, which is more work than a fail2ban regex.

There is more running than fail2ban — an agent, a local API, bouncers — which is more operational surface on a small host. For a single hobby server fail2ban’s simplicity may still be the better trade. Across a fleet, the central decision store and shared intelligence justify it.

See also: fail2ban, nftables, Wazuh for the SIEM layer above, and host hardening patterns.