CrowdSec: Mehr als eine Fail2Ban Alternative

Fail2Ban dürfte jedem sicherheitsbedachten Linux-Admin ein Begriff sein.
Es prüft Zugriffe auf vorher definierte Dienste und blockiert IP basierend ab einer bestimmten Anzahl von z.B. fehlgeschlagener Loginversuche diese IP für eine bestimmte Dauer.
Dadurch werden automatisierte Scanversuche und unerwünschte Zugriffe nach vorherigen Auffälligkeiten unterbunden.

Was wäre nun, wenn man seine eigenen entdeckten schlechten Akteure mit anderen Admins teilt?
Hier kommt CrowdSec ins Spiel.

CrowdSec funktioniert für sich alleine isoliert, so kann es optional auch betrieben werden, wie ein feiner granuliertes Fail2Ban, es können Syslog, journald, AWS Cloudtrail/Kinesis, Docker logs, Dateien und sogar der Windows Event Log überwacht werden und mit entsprechenden Szenarien/Parsern sowie Bouncern getriggert und anschließend blockiert werden, dazu in späteren Blogeinträgen detailliert mehr. Ja richtig gelesen, Windows Event Logs, es können auch Windows Server überwacht werden, dieses Feature ist allerdings noch recht neu.

Allerdings ist CrowdSec alles andere als ein Einzelspieler, es bezieht seine Stärke aus der Community, den anderen CrowdSec Usern.
Es ist wie folgt aufgebaut: Jeder von den Usern entdeckter Angriff wird an eine flüchtige Smoke-Datenbank gesendet, diese umfasst Millionen von gemeldeten IPs, dazu die Art und den Zeitpunkt des Angriffes.
Es werden keine sonstigen Details oder Logs übertragen, man handelt hier mit Bedacht auf GDPR Regularien.

Anschließend werden in der sogenannten Konsens Kammer mittels einem User Trust Rank System, Honeypots, Whitelists und Algorithmen entschieden ob es sich um eine Gefahr handelt, oder ob es vielleicht ein false positive oder der Versuch ist, eine IP absichtlich zu diskreditieren.

Wurde ausgehandelt, das die IP definitiv ein Angreifer ist, wird die IP in die Fire-Datenbank, hier befindliche IPs werden an alle aktiv teilnehmenden CrowdSec-User zum bannen übergeben. In diesem Pool befinden sich zehntausende IPs.

Die IPs werden alle 3 Tage auf die aktuelle Gefahrenlage geprüft, niemand hat etwas davon wenn Berge von alten IPs, die keine Gefahr mehr darstellen, unnötig geblockt werden.

Jetzt geht es in die Details, die ich in separaten Beiträgen näher beleuchten werde:

CrowdSec: Installation unter Debian/Ubuntu
CrowdSec: Anfängliches parsen der Daten
CrowdSec: Die Wahl der Angriffsszenarien
CrowdSec: Bouncers, die digitalen Türsteher
CrowdSec: cscli verstehen
CrowdSec: Whitelists erstellen
CrowdSec: Die Web-Konsole

Speichere in deinen Favoriten diesen permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert