Beide Werkzeuge lesen Protokolle und sperren Adressen, und auf den ersten Blick ist CrowdSec ein Fail2ban mit neuerem Code. Der Unterschied ist wesentlicher als das, und er liegt nicht im Alter des Codes, sondern darin, woher die Sperrentscheidung kommt.
Der Aufbau
Fail2ban ist ein einzelner Prozess, der Protokolle liest, Treffer regulärer Ausdrücke zählt und einen Firewall-Befehl aufruft. Jede Entscheidung fällt auf Ihrer Maschine anhand Ihrer Zähler. Nichts wird irgendwohin gesendet, es gibt keine Abhängigkeiten, und die Konfiguration besteht aus Textdateien.
CrowdSec ist zweigeteilt, und das ist das Wichtigste, was man vor der Installation verstehen muss. Der Agent selbst erkennt nur: Er zerlegt Protokolle, wendet Szenarien an und schreibt Entscheidungen in seine eigene Datenbank. Umgesetzt werden die Entscheidungen von einem separaten Programm, dem Bouncer. Ohne installierten Bouncer läuft CrowdSec, zeigt Meldungen, führt eine Entscheidungsliste — und blockiert nichts.
Das ist die häufigste Enttäuschung bei der ersten Bekanntschaft: Das Werkzeug ist installiert, die Angriffe sind sichtbar, und der Datenverkehr fließt genau wie zuvor.
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers list
Der letzte Befehl muss mindestens einen registrierten Eintrag zeigen. Eine leere Liste bedeutet: Es wird nicht blockiert.
Der zweite Unterschied: geteilte Reputation
Fail2ban weiß nur, was bei Ihnen geschehen ist. Eine Adresse, die gestern hundert fremde Server angegriffen hat, ist für es sauber, bis sie bei Ihnen anklopft — und ihre ersten fünf Versuche sind gratis.
CrowdSec sendet Signale über ausgelöste Erkennungen in ein gemeinsames Netz und erhält von dort eine Liste von Adressen, die bei anderen aufgefallen sind. Der praktische Effekt: Ein merklicher Teil des Ratens wird vor dem ersten Versuch abgeschnitten. Besonders wichtig ist das bei verteilten Angriffen — tausende Adressen mit je einem Versuch, wo lokale Zähler definitionsgemäß machtlos sind.
Und hier das, was man vorher wissen sollte: Der Austausch geht in beide Richtungen. Ihren Server verlassen die Adressen der Angreifer und die Typen der ausgelösten Szenarien. Ein vollständig lokaler Betrieb ist möglich — ohne Anmeldung an der Cloud-Konsole —, dann ist Ihnen die gemeinsame Liste aber ebenfalls nicht zugänglich, und der Hauptvorteil entfällt. Das ist eine bewusste Entscheidung und keine Konfigurationskleinigkeit.
Befehle für den Alltag
sudo cscli metrics
sudo cscli alerts list
sudo cscli decisions list
sudo cscli decisions delete --ip 203.0.113.25
metrics beantwortet die Frage, ob die Protokolle überhaupt gelesen werden: Ist die Zahl der zerlegten Zeilen null, ist die Sammlung für Ihren Webserver nicht installiert oder der Protokollpfad falsch. Das ist der zweithäufigste Fall von „läuft und tut nichts“.
sudo cscli collections list
sudo cscli collections install crowdsecurity/nginx
Ressourcen
CrowdSec ist in Go geschrieben und hält seinen Zustand in einer Datenbank. Der Speicherbedarf liegt in der Größenordnung von hundert Megabyte, dazu der Bouncer. Auf einem Server mit einem Gigabyte ist das spürbar, ab zwei nicht mehr. Fail2ban ist leichter — und leistet weniger.
Lohnt sich beides
Sie geraten sich nicht ins Gehege: Das eine schreibt seine Regeln in die Firewall, das andere seine, und eine doppelt gesperrte Adresse schadet nicht. Eine sinnvolle Aufteilung sieht so aus.
CrowdSec übernimmt das Massengeschäft: SSH-Raten, das Abklappern des Webservers, bekannte schlechte Adressen aus der gemeinsamen Liste. Fail2ban bleibt dort, wo Sie ein eigenes Protokoll in eigenem Format haben, für das ein regulärer Ausdruck einfacher zu schreiben ist als ein Szenario — eine selbst entwickelte Anwendung, ein seltener Dienst, ein besonderes Anmeldeformular.
Müssen Sie sich für eines entscheiden, gilt: Auf einem Server mit Website, an der ständig herumprobiert wird, bringt CrowdSec dank der gemeinsamen Liste mehr. Auf einem Server, der nur Ihnen per SSH mit Schlüsseln offensteht, ist der Unterschied gering — dort ist der Großteil der Arbeit bereits durch abgeschaltete Passwörter erledigt.
Eine gemeinsame Grenze
Keines von beiden schützt vor einer Schwachstelle in einer Anwendung. Beide arbeiten mit Anfragefrequenz und Adressreputation, und eine Anfrage, die eine Lücke in einem Plugin beim ersten Versuch von einer sauberen Adresse ausnutzt, geht an beiden vorbei. Das ist die Aufgabe anderer Werkzeuge — einer WAF auf Anfrageebene und rechtzeitiger Updates. Adressen zu sperren nimmt den Hintergrund weg, nicht die Ursache.
Der praktische Wert beider hängt davon ab, ob jemand das Ergebnis ansieht. Eine steigende Zahl von Entscheidungen, ein erstmals ausgelöstes Szenario, ein Wechsel der Länder, aus denen die Versuche kommen — das ist die Information, für die das Werkzeug installiert wurde. Wie sie auf einer Seite aussieht, zeigt die Demo unten.