In diesem Beitrag beschreibe ich kurz, was CrowdSec ist, welche Zertifizierungen ich abgeschlossen habe, wie ich CrowdSec auf der E.F.A. (Email Filter Appliance) integriert habe, welche Filter out-of-the-box funktionieren — und wie ich fehlende Unterstützung (z. B. für MailScanner) durch eigene Parser und Szenarios ergänze.

Was ist CrowdSec?

CrowdSec ist eine Open-Source-Plattform zur Erkennung und Abwehr von bösartigen Aktivitäten anhand von Log-Analysen. Der Kern besteht aus einem lokalen Agenten, der Logs einliest, Ereignisse korreliert und auf Basis von Signalen (sogenannte scenarios) Entscheidungen trifft. Erkenntnisse können lokal genutzt oder an die Community-Sharing-Plattform gesendet werden, um die Reputationen von IPs zu teilen.

Meine Zertifizierungen

Ich habe mehrere Zertifizierungen rund um CrowdSec durchlaufen, die mir geholfen haben:

• Verständnis der Architektur (agent, bouncer, hub)
• Erstellung eigener Parser und Szenarios
• Integration mit externen Diensten (z. B. Firewalls, API-basierte Bouncer)

Die Zertifizierungen haben vor allem im Bereich Log-Modelling und Scenario-Design meine Fähigkeit verbessert, aus oft heterogenen Mail-Logs zuverlässige Signale zu extrahieren.

CrowdSec auf der E.F.A. (Email Filter Appliance)

Auf meiner E.F.A. läuft ein Satz klassischer Mail-Dienste (sshd für Remote-Management, postfix für SMTP, SpamAssassin und MailScanner für Mailprocessing). CrowdSec lässt sich gut auf der E.F.A. betreiben und bringt sofort Mehrwert:

• Out-of-the-box: Für viele Dienste existieren bereits Parser & Szenarios — z. B. sshd, postfix, webserver-logs, und mehr.
• Mail-spezifische Lücken: Für MailScanner gibt es jedoch zum Zeitpunkt meiner Integration kein fertiges Parser-/Scenario-Paket.

Warum kein MailScanner-Support vorhanden ist

MailScanner ist in vielen Installationen ein wichtiger Teil der Mailpipeline. Da seine Logstruktur teils proprietär oder stark konfigurierbar ist, existieren nicht immer allgemeingültige Parser. Außerdem sind Mail-Logs oft sehr rauschbehaftet — viele Events sind normal und müssen gefiltert werden.

Meine Lösung: Eigene Parser & Szenarios

Ich habe deshalb eigene parsers (für die Log-Formate) und scenarios (für die Erkennung von Angriffs-/Missbrauchsmustern) geschrieben. Hier die konkreten Beispiele:

Parser a) MailScanner Spam Blacklist

name: cbrandlehner/mailscanner-spam-blacklist
description: Parse MailScanner spam logs for blacklisted senders
onsuccess: next_stage
filter: "evt.Parsed.program == 'MailScanner'"
grok:
  pattern: 'Message %{NOTSPACE:message_id} from %{IP:source_ip} \(%{EMAILADDRESS:from_email}\) to %{NOTSPACE:to_domain} is spam \(%{WORD:spam_reason}\)'
  apply_on: message
statics:
  - meta: log_type
    value: mailscanner_blacklist
  - meta: source_ip
    expression: evt.Parsed.source_ip
  - parsed: source_ip
    expression: evt.Parsed.source_ip
  - parsed: spam_reason
    expression: evt.Parsed.spam_reason
  - parsed: rawmessage
    expression: evt.Line.Raw

Parser b) MailScanner Spam mit Score

name: cbrandlehner/mailscanner-spam
description: Parse MailScanner spam logs
onsuccess: next_stage
filter: "evt.Parsed.program == 'MailScanner'"
grok:
  pattern: 'Message %{NOTSPACE:message_id} from %{IP:source_ip} \(%{EMAILADDRESS:from_email}\) to %{NOTSPACE:to_domain} is spam.*(score|Wertung)=%{NUMBER:spam_score}'
  apply_on: message
statics:
  - meta: log_type
    value: mailscanner_spam
  - meta: source_ip
    expression: evt.Parsed.source_ip
  - parsed: source_ip
    expression: evt.Parsed.source_ip
  - parsed: spam_score
    expression: float(evt.Parsed.spam_score)
  - parsed: rawmessage
    expression: evt.Line.Raw

Scenario c) Blacklisting sofort sperren

name: cbrandlehner/mailscanner-blacklisted
description: Detects MailScanner logs where a message is marked as spam due to blacklisting
type: trigger
filter: "evt.Meta.log_type == 'mailscanner_blacklist' && evt.Parsed.spam_reason == 'blacklisted'"
groupby: evt.Parsed.source_ip
blackhole: 5m
labels:
  type: spam
  remediation: true
  behavior: "smtp:spam"
  spoofable: 0
  confidence: 2
  label: "MailScanner detected an SMTP message from an blacklisted sender"
  service: smtp

Scenario d) SPAM mit sehr hohem Score

name: cbrandlehner/mailscanner-highscore-spam
description: Detects spam messages in MailScanner logs with score > 20.0
type: leaky
filter: "evt.Meta.log_type == 'mailscanner_spam' && float(evt.Parsed.spam_score) > 20.0"
groupby: evt.Parsed.source_ip
leakspeed: 10s
capacity: 1
blackhole: 5m
labels:
  type: spam
  remediation: true
  behavior: "smtp:spam"
  spoofable: 0
  confidence: 1
  label: "MailScanner classifed an SMTP email as SPAM with a spam_score higher 20"
  service: smtp

Testing & Deployment

Meine Vorgehensweise:

1. Parser lokal gegen historische Logs testen (benchmarks, grep + regex)
2. Scenarios in simulation mode laufen lassen, Alerts sammeln
3. False-Positives analysieren und Regex/Filter verbessern
4. Produktion: Szenarien schrittweise aktivieren und Monitoring ergänzen

Tipps & Best-Practices

• Nutze labels im Parser, damit Szenarien gezielt filtern können.
• Beginne mit conservative thresholds und verfeinere.
• Verwende CrowdSec-Community-Feeds, aber prüfe sie — nicht alle Blocks sind in jeder Umgebung sinnvoll.

Fazit

CrowdSec ist ein mächtiges Werkzeug für die Absicherung von Mail-Infrastrukturen — auf der E.F.A. liefert es sofort Mehrwert für viele Standarddienste. Für spezielle Tools wie MailScanner lohnt sich jedoch die Erstellung eigener Parser und Szenarios: so kannst du präzise Signale erzeugen und die False-Positive-Rate niedrig halten.

Den vollständigen Parser, die Szenarien, die Collection und meine Test-Scenarios habe ich als Pull Request zur Diskussion auf GitHub veröffentlicht: PR #1500 im CrowdSec Hub.