Security für mailcow — Anleitung

Installation

1. Das Modul steckt im mailcow Toolkit 0.6.0 oder neuer (ein Paket, eine Lizenz pro Produkt). Führe auf dem mailcow-Host als root den Toolkit-Installer wie gewohnt aus: sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>, oder aktualisiere das Toolkit unter System → Updates (Toolkit). Der Installer kopiert data/web/mlw-security/, legt die Tabellen des Moduls in mailcows Datenbank an, ergänzt den Menüeintrag und den minütlichen Timer mlw-mailcow-security-<instance>.timer und lädt php-fpm neu.
2. Öffne System → Security im mailcow-Adminmenü.

Lizenz

Öffne System → Updates (Toolkit) und such die Karte Security for mailcow: Schlüssel einfügen und aktivieren oder den 30-tägigen Test starten. Auf der Shell: php /web/mlw-toolkit/cli.php activate mailcow-security <KEY> in php-fpm-mailcow. Die Lizenz wird täglich geprüft; ohne Internet läuft das Modul 7 Tage nach der letzten erfolgreichen Prüfung.

Ohne gültige Lizenz wird nichts gelesen, erkannt, gesperrt oder gesendet; früher gesetzte Sperren werden trotzdem aufgehoben, wenn sie ablaufen, und der Verlauf bleibt. Nichts wird gelöscht.

Der erste Lauf

Der erste Lauf importiert, was mailcow noch in seinen Protokollen hat (meist die letzten Stunden), und sperrt und warnt dabei nicht. Danach liest der Job jede Minute nur neue Zeilen. Overview → Status zeigt den letzten Lauf; meldet eine Zeile, dass Zeilen verloren gingen, hat mailcow seine Protokolle gekürzt, bevor sie gelesen wurden (ein sehr ausgelasteter Server): Erhöhe LOG_LINES in mailcow.conf.

Was gelesen wird

Quelle	Was zum Datensatz wird
dovecot (redis DOVECOT_MAILLOG)	fehlgeschlagene IMAP- / POP3- / ManageSieve-Anmeldungen (mit Anzahl der Versuche), Verbindungen, die sich nie anmelden, erfolgreiche Anmeldungen
postfix (redis POSTFIX_MAILLOG)	fehlgeschlagenes SMTP AUTH, authentifizierte Sendungen, rspamd-Ablehnungen, Ablehnungen durch DNS-Blocklisten, Relay-Versuche, Protokolltests (Verbindung nach EHLO verloren, Pipelining, TLS-Fehler, postscreen)
SOGo (redis SOGO_LOG)	fehlgeschlagene und erfolgreiche Webmail-Anmeldungen
fail2ban (redis NETFILTER_LOG)	jede Sperre durch mailcows eigenes fail2ban
Webserver (Docker-Log, über den Host-Agent)	4xx-Antworten: bekannte Exploit-Pfade (/.env, /.git, wp-login.php, phpMyAdmin, …) und andere 404
php-fpm (Docker-Log, über den Host-Agent)	fehlgeschlagene Anmeldungen an mailcow-UI und API

Datensätze von privaten Adressen (mailcows eigene Container, ein Reverse Proxy vor mailcow) und von Netzen, die du ignorierst, werden verworfen. Datensätze werden pro Minute, Adresse, Postfach und Quelle gezählt; der Verlauf wird standardmäßig 90 Tage aufbewahrt (Settings).

Übersicht

• Summen der letzten 24 Stunden je Art; ein Klick öffnet die passenden Ereignisse.
• Letzte 14 Tage: fehlgeschlagene Anmeldungen, Scans und Spam pro Tag (die Werte stehen unter Values).
• Status: Modus (nur beobachten oder automatischer Schutz), aktive Sperren, die Sperren von mailcows eigenem fail2ban, offene Vorfälle, der letzte Lauf.
• Aktivste Adressen mit einer Schaltfläche Ban, angegriffene Postfächer, aktive Vorfälle.

Regeln und Vorfälle

Eine Regel zählt Datensätze in einem gleitenden Zeitfenster. Wird die Schwelle erreicht, öffnet sie einen Vorfall; solange der Angriff andauert, wird derselbe Vorfall verlängert, nicht wiederholt.

Regel	Zählt	Standard
Web-Login-Brute-Force	fehlgeschlagene Anmeldungen an SOGo / mailcow-UI / API pro Adresse	5 in 15 min → Sperre 24 h
Langsames Brute Force	fehlgeschlagene Anmeldungen pro Adresse über einen Tag	20 in 24 h → Sperre 24 h
Password Spraying	verschiedene Postfächer, an denen eine Adresse gescheitert ist	5 in 60 min → Sperre 7 Tage
Wiederholungstäter	Sperren einer Adresse durch mailcows fail2ban	3 in 7 Tagen → Sperre 30 Tage
Web-Exploit-Scan	Anfragen nach Exploit- / Leak-Pfaden	3 in 30 min → Sperre 7 Tage
Web-404-Scan	404-Antworten pro Adresse	40 in 30 min → Warnung
Relay-Tests	„Relay access denied“ pro Adresse	3 in 60 min → Sperre 7 Tage
Protokoll-Scan	Verbindungen, die sich nie anmelden oder das Protokoll verletzen	30 in 60 min → Warnung
Spam-Flut	rspamd- und Blocklisten-Ablehnungen pro Adresse	20 in 60 min → Warnung
Angegriffenes Postfach	Fehlschläge an einem Postfach von mindestens 5 Adressen	30 in 60 min → Warnung
Sendeanstieg	von einem Postfach gesendete Nachrichten	300 in 60 min → Warnung
Anmeldungen von vielen Adressen	verschiedene Adressen, von denen sich ein Postfach anmeldet	8 in 60 min → Warnung
Anmeldung nach Fehlschlägen	eine erste Anmeldung von einer Adresse, die an dem Postfach gescheitert ist	3 Fehlschläge in 24 h → Warnung (critical)

Unter Rules kannst du jede Regel ausschalten und ihre Schwelle, ihr Zeitfenster, ihre Aktion und ihre Sperrdauer ändern (0 = dauerhaft). Adressregeln können alert oder ban; Postfachregeln alert, limit sending oder disallow login. Reset to defaults stellt alle wieder her.

Incidents listet die Vorfälle nach Status (offen, gesehen, gelöst, Fehlalarm), Mindestschweregrad und Regel. False positive setzt die Adresse auf die Allowlist und hebt ihre Sperren auf.

Automatische Aktionen

Der Schalter oben unter Rules ist anfangs aus: Das Modul beobachtet nur, und jeder Vorfall sagt, was getan worden wäre („would ban“). Lass es ein paar Tage so, sieh dir die Vorfälle an, passe die Regeln an und schalte ihn dann ein. Vorfälle, deren Angriff noch andauert, werden beim nächsten Lauf behandelt.

Nie automatisch gesperrt:

• private und reservierte Adressen;
• die Allowlist des Moduls (Settings) und die Allowlist von mailcows fail2ban (Configuration → Fail2ban);
• die eigenen öffentlichen Adressen des Servers (aus der Reverse-DNS-Prüfung des Toolkits);
• mit eingeschaltetem protect known addresses (Standard) Adressen, die sich in den letzten 30 Tagen erfolgreich an einem Postfach angemeldet haben — ein Kollege, der sich beim Passwort vertippt, wird nicht ausgesperrt.

Sperren

Eine Sperre setzt die Adresse oder das Netz in mailcows fail2ban-Denylist. mailcows netfilter setzt sie innerhalb einer Minute in der Firewall auf jedem mailcow-Port um, und du siehst sie auf mailcows eigener Fail2ban-Seite. Das Modul hebt sie auf, wenn sie abläuft; eine Sperre, die du auf mailcows Fail2ban-Seite löschst, gilt als aufgehoben.

Bans zeigt die Sperren des Moduls (Grund, von wem, bis wann, Cloudflare-Status), mailcows eigene temporäre fail2ban-Sperren (Lift oder Make it longer), den Rest von mailcows Denylist und den Verlauf. Das Formular oben sperrt eine Adresse oder ein Netz (CIDR) für 1 Stunde bis 30 Tage oder dauerhaft; deine eigene aktuelle Adresse wird abgelehnt.

Ist Manage external in mailcows fail2ban-Einstellungen eingeschaltet, rührt netfilter die Firewall nicht an: Die Seite warnt dich, und deine eigene Firewall muss mailcows Liste umsetzen.

Cloudflare

Liegen die mailcow-Web-Hosts (UI, Webmail) hinter dem Cloudflare-Proxy, erreichen Web-Angriffe mailcow von Cloudflares Adressen aus, und netfilter kann sie nicht stoppen. Wähle unter Settings → Cloudflare bans of the web rules and ticked manual bans oder every ban: Jede Sperre wird dann zusätzlich zu einer IP Access Rule („block“) auf Cloudflare-Kontoebene, die alle Zonen des Kontos abdeckt und zusammen mit der Sperre entfernt wird. Dafür werden die unter System → DNS & Cloudflare gespeicherten Cloudflare-Zugangsdaten genutzt; der Token braucht Account → Account Firewall Access Rules → Edit (der Global API Key kann das). Cloudflare sperrt einzelne Adressen und die Bereiche /16 und /24 (IPv4), /32, /48 und /64 (IPv6).

Eine Adresse, ein Postfach

Klick auf eine Adresse, um ihre Datensätze, die Postfächer, die sie probiert hat, ihre erfolgreichen Anmeldungen, Vorfälle und Sperren, ihr Reverse DNS und Links zu AbuseIPDB, ipinfo und Shodan zu sehen; sperre sie, hebe ihre Sperre auf oder setze sie auf die Allowlist (optional auch auf die von mailcow).

Klick auf ein Postfach, um die Adressen zu sehen, die es probiert haben, mit Fehlschlägen und erfolgreichen Anmeldungen nebeneinander (ein Warnzeichen markiert eine Adresse mit beidem), dazu seine Sendungen, Anmeldungen und Vorfälle. Aktionen, alle über mailcows eigene Funktionen und auch von mailcow protokolliert:

• Disallow login: Das Postfach empfängt weiter Mail, aber niemand kann sich anmelden (mailcows „disallow login“); Allow login again macht das rückgängig.
• End IMAP / POP3 sessions: dovecot trennt die Sitzungen sofort (über den Host-Agent).
• Require a password change bei der nächsten Anmeldung.
• Limit sending auf N Nachrichten pro Stunde (Settings) oder das Limit entfernen.

Warnungen

Unter Settings → Alerts: die E-Mail-Adresse (leer = die Benachrichtigungsadresse des Toolkits), der Telegram-Bot-Token (verschlüsselt; „-“ entfernt ihn) und die Chat-ID, der Mindestschweregrad (Standard: high), die Höchstzahl an Warnungen pro Stunde (der Rest wird in der nächsten Warnung mitgezählt), die Sprache (Englisch oder Rumänisch) und die tägliche Zusammenfassung (nach 07:00). Send a test alert prüft beide Kanäle. Jeder neue Vorfall ab dem gewählten Schweregrad ergibt eine Warnung mit einem Link zu ihm.

Audit-Log und Shell

Audit log listet jede Aktion: Sperren, Aufhebungen, Allowlist-Änderungen, Vorfallstatus, Kontoaktionen, Regel- und Einstellungsänderungen — durch einen Administrator oder durch eine Regel.

In php-fpm-mailcow (docker compose exec -u www-data php-fpm-mailcow …):

php /web/mlw-security/cli.php status
php /web/mlw-security/cli.php ban 203.0.113.7 48 "reason"
php /web/mlw-security/cli.php unban 203.0.113.7

Deinstallation

sudo ./uninstall.sh hebt zuerst jede Sperre des Moduls auf und entfernt dann die Dateien und Timer. Die Tabellen mlw_sec_* bleiben in mailcows Datenbank (und in ihren Backups).