Zum Inhalt

Intrusion Prevention: CrowdSec & nftables Threat Intelligence

Erstellt: 10.11.2026 Aktualisiert: 10.11.2026

Management Summary: Klassische Host-basierte Intrusion-Prevention-Tools wie Fail2ban analysieren Protokolldateien ausschließlich isoliert auf einem einzelnen Host und agieren rein reaktiv, nachdem Angriffe bereits gestartet wurden. Moderne Botnetze umgehen solche Einzellösungen mühelos, indem sie zehntausende rotierende IP-Adressen nutzen und Angriffe über Wochen strecken („Low and Slow“). CrowdSec revolutioniert diesen Ansatz durch eine hochperformante, in Go geschriebene Security Engine, die verhaltensbasierte Log-Analyse mit weltweiter kollaborativer Threat Intelligence verbindet: Wird eine böswillige IP-Adresse irgendwo auf der Welt auffällig, wird sie vorab auf allen angebundenen Systemen gesperrt. Dieser Leitfaden behandelt die Engine- und API-Architektur (LAPI/CAPI), Erkennungs-Szenarien via Leaky Bucket, atomare Remediation über native nftables-Kernel-Sets, Whitelisting und das operative Incident-Runbook.

  • Fail2ban vs. CrowdSec

    Warum isolierte Regelsätze modernen Botnets unterlegen sind und wie kollektive Threat Intelligence Angriffe im Keim erstickt.

  • Engine & API-Architektur

    Die modulare Trennung: Lokale Security Engine (Log-Parser & Szenarien), Local API (LAPI) und Central API (CAPI).

  • Hub, Collections & Scenarios

    Installation verifizierter Erkennungsregeln für SSH-Brute-Force, Nginx-Virtual-Hosts, Reverse-Proxies und Port-Scans mit cscli.

  • Remediation mit nftables-Bouncer

    Automatisches Sperren bösartiger IPs im Linux-Kernel über High-Speed nftables-Sets ohne Performance-Verlust.

  • Multi-Server & SIEM-Export

    Zentralisierte Erkennung in Server-Clustern: Mehrere Agenten senden Telemetrie an eine zentrale LAPI-Instanz.

  • Whitelisting & Alert-Monitoring

    False-Positives vermeiden mit sauberen Whitelists (parsers/s02-enrich/), Statuskontrolle via cscli alerts und Notfall-Runbooks.

1. Fail2ban vs. CrowdSec: Die Grenzen traditioneller Intrusion Prevention

Über zwei Jahrzehnte hinweg war fail2ban der De-facto-Standard zur Abwehr von SSH-Brute-Force-Angriffen. In modernen Produktionsumgebungen stößt Fail2ban jedoch an fundamentale architektonische Grenzen:

  1. Reaktive Single-Host-Isolation: Fail2ban erfährt erst von einem Angreifer, wenn dieser bereits anklopft. Es gibt keinen Wissensaustausch mit anderen Servern.
  2. Hohe CPU-Last bei Log-Spikes: Fail2ban parst Logdateien sequenziell mit Python-RegEx. Bei DDoS- oder Web-Scans treibt das die Systemauslastung in die Höhe.
  3. Machtlos gegen verteilte Botnetze: Ein Angreifer, der 5.000 IP-Adressen kontrolliert und pro IP nur einen Anmeldeversuch pro Stunde durchführt, löst niemals den Schwellenwert von maxretry = 5 aus.
%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    Logs["Server-Logquellen<br/>(journald, auth.log, nginx)"] ==> Parser["CrowdSec Parser Engine<br/>(Grok / Go Streaming Pipeline)"]
    Parser --> Scenarios["Szenarien-Evaluierung<br/>(Leaky-Bucket-Algorithmus)"]
    Scenarios -->|"Schwelle überschritten"| LAPI["Local API (LAPI)<br/>Erzeugt Alert & Decision"]
    LAPI --> Bouncer["nftables Bouncer<br/>(Atomarer Kernel-Set Drop)"]
    LAPI -.->|"Anonymisierte Meldung"| CAPI["CrowdSec CAPI<br/>(Globale Community-Cloud)"]
    CAPI -.->|"Globale Blocklist-Updates"| LAPI

Der kollaborative CrowdSec-Vorteil

CrowdSec kehrt das Spiel um: Wenn ein Botnet einen Honeypot oder Server in Japan scannt, validiert die Central API (CAPI) das Verhalten über Konsens-Algorithmen und verteilt die bösartige IP-Adresse binnen Minuten als verifizierte Blocklist an alle CrowdSec-Instanzen weltweit. Der Angriff auf deinen Server wird abgewehrt, bevor das erste feindliche Datenpaket deine Netzwerkschnittstelle erreicht.

