OPNsense CrowdSec: Community-Blocklist gegen Bots und Bruteforce

Wer die WAN-Logs einer produktiven OPNsense-Firewall einen Tag lang beobachtet, sieht dasselbe Muster wie in jedem anderen Netz mit öffentlicher IP: dauerhaftes Grundrauschen aus Bots, die SSH-Ports abklopfen, Shodan-Scanner, die nach vergessenen Diensten suchen, und Bruteforce-Kampagnen gegen VPN-Portale, RDP-Gateways und Webanwendungen. Statische IP-Blocklisten helfen — sie kommen aber immer zu spät, weil sie erst reagieren, wenn eine IP anderswo bereits Schaden angerichtet hat und ausreichend gemeldet wurde.

CrowdSec dreht dieses Prinzip um: Der Agent analysiert die Logs Ihrer eigenen Firewall in Echtzeit, erkennt Angriffsmuster anhand von Verhaltensregeln — sogenannten Szenarien — und teilt die aggregierten Signale anonymisiert mit einer Community aus zehntausenden Betreibern. Das Ergebnis ist eine dynamische, verhaltensbasierte Blocklist, die neue Angreifer oft innerhalb weniger Minuten nach ihrem ersten Auftauchen weltweit sichtbar macht. Über das OPNsense-Plugin os-crowdsec lässt sich das Ganze sauber in die bestehende Firewall integrieren.

Warum statische Blocklisten allein nicht mehr reichen

Klassische IP-Blocklisten wie Spamhaus DROP, FireHOL Level 1 oder AbuseIPDB sind wertvoll, haben aber drei strukturelle Schwächen. Erstens sind sie reaktiv: Eine IP taucht erst dann auf einer Liste auf, wenn genügend Beobachter dieselbe Adresse gemeldet haben — bei kurzlebigen Botnetz-Nodes ist die Nutzungsdauer oft schon vorbei, bevor die Liste greift. Zweitens sind sie kontextfrei: Eine dynamische Consumer-IP, die vor drei Wochen missbraucht wurde, kann heute völlig unauffällig sein. Drittens skalieren sie schlecht gegen verteilte Kampagnen, bei denen jede IP nur wenige Requests pro Ziel fährt.

CrowdSec ergänzt statische Listen um zwei Fähigkeiten, die klassische Blocklisten strukturell nicht liefern können: lokale Verhaltensanalyse Ihrer eigenen Logs und Community-Signale nahezu in Echtzeit.

Was CrowdSec anders macht

CrowdSec besteht aus vier Komponenten, die man beim Setup auseinanderhalten muss:

• Agent — Liest lokale Logquellen (OPNsense-Filter, Suricata, Nginx, sshd) und wendet Szenarien an
• Local API (LAPI) — Zentrale Datenbank der lokal getroffenen Entscheidungen, sqlite oder PostgreSQL
• Hub — Repository mit Parsern, Szenarien und Collections für unterschiedliche Dienste
• Bouncer — Durchsetzende Komponente, die die Entscheidungen tatsächlich anwendet (Firewall-Regeln, HTTP-403, Captcha)

Der entscheidende Unterschied zu Fail2ban: CrowdSec trifft die Erkennung im Agenten, meldet die Entscheidung an die LAPI und lässt die Blockade durch einen separaten Bouncer erfolgen. Dadurch kann derselbe Alert gleichzeitig lokal blocken und anonymisiert an die zentrale CrowdSec-Konsole gemeldet werden, wo er in die Community-Blocklist (CAPI, „Central API”) einfließt.

Installation des os-crowdsec-Plugins

Auf einer aktuellen OPNsense (Stand 2026: 25.7 „Ultimate Unicorn”) installieren Sie das Plugin über System → Firmware → Plugins:

Plugin:  os-crowdsec
Version: 1.6.x (aktueller Stand aus dem Community-Repository)

Nach der Installation stehen unter Services → CrowdSec vier Reiter zur Verfügung: General, Bouncers, Alerts und Decisions. Der lokale Agent läuft als eigener Dienst auf der Firewall, die LAPI-Datenbank liegt standardmäßig unter /var/db/crowdsec/.

Enrollment in die CrowdSec-Konsole

Die Anbindung an die kostenlose CrowdSec-Konsole aktiviert Sie mit einem Enrollment-Token, das Sie auf app.crowdsec.net erzeugen:

configctl crowdsec console enroll <TOKEN>
configctl crowdsec reload

Ohne Enrollment funktioniert die lokale Erkennung uneingeschränkt — Sie erhalten aber weder die Community-Blocklist noch die zentrale Sicht auf Alerts über mehrere Standorte hinweg.

Szenarien und Collections aktivieren

Szenarien sind YAML-Definitionen, die Angriffsmuster beschreiben — etwa „mehr als fünf fehlgeschlagene SSH-Logins innerhalb einer Minute von derselben IP”. Collections bündeln passende Parser und Szenarien für einen Dienst.

Für OPNsense empfehlen sich in der Praxis folgende Collections:

Collection	Typischer Anwendungsfall
crowdsecurity/sshd	Bruteforce gegen SSH-Zugänge
crowdsecurity/http-cve	Bekannte CVE-Ausnutzungen gegen Webanwendungen
crowdsecurity/nginx	Web-Scanner, Path-Traversal, exzessive 4xx-Fehler
crowdsecurity/opnsense	Firewall-Log-Parser für OPNsense-eigene Ereignisse
crowdsecurity/suricata	Übernahme von Suricata-Alerts als CrowdSec-Signale
crowdsecurity/base-http-scenarios	Generische HTTP-Angriffsmuster

