CrowdSec: Deploy Community-Powered Threat Intelligence and Intrusion Prevention

Introduction

Traditional intrusion prevention systems rely on static signatures that attackers can trivially bypass with minor payload mutations. CrowdSec takes a different approach: it uses behavioral analysis to detect attack patterns in logs, then shares anonymized attacker IPs with a global community blocklist. Every server running CrowdSec contributes intelligence — and every server benefits from the collective.

In practice this means your web server can start blocking IPs that attacked someone else's SSH daemon in Singapore five minutes ago, before those IPs ever touch your infrastructure. CrowdSec calls these shared signals the Community Blocklist, and it's free.

This guide walks through a complete CrowdSec deployment on a Linux server:

• Installing the Security Engine (log parser + scenario engine)
• Configuring log sources and detection scenarios
• Installing the cs-firewall-bouncer to enforce blocks via iptables/nftables
• Enrolling in the CrowdSec Console for centralized visibility
• Testing detections and verifying the full pipeline works end-to-end

By the end you will have a live collaborative IPS that feeds from — and contributes to — a threat intelligence network of millions of nodes.

Prerequisites

Before starting, verify your environment:

# Confirm OS
lsb_release -a
 
# Confirm sudo access
sudo whoami
 
# Check available firewall backend
sudo iptables -V || sudo nft --version
 
# Check that key log files exist (adjust paths for your apps)
ls -lh /var/log/auth.log /var/log/nginx/access.log 2>/dev/null

You will also need outbound HTTPS (port 443) access to api.crowdsec.net for the Community Blocklist and Console enrollment. If you are behind a corporate proxy, set HTTPS_PROXY before running installer commands.

Step 1 — Install CrowdSec Security Engine

CrowdSec provides an official apt/yum repository. Add it and install:

# Add the CrowdSec repository
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
 
# Install the Security Engine
sudo apt update && sudo apt install -y crowdsec
 
# Confirm the service is running
sudo systemctl status crowdsec

On RHEL/Rocky/AlmaLinux:

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash
sudo dnf install -y crowdsec
sudo systemctl enable --now crowdsec

Verify the engine is healthy and has detected your running services:

sudo cscli machines list
sudo cscli collections list

CrowdSec auto-detects common services (Nginx, SSH, Apache) during installation and installs matching collections — bundles of parsers and scenarios. You should see crowdsecurity/linux and crowdsecurity/sshd at minimum.

Step 2 — Review and Tune Acquired Collections

Collections are the core detection logic. Each collection contains parsers (which extract fields from log lines) and scenarios (which identify attack patterns).

# List all installed scenarios
sudo cscli scenarios list
 
# List all installed parsers
sudo cscli parsers list
 
# Browse the Hub for additional collections
sudo cscli hub list

Install collections for any additional services you run:

# Nginx web server
sudo cscli collections install crowdsecurity/nginx
 
# Apache
sudo cscli collections install crowdsecurity/apache2
 
# WordPress brute force / scanning
sudo cscli collections install crowdsecurity/wordpress
 
# MySQL/MariaDB
sudo cscli collections install crowdsecurity/mysql
 
# Postfix mail server
sudo cscli collections install crowdsecurity/postfix
 
# Reload after installing new collections
sudo systemctl reload crowdsec

After adding collections, confirm CrowdSec is successfully parsing the relevant log files:

# Show acquisition configuration (which log files CrowdSec reads)
sudo cscli metrics show acquisition
 
# Check for parser errors
sudo cscli metrics show parsers

If a log file is not being read, add it to /etc/crowdsec/acquis.yaml:

# /etc/crowdsec/acquis.yaml — append entries for custom log paths
---
filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx
---
filenames:
  - /var/log/auth.log
labels:
  type: syslog

Reload after editing:

sudo systemctl reload crowdsec

Step 3 — Install the Firewall Bouncer

