Die meisten Wallboxen haben genau einen OCPP-WebSocket. Lokal soll trotzdem der eigene Regler Strom und Phasen setzen — MQTT, HTTP, Modbus, nicht das Backend in der Cloud. Gleichzeitig sollen Dienste wie ein Enphase IQ Energy Router, EverHome oder Monta live mitlesen. Wer den einen Slot an ein Vendor-CSMS hängt, gibt die Steuerung oft stillschweigend ab.

Dieser Beitrag beschreibt die Problemstellung und wie ein eigenes Open-Source-Projekt sie löst: ocpp-fanout.

Ausgangslage

OCPP 1.6-J ist der Kanal, den die Wallbox für die Backend-Kommunikation hat. Ein Slot heißt: eine WebSocket-URL. Alles, was die Box als CSMS ansieht, darf CallResults liefern — und in der Praxis auch Befehle schicken: SetChargingProfile, RemoteStart, ChangeConfiguration.

Ich will drei Dinge gleichzeitig:

1. Laden, Phasen, Start/Stop durch den lokalen Regler
2. Die Box bleibt OCPP-online
3. Enlighten, EverHome und Monta sehen Live-Daten, ohne die Box zu übernehmen

Das widerspricht sich, sobald das „Monitor“-Backend ein volles CSMS ist.

Das Problem

Viele Monitor-Backends sind keine reinen Zuschauer. Sie schicken Calls zur Wallbox. Ohne CallResult gilt die Box in der App als tot. Mit unkontrollierter Weiterleitung übernimmt das Backend die Ampere. Beides ist falsch, wenn der lokale Regler die Ladeleistung setzt.

Konkret:

• Enphase IQ Energy Router sendet laufend GetConfiguration und TriggerMessage(StatusNotification). Ohne lokale Antwort bleibt Enlighten leer, obwohl der WebSocket steht. Leitet man SetChargingProfile durch, springen die Ampere — der Router soll im Monitor-Modus zuschauen, nicht laden.
• EverHome spricht WebSocket ohne Subprotokoll ocpp1.6. Ein Standard-OCPP-Proxy bricht mit Server sent no subprotocol ab.
• Monta braucht CallResults, optional RemoteStart und stimmige StartTransaction / transactionId. Ein Dummy, der andere IDs vergibt, füllt das Ladeprotokoll nicht.

Die Wallbox kann das nicht gleichzeitig erfüllen. Es gibt nur einen Slot.

Ein Splitter allein reicht nicht

joulo-ocpp-proxy macht genau den Split 1→N: eine eingehende Verbindung, ein Primary mit voller Kontrolle, beliebig viele Secondaries als Spiegel. Secondary zur Wallbox wird verworfen. Das ist gewollt: ein Secondary darf die Box nicht fernsteuern.

Richtung	Primary	Secondary
Wallbox → CSMS	weitergeleitet	gespiegelt
CSMS → Wallbox	weitergeleitet	verworfen

Genau dort kippt der Plan. Die Monitor-Backends schicken trotzdem Calls. Joulo wirft sie weg und antwortet nicht an ihrer Stelle. Es gibt kein CallResult, die Vendor-App bleibt ohne Live-Status (historische kWh können trotzdem erscheinen).

Joulo hat außerdem nur einen Schalter SECONDARY_CSMS_APPEND_CHARGE_POINT_ID. Enphase will die Charge-Point-ID in der URL, EverHome und Monta haben die Identität oft schon im Pfad. Ein Flag für alle Secondaries passt nicht.

Die Lösung: ocpp-fanout

Ich habe Joulo nicht geforkt. Der Proxy bleibt das Image von ghcr.io. Davor und dahinter sitzt eigener Code: ein Dummy-Primary, kleine Antwort-Shims und eine Web-UI.

Drei Ergänzungen schließen die Lücken:

