Die interne Funktionsweise von CrowdSec

Nach der Installation von CrowdSec stellt sich schnell die Frage, wie die Software eigentlich arbeitet. Anders als klassische Werkzeuge zur Angriffserkennung besteht CrowdSec nicht aus einer einzelnen Anwendung, sondern aus mehreren spezialisierten Komponenten, die eng miteinander zusammenarbeiten.

Diese modulare Architektur sorgt dafür, dass CrowdSec flexibel erweitert werden kann und sowohl auf kleinen Linux-Servern als auch in komplexen Unternehmensumgebungen zuverlässig funktioniert.

In diesem dritten Teil der Serie werfen wir einen Blick hinter die Kulissen und lernen die wichtigsten Bausteine kennen.

Die Architektur im Überblick

Vereinfacht lässt sich der Ablauf wie folgt darstellen:

Logdateien
     │
     ▼
Agent
     │
     ▼
Parser
     │
     ▼
Szenarien
     │
     ▼
Local API (LAPI)
     │
     ▼
Decisions
     │
     ▼
Bouncer
     │
     ▼
Firewall / Webserver / Reverse Proxy

Jede Komponente übernimmt dabei eine klar definierte Aufgabe.

Der CrowdSec Agent

Der Agent ist das Herzstück von CrowdSec.

Er läuft als Systemdienst im Hintergrund und überwacht kontinuierlich die konfigurierten Logdateien.

Typische Quellen sind:

• SSH
• Apache
• Nginx
• Traefik
• Postfix
• Dovecot
• MySQL
• MariaDB
• Docker
• Kubernetes
• viele weitere Anwendungen

Sobald neue Logeinträge entstehen, liest der Agent diese nahezu in Echtzeit ein und übergibt sie an die nächste Verarbeitungsstufe.

Der Agent trifft dabei noch keine Entscheidungen. Seine Aufgabe besteht ausschließlich darin, die Daten zuverlässig einzusammeln und weiterzugeben.

Die Local API (LAPI)

Die Local API – häufig einfach LAPI genannt – ist die zentrale Schaltstelle von CrowdSec.

Sie verwaltet sämtliche Informationen über:

• erkannte Ereignisse
• Maschinen
• Parser
• Szenarien
• Entscheidungen
• Bouncer
• Community-Informationen

Alle anderen Komponenten kommunizieren mit der LAPI.

Dadurch können mehrere Bouncer gleichzeitig auf dieselben Entscheidungen zugreifen.

Die LAPI speichert die Daten standardmäßig in einer SQLite-Datenbank. Für größere Installationen können alternativ auch PostgreSQL oder MySQL/MariaDB genutzt werden.

Warum Agent und LAPI getrennt sind

Auf den ersten Blick wirkt diese Trennung vielleicht unnötig.

Sie bietet jedoch zahlreiche Vorteile:

• mehrere Agenten können dieselbe LAPI nutzen
• mehrere Bouncer greifen auf dieselben Daten zu
• zentrale Verwaltung möglich
• bessere Skalierbarkeit
• einfachere Erweiterbarkeit

Gerade in größeren Netzwerken spielt diese Architektur ihre Stärken aus.

Collections

Collections sind vorkonfigurierte Pakete für bestimmte Anwendungen.

Sie enthalten beispielsweise:

• Parser
• Szenarien
• Postoverflows
• Konfigurationen

Für Administratoren bedeutet das:

Anstatt jede einzelne Regel manuell zu installieren, genügt meist die passende Collection.

Ein Beispiel:

Die Apache-Collection installiert automatisch alle benötigten Komponenten zur Erkennung typischer Webangriffe.

Dasselbe gilt unter anderem für:

• SSH
• Nginx
• Traefik
• Postfix
• Dovecot
• Nextcloud
• Docker
• Kubernetes

Collections vereinfachen die Einrichtung erheblich und sorgen dafür, dass alle zusammengehörenden Komponenten korrekt miteinander arbeiten.

Parser

Logdateien verschiedener Programme unterscheiden sich erheblich.

Ein SSH-Log sieht völlig anders aus als ein Apache- oder PostgreSQL-Log.

Parser sorgen dafür, dass CrowdSec diese unterschiedlichen Formate versteht.

Sie übernehmen unter anderem folgende Aufgaben:

• Logzeilen lesen
• Felder erkennen
• Zeitstempel extrahieren
• IP-Adressen identifizieren
• Benutzernamen erkennen
• HTTP-Methoden auswerten
• Statuscodes übernehmen

Anschließend liegen alle Informationen in einem einheitlichen internen Format vor.

Erst dadurch können die nachfolgenden Szenarien unabhängig vom jeweiligen Dienst arbeiten.

Szenarien

Szenarien bilden die eigentliche Angriffserkennung.

Sie analysieren die aufbereiteten Daten und erkennen verdächtige Muster.

Typische Beispiele sind:

• SSH-Brute-Force
• Passwort-Spraying
• WordPress-Login-Angriffe
• SQL-Injection
• Directory Traversal
• Webscanner
• Portscanner
• Botnet-Aktivitäten
• Credential Stuffing

Dabei betrachtet CrowdSec nicht nur einzelne Logeinträge.