Detecting attacks is only half the picture — you need a bouncer to enforce blocks. The cs-firewall-bouncer integrates with iptables or nftables and automatically bans IPs that CrowdSec flags.

sudo apt install -y crowdsec-firewall-bouncer-iptables
# OR for nftables:
sudo apt install -y crowdsec-firewall-bouncer-nftables

During installation an API key is automatically generated and written to /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Verify the bouncer is registered:

sudo cscli bouncers list

You should see crowdsec-firewall-bouncer listed with a green status. Confirm active iptables chains:

sudo iptables -L crowdsec-blacklists -n --line-numbers
# OR for nftables:
sudo nft list table crowdsec

The bouncer creates dedicated chains so it never interferes with your existing firewall rules.

Step 4 — Configure the Community Blocklist

The Community Blocklist is a free, continuously updated feed of malicious IPs aggregated from all CrowdSec participants worldwide. It is pulled automatically once you connect your engine to the CrowdSec Central API (CAPI).

Check your CAPI enrollment status:

sudo cscli capi status

If it returns not enrolled, register:

sudo cscli capi register
sudo systemctl restart crowdsec

Once enrolled, the engine pulls the Community Blocklist every 2 hours. Confirm the decisions (active blocks) are flowing in:

# Show all active decisions (local + community)
sudo cscli decisions list
 
# Show only decisions sourced from the community blocklist
sudo cscli decisions list --origin CAPI

You should see hundreds to thousands of IPs from the community feed within a few hours of enrollment.

Step 5 — Enroll in the CrowdSec Console

The CrowdSec Console provides a web UI for fleet management, alert visibility, and blocklist subscriptions. It is free for up to three machines.

1. Create an account at https://console.crowdsec.net
2. Navigate to Security Engines → Add and copy your enrollment key
3. Run the enrollment command on your server:

sudo cscli console enroll <YOUR_ENROLLMENT_KEY>
sudo systemctl restart crowdsec

4. Return to the Console and accept the pending enrollment.

From the Console you can:

• View real-time alerts and decision history
• Subscribe to premium blocklists (Firehol, cybercrime trackers, Tor exit nodes, etc.)
• Manage multiple servers from a single pane
• Configure CTI API lookups for enriched threat context

Step 6 — Simulate and Test Detections

Test that the full detection-to-ban pipeline is working before relying on it in production.

Test SSH brute-force detection

# From a separate test machine (NOT your server), attempt multiple bad logins
for i in {1..10}; do ssh baduser@<your-server-ip> 2>/dev/null; done

Back on the server, watch alerts appear in real time:

sudo cscli alerts list --limit 10

Manually add a test IP decision

# Ban a test IP for 5 minutes
sudo cscli decisions add --ip 192.0.2.1 --duration 5m --reason "manual-test"
 
# Confirm it appears in iptables
sudo iptables -L crowdsec-blacklists -n | grep 192.0.2.1
 
# Remove it
sudo cscli decisions delete --ip 192.0.2.1

Run the CrowdSec detection wizard (optional)

sudo cscli setup detect

This wizard scans your services and recommends additional collections you may have missed.

Step 7 — Tune Allowlists and Notification Profiles

Allowlist legitimate IPs

Prevent false positives by allowlisting your own monitoring systems, office IPs, or known scanners:

# /etc/crowdsec/parsers/s02-enrich/mywhitelist.yaml
name: crowdsecurity/whitelists
description: "Allowlist trusted IPs"
whitelist:
  reason: "Internal or trusted source"
  ip:
    - "10.0.0.0/8"
    - "192.168.0.0/16"
    - "YOUR.OFFICE.IP.HERE"

sudo systemctl reload crowdsec
 
# Confirm whitelist is active
sudo cscli parsers list | grep whitelist

Configure notification profiles

CrowdSec can send alerts to Slack, email, PagerDuty, Splunk, and more via notification plugins:

# Install the Slack notification plugin
sudo apt install -y crowdsec-notification-slack

