Server, die direkt aus dem Internet erreichbar sind, werden früher oder später mit Portscans, Brute-Force-Versuchen und automatisierten Angriffen konfrontiert. Eine klassische Firewall ist dabei nur die erste Verteidigungslinie: Sie kann Ports freigeben oder sperren, erkennt aber nicht automatisch jedes verdächtige Verhalten auf Anwendungsebene. Genau hier setzt CrowdSec an.

Die Open-Source-Lösung analysiert Logdaten, erkennt typische Angriffsmuster und erzeugt daraus Entscheidungen. Mit einer passenden Remediation Component, früher meist „Bouncer“ genannt, können diese Entscheidungen anschließend durch Firewall, Reverse Proxy oder Webserver durchgesetzt werden.

In diesem Beitrag zeigen wir, warum CrowdSec für viele Administratoren eine interessante Alternative zu Fail2Ban ist, wie du CrowdSec installieren kannst und wie du anschließend kontrollierst, ob Erkennung und Blockierung tatsächlich funktionieren.

Was ist CrowdSec?

CrowdSec ist eine leichtgewichtige, kollaborative Intrusion-Detection-Lösung mit optionalen WAF-Funktionen. Technisch arbeitet CrowdSec vereinfacht in mehreren Schritten:

1. Logquellen werden eingelesen.
2. Parser normalisieren die Daten.
3. Szenarien prüfen das Verhalten auf bekannte Angriffsmuster.
4. Aus den erkannten Ereignissen entstehen Entscheidungen.
5. Eine Remediation Component setzt diese Entscheidungen technisch durch.

Ein entscheidender Punkt: Die Security Engine blockiert allein noch keinen Angreifer. Sie erkennt verdächtiges Verhalten und erzeugt Entscheidungen. Für die eigentliche Sperre benötigen Sie beispielsweise den Firewall Bouncer oder einen passenden Nginx-Bouncer.

Zusätzlich bietet CrowdSec eine kollaborative Komponente. Wenn Sie die entsprechenden Funktionen nutzen, können erkannte Angreiferinformationen in die gemeinsame CrowdSec-Infrastruktur einfließen und umgekehrt zur Bewertung von IP-Adressen beitragen.

CrowdSec statt Fail2Ban: Wo liegt der Unterschied?

Auf einem öffentlich erreichbaren Server sind insbesondere SSH, Webserver, Maildienste und andere Netzwerkdienste interessante Ziele für automatisierte Angriffe. Fail2Ban ist für solche Fälle weiterhin eine bewährte und schlanke Lösung. CrowdSec geht das Problem jedoch etwas anders an: Die Security Engine erkennt Verhalten und erzeugt Decisions, während separate Remediation Components diese Entscheidungen beispielsweise über die Firewall oder einen Webserver umsetzen. Zusätzlich kann CrowdSec bei entsprechender Konfiguration Community-Blocklists und Central-API-Daten einbeziehen.

Ein typisches Beispiel ist ein SSH-Brute-Force-Angriff: Statt einzelne Fehlversuche isoliert zu behandeln, wertet CrowdSec Ereignisse als Muster aus und kann daraus eine Ban-Entscheidung erzeugen. Ob CrowdSec für deinen Server wirklich besser als Fail2Ban ist, hängt vom Einsatzzweck ab. Für einen einzelnen, möglichst einfachen SSH-Schutz kann Fail2Ban völlig ausreichen. Sobald mehrere Dienste, verschiedene Bouncer oder zentralere Entscheidungsquellen interessant werden, wird CrowdSec deutlich spannender.

Das ergänzt klassische Hardening-Maßnahmen sinnvoll. Auch die Deaktivierung von Passwort-Logins zugunsten von SSH-Keys bleibt wichtig. Mehr dazu finden Sie in unserem Beitrag SSH-Login per Passwort deaktivieren.

CrowdSec installieren unter Debian und Ubuntu

Für Linux stellt CrowdSec ein offizielles Repository bereit. Die aktuelle Dokumentation empfiehlt für Debian-/Ubuntu-Systeme die Installation über das CrowdSec-Repository.

1. Repository einrichten

curl -s https://install.crowdsec.net | sudo sh

Danach installieren Sie die Security Engine:

sudo apt install crowdsec

Anschließend können Sie die installierte Version prüfen:

sudo cscli version

