CrowdSec on Linux VPS – Next-Generation IDS to Replace Fail2ban

Fail2ban is the classic brute-force protection tool on Linux that almost every VPS administrator has used. But after more than 15 years, attack patterns have completely changed. Attackers no longer use a single IP to brute force passwords – they use thousands of IPs from distributed botnets around the world. Fail2ban can only detect after that IP has already attacked your server. CrowdSec solves this problem by sharing threat intelligence across the community – an IP attacking another server will be blocked on your server before it even knocks on your door.

In this tutorial, I will guide you through installing and configuring CrowdSec on Linux VPS (Ubuntu and AlmaLinux), from architecture overview to daily administration commands.

Why CrowdSec Can Replace Fail2ban?

Fail2ban works with a simple model: read logs, find suspicious patterns, ban IPs. Each server fights its own battle. CrowdSec also analyzes logs similarly, but adds an important layer: crowd-sourced threat intelligence.

When CrowdSec on server A detects a bad IP, that information is sent to the central hub and shared with the entire community. Server B receives updated blocklists without needing to wait for an attack first. It’s like a community immune system – when one person discovers a virus, the whole group gets vaccinated.

Additionally, CrowdSec is written in Go so it processes logs significantly faster than Fail2ban (Python). The API-first architecture allows flexible integration – you can manage through REST API instead of SSHing into servers to manually edit configs.

CrowdSec Architecture

CrowdSec consists of 3 main components:

• Agent (Security Engine): reads logs, analyzes according to predefined scenarios, detects anomalous behavior. This is the “brain” that detects attacks.
• LAPI (Local API): stores alerts and decisions. Agent sends alerts to LAPI, LAPI decides whether to ban or not and stores it. LAPI also syncs with CrowdSec’s Central API to receive community blocklists.
• Bouncer: enforces blocking decisions. Bouncer connects to LAPI, retrieves the list of banned IPs and applies them to firewall, nginx, or any blocking point. One LAPI can serve multiple different bouncers.

Flow: Log → Agent analyzes → Alert sent to LAPI → LAPI creates Decision → Bouncer gets Decision → Block IP at firewall.

Furthermore, CrowdSec provides community blocklists. When you enroll in CrowdSec console, your server will receive lists of IPs reported by the community. You also contribute back when your server detects new bad IPs. This entire sharing process only sends IP + attack type, no logs or sensitive data.

Installing CrowdSec

CrowdSec supports both Debian/Ubuntu and RHEL/AlmaLinux. Installation is quite simple via package manager.

Ubuntu / Debian

Add CrowdSec repository then install:

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

AlmaLinux / Rocky Linux

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

After installation, CrowdSec automatically runs as systemd service:

sudo systemctl status crowdsec

CrowdSec will auto-detect running services on the server (SSH, nginx, Apache…) and install corresponding collections. You can check with this command:

sudo cscli collections list

Installing Bouncer

CrowdSec Agent only detects, it doesn’t block. To actually block IPs, you need to install a bouncer. The most common bouncer is crowdsec-firewall-bouncer-iptables, which operates at the firewall layer.

Ubuntu / Debian

sudo apt install crowdsec-firewall-bouncer-iptables

AlmaLinux / Rocky Linux

sudo dnf install crowdsec-firewall-bouncer-iptables

After installation, the bouncer automatically registers with LAPI and starts pulling decisions. Check status:

sudo cscli bouncers list

The result will show the connected bouncer with the latest pull time. If you see the bouncer in the list with validated status, everything is working.

If the server uses nftables instead of iptables, install crowdsec-firewall-bouncer-nftables instead. On Ubuntu 22.04+ and AlmaLinux 9+, nftables is the default so you should check first with iptables --version command to see which backend is being used.

Configuring acquis.yaml

The file /etc/crowdsec/acquis.yaml (or files in /etc/crowdsec/acquis.d/) is where you declare log sources for CrowdSec to read. Each entry consists of log path and label indicating the log type.

CrowdSec automatically creates default configuration during installation, but you should check and add if needed. Here are common log sources:

SSH log

filenames:
  - /var/log/auth.log        # Ubuntu/Debian
  - /var/log/secure           # AlmaLinux/Rocky
labels:
  type: syslog

Nginx access log

filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx

General syslog

filenames:
  - /var/log/syslog            # Ubuntu/Debian
  - /var/log/messages          # AlmaLinux/Rocky
labels:
  type: syslog

After editing acquis.yaml, restart CrowdSec to apply:

sudo systemctl restart crowdsec

In newer CrowdSec versions, you can separate each log source into individual files in the /etc/crowdsec/acquis.d/ directory. For example: ssh.yaml, nginx.yaml. This approach is easier to manage when the server runs multiple services.

Installing Collections from Hub

Collections are pre-packaged rule sets for each service. CrowdSec Hub provides hundreds of collections contributed by the community. Important collections for VPS:

# Collection for SSH - detects brute force, password spray
sudo cscli collections install crowdsecurity/sshd
# Collection for Nginx - detects scans, exploits, bad user-agents
sudo cscli collections install crowdsecurity/nginx
# Comprehensive collection for Linux - includes many basic parsers and scenarios
sudo cscli collections install crowdsecurity/linux

View installed collections:

sudo cscli collections list

To explore more, use this command to see the entire hub (parsers, scenarios, collections, postoverflows):

sudo cscli hub list

After installing additional collections, restart CrowdSec:

sudo cscli hub update
sudo systemctl restart crowdsec

Common Administration Commands

Here are commands you’ll use daily to monitor CrowdSec:

View banned IP list

sudo cscli decisions list

This command displays all currently blocked IPs, with reason (which scenario triggered), ban time, and source (local or community blocklist).

