OPNsense - CrowdSec
Auf einen Blick
| Gilt für | OPNsense 26.1/26.7 mit Plugin os-crowdsec 1.0.12 (CrowdSec 1.8, Firewall-Bouncer 0.0.38) |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 20 Minuten (Grundeinrichtung), Anbindung weiterer Server je ca. 10 Minuten |
| Rechte | Administrator (OPNsense-WebUI), Shell-Zugang für cscli |
| Stand | Oktober 2026 |
CrowdSec ist ein Open-Source-Sicherheitssystem (MIT-Lizenz), das Angriffe anhand von Logdateien erkennt und die angreifenden IP-Adressen sperrt – ähnlich wie Fail2ban, aber mit einem entscheidenden Unterschied: Erkannte Angreifer werden anonymisiert mit der weltweiten CrowdSec-Community geteilt, und im Gegenzug erhält jede Installation eine Community-Blocklist mit IP-Adressen, die gerade an vielen anderen Stellen angreifen. Mit dem Plugin os-crowdsec läuft CrowdSec direkt auf der OPNsense: Es erkennt Port-Scans und Brute-Force-Versuche auf die Firewall, sperrt Angreifer automatisch per Firewall-Regel – und kann als zentrale Sperrinstanz auch für Angriffe auf Server dahinter dienen.
So funktioniert CrowdSec
| Komponente | Bezeichnung im Plugin | Aufgabe |
|---|---|---|
| Security Engine / Log Processor | Log Processor (IDS) | Liest Logdateien, wertet sie mit Parsern und Szenarien aus (z. B. „SSH-Brute-Force“, „Port-Scan“, „Web-Scan“) und erzeugt bei Treffern Alarme |
| Local API (LAPI) | LAPI | Zentrale Stelle für Entscheidungen (Decisions, z. B. „IP für 4 Stunden sperren“), nimmt Alarme lokaler und entfernter Agenten entgegen und gleicht sich mit der CrowdSec-Zentrale ab |
| Bouncer / Remediation Component | Remediation Component (IPS) | Setzt Entscheidungen um – auf der OPNsense als Firewall-Bouncer, der gesperrte IPs in pf-Tabellen (Aliase) schreibt |
| Hub | Collections, Scenarios, Parsers … | Fertige Regelpakete für Dienste wie OPNsense, SSH, nginx, Caddy, HAProxy, Postfix, Windows u. v. m. |
| Console (optional) | Enrollment key | Weboberfläche app.crowdsec.net zur zentralen Übersicht und für zusätzliche Blocklisten |
Schritt 1: Plugin installieren
System → Firmware → Plugins: os-crowdsec installieren und die Seite neu laden. Dabei werden die Pakete crowdsec (Security Engine) und crowdsec-firewall-bouncer mitinstalliert. Das Menü befindet sich unter Services → CrowdSec mit Settings, Machines, Bouncers, Alerts, Decisions sowie den Hub-Bereichen Collections, Scenarios, Parsers, Postoverflows und den AppSec-Einträgen.
Schritt 2: Einstellungen prüfen
Services → CrowdSec → Settings – nach der Installation sind die drei Hauptkomponenten bereits aktiv:
| Einstellung | Standard | Empfehlung |
|---|---|---|
| Enable Log Processor (IDS) | an | an – erkennt Angriffe und liefert Signale an die Community |
| Enable LAPI | an | an, solange keine zentrale LAPI auf einem anderen System genutzt wird |
| Enable Remediation Component (IPS) | an | an – sperrt die Angreifer |
| Enrollment key | leer | optional: Schlüssel aus app.crowdsec.net („Enroll command“) für die Console |
| LAPI listen address / port | 127.0.0.1 / 8080 | für zusätzliche Agenten auf die LAN-Adresse ändern (Schritt 6); Port bei Konflikten (z. B. Webdienst auf 8080) anpassen |
| Create blocklist rules | an | an – erzeugt automatisch Sperrregeln für alle Interfaces, IPv4/IPv6, ein- und ausgehend |
| Enable log for rules | aus | an, um gesperrte Verbindungen im Firewall-Log zu sehen |
| Tag for matched packets | leer | optional, z. B. crowdsec zur Diagnose
|
Apply – die Dienste laufen. Standardmäßig sind die Collections crowdsecurity/freebsd und crowdsecurity/opnsense installiert; dazu wertet das Plugin das Firewall-Log für die Erkennung von Port-Scans aus. Seit CrowdSec 1.6.3 sind private IP-Netze (RFC 1918) standardmäßig von Sperren ausgenommen.
Schritt 3: Wie gesperrt wird
Der Firewall-Bouncer schreibt alle gesperrten Adressen – eigene Erkennungen und die Community-Blocklist – in die Aliase crowdsec_blocklists (IPv4) und crowdsec6_blocklists (IPv6). Mit Create blocklist rules legt das Plugin passende Block-Regeln an, die Verkehr von und zu diesen Adressen auf allen Interfaces verwerfen.
Wer eigene Regeln bevorzugt (z. B. nur auf dem WAN oder als Floating Rule mit bestimmter Reihenfolge), deaktiviert Create blocklist rules und verwendet die beiden Aliase in eigenen Regeln unter Firewall → Rules.
Schritt 4: Funktion testen
Per SSH auf der OPNsense (Shell, Menüpunkt 8):
cscli metrics # Logquellen, Parser, Szenarien, Bouncer-Abfragen
cscli decisions list # aktuelle lokale Sperren
cscli alerts list # erkannte Angriffe
cscli bouncers list # registrierte Bouncer (Firewall-Bouncer muss erscheinen)
Sperrtest mit der eigenen IP (die SSH-Sitzung friert danach für zwei Minuten ein – vorher sicherstellen, dass ein anderer Zugang besteht):
cscli decisions add -t ban -d 2m -i <eigene-oeffentliche-IP>
Da private Netze ausgenommen sind, funktioniert der Test nur mit einer öffentlichen Adresse, z. B. von einem externen Server oder Mobilfunk-Hotspot aus. Eine Sperre lässt sich mit cscli decisions delete -i <IP> wieder aufheben. Alarme und Entscheidungen sind auch in der Oberfläche unter Alerts und Decisions sichtbar.
Schritt 5: Weitere Dienste der Firewall schützen
Unter Services → CrowdSec → Collections bzw. per cscli lassen sich weitere Regelpakete aus dem Hub installieren – passend zu den Diensten, die auf der OPNsense laufen, z. B.:
| Dienst auf der OPNsense | Collection |
|---|---|
| SSH, Weboberfläche | bereits in crowdsecurity/opnsense bzw. crowdsecurity/freebsd enthalten |
| Caddy (Zugriffslogs im JSON-Format) | crowdsecurity/caddy – Logquelle unter /usr/local/etc/crowdsec/acquis.d/ eintragen
|
| NGINX | crowdsecurity/nginx |
| HAProxy | crowdsecurity/haproxy |
| Postfix | crowdsecurity/postfix |
Beispiel für Caddy:
cscli collections install crowdsecurity/caddy
cat > /usr/local/etc/crowdsec/acquis.d/caddy.yaml <<'EOF'
filenames:
- /var/log/caddy/access/*.log
force_inotify: true
poll_without_inotify: true
labels:
type: caddy
EOF
Danach CrowdSec in der Oberfläche neu starten (Services → CrowdSec → Settings bzw. Dienste-Widget). Hub-Updates (neue Szenarien und Parser) lädt das Plugin automatisch per Cronjob.
Schritt 6: Server hinter der Firewall einbinden
Eine Stärke von CrowdSec: Die OPNsense kann als zentrale LAPI dienen. CrowdSec-Agenten auf Web-, Mail- oder Linux-Servern melden Angriffe an die Firewall – und die Firewall sperrt den Angreifer für das gesamte Netz.
- Auf der OPNsense LAPI listen address auf die LAN-Adresse setzen (z. B.
192.168.10.1) und unter Firewall → Rules TCP 8080 nur von den Servern auf die Firewall erlauben. - Auf dem Server CrowdSec installieren (Paketquelle von CrowdSec, z. B. unter Debian), die lokale LAPI deaktivieren und den Agenten registrieren:
sudo cscli lapi register -u http://192.168.10.1:8080 --machine webserver01
- Auf der OPNsense den neuen Agenten bestätigen:
cscli machines list
cscli machines validate webserver01
- Auf dem Server die passenden Collections installieren (z. B. crowdsecurity/nginx, crowdsecurity/sshd) und CrowdSec neu starten.
Erkennt der Webserver nun z. B. einen Brute-Force-Angriff, landet die Angreifer-IP in den Aliasen der OPNsense und wird am Perimeter für alle Systeme gesperrt. Unter Services → CrowdSec → Machines erscheinen alle angebundenen Agenten.
CrowdSec Console und Blocklisten
Mit dem Enrollment key wird die Firewall in der Console unter app.crowdsec.net angemeldet (alternativ per cscli console enroll <key>). Dort sind Alarme aller Instanzen zentral sichtbar.
| Tarif | Leistungen (Stand 10/2026) |
|---|---|
| Community (kostenlos) | Community-Blocklist, Console-Übersicht; Umfang der Blocklist hängt davon ab, dass die eigene Instanz Signale beiträgt |
| Premium | Abrechnung je angemeldeter Security Engine; u. a. Premium-Community-Blocklist, längere Alarmaufbewahrung, Benachrichtigungen, API-Zugriff |
| Platinum-Blocklisten | kuratierte Blocklisten (u. a. Threat-Intelligence-, Branchen-, KI-Crawler-Listen), laut Preisseite ab 1.900 USD/Monat für KMU |
| Enterprise | auf Anfrage |
CrowdSec im Vergleich
| Werkzeug | Ansatz | Ergänzung |
|---|---|---|
| CrowdSec | Verhaltensbasierte Erkennung in Logs + Community-Blocklist, automatische Sperren | schützt eigene Dienste und veröffentlichte Server |
| Q-Feeds | Kuratierte Listen bösartiger IPs/Domains | vorbeugend, auch DNS |
| Suricata (Intrusion Detection) | Signaturen auf Paketebene | erkennt Exploits auf erlaubten Verbindungen |
| Zenarmor | Anwendungs- und Webkontrolle für Clients | schützt Benutzer beim Surfen |
| Maltrail | Erkennung verdächtiger Ziele im eigenen Verkehr | zeigt infizierte Clients |
Sicherheit und Betrieb
- Eigene Zugänge absichern: Feste Admin-IPs, die öffentlich sind (z. B. Homeoffice, Dienstleister), per Whitelist ausnehmen, damit Tippfehler beim Login nicht zur Selbstaussperrung führen – CrowdSec unterstützt dafür eigene Whitelist-Parser bzw. AllowLists.
- LAPI nicht öffentlich erreichbar machen: Nur aus dem LAN bzw. von den eigenen Servern.
- Logs auswerten: Alarme zusätzlich an ein SIEM weiterleiten, z. B. ein Open-Source-SIEM auf Wazuh-Basis.
- Updates: CrowdSec und Bouncer kommen mit OPNsense-Firmware- bzw. Plugin-Updates; Hub-Inhalte aktualisiert der Cronjob.
- Datenschutz: Beim Teilen von Signalen übermittelt CrowdSec Angreifer-IP, Zeitpunkt und erkanntes Szenario an die Zentrale – keine Inhalte. Für den Einsatz in Unternehmen in der Datenschutzdokumentation berücksichtigen.
Typische Probleme
| Symptom | Lösung |
|---|---|
Firewall-Bouncer erscheint nicht in cscli bouncers list |
Remediation Component deaktiviert oder Dienst nicht gestartet – Einstellungen speichern/anwenden, Log unter /var/log/crowdsec/ prüfen.
|
| Sperrtest wirkt nicht | Test-IP ist privat (standardmäßig ausgenommen) oder Create blocklist rules deaktiviert ohne eigene Regeln. |
| LAPI startet nicht | Port 8080 bereits belegt (z. B. durch einen anderen Dienst) – LAPI listen port ändern. |
| Entfernter Agent kann sich nicht registrieren | LAPI lauscht nur auf 127.0.0.1, Firewall-Regel für TCP 8080 fehlt oder Maschine nicht mit cscli machines validate bestätigt.
|
| Keine Alarme aus Caddy/NGINX-Logs | Collection installiert, aber Logquelle (acquis) fehlt oder Logformat passt nicht; cscli metrics zeigt, ob Zeilen gelesen und geparst werden.
|
Fazit
CrowdSec bringt eine moderne, kollaborative „Fail2ban-Alternative“ auf die OPNsense: Port-Scans und Brute-Force-Angriffe werden erkannt und automatisch gesperrt, die Community-Blocklist hält bekannte Angreifer schon vorab fern, und mit der Firewall als zentraler LAPI schützen Erkennungen auf einzelnen Servern das gesamte Netz. Das Plugin ist schnell eingerichtet – entscheidend sind passende Collections für die eigenen Dienste und Ausnahmen für eigene Zugänge.
Unterstützung von m.a.x. it
Sie möchten CrowdSec, Threat-Intelligence-Listen und IDS/IPS auf Ihrer OPNsense kombinieren oder veröffentlichte Server zentral über die Firewall schützen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.
Siehe auch
- OPNsense - Q-Feeds Threat Intelligence
- OPNsense - Zenarmor Next-Generation-Firewall
- OPNsense - Caddy Reverse Proxy
- OPNsense - Wazuh-Agent
- OPNsense - Maltrail Erkennung von Schadverkehr
- Suricata
- IPS
- IDS
- Threat Intelligence
- Botnet
Links und Quellen
- CrowdSec-Doku – Installation auf OPNsense
- Quellcode und Changelog des Plugins os-crowdsec
- CrowdSec Hub – Collections und Szenarien
- CrowdSec – Tarife
- m.a.x. it – OPNsense-Firewall-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
