Securing a Linux Server: Part 3 — CrowdSec

Fail2ban protects each server individually: it only sees its own logs and doesn’t know that the same addresses attacked thousands of other machines a minute ago. CrowdSec solves the same problem — detect attacks from logs and block the address — but adds to the local analysis a shared list of attacking addresses collected by all its users.

CrowdSec is distributed under the MIT license. Current version — 1.8.1 (03.09.2026).

How CrowdSec is organized

The CrowdSec documentation uses the following concepts:

• Security Engine — the detection system itself. It consists of a log handler (Log Processor, often called the agent) and a Local API.
• Log Processor reads service logs and HTTP requests, parses them with parsers and matches them against scenarios — descriptions of malicious behavior: password guessing, scanning, searching for vulnerable paths on a site.
• Local API (LAPI) stores blocking decisions and distributes them to remediation components. Through it the Security Engine also exchanges data with the central CrowdSec API.
• Remediation Components (they are called bouncers) — separate programs that receive decisions from the LAPI and perform blocking: in the firewall, in the web server, in the reverse proxy.
• Collections — ready-made sets of parsers and scenarios for a specific service (SSH, Nginx, Postfix, etc.). They are stored in the Hub catalog.
• Console — web interface for viewing alerts and blocks from all connected servers.

An important detail explicitly stated in the documentation: the Security Engine by itself doesn’t block anything — it’s only a detection system. Without a remediation component CrowdSec will detect attacks but let attackers through.

Shared list of attackers

When your server detects an attack, it sends a signal — the address and the triggered scenario — to the central API. From the signals of thousands of CrowdSec installations the Community Blocklist is compiled and distributed to participants. The conditions depend on contribution level:

• those who regularly send signals receive the full list — up to 15,000 addresses, selected by scenarios that appear on your host;
• those who do not send signals receive a reduced version — up to 3,000 addresses;
• paid plans provide up to 60,000 addresses.

This way the server preemptively blocks addresses that have not yet attacked it specifically but have already been seen on other machines.

Installation on Debian and Ubuntu

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-nftables   # or -iptables

The first command adds the CrowdSec repository, the second installs the Security Engine, the third installs the remediation component for the firewall. During installation CrowdSec tries to detect running services and automatically installs appropriate parsers and scenarios. If some service is not detected, its log is added to the sources settings manually and the required collection is installed:

sudo cscli collections list
sudo cscli collections install crowdsecurity/nginx
sudo systemctl reload crowdsec

First commands

sudo cscli metrics                 # what is being read and what is triggering
sudo cscli alerts list             # detected attacks
sudo cscli decisions list          # active block decisions
sudo cscli decisions delete --ip 203.0.113.10   # remove block
sudo cscli console enroll <key>   # enroll server to Console

cscli metrics is the main diagnostic command: if it doesn’t show lines for the desired log, CrowdSec isn’t reading it and that service is not protected.

Whitelists

Before enabling blocking, add your addresses to the whitelist: office, monitoring servers, addresses used by administrators. The documentation specifically recommends this step — a false positive on your own monitoring will block it just like a bot.

How CrowdSec differs from Fail2ban

For a single server with SSH, Fail2ban is sufficient. CrowdSec makes sense when there are multiple servers, when you need to protect web applications by behavior rather than only by failed logins, and when you want to block known attackers before the first attempt.

Running Fail2ban and CrowdSec simultaneously for the same logs doesn’t make sense: they will duplicate blocks and it will become harder to figure out who blocked an address. Usually one is chosen.

Common mistakes

• Only the Security Engine is installed without a remediation component — attacks are visible in cscli alerts, but nothing is blocked.
• Own addresses and monitoring are not added to the whitelist.
• The service writes logs to a non-standard location, CrowdSec doesn’t read it, and the administrator assumes the service is protected. Check with cscli metrics.
• The remediation component is chosen for the wrong firewall (iptables instead of nftables).
• Collections are not updated: scenarios in the Hub are regularly extended — update with cscli hub update and cscli hub upgrade.

How to integrate CrowdSec into the overall protection setup of a new server is described in the article “A new server is not a blank slate”.