CrowdSec unterstützt neben Debian und Ubuntu auch weitere Linux-Distributionen. Für produktive Systeme sollten Sie sich dabei an die jeweils aktuelle Installationsdokumentation des Herstellers halten.

2. Prüfen, ob CrowdSec läuft

Nach der Installation sollte zunächst der Dienst selbst funktionieren:

sudo systemctl status crowdsec

Zusätzlich lohnt sich ein Blick auf die Logdatei:

sudo tail -f /var/log/crowdsec.log

Die aktuelle CrowdSec-Dokumentation verwendet die lokale Logdatei unter Linux als einen der wichtigsten Ausgangspunkte für Fehlersuche und Diagnose.

3. Logdaten und Erkennung kontrollieren

CrowdSec ist nur dann nützlich, wenn die relevanten Logs tatsächlich eingelesen und verarbeitet werden. Dafür stellt die Software umfangreiche Metriken bereit.

Ein guter erster Check ist:

sudo cscli metrics show acquisition parsers

Hier sollten die konfigurierten Datenquellen auftauchen. Besonders wichtig ist, dass Logs gelesen und erfolgreich geparst werden.

Auf einem typischen Linux-Server können beispielsweise SSH-, System- oder Webserver-Logs relevant sein. In aktuellen CrowdSec-Setups kann der Installations-Wizard vorhandene Dienste erkennen und passende Logquellen vorbereiten. Trotzdem sollten Administratoren die tatsächliche Erfassung immer über die Metriken prüfen.

Wenn Sie sehen, dass eine erwartete Logquelle fehlt oder keine Zeilen verarbeitet werden, liegt das Problem häufig nicht bei der Erkennung selbst, sondern bereits bei der Acquisition-Konfiguration.

4. Collections passend zum Server installieren

CrowdSec arbeitet mit sogenannten Collections, die passende Parser und Szenarien für bestimmte Technologien bündeln. Welche Collections sinnvoll sind, hängt von Ihrem Stack ab.

Installierte Konfigurationen sehen Sie beispielsweise mit:

sudo cscli hub list

Eine Collection wird über cscli installiert, zum Beispiel für Nginx:

sudo cscli collections install crowdsecurity/nginx

Danach sollten Sie die Konfiguration erneut kontrollieren und anschließend die Metriken prüfen.

Für produktive Systeme empfiehlt es sich außerdem, die CrowdSec-Hub-Daten regelmäßig aktuell zu halten:

sudo cscli hub update
sudo cscli hub upgrade

Damit aktualisieren Sie zunächst den verfügbaren Index und anschließend die bereits installierten Parser, Szenarien und Collections auf den aktuellen Stand.

5. CrowdSec tatsächlich blockieren lassen

Hier kommt ein wichtiger Unterschied ins Spiel: CrowdSec erkennt, der Remediation Component setzt durch.

Für klassische Linux-Dienste wie SSH ist der Firewall Bouncer interessant. Auf Debian und Ubuntu kann beispielsweise der nftables-Bouncer installiert werden:

sudo apt install crowdsec-firewall-bouncer-nftables

Alternativ gibt es für Systeme mit iptables den entsprechenden Bouncer:

sudo apt install crowdsec-firewall-bouncer-iptables

Welche Variante korrekt ist, hängt von Ihrem Firewall-Stack ab. Bei einem aktuellen Linux-System lässt sich beispielsweise prüfen, ob iptables auf das nftables-Backend zeigt:

iptables -V

Wenn dort nf_tables erscheint, ist nftables im Einsatz.

Der Firewall Bouncer holt Entscheidungen von der CrowdSec Local API und pflegt daraus eine Blockliste im jeweiligen Firewall-Stack. So können erkannte Angreifer auf IP-Ebene geblockt werden.

Webserver sind ein Sonderfall

Wenn Sie nicht nur SSH oder andere Netzwerkdienste schützen, sondern einen Webserver oder Reverse Proxy absichern möchten, ist ein passender Webserver-Bouncer häufig die bessere Wahl.

Für Nginx bietet CrowdSec beispielsweise den crowdsec-nginx-bouncer. Dieser kann Entscheidungen direkt im Webserver durchsetzen und lässt sich außerdem mit den AppSec-/WAF-Funktionen von CrowdSec kombinieren.