Edit /etc/crowdsec/notifications/slack.yaml with your webhook URL, then add a profile in /etc/crowdsec/profiles.yaml:

- name: default_ip_remediation
  filters:
    - Alert.Remediation == true && Alert.GetScope() == "Ip"
  decisions:
    - type: ban
      duration: 4h
  notifications:
    - slack_default
  on_success: break

sudo systemctl reload crowdsec

Verification

Run through this checklist to confirm everything is working end-to-end:

# 1. Engine is running and healthy
sudo systemctl is-active crowdsec
 
# 2. Bouncers are connected
sudo cscli bouncers list
 
# 3. CAPI is enrolled and syncing
sudo cscli capi status
 
# 4. Community decisions are being received
sudo cscli decisions list --origin CAPI | head -20
 
# 5. iptables chain has active bans
sudo iptables -L crowdsec-blacklists -n | wc -l
 
# 6. Recent local alerts
sudo cscli alerts list --limit 5
 
# 7. Log tail for any errors
sudo journalctl -u crowdsec -n 50 --no-pager

A healthy deployment shows: active service, at least one bouncer connected, CAPI enrolled, community decisions present in iptables, and no critical errors in the journal.

Troubleshooting

Bouncer shows "offline" in cscli bouncers list

The bouncer's API key may have been regenerated. Re-register:

sudo cscli bouncers delete crowdsec-firewall-bouncer
sudo cscli bouncers add crowdsec-firewall-bouncer
# Copy the generated key into /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
sudo systemctl restart crowdsec-firewall-bouncer

No decisions from CAPI after 24 hours

Check your outbound connectivity to api.crowdsec.net:443. Corporate firewalls often block unknown HTTPS endpoints:

curl -v https://api.crowdsec.net/v2/ping 2>&1 | tail -20

Also confirm CAPI registration completed:

sudo cat /etc/machine-id
sudo cscli capi status

Parser errors — log lines not matching

Enable verbose logging temporarily to diagnose parser failures:

# In /etc/crowdsec/config.yaml, set:
#   log_level: debug
sudo systemctl restart crowdsec
sudo journalctl -u crowdsec -f | grep -i "error\|warn\|skip"

Use cscli explain to test a specific log line against your parsers:

echo '2026-05-04T10:00:00Z server sshd[1234]: Failed password for invalid user admin from 1.2.3.4 port 54321 ssh2' \
  | sudo cscli explain --type syslog --log -

Firewall bouncer not blocking despite active decisions

Ensure the iptables chains exist and your INPUT chain references them:

sudo iptables -L INPUT -n | grep crowdsec
# Should show: -j crowdsec-blacklists

If missing, restart the bouncer:

sudo systemctl restart crowdsec-firewall-bouncer

On systems using ufw, make sure raw iptables rules survive ufw resets by adding the crowdsec rules in /etc/ufw/before.rules.

Summary

You now have a fully operational CrowdSec deployment that:

• Parses logs from SSH, Nginx, and any other configured services using behavioral scenarios
• Blocks attacking IPs at the kernel firewall level via cs-firewall-bouncer
• Shares anonymized attacker IPs with the global CrowdSec community
• Receives the Community Blocklist — blocking IPs that are attacking other servers worldwide
• Reports to the CrowdSec Console for centralized visibility and fleet management

CrowdSec's biggest advantage over traditional tools like Fail2ban is the network effect: every node strengthens every other node. As your server detects new attackers it contributes to a blocklist protecting millions of servers simultaneously. Combined with premium blocklist subscriptions from the Console (Firehol, Tor exits, cybercrime trackers), CrowdSec can dramatically reduce your attack surface with near-zero false positive rates.

Next steps to consider: deploying the CrowdSec Helm chart for Kubernetes clusters, integrating with a SIEM via the crowdsec-notification-http plugin, or enabling the AppSec Component (WAF mode) for Layer 7 HTTP protection.