Vielmehr analysiert es das Verhalten über einen bestimmten Zeitraum.

Ein einzelner fehlgeschlagener Login stellt beispielsweise noch keinen Angriff dar.

Erst wenn eine definierte Anzahl von Ereignissen innerhalb eines Zeitfensters auftritt, löst das Szenario aus.

Dadurch reduziert CrowdSec Fehlalarme deutlich.

Entscheidungen (Decisions)

Erkennt ein Szenario einen Angriff, erzeugt CrowdSec eine sogenannte Decision.

Eine Decision beschreibt die Reaktion auf einen Angreifer.

Typische Entscheidungen sind:

• IP sperren
• Zugriff verweigern
• HTTP 403 zurückgeben
• Anfrage blockieren
• Zeitlich begrenzte Sperre
• Dauerhafte Sperre

Die Decision wird zunächst lediglich in der LAPI gespeichert.

Noch wurde der Angreifer also nicht blockiert.

Diese Trennung ermöglicht eine flexible Weiterverarbeitung.

Bouncer

Die eigentliche Sperrung übernimmt der Bouncer.

Ein Bouncer fragt regelmäßig die LAPI nach neuen Decisions ab.

Er setzt diese anschließend auf der jeweiligen Plattform um.

Je nach eingesetztem Bouncer geschieht dies beispielsweise über:

• nftables
• iptables
• UFW
• Nginx
• Apache
• Traefik
• HAProxy
• Cloudflare
• Caddy

Dadurch bleibt CrowdSec unabhängig vom eigentlichen Schutzmechanismus.

Es können sogar mehrere Bouncer gleichzeitig aktiv sein.

Ein Beispiel:

• Firewall blockiert die IP.
• Nginx liefert HTTP 403.
• Traefik verweigert den Zugriff.

Alle greifen dabei auf dieselbe Decision zu.

Der komplette Datenfluss

Der gesamte Ablauf lässt sich anhand eines SSH-Brute-Force-Angriffs nachvollziehen.

1. Angriff

Ein Bot versucht wiederholt, sich per SSH anzumelden.

↓

2. Logdatei

OpenSSH schreibt jede Anmeldung in die Logdatei.

↓

3. Agent

Der Agent liest die neuen Logeinträge.

↓

4. Parser

Die SSH-Parser erkennen:

• IP-Adresse
• Benutzername
• Zeitpunkt
• Fehlermeldung

↓

5. Szenario

Das Brute-Force-Szenario erkennt beispielsweise:

• 10 Fehlversuche
• innerhalb von 60 Sekunden

↓

6. Decision

CrowdSec erstellt:

Blockiere IP-Adresse für vier Stunden.

↓

7. LAPI

Die Decision wird gespeichert.

↓

8. Bouncer

Der Firewall-Bouncer fragt die LAPI ab.

↓

9. Firewall

Die IP-Adresse wird automatisch gesperrt.

↓

10. Angriff beendet

Weitere Anfragen werden verworfen.

Der gesamte Vorgang dauert meist nur wenige Sekunden.

Vorteile der modularen Architektur

Die Trennung der einzelnen Komponenten bringt zahlreiche Vorteile.

Dazu gehören:

• sehr flexibel
• leicht erweiterbar
• zentrale Verwaltung
• mehrere Bouncer gleichzeitig
• verschiedene Datenbanken möglich
• API-basierte Kommunikation
• geringe Abhängigkeiten
• gute Skalierbarkeit
• einfache Integration neuer Anwendungen

Gerade diese Architektur unterscheidet CrowdSec deutlich von klassischen Sicherheitswerkzeugen.

Warum CrowdSec so gut skalierbar ist

Die modulare Bauweise ermöglicht den Einsatz in sehr unterschiedlichen Umgebungen.

Beispiele:

Kleiner VPS

• Agent
• LAPI
• Firewall-Bouncer

Alles läuft auf einem einzigen Server.

Unternehmensnetzwerk

• mehrere Agenten
• zentrale LAPI
• mehrere Firewall-Bouncer
• Reverse-Proxy-Bouncer
• Dashboard

Alle Server liefern ihre Informationen an eine gemeinsame Instanz.

Dadurch lassen sich Angriffe zentral überwachen und verwalten.

Die Architektur von CrowdSec ist bewusst modular aufgebaut und trennt die einzelnen Aufgaben klar voneinander. Während der Agent Logdateien sammelt, bereiten Parser die Daten auf und Szenarien erkennen verdächtige Muster. Die Local API verwaltet alle Informationen und stellt sie den Bouncern zur Verfügung, die schließlich die eigentlichen Schutzmaßnahmen umsetzen.

Dieses Zusammenspiel sorgt dafür, dass CrowdSec flexibel, leistungsfähig und hervorragend skalierbar ist – vom einzelnen Debian-Server bis hin zu komplexen Unternehmensumgebungen mit mehreren Hosts und unterschiedlichen Schutzmechanismen.

Im nächsten Teil der Serie lernen Sie die wichtigsten Befehle der Kommandozeile kennen. Mit cscli verwalten Sie Collections, Parser, Szenarien, Warnungen und Entscheidungen und erhalten einen umfassenden Überblick über den aktuellen Sicherheitsstatus Ihres Systems.