Quick start: Deploy CrowdSec and Firewalld Bouncer in 5 Minutes
The moment you expose SSH port 22 to the Internet, even a low-end VPS endures 3,000 to 5,000 automated password-guessing attempts every day. Fail2ban has been the go-to tool for years. However, its single-threaded regex log parsing has shown clear performance bottlenecks. CrowdSec solves this fundamentally: it detects local attacks while proactively pre-empting tens of thousands of malicious IPs shared by the community.
Quick deployment steps on Fedora Server (requires root or sudo privileges):
Step 1: Add the official CrowdSec repository
# Install the official repository setup script from PackageCloud
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash
Step 2: Install the Security Engine and Firewall Bouncer
# Install the analysis engine and firewall remediation component
sudo dnf install -y crowdsec crowdsec-firewall-bouncer-iptables
Step 3: Start and enable services on boot
# Start the CrowdSec daemon
sudo systemctl enable --now crowdsec
# Start the Firewall Bouncer
sudo systemctl enable --now crowdsec-firewall-bouncer
Step 4: Verify connectivity
# View currently banned IPs
sudo cscli decisions list
# Verify the bouncer has successfully connected to the engine
sudo cscli bouncers list
When the Valid column shows true, the system has started parsing logs and is ready to push offending IPs into firewalld.
Operational Architecture: Decoupling Engine and Bouncer
Fedora Server defaults to firewalld backed by nftables. In the past, administrators running fail2ban on Fedora often ran into rule conflicts or bloated linear iptables chains. CrowdSec handles this far more elegantly thanks to its fully modular architecture.
1. Collaboration Mechanism Between Engine and Bouncer
Instead of combining log analysis and network filtering into a single monolithic process, CrowdSec splits responsibilities between two components:
- CrowdSec Engine: Dedicated to reading and dissecting logs. This background daemon consumes only about 60–80MB of RAM. It parses logs directly from
journald, Nginx, or SSH against predefined scenarios. Detect a client failing 5 password attempts in 10 seconds? The engine immediately issues a Decision (remediation action) with a ban duration, typically 4 hours. - Firewall Bouncer: Dedicated to enforcement. The bouncer periodically polls the Engine via Local API on port
8080(restricted to localhost). When a new decision arrives, it instantly injects the offending IP into thefirewalldblocklist. This happens in real time without restarting the firewall or disrupting existing active sessions.
2. Early Warning Network (Crowd-sourced Intelligence)
This is CrowdSec’s greatest advantage over traditional Fail2ban. Suppose a botnet probes a vulnerability on a Fedora server in Frankfurt. That IP address is instantly submitted to CrowdSec’s central platform, algorithmically verified to filter false positives. Within minutes, your server receives an updated blocklist. The moment the attacker reaches your network perimeter, their packets are dropped instantly—before they even reach your SSH or Nginx processes.
Optimized Configuration for Production Environments
1. Tune the Bouncer to Leverage firewalld ipset
Open the bouncer configuration file:
sudo nano /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
Verify that the parameters are properly set to firewalld mode:
mode: firewalld
blacklists_ipv4: crowdsec-blacklists
blacklists_ipv6: crowdsec6-blacklists
supported_actions:
- ban
In this mode, the bouncer creates an ipset named crowdsec-blacklists attached directly to the active zone. Thanks to the hash table mechanism with O(1) lookup complexity, even with 50,000 banned IPs, the server CPU remains practically idle with zero network throughput degradation.
Restart the bouncer to apply changes:
sudo systemctl restart crowdsec-firewall-bouncer
2. Enable Scenarios for Nginx Protection and Web Vulnerability Scanning
By default, CrowdSec only parses SSH logs after installation. If your server also runs Nginx or a reverse proxy, install the relevant scenarios from the CrowdSec Hub:
# Detect sensitive path scanning and Nginx web attacks
sudo cscli collections install crowdsecurity/nginx
# Block automated scanning tools like SQLmap and Nikto
sudo cscli collections install crowdsecurity/http-cve
# Reload engine configuration
sudo systemctl reload crowdsec
3. Centralized Management via CrowdSec Console
When managing three or more Fedora nodes, monitoring each server via the terminal becomes time-consuming. Register for a free account at app.crowdsec.net to aggregate all alerts onto an intuitive dashboard:
# Enroll the node into the dashboard using the web console token
sudo cscli console enroll <YOUR_ENROLL_KEY>
# Restart the engine to activate synchronization
sudo systemctl restart crowdsec
Production Best Practices and Tips
1. Configure Whitelists to Avoid Locking Yourself Out
The most frustrating scenario: opening multiple SSH tabs simultaneously via a script or using the wrong private key, locking yourself out for half a day. Add your office static IP or VPN subnet to the whitelist beforehand:
sudo nano /etc/crowdsec/parsers/s02-enrich/my-whitelist.yaml
Add the following content:
name: my/admin-whitelist
description: "Administrator IP whitelist"
filter: "true"
whitelist:
reason: "Admin static IP"
ip:
- "123.45.67.89" # Your static IP
cidr:
- "192.168.1.0/24" # Internal network range
- "10.8.0.0/24" # WireGuard or OpenVPN subnet
Reload the engine to update the allowlist:
sudo systemctl reload crowdsec
2. Quickly Unban an IP When a Teammate Gets Blocked
If a team member enters the wrong credentials and gets blocked, you can release the IP immediately:
# Unban a specific IP
sudo cscli decisions delete --ip 198.51.100.25
# Emergency case: delete all active bans
sudo cscli decisions delete --all
3. Inspect Operational Metrics with cscli metrics
Stop guessing whether the engine is processing logs correctly. Run:
sudo cscli metrics
The terminal will output detailed statistics: lines of logs read, successfully parsed events, and which scenarios were triggered most frequently over the past 24 hours. This provides the most accurate baseline for tuning thresholds without digging through raw logs.
