mailcows eingebautes fail2ban macht eine Sache gut: Es fängt die lautesten Angriffe. Zehn fehlgeschlagene Anmeldungen in zehn Minuten bringen eine dreißigminütige Sperre. Danach vergisst es sie.
Alles Leisere kommt durch. Eine Adresse, die den ganzen Tag alle paar Minuten ein Passwort probiert. Ein Botnetz, das seine Versuche über hunderte Adressen verteilt, sodass keine einzelne den Schwellwert auslöst. Ein Scanner, der dein Webmail nach /.env oder wp-login.php durchsucht. Ein Postfach, dessen Passwort erraten wurde und das jetzt Spam versendet. Guter Schutz gegen Brute-Force auf deinem mailcow muss all das sehen, sich daran erinnern und nur handeln, wenn du es sagst.
Genau das macht Security für mailcow. Es liest, was mailcow ohnehin protokolliert, speichert den Verlauf in der mailcow-Datenbank, wendet 13 Regeln für das an, was fail2ban übersieht, und sperrt über mailcows eigenen netfilter — so gebaut, dass es dich nicht aussperren kann. Dieses Tutorial führt dich von der Installation bis zu einer eingestellten, automatischen Konfiguration.
Voraussetzungen
Bevor du loslegst, prüfe, ob du Folgendes hast:
- mailcow-dockerized unter Linux mit docker compose und systemd.
- Das mailcow Toolkit 0.6.0 oder neuer — dieses Produkt ist eines der Module in diesem Paket, mit eigener Lizenz.
- Root-Zugriff auf dem Host, um
install.shauszuführen. - Ausgehendes HTTPS vom Server zu
medialab.worksfür die Lizenzprüfung. - mailcows laufenden netfilter-Container — er wendet die Sperren an. Wenn in mailcows fail2ban-Einstellungen Manage external aktiv ist, rührt netfilter die Firewall nicht an und deine eigene Firewall muss mailcows Liste anwenden.
- Optional: ein Cloudflare-Token mit Account → Account Firewall Access Rules → Edit und ein Telegram-Bot-Token, wenn du Telegram-Warnungen möchtest.
Schritt 1 — Toolkit installieren und System → Sicherheit öffnen
Führe auf dem mailcow-Host als root den Toolkit-Installer wie gewohnt aus:
sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>
Wenn du das Toolkit bereits betreibst, aktualisiere es stattdessen über System → Updates (Toolkit).
Der Installer kopiert data/web/mlw-security/, legt die Tabellen des Moduls in mailcows Datenbank an, fügt den Menüpunkt und den minütlichen Timer mlw-mailcow-security-<instance>.timer hinzu und lädt php-fpm neu. Öffne dann System → Sicherheit im mailcow-Adminmenü.
Schritt 2 — Lizenz aktivieren
Öffne System → Updates (Toolkit) und suche die Karte Security für mailcow: Füge den Schlüssel ein und aktiviere ihn, oder starte die 30-tägige Testphase. Auf der Shell, innerhalb von php-fpm-mailcow:
php /web/mlw-toolkit/cli.php activate mailcow-security <KEY>
Ohne gültige Lizenz wird nichts gelesen, erkannt, gesperrt oder versendet — bestehende Sperren werden beim Ablauf aber weiterhin aufgehoben, und nichts wird gelöscht. Details stehen im Benutzerhandbuch.
Schritt 3 — Verstehen, was gelesen wird
Der erste Lauf importiert, was mailcow noch in seinen Logs aufbewahrt (meist die letzten Stunden), und sperrt oder warnt nicht. Ab dann liest der Job jede Minute nur neue Zeilen aus Quellen, die mailcow ohnehin schreibt:
- dovecot — fehlgeschlagene IMAP- / POP3- / ManageSieve-Anmeldungen mit Versuchszählern, Verbindungen, die sich nie anmelden, erfolgreiche Anmeldungen.
- postfix — fehlgeschlagenes SMTP AUTH, authentifizierte Sendungen, rspamd- und DNS-Blocklist-Abweisungen, Relay-Versuche, Protokoll-Scans.
- SOGo — fehlgeschlagene und erfolgreiche Webmail-Anmeldungen.
- fail2ban — jede Sperre, die mailcows eigenes fail2ban verhängt.
- Webserver — 4xx-Antworten, einschließlich bekannter Exploit-Pfade und anderer 404er.
- php-fpm — fehlgeschlagene Anmeldungen an mailcow-UI und API.
Datensätze privater Adressen (mailcows eigene Container, ein Reverse Proxy vor mailcow) und von Netzwerken, die du ignorierst, werden verworfen. Der Verlauf wird standardmäßig 90 Tage aufbewahrt. Wenn Übersicht → Status meldet, dass Zeilen verloren gingen, hat mailcow seine Logs gekürzt, bevor sie gelesen wurden — erhöhe LOG_LINES in mailcow.conf.
Schritt 4 — Den Angriffsverlauf lesen
Gehe zu Übersicht. Du bekommst die Summen der letzten 24 Stunden pro Art, ein Diagramm über 14 Tage mit fehlgeschlagenen Anmeldungen, Scans und Spam pro Tag, die aktivsten Adressen mit einer Sperren-Schaltfläche, die angegriffenen Postfächer und die aktiven Vorfälle. Ein rotes Schild neben dem Menü System zeigt offene schwerwiegende Vorfälle auf jeder Admin-Seite, sodass du sie bemerkst, ohne danach zu suchen.
Verbringe hier ein paar Minuten, bevor du etwas änderst. Es zeigt dir, ob dein Server überwiegend Hintergrundrauschen sieht oder eine echte Kampagne.
Schritt 5 — Die 13 Regeln durchgehen
Jede Regel zählt Datensätze in einem gleitenden Fenster und öffnet einen Vorfall, wenn der Schwellwert erreicht ist. Solange der Angriff andauert, wird derselbe Vorfall verlängert, nicht wiederholt. Die Standardwerte:
| Regel | Zählt | Standard |
|---|---|---|
| Web-Login-Brute-Force | fehlgeschlagene SOGo- / UI- / API-Anmeldungen pro Adresse | 5 in 15 Min. → Sperre 24 Std. |
| Langsame Brute-Force | fehlgeschlagene Anmeldungen pro Adresse über einen Tag | 20 in 24 Std. → Sperre 24 Std. |
| Password Spraying | verschiedene Postfächer, an denen eine Adresse scheiterte | 5 in 60 Min. → Sperre 7 Tage |
| Wiederholungstäter | mailcow-fail2ban-Sperren einer Adresse | 3 in 7 Tagen → Sperre 30 Tage |
| Web-Exploit-Scan | Anfragen auf Exploit- / Leak-Pfade | 3 in 30 Min. → Sperre 7 Tage |
| Web-404-Scan | 404-Antworten pro Adresse | 40 in 30 Min. → Warnung |
| Relay-Versuche | „Relay access denied“ pro Adresse | 3 in 60 Min. → Sperre 7 Tage |
| Protokoll-Scan | Verbindungen, die sich nie anmelden oder das Protokoll brechen | 30 in 60 Min. → Warnung |
| Spamwelle | rspamd- und Blocklist-Abweisungen pro Adresse | 20 in 60 Min. → Warnung |
| Angegriffenes Postfach | Fehlversuche an einem Postfach von mindestens 5 Adressen | 30 in 60 Min. → Warnung |
| Versandspitze | 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 Fehlversuchen | eine erste Anmeldung von einer Adresse, die am Postfach gescheitert ist | 3 Fehlversuche in 24 Std. → Warnung (kritisch) |
In Regeln kannst du jede Regel abschalten und ihren Schwellwert, ihr Fenster, ihre Aktion und ihre Sperrdauer ändern (0 = dauerhaft). Adressregeln können warnen oder sperren; Postfachregeln können warnen, den Versand begrenzen oder die Anmeldung verweigern. Auf Standard zurücksetzen bringt alle zurück.
Die letzten vier Zeilen sind deine Erkennung kompromittierter Postfächer: eine Versandspitze, Anmeldungen von vielen Adressen, Fehlversuche über viele Adressen an einem Postfach verteilt und — die schärfste — eine Anmeldung von einer Adresse, die an diesem Postfach zuvor gescheitert ist. Das ist ein Passwort, das wahrscheinlich erraten wurde.
Schritt 6 — Zuerst nur überwachen
Der Schalter oben in Regeln ist anfangs aus. Jeder Vorfall sagt, was getan worden wäre („würde sperren“). Lass es ein paar Tage so, sieh dir die Vorfälle an, passe Schwellwerte an und schalte es dann ein. Vorfälle, deren Angriff noch andauert, werden beim nächsten Lauf behandelt.
Wenn du Vorfälle durchgehst, nutze bei Bedarf Falsch positiv: Das setzt die Adresse auf die Ausnahmeliste und hebt ihre Sperren auf.
Schritt 7 — Automatische Aktionen einschalten
Mit aktivierten automatischen Aktionen landet eine Sperre für die Dauer der Regel in mailcows fail2ban-Sperrliste. mailcows netfilter wendet sie innerhalb einer Minute auf jeden mailcow-Port an, und du siehst sie auf mailcows eigener Fail2ban-Seite. Das Modul hebt sie beim Ablauf auf; eine Sperre, die du auf mailcows Fail2ban-Seite löschst, gilt als aufgehoben.
Nie automatisch gesperrt:
- private und reservierte Adressen;
- die Ausnahmeliste des Moduls (Einstellungen) und mailcows fail2ban-Ausnahmeliste (Konfiguration → Fail2ban);
- die eigenen öffentlichen Adressen des Servers;
- mit aktiviertem bekannte Adressen schützen (Standard), Adressen, die sich in den letzten 30 Tagen erfolgreich an einem Postfach angemeldet haben — damit ein Kollege, der sich vertippt, nicht ausgesperrt wird.
Schritt 8 — Auf Konten über mailcow selbst reagieren
Für ein Postfach, das kompromittiert aussieht, laufen Kontoaktionen über mailcows eigene Funktionen: Anmeldung verweigern (das Postfach empfängt weiterhin Mail), die IMAP- / POP3-Sitzungen beenden, Passwortänderung verlangen, Versand begrenzen. Du kannst das aus der Ansicht für eine einzelne Adresse oder ein einzelnes Postfach heraus tun, die Fehlversuche, Anmeldungen, Sendungen, Vorfälle und Sperren auf einen Blick zeigt. Jede Aktion — deine oder die des Moduls — landet im Protokoll.
Schritt 9 — Manuelle Sperren und Cloudflare
Sperren zeigt die Sperren des Moduls (Grund, von wem, bis wann, Cloudflare-Status), mailcows eigene temporäre fail2ban-Sperren mit Aufheben oder Verlängern und den Rest von mailcows Sperrliste. Das Formular oben sperrt eine Adresse oder ein Netzwerk (CIDR) für 1 Stunde bis 30 Tage oder dauerhaft; deine eigene aktuelle Adresse wird abgelehnt.
Wenn mailcow-UI und Webmail hinter Cloudflares Proxy liegen, erreichen Web-Angriffe mailcow von Cloudflares Adressen, und netfilter kann sie nicht stoppen. Wähle in Einstellungen → Cloudflare Sperren der Web-Regeln und angehakte manuelle Sperren oder jede Sperre: Jede Sperre wird dann zusätzlich eine Cloudflare-IP-Zugriffsregel auf Kontoebene, die zusammen mit der Sperre entfernt wird.
Schritt 10 — Warnungen
Stelle Warnungen per E-Mail und Telegram ab der von dir gewählten Schwere ein, mit einem Stundenlimit und optional einer täglichen Zusammenfassung. Warnungen gehen nur an die Adresse und den Chat, die du konfigurierst. Alles andere — Logs, Adressen, Postfachnamen, Verlauf — bleibt in deiner mailcow-Datenbank und wird nie an medialab.works gesendet.
Noch etwas Wissenswertes: Wenn eine schwere Schwachstelle PHP, nginx, SOGo oder eine andere mailcow-Komponente trifft, kann mit der Lizenzprüfung ein virtueller Patch kommen — eine genaue Abhilfe, bei kritischen automatisch angewendet. Er senkt das Risiko bis zum Update; er ersetzt das Update nicht.
Tipps und Fehlerbehebung
- Sperren erscheinen nicht in der Firewall. Prüfe, ob mailcows netfilter-Container läuft. Wenn Manage external aktiv ist, lässt netfilter die Firewall in Ruhe und deine eigene Firewall muss mailcows Liste anwenden — die Seite Sperren warnt dich davor.
- Du hast dich selbst ausgesperrt. Deine aktuelle Adresse wird vom manuellen Sperrformular abgelehnt, und bekannte Adressen sind standardmäßig geschützt. Wenn du trotzdem erwischt wirst, entferne die Sperre auf mailcows Fail2ban-Seite — sie gilt als aufgehoben.
- Zu viele Warnungen. Erhöhe Schwellwerte oder Schweregrade pro Regel, oder verlass dich auf das Stundenlimit und die tägliche Zusammenfassung.
- Web-Angriffe kommen weiterhin an. Wenn du hinter Cloudflares Proxy liegst, konfiguriere Cloudflare in den Einstellungen; netfilter allein kann den echten Client nicht sehen.
- Zeilen gingen verloren. Erhöhe
LOG_LINESinmailcow.confauf einem sehr stark ausgelasteten Server.
Fazit
fail2ban ist weiterhin die erste Verteidigungslinie, und du solltest es behalten. Security für mailcow ist die zweite: ein gespeicherter Verlauf, 13 Regeln für die langsamen und verteilten Angriffe, Erkennung kompromittierter Postfächer und Sperren, die über die Firewall laufen, der mailcow bereits vertraut. Starte im reinen Überwachungsmodus, beobachte ein paar Tage und lass es dann handeln. Die Produktseite enthält die Funktionsliste, das Handbuch deckt jeden Bildschirm ab, und das Changelog verfolgt, was sich geändert hat. Wenn etwas nicht zu deinem Setup passt, sind die Wissensdatenbank und die FAQ ein guter nächster Schritt, oder kontaktiere uns.