1. dummy-csms als Primary. Die Box braucht irgendwohin einen Peer, der CallResults liefert ([3, id, payload]), sonst gilt sie als offline. Der Dummy tut das. Eigene Steuerung sendet er nicht. POST /inject ist der einzige Weg, über Joulo einen CSMS-Call zur Box zu schicken — und der Endpunkt hängt nur am Compose-Netz, nicht am Host.
2. Shims zwischen Joulo und jedem knickrigen Secondary. Joulo sieht einen normalen OCPP-1.6-Peer. Der Shim spricht upstream so, wie der Vendor es wirklich tut. Standard: CSMS-Calls lokal beantworten, die Wallbox sieht sie nie. Allowlist in der Setup-UI: ausgewählte Calls werden auf der Primary-Leitung injiziert, Joulo leitet sie zur Box, CallResult kommt zurück zum Vendor.
3. Web-UI auf demselben Host: Live-Paketfluss, Setup für Backend-URLs und Allowlist, Dark/Light. Erlaubte Befehle gelten sofort. Den Stack neu starten muss man nur nach URL-Änderung.

Ein Image, drei Shim-Dienste (SHIM_NAME / SHIM_PORT): Enphase, EverHome, Monta.

Wer darf was

Ziel	Wer
Laden, Phasen, Start/Stop	lokaler Regler (MQTT / Enphase HTTP, nicht OCPP)
Box bleibt OCPP-online	Dummy-CSMS als Primary
Enlighten / EverHome / Monta sehen Live-Daten	Secondaries über Shims
Ausgewählte CSMS-Befehle dürfen zur Box	Setup-Allowlist → Dummy-Inject durch Joulo
Alles andere bleibt von der Box fern	Shim antwortet lokal, UI zeigt dropped

Die Wallbox zeigt auf einen WebSocket: ws://<host>:9100/<chargePointId>.

Was die Shims konkret tun

• Enphase: lokale Antworten auf GetConfiguration und TriggerMessage. Wer Live-Status in Enlighten will, erlaubt in Setup TriggerMessage:StatusNotification. SetChargingProfile bleibt von der Allowlist fern, solange der Router nur beobachten soll.
• EverHome: WebSocket ohne Subprotokoll ocpp1.6, sonst kommt die Verbindung nicht zustande.
• Monta: CallResults, optionales RemoteStart (nur wenn allowlisted), transactionId auf MeterValues / StopTransaction auf die von Monta vergebene ID mappen, StartTransaction nachspielen, wenn schon eine Session offen ist.

Spec-konforme lokale Antworten gibt es auch für RFID-Liste und Clear Profile (Accepted), ohne die Box zu beschreiben.

Sichtbarkeit

Ohne UI rät man, welcher Call wo landet. Die Live-Ansicht zeigt den Paketfluss: Wallbox, Proxy, Dummy, Shims, Backends — und den Korb dropped für alles, was der Secondary nicht zur Box durchreicht.

Beim Laden zeigt die EV-Karte Phasen, Ampere je Phase und kW aus den MeterValues (Current.Import L1/L2/L3 und Power.Active.Import).

Betrieb

Zwei Compose-Dateien: voller Stack mit Healthchecks und rotierten Logs, oder eine einfache Variante ohne Healthchecks, in der Charge-Point-ID, Backend-URLs und Allowlist nur in der Setup-UI stehen. Compose baut Dummy, Shim und UI lokal; Joulo kommt von ghcr.io.

git clone https://github.com/cbrandlehner/ocpp-fanout.git
cd ocpp-fanout
git checkout v1.0.0
cp .env.example .env
docker compose up -d --build

Web-UI: http://<host>:8088/. Den OCPP-WebSocket (Standardport 9100) und die Setup-UI nicht ins öffentliche Internet legen. Strom und Phasen gehören zum lokalen Regler, nicht zum Secondary, es sei denn, ein Befehl steht bewusst auf der Allowlist.

Quellcode und Release 1.0: github.com/cbrandlehner/ocpp-fanout, Tag v1.0.0. Deutsche Bedienung: docs/ANLEITUNG.md.

Hinweis

ocpp-fanout ist ein unabhängiges Open-Source-Projekt ohne Herstellersupport. Es steht in keiner Verbindung zu go-e, Enphase, everHome, Monta, Joulo, Tesla oder anderen Anbietern, deren Produkte es ansprechen kann, und wird von diesen weder unterstützt noch empfohlen. Nutzung auf eigene Gefahr. Produktnamen dienen nur der Beschreibung der Anbindung.

Fazit

Ein OCPP-Slot kann nicht gleichzeitig lokaler Regler und drei Vendor-CSMS sein. Joulo teilt 1→N und hält Secondary-Steuerung von der Box fern — das allein lässt Enlighten, EverHome und Monta aber tot aussehen, weil ihnen die CallResults fehlen. ocpp-fanout ergänzt Dummy, Shims und UI: die Secondaries bleiben am Leben, Antworten sind lokal, und nur eine explizite Allowlist darf einen Befehl zur Wallbox injizieren. Die Steuerung bleibt, wo sie hingehört.