2. CrowdSec Kern-Architektur: Security Engine, LAPI & CAPI

Die CrowdSec-Architektur ist streng modular aufgebaut und trennt Erkennung, Entscheidung und Durchsetzung:

  1. Security Engine (Agent): Liest unstrukturierte Logs, normalisiert sie über Grok-basierte Parser in strukturierte Events und füttert Szenarien.
  2. Local API (LAPI): Der lokale Entscheidungs-Hub. Sie speichert Alarme und Sperr-Entscheidungen (Decisions) in einer lokalen SQLite- oder PostgreSQL-Datenbank und bedient Bouncer über eine authentifizierte REST-API.
  3. Central API (CAPI): Der globale Cloud-Dienst. Er synchronisiert Blocklisten und empfängt anonymisierte Angreifer-Metadaten (nur IP, Zeitstempel und Szenario-Name – niemals Log-Inhalte oder persönliche Daten!).

Konfiguration der Datenquellen in /etc/crowdsec/acquis.yaml

In /etc/crowdsec/acquis.yaml wird definiert, welche Logs CrowdSec überwachen soll:

# /etc/crowdsec/acquis.yaml
# Überwachung des systemd-Journals auf SSH-Authentifizierungsereignisse
filenames:
  - /var/log/auth.log
labels:
  type: syslog
---
# Überwachung von Webserver-Access-Logs (Nginx)
filenames:
  - /var/log/nginx/*.log
labels:
  type: nginx
---
# Natives systemd Journal einbinden (Debian 12+ / Bookworm)
source: journalctl
journalctl_filter:
  - _SYSTEMD_UNIT=ssh.service
labels:
  type: syslog

3. Installation & Hub-Ökosystem: Collections, Parsers & Szenarien

Unter Debian und Ubuntu wird CrowdSec über das offizielle Paket-Repository bezogen:

# Offizielles CrowdSec-Repository einbinden und Engine installieren
curl -s https://packagecloud.io/install/repositories/crowdsecurity/crowdsec/script.deb.sh | sudo bash
sudo apt-get install crowdsec

# Status der installierten Komponenten prüfen
sudo cscli hub list

Collections installieren

Eine Collection bündelt alle notwendigen Parser und Szenarien für einen bestimmten Dienst:

# Basis-Schutz für Linux-Betriebssystem und OpenSSH
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/sshd

# Schutz für Nginx-Webserver und HTTP-Exploits
sudo cscli collections install crowdsecurity/nginx

# Dienst neu laden, um die neuen Regeln zu aktivieren
sudo systemctl reload crowdsec

Anatomie eines Szenarios (Der Leaky-Bucket-Algorithmus)

Szenarien definieren, ab wann ein Verhalten als bösartig eingestuft wird. Sie nutzen das Leaky-Bucket-Modell:

# Beispiel: /etc/crowdsec/scenarios/ssh-bf.yaml
type: leaky
name: crowdsecurity/ssh-bf
description: "Erkennt SSH-Brute-Force-Angriffe"
filter: "evt.Meta.log_type == 'ssh_failed-auth'"
groupby: evt.Meta.source_ip
capacity: 5        # Der Eimer fasst 5 Fehlversuche
leakspeed: 10s     # Alle 10 Sekunden tropft 1 Versuch aus dem Eimer
blackhole: 1m      # Nach Alarm 1 Minute lang keine weiteren Events für diese IP werten
remediation: true  # Löst eine Sperr-Entscheidung (Decision) aus

Erreicht die IP 5 Fehlversuche, bevor der Eimer leergetropft ist, läuft der Eimer über und die LAPI erzeugt eine Sperr-Entscheidung.

4. High-Speed Remediation mit dem nftables-Bouncer

Die CrowdSec-Engine analysiert lediglich Logs. Um bösartige IPs auf Netzwerkebene abzuwehren, wird ein Remediation Bouncer benötigt.

Herkömmliche Tools fügen für jede gesperrte IP eine eigene Zeile in die Firewall ein (iptables -A INPUT -s ... -j DROP). Bei 10.000 IPs führt dies zu drastischen Latenzen, da jedes Datenpaket 10.000 Regeln sequenziell durchlaufen muss.

Der nftables-Bouncer nutzt stattdessen native Kernel-Sets mit $O(1)$-Suchaufwand (konstante Zeit). Ob 10 oder 100.000 IPs gesperrt sind: Die CPU-Last bleibt unmessbar gering!

1. Bouncer installieren

# Installiere den nativen nftables-Firewall-Bouncer
sudo apt-get install crowdsec-firewall-bouncer-nftables

# Verifiziere die erfolgreiche Registrierung an der LAPI
sudo cscli bouncers list

2. Konfiguration in /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

# /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
api_url: http://127.0.0.1:8080/
api_key: <automatisch_generierter_api_schluessel>
mode: nftables
update_frequency: 10s
blacklists_ipv4: crowdsec_blacklists
blacklists_ipv6: crowdsec6_blacklists
# Strikter Verwurf ohne Antwortpaket (spart Bandbreite)
deny_action: DROP

3. Aktive Kernel-Sets live inspizieren

# Zeige das native nftables-Set mit allen aktiv geblockten IP-Adressen an
sudo nft list set inet crowdsec crowdsec_blacklists

5. Decisions-Management, Whitelisting & Metriken

Die CLI cscli bietet die vollständige operative Kontrolle über aktive Sperren und Alarme.

1. Entscheidungen und Alarme abfragen

# Zeige alle aktiven Alarme der letzten Tage an
sudo cscli alerts list

# Zeige alle derzeit im System gesperrten IP-Adressen
sudo cscli decisions list

# Manuelle Sperre für eine verdächtige IP für 24 Stunden verhängen
sudo cscli decisions add --ip 198.51.100.42 --duration 24h --reason "Manuelle Sperre nach Forensik"

# Manuelle Sperre vorzeitig aufheben
sudo cscli decisions delete --ip 198.51.100.42

2. Administrator-Whitelists konfigurieren

Um versehentliche Sperren von Administratoren, Monitoring-Systemen oder VPN-Gateways auszuschließen, wird eine Parser-Whitelist angelegt:

Erstelle /etc/crowdsec/parsers/s02-enrich/01-admin-whitelist.yaml:

# /etc/crowdsec/parsers/s02-enrich/01-admin-whitelist.yaml
name: enterprise/admin-whitelist
description: "Whitelistet Firmen-Subnetze und Admin-VPNs"
whitelist:
  reason: "Corporate Management Infrastructure"
  ip:
    - "127.0.0.1"
    - "::1"
  cidr:
    - "192.0.2.0/24"     # Beispiel: Firmen-Office
    - "198.51.100.0/28"  # Beispiel: Admin-VPN Gateway

Lade die Konfiguration neu:

sudo systemctl reload crowdsec

3. Verarbeitungs-Metriken analysieren mit cscli metrics

# Zeige Verarbeitungsstatistiken der Engine, Parser und Log-Quellen
sudo cscli metrics

6. Enterprise-Betrieb, Monitoring & Notfall-Runbook

Achtung hinter Reverse-Proxies und CDN (z. B. Cloudflare)

Lauscht CrowdSec auf Webserver-Logs hinter Cloudflare oder einem Load-Balancer, sieht der Webserver standardmäßig nur die IP des Proxies. Wird diese gesperrt, ist die gesamte Webseite für alle Besucher offline!

Lösung: In Nginx das ngx_http_realip_module konfigurieren (set_real_ip_from ...; real_ip_header CF-Connecting-IP;), damit die echte Client-IP in den Logs landet. Installiere zusätzlich die Collection crowdsecurity/http-cve.

Notfall-Entstörungs-Runbook

Notfall-Szenario Sofortmaßnahme Dauerhafte Lösung
Administrator versehentlich gesperrt sudo cscli decisions delete --ip <admin_ip> auf der Konsole ausführen. Admin-IP-Bereich sofort in 01-admin-whitelist.yaml eintragen.
Bouncer blockiert nichts mehr Status prüfen: sudo systemctl status crowdsec-firewall-bouncer. API-Key mit cscli bouncers list prüfen. API-Key in /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml abgleichen.
Log-Parsing erzeugt Fehler sudo cscli explain --log "<fehlerhafte_logzeile>" --type nginx Fehlenden Parser über cscli hub nachinstallieren oder Grok-Pattern anpassen.

Mit CrowdSec und dem nftables-Bouncer ist dein Linux-Server in ein globales Cyber-Abwehrnetzwerk eingebunden: Angreifer werden frühzeitig erkannt, an der Firewall atomar verworfen und dein Server bleibt für legitime Benutzer reaktionsschnell und geschützt.