Ich habe einen Ubuntu 20.04-Server, der jeden Tag Hunderte von SMTP-AUTH-Anfragen auf meinem Postfix-Server von derselben IP empfängt. Ich habe fail2ban installiert, aber ironischerweise gelingt es nicht, die IP zu sperren.
Meine /etc/fail2ban/jail.localDatei ist (die Teile sind persönliche und geschäftliche IPs):
[postfix-flood-attack]
enabled = true
bantime = 1h
filter = postfix-flood-attack
action = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
logpath = /var/log/mail.log
ignoreip = <snip> 127.0.0.1/8
maxretry = 3
[postfix]
enabled = true
maxretry = 3
bantime = 1h
filter = postfix[mode=aggressive]
logpath = /var/log/mail.log
ignoreip = <snip> 127.0.0.1/8
[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps
filter = dovecot
logpath = /var/log/mail.log
maxretry = 3
ignoreip = <snip> 127.0.01/8
Das fragliche Gefängnis ist postfix-flood-attack, entnommen ausam Ende dieses Tutorials. Die /etc/fail2ban/filter.d/postfix-flood-attack.confDatei ist:
[Definition]
failregex = lost connection after AUTH from (.*)\[<HOST>\]
ignoreregex =
Meine Logmeldungen sehen so aus
Aug 15 13:54:45 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:46 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: warning: unknown[193.35.48.18]: SASL PLAIN authentication failed:
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:51 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:58 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268734]: connect from unknown[193.35.48.18]
Aug 15 13:55:05 ikana postfix/smtps/smtpd[268734]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: warning: unknown[193.35.48.18]: SASL PLAIN authentication failed:
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Laut fail2ban-regexsollte dies funktionieren, aber die IP wird nicht gesperrt. Die Ausgabe des Befehls fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix-flood-attack.conflautet:
Running tests
=============
Use failregex filter file : postfix-flood-attack, basedir: /etc/fail2ban
Use log file : /var/log/mail.log
Use encoding : UTF-8
Results
=======
Failregex: 5356 total
|- #) [# of hits] regular expression
| 1) [5356] lost connection after AUTH from (.*)\[<HOST>\]
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [37949] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-
Lines: 37949 lines, 0 ignored, 5356 matched, 32593 missed
[processed in 1.43 sec]
Missed line(s): too many to print. Use --print-all-missed to print all 32593 lines
Es findet also eine Übereinstimmung für 5.356 Protokolle und sperrt keines davon. Normalerweise gibt es 8 Versuche innerhalb der standardmäßigen Suchzeit von 10 Minuten. Ein Ausschnitt der Verwendung der -vOption mit fail2ban-regexzeigt die folgenden Übereinstimmungen mit Zeitstempeln:
...
193.35.48.18 Thu Aug 15 13:50:55 2019
193.35.48.18 Thu Aug 15 13:51:02 2019
193.35.48.18 Thu Aug 15 13:51:10 2019
193.35.48.18 Thu Aug 15 13:51:15 2019
193.35.48.18 Thu Aug 15 13:54:50 2019
193.35.48.18 Thu Aug 15 13:54:57 2019
193.35.48.18 Thu Aug 15 13:55:04 2019
193.35.48.18 Thu Aug 15 13:55:09 2019
193.35.48.18 Thu Aug 15 13:58:40 2019
193.35.48.18 Thu Aug 15 13:58:48 2019
193.35.48.18 Thu Aug 15 13:58:54 2019
193.35.48.18 Thu Aug 15 13:58:59 2019
...
Antwort1
Die Konfiguration sieht gut aus, aber es gibt ein wichtiges Detail, das bei der Ausgabe von zu beachten ist fail2ban-regex: Es wurde entschieden, dass die Daten aus dem Jahr 2019 stammen. Angesichts der Protokolle in der Frage schien dies zunächst ziemlich dumm. Es stellte sich heraus, dass dies ein bekanntes Problem mit fail2ban ist, etwas, das sie alsdie TZ-Ausgabe. Nachdem Sie Ihren Server für die Verwendung einer bestimmten Zeitzone konfiguriert haben, müssen Sie entweder eine Reihe von Diensten oder das gesamte System neu starten, damit die Änderungen richtig wirksam werden. Ich kann mich zwar nicht erinnern, wie lange es her ist, aber ich glaube, ich habe meinen Server seit der Konfiguration der Zeitzone nie neu gestartet.
Nach dem Neustart des Syslog-Dienstes über systemctl restart syslogerkannte fail2ban Logzeilen in der richtigen Zeitzone.
Fail2ban hat die Log-Nachrichten sofort in der konfigurierten Suchzeit erkannt und die IP gesperrt, die meinen Server seit Tagen plagt. Ich vermute, Fail2ban fragt Syslog nach den Zeitzoneninformationen, anstatt die auf dem Computer eingestellten Werte zu verwenden, seit der Fail2ban-Server gestartet wurde.
Ich hoffe, dass dies jemand anderem mit einem ähnlichen Problem helfen kann.
Antwort2
Die Mehrdeutigkeit, die dazu führte, dass fail2ban annahm, dass diese Daten im Jahr 2019 liegen, kann nicht auftreten, wenn Sie die Standard-Datumsformatierung verwenden. Sie können das Problem vollständig vermeiden, indem Sienach ISO 8601– Im Jahr 2020 gibt es für Sie möglicherweise keinen guten Grund mehr, bei der abwärtskompatiblen Protokollformatierung zu bleiben.
Außerdem können Sie in Ubuntu die Datumsformatierung/-analyse wahrscheinlich vollständig überspringen, indem Sie fail2ban anweisen, das systemd-Journal direkt zu verwenden, das einfache Offsets von der Epoche ohne Zeitzoneninformationen bereitstellt (versuchen Sie es backend = systemdim [DEFAULT]Block in der lokalen Jail-Konfiguration).