View recent alerts

sudo cscli alerts list

Alerts are detection events, may or may not include decisions (bans). Useful when you want to see who is probing the server without being banned yet.

View overall metrics

sudo cscli metrics

Shows number of log lines parsed, alerts triggered, bucket overflows, etc. Very useful to check if CrowdSec is reading log files correctly.

Manual ban or unban IP

# Ban 1 IP for 24 hours
sudo cscli decisions add --ip 1.2.3.4 --duration 24h --reason "manual ban"
# Ban entire subnet
sudo cscli decisions add --range 1.2.3.0/24 --duration 24h --reason "subnet ban"
# Remove ban for 1 IP
sudo cscli decisions delete --ip 1.2.3.4

Whitelist IP

If your IP gets banned by mistake (e.g., entering wrong SSH password several times), you can quickly unban with the command:

sudo cscli decisions delete --ip YOUR_IP

However, it might get banned again next time. To whitelist permanently, create a whitelist file in CrowdSec:

sudo nano /etc/crowdsec/parsers/s02-enrich/my-whitelists.yaml

File content:

name: my-whitelists
description: "Whitelist trusted IPs"
whitelist:
  reason: "trusted IP"
  ip:
    - "YOUR_IP"
    - "YOUR_OFFICE_IP"
  cidr:
    - "10.0.0.0/8"

Restart CrowdSec after adding whitelist:

sudo systemctl restart crowdsec

Always whitelist your management IP. Nothing is more frustrating than locking yourself out of the server because CrowdSec mistakenly banned your IP.

CrowdSec Console

CrowdSec provides a free web dashboard at app.crowdsec.net. From here you can view alerts, decisions, and manage multiple servers simultaneously with a visual interface.

To connect your server to the console, register an account at app.crowdsec.net, then get the enrollment key and run on the server:

sudo cscli console enroll YOUR_ENROLLMENT_KEY

After enrollment, go to the web console to accept the new server. From here you will see:

• Real-time alerts list
• Attack IP map (geo view)
• Manage subscribed blocklists
• Monitor multiple servers from 1 dashboard

Console is free for community tier, sufficient for most personal VPS and small businesses. Paid version adds premium blocklists and advanced management features.

CrowdSec vs Fail2ban Comparison

Criteria	Fail2ban	CrowdSec
Language	Python	Go
Log parsing performance	Slow with large logs	Fast, handles millions of log lines well
Threat intelligence	None, each server handles itself	Community blocklists, shared bad IPs
Architecture	Monolithic (1 process)	Modular (Agent + LAPI + Bouncer)
API	No REST API	Full REST API
Dashboard	None (CLI only)	Free web console
Configuration	Regex-based filters	YAML scenarios + parsers
Container support	Limited	Official Docker image
Multi-server	Each server configured separately	1 LAPI manages multiple agents + bouncers
Community	Mature, stable	Rapidly developing, rich hub
Cost	Completely free	Free (community), paid for premium blocklists

Keep Fail2ban Parallel or Migrate Completely?

Short answer: you can run both in parallel without conflicts. CrowdSec and Fail2ban operate independently, both reading logs but enforcing bans through different iptables chains.

Migration strategy I recommend:

1. Phase 1: Parallel (1-2 weeks). Install CrowdSec + bouncer, keep Fail2ban running normally. Monitor if CrowdSec detects correctly using cscli decisions list and cscli metrics.
2. Phase 2: Fail2ban passive. Change Fail2ban action to action = %(action_)s (log only, no ban). Let CrowdSec handle blocking. Compare logs from both sides to see if anything is missed.
3. Phase 3: Disable Fail2ban. After trusting CrowdSec operates stably, disable Fail2ban. Keep the package for quick rollback if needed.

# When ready to disable Fail2ban
sudo systemctl stop fail2ban
sudo systemctl disable fail2ban

If you have custom Fail2ban jails for specific services that CrowdSec doesn’t have scenarios for yet, keep Fail2ban for those specific services. No need for all-or-nothing approach.

Checkpoint: Test CrowdSec Operation

After installing CrowdSec and bouncer, you should verify everything works correctly before confidently leaving it there.

Step 1: Check services

sudo systemctl status crowdsec
sudo systemctl status crowdsec-firewall-bouncer

Both services must be in active (running) state.

Step 2: Check metrics

sudo cscli metrics

Look at the “Acquisition Metrics” section. If CrowdSec is reading logs correctly, you’ll see the number of parsed lines increasing. If everything is 0, check acquis.yaml again.

Step 3: Test SSH password probing

From another machine (or use a second VPS), try SSH with wrong passwords repeatedly:

# Run from TEST machine, not the main server
for i in $(seq 1 10); do ssh fakeuser@YOUR_SERVER_IP; done

After several attempts, return to the main server and check:

sudo cscli decisions list

If the test IP appears in the decisions list with reason crowdsecurity/ssh-bf, CrowdSec is working correctly. The bouncer will automatically block that IP at the firewall layer.

Step 4: View alert details

sudo cscli alerts list
sudo cscli alerts inspect -d ALERT_ID

Inspecting alerts will show you details: which IP, which scenario triggered, which log lines matched, ban duration.

Step 5: Clean up after testing

Unban the test IP to avoid mistaken lockouts:

sudo cscli decisions delete --ip TEST_IP

Don’t test password probing from the same IP you’re SSHing to the server. If CrowdSec bans that IP, you’ll lose connection immediately. Always test from a different IP or whitelist your management IP before testing.

---

CrowdSec isn’t a silver bullet, but it solves Fail2ban’s biggest weakness: each server having to detect attacks from scratch. With a rapidly growing community and modern architecture, CrowdSec is a logical step forward for anyone managing Linux VPS.