Beim studieren der Server Logs meines Debian Lenny Servers fiehl mir auf das sehr viele fehlgeschlagene authentifizierungs Versuche am SMTP Daemon von Postfix statt gefunden hatten. Folgende Meldung wiederholte sich mehrfach:

Apr 28 15:33:56 mail postfix/smtpd[8110]: warning: unknown[218.248.1.181]: SASL CRAM-MD5 authentication failed: PDM2NjYyMjQ0OTU5OTE5MTMuMTI3MjQ2MTYzNUBFTVAtUz4=

Mich wunderte das die IP Adresse nicht nach 3 Versuchen von Fail2ban (Version 0.8.3-2sid1) gebannt wurde. Es hat sich herausgestellt das der Reguläre Ausdruck den Fail2ban für das erkennen Fehlgeschlagener authentifizierungs Versuche nicht mit der Log-Nachricht übereinstimmt. Ein Entfernen des $ am Ende des Regulären Ausdrucks (failregex) in der Datei /etc/fail2ban/filter.d/sasl.conf reichte aus um die Logs passend zu filtern.

Warum das $ entfernen?
Das $ steht in einem Regulären Ausdruck für das Ende der zu suchenden Zeichenkette. Da aber nach „authentication failed“ in dem Log Eintrag weitere Zeichen folgen passt der Reguläre Ausdruck nicht zum Logeintrag.

failregex = : warning: [-._w]+[<HOST>]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed

Ist meine aktueller Eintrag um fehlgeschlagene authentifizierungs Versuche am Postfix SMTP Daemon zu erkennen.

Spamassassin füllte meine Logs zum selben Zeitpunkt mit:

Apr 28 00:31:27 mail spamd[21987]: spamd: creating default_prefs: /nonexistent/.spamassassin/user_prefs
Apr 28 00:31:27 mail spamd[21987]: config: cannot write to /nonexistent/.spamassassin/user_prefs: No such file or directory
Apr 28 00:31:27 mail spamd[21987]: spamd: failed to create readable default_prefs: /nonexistent/.spamassassin/user_prefs

Eine weitere Lösung musste her… Da Spamassassin bei mir unter dem Benutzer nobody läuft und dieser zu diesem Zeitpunkt kein gültiges Heimatverzeichnis in der /etc/passwd Datei hinterlegt hatte blieben mir sinnvolle 2 Möglichkeiten. Zum einen das Eintragen eines gültigen Heimatverzeichnisses in die Datei /etc/passwd. (Platzhalter: <VERZEICHNIS>)

nobody:x:65534:65534:nobody:<VERZEICHNIS>:/bin/false

Zum Anderen gab es die Möglichkeit Spamassassin durch eine Änderung in /etc/defaults/spamassassin mit einem virtuellen Verzeichnis zu starten. Hier mein Aktueller Eintrag für standard Startoptionen von Spamassassin: (Platzhalter: <VERZEICHNIS>)

OPTIONS="--create-prefs --max-children 5 --helper-home-dir -u nobody -x --virtual-config-dir=<VERZEICHNIS>"

Ich entschied mich für die zweite Möglichkeit (Verzeichnis: /var/spool/spamassassin).

ein Kommentar »
 
  1. jcp sagt:

    guter Tip Danke!!!