DLDanpLab
DanpLab · Lab NoteArchitettura operativa

CrowdSec: a modern alternative to Fail2Ban for homelab and small infrastructures

CrowdSec is an open source collaborative IPS that overcomes the limitations of Fail2Ban with behavioral detection, shared blocklists, and native container support. Practical guide to installation on a Linux homelab.

4 min readBased on real operational use
crowdsecsecurityhomelabfail2banlinuxdocker

Fail2Ban has been the go-to tool for years to protect Linux servers from brute-force attacks. It works, it's simple, but it has known limitations: it only analyzes local logs, doesn't share intelligence with other nodes, requires manual rules for each service, and lacks context awareness. CrowdSec solves these problems with a modern approach: it is an open-source, collaborative IPS (Intrusion Prevention System) with a behavioral engine and a shared threat intelligence network.

Why CrowdSec and not Fail2Ban

Fail2Ban counts failed attempts in logs and applies a temporary ban via iptables. It works well for SSH and a few other services, but becomes fragile when you add Docker containers, reverse proxies, or complex web applications. CrowdSec introduces three fundamental differences:

  • Behavioral detection: it doesn't just count failures, but analyzes attack patterns (scans, aggressive crawling, known exploits) through predefined "scenarios".
  • Shared threat intelligence: every CrowdSec node can send anonymous signals to the central network and receive updated blocklists in real-time from all participants. An attacker blocked on one server is automatically blocked on yours too.
  • Component-based architecture: the detection agent (crowdsec) is separate from the remediation component (bouncer). You can have one agent analyzing logs and multiple bouncers (iptables, nginx, Cloudflare, Traefik) applying the decisions.

Installation on Debian/Ubuntu

The installation is simple and well documented. On Debian 12 or Ubuntu 24.04, add the official repository and install:


wget -qO /usr/share/keyrings/crowdsec-archive-keyring.asc https://packagecloud.io/crowdsec/crowdsec/gpgkey
echo "deb [signed-by=/usr/share/keyrings/crowdsec-archive-keyring.asc] https://packagecloud.io/crowdsec/crowdsec/debian/ bookworm main" > /etc/apt/sources.list.d/crowdsec.list
apt update && apt install crowdsec

At the end, CrowdSec is already active and monitoring system logs. Check the status:

cscli metrics

The output shows the number of active decisions, the scenarios that matched, and the current ban lists.

Configuring the bouncers

The iptables bouncer is included by default and applies bans at the kernel level. For services exposed via a reverse proxy, it is recommended to install the specific bouncer:


apt install crowdsec-nginx-bouncer


apt install crowdsec-firewall-bouncer-cloudflare

For Docker, CrowdSec can read container logs via the docker datasource:


source: docker
container_name:
  - traefik
  - nginx-proxy
labels:
  type: syslog

After each change, reload the configuration:

systemctl reload crowdsec

Custom scenarios for homelab

CrowdSec includes predefined scenarios for SSH, Nginx, Apache, MySQL, WordPress, and many others. For a typical homelab, you can create custom scenarios. Here is an example to protect a Vaultwarden instance:


type: leaky
name: danplab/vaultwarden-bf
description: "Detect brute-force on Vaultwarden"
filter: "evt.Meta.log_type == 'vaultwarden' && evt.Meta.http_status == '401'"
leakspeed: "10s"
capacity: 5
groupby: evt.Meta.source_ip
blackhole: 5m
labels:
  remediation: true
  classification: bruteforce

The local dashboard

CrowdSec includes a lightweight web dashboard (Metabase-based) to visualize statistics and decisions:

cscli dashboard setup
cscli dashboard start

The dashboard is accessible at http://127.0.0.1:8080 and should be protected behind a reverse proxy with authentication.

Hardening checklist for homelab

Before considering the installation complete, verify these points:

  • [ ] CrowdSec started and enabled at boot: systemctl enable --now crowdsec
  • [ ] At least one active bouncer: cscli bouncers list
  • [ ] Relevant scenarios loaded: cscli scenarios list
  • [ ] Enrollment in the threat intelligence network (free): cscli console enroll
  • [ ] Docker logs included in acquis.yaml if you use containers
  • [ ] Dashboard configured and protected behind a reverse proxy
  • [ ] Notifications configured (email, Slack, Discord) for critical bans
  • [ ] Automatic updates: apt install unattended-upgrades and include the CrowdSec repo

Quick comparison: Fail2Ban vs CrowdSec

| Feature | Fail2Ban | CrowdSec | |---|---|---| | Detection | Regex counting on logs | Multi-phase behavioral analysis | | Threat intelligence | No | Yes, shared global network | | Multiple bouncers | Only iptables/firewalld | iptables, nginx, Cloudflare, Traefik, pf | | Container support | Manual | Native via acquis.yaml | | Dashboard | No (CLI only) | Yes, integrated | | Performance | CPU load on large logs | More efficient, optimized parsing | | Learning curve | Very low | Medium |

When to stick with Fail2Ban

CrowdSec is not always the right choice. If you have a single VPS with only SSH exposed and want the simplest possible configuration, Fail2Ban remains perfectly adequate. CrowdSec shines when you have multiple services, containers, reverse proxies, and want coordinated protection with external intelligence.

Resources

Article published on DanpLab. CrowdSec is free software released under the MIT license.