HP iLO 4 spricht ein TLS, das moderne Browser und aktuelle OpenSSL-Bibliotheken ablehnen. Ein Reverse Proxy mit gültigem Zertifikat davor ist der pragmatische Weg: GET /redfish/v1 funktioniert, aber POST auf die Reset-Action kommt mit HTTP 502 vom Proxy zurück.

Zwei unabhängige Ursachen, beide typisch für iLO 4 hinter Traefik 3.

Warum überhaupt ein Proxy?

iLO 4 (ProLiant Gen8) bringt ein BMC-Zertifikat und Cipher-Suiten mit, die heutige Clients nicht mehr akzeptieren. Traefik terminiert TLS nach außen — zum Beispiel mit Let’s Encrypt — und spricht nach innen HTTPS gegen iLO, mit insecureSkipVerify.

Lesezugriffe laufen oft ohne weiteres durch. Schreibende Redfish-Calls, insbesondere Power-On über ComputerSystem.Reset, nicht.

Ursache 1: HTTP/2 und wiederverwendete TLS-Verbindungen

Traefik 3 spricht Backends über HTTPS standardmäßig mit HTTP/2 und hält TLS-Verbindungen offen. iLO 4 kommt damit nicht zurecht. Der Proxy sieht einen kaputten Upstream und antwortet 502 Bad Gateway.

Fix am Service, mit eigenem serversTransport:

http:
  serversTransports:
    iloTransport:
      insecureSkipVerify: true
      disableHTTP2: true
      forwardingTimeouts:
        idleConnTimeout: 1s

  services:
    ilo:
      loadBalancer:
        serversTransport: iloTransport
        passHostHeader: false
        servers:
          - url: "https://ilo.example.internal"

• disableHTTP2: true — HTTP/1.1 zum BMC
• idleConnTimeout: 1s — keine langlebigen Keep-Alive-Verbindungen
• insecureSkipVerify: true — das BMC-eigene Zertifikat
• passHostHeader: false — Host-Header des Backends, nicht des öffentlichen Namens

Ursache 2: fehlender Slash und HTTP 308

Redfish-Actions bei iLO 4 erwarten den trailing slash:

POST /redfish/v1/Systems/1/Actions/ComputerSystem.Reset/

Ohne Slash antwortet iLO mit 308 und einer Location auf die interne BMC-Adresse, nicht auf den öffentlichen Proxy-Namen. Traefik folgt dem Redirect oder scheitert daran — in beiden Fällen oft wieder 502.

Clients müssen die Action-URL mit Slash posten:

POST /redfish/v1/Systems/1/Actions/ComputerSystem.Reset/
Content-Type: application/json

{"ResetType":"On"}

Diagnose

Wenn GET /redfish/v1/ durch den Proxy HTTP 200 liefert, das BMC also erreichbar ist, POST aber 502:

1. Slash an der Action-URL prüfen
2. Traefik-Logs: 308 auf eine interne IP?
3. HTTP/2 und Keep-Alive am serversTransport abschalten

Wenn auch GET 502 liefert, ist das BMC oder der Weg dorthin down — das ist ein anderes Problem.

Fazit

iLO 4 hinter einem modernen Reverse Proxy ist machbar, aber nicht „einfach durchreichen“. Traefik 3 und iLO 4 vertragen sich bei POST nicht von selbst: HTTP/2 und TLS-Keep-Alive müssen raus, und Redfish-Actions brauchen den abschließenden Slash. Danach funktioniert Power-On über Redfish zuverlässig.

Eine liquidierte österreichische GmbH hinterlässt Mail, OneDrive und SharePoint in Microsoft 365. Die Aufbewahrung soll zehn Jahre halten: lesbar, nachvollziehbar, möglichst unveränderlich. Es gibt kein Budget für ein zertifiziertes Archivprodukt, und der Tenant läuft nicht ewig weiter.

Dieser Beitrag beschreibt Ausgangslage, Anforderungen und die Umsetzung eines selbstgebauten Verfahrens — inklusive der Stelle, an der die Microsoft-Konsole und der Export scheinbar nicht zusammenpassen.

