CrowdSec

What is CrowdSec?

CrowdSec reads your service logs, detects brute force, scanning and exploitation attempts, then blocks the offending IPs at the firewall. Detections are shared anonymously across the network, so an IP that attacked someone else this morning is already blocked on your server this afternoon. It is the modern successor to tools like fail2ban with a shared threat feed attached.

Best for

Automatically banning IPs that attack your exposed services

Why choose CrowdSec

CrowdSec takes an idea that only works because it is open source: every participating server shares what it sees attacking it, and the crowd's combined blocklist protects everyone. Your machine watches its own logs for the signs of an attack, and when it recognises one it can both block the offender locally and contribute the signal. The result is that a brand new server benefits from attack patterns that other people's machines learned days ago.

Replaces

• fail2ban
• Cloudflare WAF
• Sucuri

Key features

• Log-based detection for SSH, web servers and common apps
• Community blocklist fed by every participating server
• Firewall bouncers for iptables, nftables and Cloudflare
• Works alongside reverse proxies and container stacks

What to watch out for

It is not a firewall replacement and it is not set-and-forget. Out of the box, detection depends on parsing logs correctly, and a service whose log format you did not account for is invisible to it. Aggressive blocking can lock out legitimate traffic — a shared office IP or a misconfigured scraper — so the first weeks should be spent in a learning mode before you enforce anything. Some of the strongest detection scenarios and the console are part of the company's commercial offering, so the free tier is powerful but not the whole product.

How to deploy

• Docker
• Linux packages

Getting started

Install the security engine, then the firewall bouncer — detection without enforcement only writes to logs and changes nothing. Start with ban decisions in a simulated mode for a week and actually read what it would have blocked; that review is how you avoid banning your own users. Add collections for the specific services you run rather than enabling everything, since extra parsers mean extra noise. Keep an eye on the local API's health, because if the bouncer cannot reach the engine, protection silently stops.

Typical setup

Typical installations run the security engine directly on each internet-facing server, with a firewall bouncer enforcing decisions locally, and optionally a self-hosted console aggregating everything. The most valuable scenarios are the obvious ones — SSH brute force, web scanning, credential stuffing on login pages — and adding collections for the specific services a machine runs is what makes detection effective. Most successful setups spend the first week running in a non-enforcing mode while they review decisions.

Who should look elsewhere

Not a substitute for keeping software patched, using key authentication and closing ports you do not need. It detects patterns in logs; it does not fix the underlying exposure, and an unprotected service is still unprotected until someone attacks it. Small single-user setups may also find the operational overhead — parsers, bouncers, reviewing decisions — heavier than the risk they face.

Project health

• GitHub stars: 15,031
• Last code push: 2026-10-01
• Open issues: 299
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.