CrowdSec vs Fail2Ban: Modern Intrusion Prevention for Self-Hosters

Every server exposed to the internet gets hit by automated attacks — SSH brute force, web vulnerability scanners, credential stuffing bots. Fail2Ban has been the standard defense for years, but CrowdSec offers a modern alternative with collaborative threat intelligence. Here's how they compare and which one to use.

How They Work

Both tools share the same core concept: watch logs for suspicious patterns, then take action (usually banning the offending IP).

Fail2Ban

1. Watches log files using regex patterns ("filters")
2. Counts matching events per IP address
3. When count exceeds threshold within a time window, triggers an "action"
4. Actions typically add a firewall rule (iptables/nftables) to block the IP
5. Ban expires after a configurable time

CrowdSec

1. Watches log files using YAML-defined "scenarios" (patterns + behavior logic)
2. Analyzes events against scenarios (supports rate-based, pattern-based, and behavioral detection)
3. When a scenario triggers, creates a "decision" (block, captcha, throttle)
4. Decisions are enforced by "bouncers" (plugins for Nginx, iptables, Cloudflare, etc.)
5. Crowd intelligence — Shares and receives threat data from the CrowdSec network

The crowd intelligence is the key differentiator. When one CrowdSec user detects an attacker, every other CrowdSec user can block that IP proactively, before the attack reaches their server.

Setup Comparison

Fail2Ban Installation

# Debian/Ubuntu
sudo apt install fail2ban

# Fedora
sudo dnf install fail2ban

Create a local configuration:

# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
banaction = nftables

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log

[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log

sudo systemctl enable --now fail2ban

CrowdSec Installation

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec  # or dnf install crowdsec

Install the firewall bouncer:

sudo apt install crowdsec-firewall-bouncer-nftables

CrowdSec auto-detects installed services and loads appropriate scenarios:

# See what collections (scenario groups) are installed
sudo cscli collections list

# Install additional collections
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/linux-lpe

Docker Setup

CrowdSec with Docker:

services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: crowdsec
    volumes:
      - crowdsec_config:/etc/crowdsec
      - crowdsec_data:/var/lib/crowdsec/data
      - /var/log:/var/log:ro
    environment:
      - COLLECTIONS=crowdsecurity/linux crowdsecurity/nginx crowdsecurity/sshd
    restart: unless-stopped

  bouncer:
    image: crowdsecurity/crowdsec-firewall-bouncer-nftables:latest
    container_name: crowdsec-bouncer
    network_mode: host
    cap_add:
      - NET_ADMIN
    volumes:
      - crowdsec_bouncer:/etc/crowdsec
    depends_on:
      - crowdsec
    restart: unless-stopped

volumes:
  crowdsec_config:
  crowdsec_data:
  crowdsec_bouncer:

Fail2Ban with Docker is more awkward — it needs access to host log files and host networking for firewall rules. Most Docker users run Fail2Ban directly on the host.

Detection Capabilities

Fail2Ban Filters

Fail2Ban uses regex patterns. Simple and effective for known patterns:

# Custom filter example
[Definition]
failregex = ^.*authentication failure.*rhost=<HOST>.*$

• Works on any log format you can write a regex for
• Community-maintained filters for common services
• Easy to write custom filters
• Limited to pattern matching — can't detect behavioral patterns

CrowdSec Scenarios

CrowdSec uses YAML scenarios with more sophisticated logic:

type: leaky
filter: "evt.Meta.log_type == 'ssh_failed-auth'"
groupby: "evt.Meta.source_ip"
capacity: 5
leakspeed: "10s"
blackhole: 1m
labels:
  type: bruteforce

• Leaky bucket — Rate-based detection with configurable leak speed
• Trigger — Instant detection on specific events
• Conditional — Detection based on event sequences
• Behavioral — Multi-stage attack detection (scan → exploit attempt)

Crowd Intelligence (CrowdSec Only)

The CrowdSec Central API maintains a blocklist of known attacker IPs, contributed by the community:

• Your CrowdSec instance shares detected attacker IPs (anonymized)
• You receive a curated blocklist of IPs flagged by other users
• This provides proactive blocking — many attacks are stopped before they reach your logs

The community blocklist is free and opt-in. You can use CrowdSec without sharing data, but you won't receive the community blocklist.

Enforcement

Fail2Ban Actions

Fail2Ban primarily uses firewall rules:

banaction = nftables  # or iptables, ufw

Each banned IP gets a firewall rule. With many bans, this can create thousands of rules.

CrowdSec Bouncers

CrowdSec uses "bouncers" — enforcement plugins that integrate at different levels:

• Firewall bouncer — nftables/iptables rules (like Fail2Ban)
• Nginx bouncer — Block at the web server level
• Cloudflare bouncer — Block at the CDN level (before traffic reaches your server)
• WordPress bouncer — Block at the application level
• Custom bouncers — API for building your own

The Cloudflare bouncer is particularly powerful for self-hosters using Cloudflare — attacks are stopped at the edge before consuming your bandwidth.

Action Types

Performance

Resource Usage

Scale

Fail2Ban struggles with thousands of firewall rules — each banned IP is a separate rule. CrowdSec uses IP sets (nftables sets), which handle millions of IPs efficiently.

For a homelab with occasional attacks, both work fine. For a public-facing server getting thousands of attempts per hour, CrowdSec handles the scale better.

Management

Fail2Ban CLI

# Check status
sudo fail2ban-client status
sudo fail2ban-client status sshd

# Unban an IP
sudo fail2ban-client set sshd unbanip 1.2.3.4

# Check banned IPs
sudo fail2ban-client get sshd banip --with-time

CrowdSec CLI

# View decisions (bans)
sudo cscli decisions list

# View alerts (detections)
sudo cscli alerts list

# Manually add a ban
sudo cscli decisions add --ip 1.2.3.4 --duration 24h --reason "manual ban"

# Remove a ban
sudo cscli decisions delete --ip 1.2.3.4

# View installed scenarios
sudo cscli scenarios list

# Check metrics
sudo cscli metrics

CrowdSec also has a free web dashboard at app.crowdsec.net for viewing your instance's activity.

Which Should You Use?

Choose Fail2Ban When

• You want the simplest possible setup
• You're protecting a single server with SSH and maybe one web service
• You prefer tools you can fully understand in an afternoon
• You don't want any cloud connectivity
• You're on a very resource-constrained machine

Choose CrowdSec When

• You want proactive blocking from community intelligence
• You run multiple public-facing services
• You use Cloudflare and want edge-level blocking
• You want more sophisticated detection (behavioral, multi-stage)
• You manage multiple servers (CrowdSec console provides centralized management)

Use Both

They can run simultaneously. Use Fail2Ban for SSH (simple, proven) and CrowdSec for web services (better detection, crowd intelligence, Cloudflare integration). They won't conflict as long as they're watching different log files.

Verdict

Fail2Ban is a reliable workhorse that's been protecting servers for over a decade. It does what it does well, and every sysadmin knows how to configure it.

CrowdSec is the modern replacement with genuine advantages: crowd intelligence means you're protected by the collective experience of thousands of servers, the bouncer architecture is more flexible than Fail2Ban's firewall-only approach, and the detection scenarios are more sophisticated.

For new setups, CrowdSec is the better choice. The community blocklist alone justifies the slightly more complex setup. For existing Fail2Ban setups that work, there's no urgent need to migrate — but consider adding CrowdSec alongside it, especially for web-facing services.