Ausgangslage

Nach der Liquidation bleiben die Daten in Microsoft 365, bis jemand sie abzieht. Typische Versuchung: ZIP vom OneDrive, PST aus Outlook, SharePoint-Bibliothek „herunterladen“. Das ist weder vollständig noch nachvollziehbar, und in zehn Jahren will niemand raten, welche ZIP-Datei die richtige war.

Rechtlich relevant sind in Österreich unter anderem Nachvollziehbarkeit, Lesbarkeit und Unveränderbarkeit (BAO, UGB). Das ersetzt kein zertifiziertes DMS und keine Freigabe durch den Steuerberater. Frist und Umfang muss der Steuerberater bestätigen. Die Projektvorgabe hier war bewusst 10 Jahre, nicht die oft zitierte 7-Jahres-Untergrenze.

Dieses Verfahren ist nicht GoBD-zertifiziert, nicht BAO-zertifiziert und kein WORM-Produkt. Was Technik und Betrieb leisten, steht unten; Lücken werden nicht verschwiegen.

Anforderungen

• Originalbytes, nicht nur PDF-Renderings. Mail als MIME (.eml).
• Jede Datei mit SHA-256; Katalog und Blob müssen zusammenpassen.
• Finden ohne den Tresor zu durchsuchen: Excel-Katalog (Filterkopf, keine Makros, keine Formeln).
• Ablage mit Object Lock (Compliance, 10 Jahre), Versioning an. Der Alltagsbenutzer darf holen und Nachträge ablegen, nicht löschen.
• Microsoft-Quelle nur lesen, nichts löschen.
• Dry-Run ist Default. Cloud-Kosten nur mit explizitem Flag.
• Nach der Übergabe arbeitet der Empfänger mit Katalog und eigenem AWS-Zugang. Keine Abhängigkeit von der Werkstatt-Maschine.

Umsetzung

Die Pipeline ist klein und bewusst zweigeteilt.

Steuerung vs. Worker. Ein Laptop orchestriert (Erreichbarkeit, Provisioning, Sync). Der Export lief auf einer Wegwerf-VM. Nach dem Upload in den Tresor ist die VM weg; lokal bleibt nichts, was man in zehn Jahren noch booten müsste.

Microsoft Graph, nur lesen. Berechtigungen: Mail.Read, Files.Read.All, Sites.Read.All, User.Read. Der Archiv-Admin liegt außerhalb der Firmendomäne (*.onmicrosoft.com), nicht im Benutzerstamm der GmbH. App-Registrierung plus Admin-Consent; Secrets nie ins Git.

Originalbytes, Hash, Resume. Dateien und Mails landen als Content-Addressed Store plus Pfadkopie. Daneben SHA-256-Sidecars und Manifeste. Eine SQLite-Job-DB erlaubt Resume nach Abbruch. Das Audit-Log enthält keine Tokens und keine Mail-Bodies.

Katalog, nicht Suche im Bucket. Jeder Lauf schreibt Excel (Katalog.xlsx): ursprünglicher Pfad, Dateiname, Betreff, SHA-256, S3-Schlüssel, Fehler, Laufinfo, eine Blatt-Anleitung. Dieselbe Datei liegt zusätzlich unter einem festen Schlüssel im Bucket. Glacier/S3 bleibt der Tresor.

S3 Object Lock. Bucket in eu-central-1, Versioning an, Object Lock Compliance, Default-Retention 10 Jahre. Compliance lässt sich nicht umgehen — auch nicht als Root. IAM für den Empfänger: Lesen und PutObject für Nachträge (etwa eine Abschlussbilanz), kein Delete.

Übergabe. Paket ohne Secrets: Katalog, kleines CLI, Anleitung. Der Empfänger richtet Access Key und Secret einmal lokal ein (nicht per Chat). Alltag: im Katalog filtern, per Schlüssel holen, SHA-256 prüfen. Nachträge denselben Weg, wieder mit Hash-Zeile im Katalog.

Die Falle: Konsole vs. Export

Die Microsoft-Konsole und der Export messen nicht dieselbe Menge. Eine Abweichung heißt nicht automatisch „es fehlen Dateien“.

Was man sieht	Was es oft ist	Was der Export nimmt
Speicher in GB (Berichte, aktive Sites)	Site plus OneDrive, inklusive Versionen, Papierkorb, Metadaten	nur aktuelle Dateibytes
Websiteinhalte / Kachel „Dokumente“	Dateien und Ordner, oft Cache	nur Graph-file
Nutzungsbericht „Dateien“	inkl. System/Papierkorb, zeitversetzt	Katalogzeilen

In diesem Lauf: rund 13 000 Mails als .eml, rund 3 400 aktuelle SharePoint-Dateien (etwa 11 GB Inhalt). Die Konsole zeigte in der Größenordnung 65 GB. Stichprobe: Office-Dateien mit mehreren Versionen (eine Präsentation 27 MB aktuell, über alle Versionen ein Vielfaches). Große Videos oft nur eine Version. Versionen erklären den Großteil der GB-Lücke; sie sind in dieser Version bewusst nicht mitarchiviert.

Websiteinhalte zählte Dateien plus Ordner und lag dazwischen — unbrauchbar als Soll-Zahl. Persönliches OneDrive war klein; der Speicher saß auf der Team-Site.

Regel: Soll-Zahl für „haben wir alle aktuellen Dateien?“ ist Graph-file bzw. Katalogzeilen, nicht Konsole-GB und nicht Websiteinhalte. Konsole-GB gegen Graph-Quota; Katalog-SHA-256 gegen lokale Blobs.

Was bewusst fehlt

• bereits gelöschte Nachrichten und Dateien (Recycling, Soft-Delete, je nach Tenant)
• alte Dateiversionen (Graph holt /content der aktuellen Version)
• vollständige ACL- und Sharing-Historie
• Teams/Chat, OneNote, Litigation-Hold-Änderungen

Ein Dateitransport (rclone o. ä.) ersetzt kein Archiv-Zertifikat. Metadaten und Berechtigungen hängen vom Backend ab; die Vollständigkeit ist nicht zugesichert. Fehler und Teilmengen müssen über Job-DB und Verify sichtbar bleiben.

Fazit

Für eine liquidierte Firma mit klarer Frist reicht ein selbstgebautes, dokumentiertes Verfahren: Originalbytes, Hash, Katalog, Object Lock, ehrliche Lücken. Es ersetzt kein zertifiziertes DMS und keinen Steuerberater. Wer die Microsoft-Konsole als Soll-Zahl nimmt, sucht Dateien, die der Export nie holen sollte — vor allem alte Versionen.

Viele Heizungsanlagen besitzen Umwälzpumpen, die außerhalb der Heizsaison oft über Monate hinweg stillstehen. Dieses lange Stillstehen kann zum Problem werden: Rotoren verkleben, Lager setzen sich fest und die Pumpe läuft bei Beginn der Heizsaison nicht mehr zuverlässig an.

Der Anwendungsfall

Im Sommer oder in Übergangszeiten bleibt die Pumpe meist komplett ausgeschaltet. Sobald die Heizperiode wieder beginnt, soll sie zuverlässig anlaufen – tut sie das nicht, drohen kalte Räume und im schlimmsten Fall ein kostspieliger Pumpentausch.

Der Workaround mit Shelly

Mit einem Shelly-Relais lässt sich ein einfacher Schutzmechanismus einbauen: Einmal pro Woche wird die Pumpe für ein paar Minuten eingeschaltet. Dadurch bleibt sie beweglich und lässt sich im Herbst wieder problemlos starten.

„Prävention ist günstiger als Reparatur – ein paar Minuten Pumpenlauf pro Woche können viel Ärger vermeiden.“

Integration in die Heizungssteuerung

Damit es keine Konflikte mit der Heizungssteuerung gibt, sollte das Skript am Ende den ursprünglichen Zustand wiederherstellen. Läuft die Pumpe, bleibt sie an – war sie ausgeschaltet, wird sie auch wieder ausgeschaltet.

Beispiel Ablauf:

• Shelly-Timer löst wöchentlich aus
• Pumpe läuft für 2–3 Minuten
• Ursprünglicher Status der Heizungssteuerung wird wieder gesetzt

Beispielskript (Shelly Script)

Das folgende Skript lässt sich direkt im Shelly eintragen:

// Shelly Script: Pumpe wöchentlich kurz einschalten
// Funktion, die nach 60s prüft ob der Eingang aktiv ist
function checkInputAndSwitch() {
  let input = Shelly.getComponentStatus("input:0");
  if (input.state) {
    print("Eingang ist aktiv – Pumpe bleibt EIN");
  } else {
    Shelly.call("Switch.Set", { id: 0, on: false });
    print("Eingang ist aus – Pumpe wird ausgeschaltet");
  }
}

