Dies hier soll weniger Ein Blogbeitrag über Fail2ban werden als mehr eine Notiz an mich selbst, damit ich die Dinge, die ich eingestellt habe, nicht vergesse.
Worum geht es?
Mailcow über Docker bringt ein eigenes Fail2ban mit sich. In der GUI von Mailcow lässt sich einstellen, wie Fail2ban sich verhalten soll. Leider können manche Dinge so immer nur "übergeordnet" verwaltet werden. Beispiel: Die Anzahl Versuche bis zur Sperrung oder der Zeitraum in dem Versuche aufgezeichnet werden. Ich habe Fail2ban sehr streng eingestellt und sperre nach dem dritten Fehlversuch.
Allerdings störte mich, dass immer wieder unzählige Anmeldeversuche mit Fantasienamen auf den Server einprasselten. Ich habe mir eine Funktion gewünscht, die ähnlich wie bei manchen WordPress-Sicherheitsplugins bei unbekannten Benutzernamen sofort sperren. Dies lässt sich aber meines Wissens nicht mit den Mailcow-Bordmitteln realisieren. Außer man bannt generell beim ersten Fehlversuch.
Meine Fail2ban-Konfiguration ist sicher nicht für jeden geeignet aber auf meinem Mailserver kenne ich die Benutzernamen und so wollte ich sozusagen mit einer "Positivliste" arbeiten.
Voraussetzungen
Mailcow-Logs werden primär als Docker-Container-Ausgaben (stdout/stderr) generiert und hauptsächlich über den JSON-Treiber von Docker verarbeitet, wobei die letzten 10.000 Zeilen persistent in Redis für die Web-UI gespeichert werden. Daher müssen wir dafür sorgen, dass Fail2ban die Logfiles überhaupt zum Lesen bekommt. Dies funktioniert laut Mailcow-Website über die Datei docker-compose.override.yml, die wir in /opt/mailcow-dockerized/ erstellen. Ich mache das mit dem Editor nano. Funktionier aber mit vi oder vim ebenso.
Die docker-compose.override.yml
Wir öffnen die docker-compose.override.yml mit dem Editor unserer Wahl und geben folgendes ein:
services:
postfix-mailcow:
logging:
driver: "journald"
dovecot-mailcow:
logging:
driver: "journald"Hier findet ihr die Mailcow-Dokumentation zum Umstellen der Logfiles: https://docs.mailcow.email/de/post_installation/firststeps-logging/
Nun werden die Logs für Postfix und Dovecot auch über den journald ausgegeben und können mit journalctl abgerufen werden. So kann auch Fail2ban auf dem Host (nicht Fail2ban von Mailcow) auf die Logs zugreifen und auswerten. Fail2ban ist auf dem Host zusätzlich installiert, damit auch die ssh-Zugriffe überwacht werden können und dies nicht aus dem Mailcow-Container heraus geschehen muss.
Der Fail2ban-Filter
Als nächstes brauchen wir einen Fail2ban-Filter um den Regex einzugeben, mit dem in den Logs nach den entsprechenden Zeilen gesucht werden kann. Die Fail2ban-Filter liegen im Verzeichnis /etc/fail2ban/filter.d
Eine typische Dovecot Logzeile sieht wie folgt aus:
Mar 21 17:56:34 mxsrv1 9e6d079edff6[916]: Mar 21 17:56:34 9e6d079edff6 dovecot: auth-worker(18103): conn unix:auth-worker (pid=135,uid=401): auth-worker<112561>: lua(test@schoenes-vom-starnberger-see.de,49.247.24.89): Password mismatch (SHA1 of given password: 7f5865)
In diesem Beispiel sieht man, dass versucht wird, sich mit dem Benutzernamen test@schoenes-vom-starnberger-see.de einzuloggen. Einen Benutzer test gibt es nicht. Die Idee ist nun, eine "Positiv-Liste" mit zulässigen Benutzernamen im Filter als Regex umzusetzen. Dies ist natürlich nur möglich, wenn erstens klar ist, welche Benutzer es genau gibt. Oft ist dies nicht möglich, weil Benutzer selbst Adressen bzw. Logins erstellen können. In meinem Fall habe ich die Kontrolle darüber und kann mit einer Positivliste arbeiten.
[Definition]
loglevel = DEBUG
failregex = ^.*lua\((?!(anton@|archiv@|office@|carla@|susi@|mike@|wyny@))[^@]+@.*?,<HOST>.*\): Password mismatch
ignoreregex =