Installation aus dem Hub geht per Kommandozeile oder Webinterface:

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

Nach jeder Änderung: cscli hub upgrade und Agent-Reload. Aktive Alerts prüfen Sie mit cscli alerts list, aktuelle Entscheidungen mit cscli decisions list.

Integration mit Suricata-Alerts

Besonders wirkungsvoll wird CrowdSec, wenn Sie es mit einer bestehenden Suricata-Installation koppeln. In vielen unserer OPNsense-Setups läuft Suricata bereits im IDS-Modus und erzeugt hochwertige Alerts, die aber ohne Automation nur im Log versauern. Der crowdsecurity/suricata-Parser liest die Suricata-EVE-Logs und überführt jeden relevanten Alert in eine CrowdSec-Entscheidung — inklusive Sperrfrist und Weiterleitung an die CAPI.

Konfiguriert wird das in /usr/local/etc/crowdsec/acquis.yaml:

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

Ein Reload aktiviert die neue Log-Quelle. Ab jetzt fließen Suricata-Erkennungen ohne Umweg in dieselbe Entscheidungslogik wie Firewall- und SSH-Ereignisse — und werden über den Firewall-Bouncer sofort auf WAN-Ebene blockiert, statt nur alarmiert zu werden.

Community-Blocklist vs. statische Blocklisten

Der Firewall-Bouncer (crowdsec-firewall-bouncer) auf OPNsense zieht sich sowohl die lokal ausgesprochenen Entscheidungen als auch die Community-Blocklist von der CAPI und trägt beide in dieselbe pf-Table ein. Damit greifen sie vor jeder anderen Firewall-Regel — praktisch identisch zu klassischen Blocklisten, aber mit deutlich anderer Update-Frequenz und Quellenlage.

Eine Gegenüberstellung, die wir in Kundengesprächen häufig verwenden:

Kriterium	Statische Blocklist	CrowdSec Community-Blocklist
Update-Frequenz	Stunden bis Tage	Wenige Minuten
Quelle	Kuratierte Betreiber	Aggregierte Signale von zehntausenden Instanzen
Kontext pro IP	Meist keiner	Szenario, Zeitstempel, Angriffstyp
Lokale Verhaltensanalyse	Nein	Ja, über Szenarien
Automatischer Ablauf	Selten	Standard: 4 Stunden bis 30 Tage je Szenario
Aufwand für eigene Meldung	Manuell	Automatisch beim Betrieb des Agenten

Beide Ansätze schließen sich nicht aus — im Gegenteil. Die Praxis auf unseren Kunden-Firewalls: Spamhaus DROP und FireHOL Level 1 als statische Basis für langlebige „bekannt schlechte” Netze, CrowdSec als reaktive Schicht für frische Bruteforce- und Scanner-IPs.

Retention, Datenschutz und Betriebsaspekte

Da CrowdSec Signale mit einem zentralen Dienst austauscht, gehört die datenschutzrechtliche Bewertung zwingend zur Einführung. Was geteilt wird, ist genau dokumentiert: die angreifende Quell-IP, das ausgelöste Szenario, ein Zeitstempel und die vom Agenten getroffene Entscheidung. Nicht übertragen werden Ziel-IPs, Payloads, Nutzernamen oder Inhalte aus den Log-Zeilen. Damit bleiben die geteilten Daten aus DSGVO-Sicht vergleichsweise unproblematisch, weil sie sich auf die IP des Angreifers und die Art des Angriffs beschränken.

Für die interne Retention sind zwei Werte relevant:

• Decision Duration — Wie lange gilt eine lokal ausgesprochene Sperre? Standard je nach Szenario 4 h bis 24 h, für Suricata-Alerts oft länger.
• LAPI-Historie — Wie lange bleiben Alerts in der lokalen sqlite/PostgreSQL-Datenbank? Sinnvoll: 30 bis 90 Tage, danach purge per Cron.

Wer die Community-Anbindung aus regulatorischen Gründen komplett vermeiden will, kann CrowdSec vollständig lokal betreiben — verzichtet dann allerdings auf die Community-Blocklist und nutzt nur die eigene Verhaltensanalyse. In stark regulierten Umgebungen kombinieren wir das häufig mit strukturierter Log-Ablage auf einem Linux-Loghost und einer separaten Backup-Strategie für die Alert-Historie.

Fazit

CrowdSec ersetzt weder Suricata noch eine saubere Firewall-Policy — es schließt aber die Lücke zwischen „Alert im Log” und „Angreifer geblockt”. Auf OPNsense integriert das os-crowdsec-Plugin lokale Erkennung, Bouncer und Community-Blocklist in eine Konfiguration, die sich mit vertretbarem Aufwand betreiben lässt und im laufenden Betrieb spürbar Angriffsvolumen von den Diensten fernhält. Wer bereits Suricata betreibt, hebt mit CrowdSec zusätzlich einen erheblichen Wert aus den vorhandenen Alerts, ohne ein weiteres SIEM aufzuziehen.

DATAZONE unterstützt Sie bei der Planung, Einführung und Härtung von CrowdSec auf Ihrer OPNsense-Firewall — inklusive Auswahl passender Szenarien, Suricata-Integration, Bouncer-Konfiguration und einer datenschutzkonformen Betriebsdokumentation. Sprechen Sie uns an, wenn Sie Ihre OPNsense-Umgebung mit CrowdSec härten möchten.