// Schedule erstellen: Montag 09:00 Uhr
Shelly.call("Schedule.Create", {
  enable: true,
  timespec: "0 9 * * 1",  // Montag 09:00
  calls: [
    {
      method: "Switch.Set",
      params: { id: 0, on: true }
    },
    {
      // hier wird das Script selbst gestartet,
      // welches dann den Timer setzt
      method: "Script.Start",
      params: { id: Shelly.getCurrentScriptId() }
    }
  ]
});

// Event-Handler: wenn das Script gestartet wird (durch Schedule)
Shelly.addEventHandler(function (ev, data) {
  if (ev === "script_started") {
    // Timer: 60 Sekunden warten, dann Funktion aufrufen
    Timer.set(60 * 1000, false, checkInputAndSwitch);
  }
});


          

Fazit

Mit wenig Aufwand lässt sich so die Lebensdauer der Pumpe verlängern. Die Kombination aus Shelly-Automatisierung und Timer bietet eine einfache, aber wirkungsvolle Lösung, um teuren Defekten vorzubeugen.

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.

When running a Linux server, which is accessible from the Internet, you will see a lot of failed SSH authentication attemtps.
This article is not about securing your server (ssh-port-change, fail2ban, private/public-key-auth only, ...) but about visualizing these attacks.

A popular tool to visualize time series data is here.

The code and documentation is documented on a GitHub.
It just looks great and providoes all the data we need to build a spy movie style attack dashboard:

Please note, this embedded image is hosted on Github, the copyright is with the author Alexis Couvreur..

The basic idea of his tool ssh-log-to-influx is to utilize a custimzed configuration of RSYNC to send specific event notifications to a custom TCP port in addition to the standard output into /var/log/messages.
So the data flow is like this:

SSHD -- RSYSLOG -- SSH-log-to-Influx -- InfluxDB -- Grafana

The documentation worked pretty well for me with one exception. RSYSLOG was not able to send events to the local TCP port 7070.
After restarting RSYSLOG I saw this in /var/log/messages:

Jan 26 16:21:24 server4711 rsyslogd[148476]: cannot connect to 127.0.0.1:7070: Permission denied [v8.2102.0-5$

After checking the port configuration in Docker I could identify the root cause. The Linux distribution on the particular server had SELinux enabled. So the fix was easy:

semanage port -a -t syslogd_port_t -p tcp 7070

ISC BIND allows for export of statistics using a web UI. This artice can help you avoid a common pitfall on CentOS.


ISC BIND allows for export of statistics using a web UI.
This feature was added in ISC BIND 9.10. So as a first step on your server, check the version:

named -v

The output should look similar to this:

BIND 9.11.26-RedHat-9.11.26-6.el8 (Extended Support Version)

Next add some configuration to /etc/named/named.conf.local

statistics-channels {
inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
};

Warning: If you try to restart ISC BIND now, you will see an error in the LOG saying:
bind couldn't allocate statistics channel 127.0.0.1#8053: permission denied
The warning is caused by SELinux not granting access to port 8053.
You can modify the SWLinux policy using the following command:

semanage port -a -t dns_port_t -p tcp 8053

Now restart the service:

systemctl restart named.service

Finally you will be able to access the statistics UI. Test it by using:

curl http://127.0.0.1:8083/xml

Mounting a NFS share should be an easy task, however you might fail to mount the NFS share.
The ESXi vmkernel.log might show this error:
WARNING: NFS41: NFS41ExidNFSProcess:2054: Server doesn't support the NFS 4.1 protocol


In fact the warning message is correct. As of DSM version 7.0.1 only NFS3 and NFS4 are supported but NOT NFS version 4.1

The problem was discussed on Reddit and the community came up with a solution.

On the Synology NAS edit /etc/nfs/syno_nfs_conf and set nfs_minor_ver_enable=1.
After restarting the NFS service using systemctl restart nfs-server you should be able to connect to the NFS share from your ESXi server.


Update
If you set this configuration, you can no longer save settings in Synology DSM. The only workaround is to change the parameter back.

Today I would no longer use this workaround, but for a short-term connection it can be a practical hack.