Install on Debian / Ubuntu

The CrowdSec project hosts a Cloudsmith repository with prebuilt packages for current Debian and Ubuntu:

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

The package installs the daemon, the local API, and runs cscli hub update on first boot to pull the current catalog. A quick sanity check:

sudo systemctl status crowdsec
sudo cscli metrics
sudo cscli machines list      # the machine should be auto-registered with the local API

What scenarios are loaded by default

The post-install runs a log-source detector and installs matching collections from the hub. On a fresh box that's usually crowdsecurity/sshd (parses /var/log/auth.log, scenarios for brute force and user enumeration) and the linux base. Confirm:

sudo cscli collections list
sudo cscli parsers list
sudo cscli scenarios list

Add more as needed — nginx and Caddy bot/CVE coverage, for example:

sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/base-http-scenarios
sudo cscli collections install crowdsecurity/http-cve
sudo systemctl reload crowdsec

Each collection bundles its parsers, scenarios, and a postoverflow if needed. cscli collections inspect crowdsecurity/nginx shows what's inside.

Add a bouncer

The daemon detects, but nothing is actually blocked until a bouncer enforces decisions. For sshd / general firewall blocking, the iptables/nftables bouncer is the standard pick:

sudo apt install crowdsec-firewall-bouncer-iptables
# or, on systems using nftables natively:
# sudo apt install crowdsec-firewall-bouncer-nftables

sudo systemctl status crowdsec-firewall-bouncer
sudo cscli bouncers list

The bouncer registers itself with the local API on first boot and pulls decisions every few seconds. To see active blocks:

sudo cscli decisions list

To manually ban an IP (useful for testing):

sudo cscli decisions add --ip 198.51.100.7 --duration 1h --reason "test"
sudo cscli decisions delete --ip 198.51.100.7

The iptables bouncer manages its own chain (CROWDSEC_CHAIN) prepended to INPUT and FORWARD, so it composes with existing firewall rules instead of replacing them.

The community blocklist

Sign up for a free CrowdSec console account, register the machine, and it pulls the community blocklist alongside locally-generated decisions. The console also surfaces a web UI for alerts and active decisions.

sudo cscli console enroll <enrollment-key-from-app.crowdsec.net>

Enrollment is opt-in — if it's not run, the local install still works, but only with local decisions.

What's actually shared

Each agent uploads aggregated decisions (attacker IP, scenario, timestamp) — no logs, no payload bodies, no usernames. The community blocklist is the consensus of decisions reported by many installs; an IP only ends up there after multiple independent reports against multiple scenarios.

Forward-auth bouncer for nginx / Caddy

For HTTP services behind a reverse proxy, the AppSec / HTTP bouncer enforces decisions before the request even hits the upstream. Two integration shapes:

  • The nginx bouncer — a Lua module that calls the local API on every request. Install as crowdsec-nginx-bouncer, configure in /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf.
  • The traefik bouncer — a Traefik middleware plugin. Same API model.
  • For Caddy, the community provides caddy-crowdsec-bouncer:
# Caddyfile snippet
{
    order crowdsec first

    crowdsec {
        api_url    http://127.0.0.1:8080
        api_key    <bouncer-api-key>
        ticker_interval 15s
    }
}

example.com {
    crowdsec
    reverse_proxy 127.0.0.1:8080
}

Generate the bouncer API key the Caddy plugin uses with:

sudo cscli bouncers add caddy-bouncer

Writing custom scenarios

Scenarios are YAML. A minimal one that blocks an IP that hits more than ten 404s in a minute against the WordPress xmlrpc path:

# /etc/crowdsec/scenarios/wordpress-xmlrpc-probe.yaml
type: leaky
name: local/wordpress-xmlrpc-probe
description: "Probing for WordPress xmlrpc.php"
filter: "evt.Meta.log_type == 'http_access-log' && evt.Meta.http_path contains '/xmlrpc.php' && evt.Meta.http_status == '404'"
leakspeed: 30s
capacity: 10
groupby: evt.Meta.source_ip
blackhole: 5m
labels:
  service: http
  type: probe
  remediation: true

The leaky type implements a leaky bucket: the bucket fills on each match, leaks at leakspeed, and overflows (triggers a decision) at capacity. After reload, cscli scenarios list will show the new local scenario.

What it doesn't do

CrowdSec is detection-and-blocking, not a WAF that inspects request bodies. The AppSec component (beta in 2025, stable in 2026) adds CRS-style rule sets to the bouncer for payload inspection, but for now most CrowdSec deployments pair it with a separate WAF (ModSecurity, the LiteSpeed WAF, or a cloud-side one) for app-layer attacks, while CrowdSec handles network-layer brute force, scanners, and consensus blocklists.