Projektübersicht

CrowdSec wurde als kollaboratives IDS (Intrusion Detection System) und Threat-Intelligence-System auf OPNsense implementiert. Es erkennt Angriffsmuster in Firewall-Logs und blockt Angreifer-IPs automatisch in der pf-Firewall, ergänzt durch eine weltweite Community-Blocklist.

1. Situation (Ausgangslage)

Das Heimnetz ist direkt mit einer statischen öffentlichen IP am Internet angebunden, ohne vorgelagerten Router. OPNsense ist der einzige Ein- und Ausgang für den gesamten Netzwerktraffic. Ohne ein Erkennungssystem waren Portscanner, Brute-Force-Angriffe gegen SSH und die Firewall-GUI sowie bekannte Angreifer-IPs aus der ganzen Welt grundsätzlich ungebremst bis zur pf-Firewall durchgekommen. Die bestehende Firewall-Konfiguration blockt zwar unerlaubte Verbindungen, erkennt aber keine Verhaltensmuster über Zeit und profitiert nicht von externen Threat-Intelligence-Quellen.

2. Task (Zielsetzung)

• Angriffserkennung: Brute-Force-Angriffe gegen SSH und OPNsense Web-GUI sowie Port-Scanner automatisch erkennen und blockieren.
• Community-Schutz: Bekannte Angreifer-IPs aus der weltweiten CrowdSec-Community automatisch beziehen und lokal sperren.
• pf-Integration: Erkannte Angreifer direkt in der bestehenden pf-Firewall blockieren, ohne zusätzliche Infrastruktur.
• Ressourcenschonung: Lösung mit minimalem Performance-Impact auf der Firewall-VM wählen.

3. Action (Umsetzung)

A. Architektur-Entscheidung und Komponentenverständnis

Vor der Installation wurde die CrowdSec-Architektur analysiert: Die drei Kernkomponenten Log-Processor (Agent), Local API (LAPI) und Firewall-Bouncer arbeiten zusammen auf OPNsense. Der Agent liest Logs und meldet Erkennungen an die LAPI. Die LAPI prüft Meldungen gegen Szenarien, trifft Sperrungsentscheidungen und synchronisiert mit der zentralen CrowdSec-API. Der Bouncer schreibt gesperrte IPs in pf-Tabellen. Diese Trennung erlaubt es, die Entscheidungslogik lokal zu behalten während man von weltweiter Threat Intelligence profitiert.

B. Installation via OPNsense Plugin-Manager

Das Plugin os-crowdsec wurde über den OPNsense Firmware-Plugin-Manager installiert. Dabei wurden automatisch fünf Pakete eingespielt: die CrowdSec-Engine (v1.7.8), der Firewall-Bouncer, das OPNsense-Plugin sowie zwei Bibliotheksabhängigkeiten. Beim Install-Vorgang wurden bereits sechs vorkonfigurierte Collections heruntergeladen und aktiviert: Schutz gegen SSH-Brute-Force (inkl. CVE-2024-6387), OPNsense-GUI-Brute-Force, Port-Scanner-Erkennung via pf-Logs sowie eine Whitelist für legitime Akteure wie Cloudflare-IPs und SEO-Crawler.

C. Konfiguration und Aktivierung

Im Settings-Tab wurden Log-Processor, LAPI und Remediation-Komponente aktiviert. Die LAPI wurde bewusst nur auf localhost gebunden, da alle Komponenten auf derselben Maschine laufen und kein externer Zugriff benötigt wird. Die Option "Create blocklist rules" sorgt dafür, dass der Bouncer die pf-Regeln automatisch anlegt und verwaltet.

D. Verifikation der pf-Regeln

Nach dem Apply wurden die automatisch angelegten pf-Regeln verifiziert. CrowdSec legt vier Regeln an: eingehender und ausgehender Block für IPv4 und IPv6 gegen die jeweiligen Blocklist-Tabellen. Alle vier Regeln nutzen quick (sofortiger Match ohne weitere Regelauswertung) und drop statt reject, sodass geblockte Angreifer keine Antwort erhalten und nicht einmal wissen ob die IP erreichbar ist.

4. Result (Ergebnis & Verifikation)

CrowdSec läuft vollständig operativ auf OPNsense. Beide Services (Engine und Bouncer) wurden per service-Befehl als laufend bestätigt. Die vier pf-Regeln sind aktiv und verifiziert. Die Acquisition-Metriken zeigen dass CrowdSec bereits aktiv den pf-Firewall-Log liest und Ereignisse in Szenarien einspeist. Die Verbindung zur zentralen CrowdSec-API ist hergestellt, Community-Blocklist wird bezogen, eigene Signale werden anonym gemeldet.

Der Ressourcenverbrauch liegt bei rund 205 MB RAM und praktisch 0% CPU im Normalbetrieb, was auf der Firewall-VM mit 6 GB RAM problemlos vertretbar ist.

Lessons Learned

• LAPI lokal halten: Die Entscheidungslogik bleibt auf eigener Hardware. Die zentrale API liefert nur Daten, entscheidet nicht. Das ist der wesentliche Unterschied zu reinen Cloud-basierten Sicherheitslösungen.
• drop ist besser als reject: Ein lautlos verworfenes Paket gibt dem Angreifer keine Information. reject sendet eine ICMP-Antwort zurück und bestätigt die Existenz der IP.
• Ingress und Egress blockieren: Geblockte IPs werden in beide Richtungen gesperrt. Das schützt auch gegen den Fall, dass ein internes Gerät kompromittiert wird und versucht, mit einer bekannten Command-and-Control-IP zu kommunizieren.
• Whitelist vor Blocklist denken: Die whitelist-good-actors-Collection verhindert, dass legitimer Traffic (Cloudflare-Tunnel, Suchmaschinen-Crawler) fälschlicherweise geblockt wird. Diese Reihenfolge muss beim Hinzufügen eigener Regeln beachtet werden.
• Zeitbasierte Erkennung verstehen: CrowdSec blockt nicht bei einzelnen Events, sondern erst wenn Schwellenwerte überschritten werden. Das reduziert False Positives erheblich gegenüber einfachen Fail2ban-Ansätzen.