Das ist besonders interessant, wenn Sie Anwendungen gegen typische Angriffe auf HTTP-Ebene schützen möchten und nicht ausschließlich ganze IP-Adressen sperren wollen.

6. Aktive Entscheidungen überprüfen

Ob CrowdSec tatsächlich Sperrentscheidungen erzeugt, können Sie direkt über cscli prüfen:

sudo cscli decisions list

Eine Entscheidung enthält unter anderem die betroffene IP, den Grund beziehungsweise das Szenario und die Art der Maßnahme.

Für einen einzelnen Testfall können Sie gezielt nach einer IP suchen:

sudo cscli decisions list -i 203.0.113.10

Die Beispiel-IP ist ein Platzhalter und nicht als reale Adresse eines Angreifers gedacht.

7. Typische Fehler bei CrowdSec

Ein häufiger Denkfehler ist die Annahme, dass die Installation allein den Server automatisch schützt. Nach der Installation sollten Sie daher immer drei Dinge prüfen:

• Werden die richtigen Logs eingelesen?
• Werden Ereignisse durch Parser und Szenarien erkannt?
• Ist eine passende Remediation Component aktiv?

Wenn keine Entscheidungen auftauchen, obwohl auf dem Server offensichtliche Login- oder Webangriffe stattfinden, beginnen Sie mit:

sudo cscli metrics show acquisition parsers

und anschließend:

sudo cscli decisions list

Bei Problemen hilft außerdem die CrowdSec-Logdatei unter /var/log/crowdsec.log.

Ein zweiter wichtiger Punkt sind Whitelists. Eigene Administrator-IP-Adressen und interne Netze sollten so berücksichtigt werden, dass Sie sich nicht versehentlich selbst aussperren. CrowdSec bringt dafür eigene Allowlisting-/Whitelist-Mechanismen mit.

CrowdSec ist ein Baustein, kein vollständiges Sicherheitskonzept

CrowdSec kann einen Linux-Server deutlich besser gegen automatisierte Angriffe absichern, ersetzt aber keine grundlegenden Sicherheitsmaßnahmen.

SSH-Keys statt Passwort-Login, aktuelle Pakete, eine restriktive Firewall, saubere Benutzer- und Rechtekonzepte, Backups und zuverlässiges Monitoring gehören weiterhin zum Fundament eines sicheren Serverbetriebs.

Gerade die Kombination aus Hardening, Monitoring und automatisierter Angriffserkennung ist im professionellen Betrieb entscheidend. Beim SSH-Hardening lohnt sich deshalb auch unser Beitrag SSH-Login per Passwort deaktivieren und nur noch SSH-Keys erlauben. Für das anschließende Monitoring deiner Infrastruktur zeigen wir außerdem in Was ist Checkmk?, wie sich Systeme und Dienste zentral überwachen lassen.

Fazit: Linux-Server mit CrowdSec schützen

CrowdSec ist vergleichsweise leichtgewichtig und lässt sich gut in bestehende Linux-Umgebungen integrieren. Die grundlegende Architektur ist einfach: Logs werden erfasst, Angriffsmuster erkannt, daraus Entscheidungen erzeugt und diese über eine Remediation Component technisch durchgesetzt.

Gerade für öffentlich erreichbare Linux-Server ist das ein sinnvoller zusätzlicher Schutz gegen automatisierte Angriffe. Entscheidend ist dabei nicht nur die Installation selbst, sondern die anschließende Kontrolle von Log-Acquisition, Parsern, Szenarien und aktiven Entscheidungen.

Wer seine Linux-Infrastruktur nicht nur absichern, sondern auch dauerhaft professionell betreiben möchte, findet auf der offiziellen Seite von ADMIN INTELLIGENCE weitere Informationen zu Linux-Servern, Security, Monitoring und dem professionellen Betrieb von IT-Infrastrukturen.

Für die technische Umsetzung in diesem Beitrag sind vor allem die offizielle CrowdSec-Dokumentation zur Linux-Installation und die Dokumentation zum Linux Firewall Bouncer relevant. Die aktuelle Dokumentation macht dabei ausdrücklich deutlich, dass die Security Engine selbst nur erkennt und erst eine Remediation Component die Entscheidungen tatsächlich durchsetzt. Für die Kontrolle der aktiven Entscheidungen kannst du anschließend sudo cscli decisions list verwenden.