CrowdSec — the CrowdSec Security Engine — is an open-source, participative intrusion detection and prevention system with optional web application firewall (WAF) capabilities. It reads the logs and HTTP requests you point it at, normalises them through parsers, and evaluates behaviour against scenarios: instead of matching a single failed login, it asks whether the pattern of activity looks like a brute-force, a scraper or an exploit attempt. When a scenario fires, the engine records the offending IP and, through a remediation component, blocks it — at the firewall, the web server or the reverse proxy. If you opt in, the signals it detects are shared anonymously so that every other participant can block those attackers before they arrive.

Key Features

• Behaviour-based detection — detection is driven by scenarios (log patterns plus a time window and a leaky bucket), not by static rules, so a scenario such as crowdsecurity/ssh-bf fires on sustained failed SSH authentication from one source rather than on a single line.
• Parsers, scenarios and collections from the CrowdSec Hub — roughly 800 scenarios, 170 parsers, 170 collections and 230 AppSec rules as maintained by the community; they are installed, enabled and upgraded with cscli hub / cscli collections install.
• Participative threat intelligence — sharing is opt-in and anonymous (signals only: IP, scenario, timestamp — no logs or payloads). In exchange the engine downloads the community blocklist of IPs validated by other participants, so known attackers are blocked pre-emptively.
• Remediation components (bouncers) — enforcement is decoupled from detection: block at layer 3/4 with the iptables, nftables, ipset or pf bouncer, or at layer 7 inside Nginx, OpenResty, Traefik or HAProxy (SPOA), push decisions up to Cloudflare, or mirror blocklists to appliances that cannot run the bouncer themselves.
• AppSec / WAF and bot detection — the engine inspects HTTP requests with the OWASP Core Rule Set in-band through supported components, adding virtual patching for CVEs and configurable bot detection for scrapers and headless browsers.
• Distributed by design — a Local API (LAPI) sits between the log processors that detect and the components that enforce, so many machines and bouncers can share one engine, and machines that never reach the internet can still be protected.
• Replay and forensics — cold logs can be replayed to validate detections, tune scenarios or produce reports, and cscli explain shows exactly which node of the pipeline parsed a given line and why it did or did not overflow a bucket.
• Observability and administration — Prometheus metrics on port 6060, the cscli command line (alerts, decisions, metrics, bouncers, allowlists), a free web Console for a fleet-wide view, and an HTTP API behind all of it.
• Light and portable — the documented minimum is one CPU core, 100 MB of RAM and 1 GB of disk, on amd64, arm64 or armhf.

Why Use CrowdSec?

CrowdSec is the modern complement to fail2ban rather than a replacement for your firewall or SIEM. Both parse logs and ban IPs, but fail2ban works one service and one host at a time: each jail has its own filter, its own ban table, and no idea what any other machine is seeing. CrowdSec centralises detection in one engine with a shared decision store, so a ban is enforced by whichever components you run, and detection is separated from enforcement — you can start in alert-only mode, watch what the scenarios fire on, and switch to blocking without re-designing anything. Because participation is anonymous and opt-in, the collective part costs you nothing operationally while giving you early sight of IPs that are already attacking other installations; and since the engine is MIT-licensed and self-hosted, none of your log data leaves your infrastructure.

Use Cases

• Stop SSH and RDP brute-force against servers, bastions and exposed services with the firewall bouncer.
• Protect a self-hosted web application with the Nginx, OpenResty, Traefik or HAProxy component plus AppSec rules.
• Cut scraper and credential-stuffing traffic with bot detection and allowlisted good crawlers.
• Give a whole fleet — cloud VMs, containers, a home lab — one LAPI, one console view and one blocklist.
• Replace a sprawl of per-service fail2ban jails with a single engine and its collection of scenarios.
• Replay and explain historic logs after an incident to see what was detected, missed, or falsely flagged.

Similar

• Fail2ban — the classic log-parsing ban tool, per-service and per-host; pair it with CrowdSec or migrate to it.
• Suricata — network-level IDS/IPS that inspects packets, where CrowdSec inspects logs and requests.
• Wazuh — host-based intrusion detection, SIEM and compliance, for the audit side of the same problem.

Platform

Linux (Debian/Ubuntu, RHEL/Fedora, SUSE, Arch, OpenWrt) · FreeBSD · Windows · macOS (via Docker) · Docker · Kubernetes · OPNsense · pfSense · cPanel/WHM

Licence

MIT (Security Engine)

Website

crowdsec.net · docs.crowdsec.net · source on GitHub