OPNsense CrowdSec: Community Blocklist Against Bots and Bruteforce

Anyone who watches the WAN logs of a production OPNsense firewall for a day sees the same pattern found on any other network with a public IP: a constant background noise of bots knocking on SSH ports, Shodan scanners looking for forgotten services, and brute-force campaigns against VPN portals, RDP gateways and web applications. Static IP blocklists help — but they always arrive late, because they only react once an IP has already caused damage elsewhere and has been reported often enough.

CrowdSec reverses this principle: the agent analyses your own firewall logs in real time, detects attack patterns using behaviour-based rules — so-called scenarios — and shares the aggregated signals anonymously with a community of tens of thousands of operators. The result is a dynamic, behaviour-based blocklist that often exposes new attackers worldwide within minutes of their first appearance. The OPNsense plugin os-crowdsec integrates all of this cleanly into your existing firewall.

Why Static Blocklists Alone Are No Longer Enough

Classic IP blocklists like Spamhaus DROP, FireHOL Level 1 or AbuseIPDB are valuable but have three structural weaknesses. First, they are reactive: an IP only appears on a list once enough observers have reported the same address — for short-lived botnet nodes the usage window is often over before the list catches up. Second, they lack context: a dynamic consumer IP that was abused three weeks ago may be completely inconspicuous today. Third, they scale poorly against distributed campaigns where each IP only fires a handful of requests per target.

CrowdSec adds two capabilities that classic blocklists structurally cannot provide: local behaviour analysis of your own logs, and community signals in near real time.

What Makes CrowdSec Different

CrowdSec consists of four components that you need to keep apart during setup:

• Agent — Reads local log sources (OPNsense filter, Suricata, Nginx, sshd) and applies scenarios
• Local API (LAPI) — Central database of local decisions, sqlite or PostgreSQL
• Hub — Repository of parsers, scenarios and collections for different services
• Bouncer — Enforcement component that actually applies the decisions (firewall rules, HTTP 403, captcha)

The key difference to Fail2ban: CrowdSec performs detection in the agent, reports the decision to the LAPI and leaves the actual blocking to a separate bouncer. As a result, the same alert can block locally and, at the same time, be reported anonymously to the central CrowdSec console, where it feeds into the community blocklist (CAPI, “Central API”).

Installing the os-crowdsec Plugin

On a current OPNsense release (as of 2026: 25.7 “Ultimate Unicorn”) you install the plugin under System → Firmware → Plugins:

Plugin:  os-crowdsec
Version: 1.6.x (current release from the community repository)

After installation, four tabs appear under Services → CrowdSec: General, Bouncers, Alerts and Decisions. The local agent runs as its own service on the firewall, the LAPI database lives by default under /var/db/crowdsec/.

Enrolling in the CrowdSec Console

You link the instance to the free CrowdSec console with an enrollment token generated on app.crowdsec.net:

configctl crowdsec console enroll <TOKEN>
configctl crowdsec reload

Without enrollment, local detection continues to work without restriction — but you get neither the community blocklist nor the central view across alerts from multiple sites.

Enabling Scenarios and Collections

Scenarios are YAML definitions describing attack patterns — for example “more than five failed SSH logins within one minute from the same IP”. Collections bundle matching parsers and scenarios for a specific service.

For OPNsense the following collections have proven useful in production:

Collection	Typical Use Case
crowdsecurity/sshd	Bruteforce against SSH access
crowdsecurity/http-cve	Known CVE exploitation against web applications
crowdsecurity/nginx	Web scanners, path traversal, excessive 4xx errors
crowdsecurity/opnsense	Firewall log parser for OPNsense-native events
crowdsecurity/suricata	Consumption of Suricata alerts as CrowdSec signals
crowdsecurity/base-http-scenarios	Generic HTTP attack patterns

Installation from the hub works via command line or web interface:

cscli collections install crowdsecurity/sshd
cscli collections install crowdsecurity/suricata
cscli collections list

After each change: cscli hub upgrade and reload the agent. Check active alerts with cscli alerts list, current decisions with cscli decisions list.

Integration with Suricata Alerts

CrowdSec becomes especially powerful when you couple it with an existing Suricata deployment. In many of our OPNsense setups Suricata already runs in IDS mode and produces high-quality alerts that would otherwise rot in the log without any automation. The crowdsecurity/suricata parser reads Suricata’s EVE logs and converts each relevant alert into a CrowdSec decision — including expiry and forwarding to the CAPI.

This is configured in /usr/local/etc/crowdsec/acquis.yaml:

filenames:
  - /var/log/suricata/eve.json
labels:
  type: suricata-evelogs

A reload activates the new log source. From that point on, Suricata detections flow into the same decision logic as firewall and SSH events — and are immediately blocked at the WAN level via the firewall bouncer instead of only being alerted on.

Community Blocklist vs. Static Blocklists

The firewall bouncer (crowdsec-firewall-bouncer) on OPNsense pulls both the locally issued decisions and the community blocklist from the CAPI and writes both into the same pf table. They therefore take effect before any other firewall rule — practically identical to classic blocklists, but with a significantly different update frequency and source base.

A comparison we frequently use in customer conversations:

Criterion	Static Blocklist	CrowdSec Community Blocklist
Update frequency	Hours to days	A few minutes
Source	Curated operators	Aggregated signals from tens of thousands of instances
Context per IP	Usually none	Scenario, timestamp, attack type
Local behaviour analysis	No	Yes, via scenarios
Automatic expiry	Rare	Standard: 4 hours to 30 days per scenario
Effort for own reporting	Manual	Automatic while running the agent

The two approaches are not mutually exclusive — on the contrary. What we run on our customers’ firewalls in practice: Spamhaus DROP and FireHOL Level 1 as a static baseline for long-lived “known bad” networks, CrowdSec as a reactive layer for fresh brute-force and scanner IPs.

Retention, Data Protection and Operational Aspects

Because CrowdSec exchanges signals with a central service, a data-protection assessment must be part of the rollout. What gets shared is precisely documented: the attacking source IP, the triggered scenario, a timestamp and the decision made by the agent. What is not transmitted are destination IPs, payloads, usernames or content from the log lines. This keeps the shared data comparatively unproblematic from a GDPR perspective, because it is limited to the attacker’s IP and the type of attack.

Two values matter for internal retention:

• Decision Duration — How long does a locally issued block last? Default depending on scenario 4 h to 24 h, often longer for Suricata alerts.
• LAPI history — How long do alerts stay in the local sqlite/PostgreSQL database? Reasonable: 30 to 90 days, then purge via cron.

If you want to avoid the community connection entirely for regulatory reasons, CrowdSec can run fully local — but then you give up the community blocklist and rely solely on your own behaviour analysis. In heavily regulated environments we often combine this with structured log storage on a Linux log host and a separate backup strategy for the alert history.

Conclusion

CrowdSec replaces neither Suricata nor a clean firewall policy — but it closes the gap between “alert in the log” and “attacker blocked”. On OPNsense, the os-crowdsec plugin integrates local detection, bouncer and community blocklist into a configuration that can be operated with reasonable effort and, in daily operation, noticeably keeps attack volume away from your services. Anyone already running Suricata extracts significant additional value from existing alerts through CrowdSec, without spinning up another SIEM.

DATAZONE supports you in planning, rolling out and hardening CrowdSec on your OPNsense firewall — including selecting suitable scenarios, Suricata integration, bouncer configuration and GDPR-compliant operational documentation. Get in touch if you want to harden your OPNsense environment with CrowdSec.