Debian 12 auf 13 Upgrade dank Skript problemlos

[tab-kh]

Gerade habe ich meinen letzten Keyhelp-Server mit Debian 12, meinen Mailserver mit ARM64, auf Debian 13 gebracht. Ging völlig problemlos dank Update-Skript. Jedenfalls bemerke ich bisher noch keine Probleme. Mail scheint nach ersten Tests zu funktionieren.

Ich hatte vorher noch einen Snapshot gemacht, den behalte ich vorsichtshalber erst einmal noch eine Weile, falls doch noch Probleme auftauchen sollten. Aber sieht erst einmal sehr gut aus. DANKE für das tolle Upgrade-Skript!

[tab-kh]

Die ersten Erfahrungen sind gemacht, insbesondere mit fail2ban. Da ich es bei postfix und dovecot unter "mode=aggressive" nicht mache ist mir heute Morgen schnell aufgefallen, dass einige Spielchen beim IMAP und POP3-Login, die mit der älteren Version und Debian 12 noch mit einem Ban "belohnt" wurden, jetzt nicht mehr geahndet wurden. Das war dann erst mal nicht so schön - wobei das mit Keyhelp nichts zu tun hat. Das machen Debian 13, Postfix, Dovecot und fail2ban unter sich aus. Debian 13 installiert neuere Versionen als Debian 12, insbesondere Dovecot scheint nun etwas andere Logzeilen zu schreiben, was aber in den installierten Filtern von fail2ban zum Teil nicht berücksichtigt wird.

Nach einigem Suchen auf Github habe ich mich dann entschlossen, die neuesten Filter postfix.conf und dovecot.conf aus dem Master Branch zu versuchen. Und siehe da, es funktioniert damit nun wieder in etwa so gut wie zuvor mit Debian 12 , nachdem heute den ganzen Tag über bei Dovecot und Postfx nichts gefunden oder gar gebannt wurde, gibt es jetzt wieder die ersten Treffer. Wobei die Angriffswelle der letzten Woche jetzt aber auch allmählich auszulaufen scheint.

Ich beobachte das mal bis morgen Nachmittag und ziehe dann vielleicht noch ein paar andere (neuere) Filterversionen für die anderen Jails nach. Je nachdem ob es im letzten Jahr noch Änderungen gab.

[tab-kh]

Die Filterdefinitionen postfix.conf und dovecot.conf zu ersetzen durch die neuesten aus dem Master-Branch kann ich also für alle Server mit Debian 13 nur empfehlen. Funktioniert bei mir problemlos, ich werde es heute noch auf drei weiteren Servern mit Debian 13 nachziehen. Wer das recidive-Jail benutzt mag es allerdings gar nicht bemerken, weil das sshd-Jail meist den Löwenanteil an den Bans hat, da geht kh-postfix, kh-postfix-sasl und kh-dovecot fast schon im Rauschen unter. Man sieht dann auch nach relativ kurzer Zeit schon gar nicht mehr warum die IPs im recidive-Jail gelandet sind. Jedenfalls nicht ohne das Journal nach den IPs zu durchforsten.

Ich bin auf diesem einen Server von recidive wieder weg, weil bei diesem Server der ssh-Zugriff in der Firewall geblockt, bzw nur für meine IPv6 zuhause und die IPs meines Jumphosts freigegeben ist (auch das werde ich wohl in nächster Zeit auf die anderen drei Server übertragen). Zudem war bei mir die Zahl der IPs, die wegen Bans in mehreren, unterschiedlichen Jails im recidive-Jail landeten, vernachlässigbar bzw Null. So sehe ich jetzt im Keyhelp-Panel wieder genau, welche IP warum geblockt ist. Und im Munin-Monitoring sehe ich zumindest die Gesamtzahlen pro Jail.

Da "mode=aggressive" beim postfix-Filter auch SASL umfasst, habe ich kh-postfix-sasl deaktiviert. Die entsprechenden IPs landen dann im kh-postfix Jail.

[Alexander]

Ich bin auf diesem einen Server von recidive wieder weg,

Nur zur Info:

Ich habe mittlerweile seit 2-3 Wochen auf bantime.inkrement etc. umgestellt und recidive entfernt. Das wird mit KH 26.0 der neue Standard (für Neu-Installationen / Dist-Upgrades).
viewtopic.php?t=14294

[tab-kh]

Klingt spannend. Ich war mir da jetzt selbst lange unsicher, ob es wirklich eine gute Idee war, habe mich aber jetzt dazu entschlossen, das erst einmal auf alle meine Keyhelp-Server zu übertragen. Mit recidive hätte ich wahrscheinlich nicht gemerkt, dass die postfix und dovecot Filter nach dem Dist-Upgrade nicht mehr so richtig funktionieren. Tatsächlich habe ich das auf den anderen Servern, die direkt auf einem Debian 13 Minimalimage installiert wurden, nicht gemerkt.

Ein paar Kopfschmerzen habe ich aber noch. Ich überlege gerade, wie ich das mit meinen geänderten Filtern am besten machen soll. Im Moment habe ich jeweils eine Filterdatei mit anderem Namen angelegt, mit einem Prefix vor dem Standardnamen.

Ich wollte die alte Datei weiterhin zur Verfügung haben und auch verhindern, dass die geänderte Datei (postfix.conf, dovecot.conf) bei irgendwelchen Updates eventuell wieder überschrieben wird. Andererseits ist sowieso zu erwarten, dass die Dateien aus dem Master-Branch, die ich übernommen habe, in der nächsten Version von fail2ban zum Standard werden oder sogar bis dahin weiter optimiert werden. Ein überschreiben würde also wahrscheinlich eher noch eine Verbesserung bringen als irgendwas zu verschlechtern.

Also werde ich wohl doch eher die Original-Filterdateien ändern. So wie es jetzt realisiert ist, bekomme ich weitere Verbesserungen der Filter bei zukünftigen Updates nicht automatisch.

Kann man an die neuen Jail-Einstellungen von Keyhelp 26.0 dann auch ohne Neuinstallation bzw Dist-Upgrade drankommen? Wäre ein Patch vielleicht eine Idee dafür? Man muss den Patch ja nicht einspielen, wenn man lieber bei der bisherigen Methode mit recidive bleiben will. Man kann natürlich alternativ auch einfach Keyhelp auf einem Server neu installieren und sich dann die Dateien von dort holen. Aber das wäre schon ein wenig Overkill für ein paar (wahrscheinlich nur eine) geänderte Dateien.

[Alexander]

Kann man an die neuen Jail-Einstellungen von Keyhelp 26.0 dann auch ohne Neuinstallation bzw Dist-Upgrade drankommen?

Die kannst du dir dann aus dieser Datei holen: /home/keyhelp/www/keyhelp/install/templates/fail2ban/jail.d/keyhelp.conf

[tab-kh]

Puh. Heute Abend habe ich mir mal das fail2ban.log angeschaut, weil offenbar eine neue Angriffswelle auf den SSH-Zugang läuft. Dabei fand ich relativ viele Warnungen der folgenden Art:

Code: Select all

2026-03-05 05:43:56,707 fail2ban.actions        [665]: WARNING [kh-postfix] 178.16.54.138 already banned

Das ist nur ein Beispiel, es kommt auch mit anderen Jails vor, derzeit naturgemäß meist mit dem sshd-Jail, seit die neue Welle angelaufen ist. Das Beispiel stammt noch aus einer älteren Logdatei, weil ich prüfen wollte, ob das auch schon vor meinen Umstellungen der Jails, Filter etc vorkam oder ob es vielleicht durch meine Änderungen verursacht wird. Wie man sieht, ja, es kam auch schon vor den Änderungen vor.

Habt ihr das auch? Oder liegt es ggf. am "aggressive" mode? Es besorgt mich jedenfalls etwas, da nach meinem Verständnis eine bereits gebannte IP keine neuen Angriffsversuche mehr starten können sollte. Es passiert jedenfalls sowohl auf dem Mailserver mit Upgrade von Debian 12 auf 13, als auch auf anderen Servern, die direkt mit Debian 13 installiert wurden. Und wie das obige Beispiel zeigt, war es wohl auch mit Debian 12 schon so, denn zum obigen Zeitpunkt (5.3.26) war das noch ein Debian 12. Nämlich mein Mailserver vor dem Upgrade.

[Tiresias]

Puh. Heute Abend habe ich mir mal das fail2ban.log angeschaut, weil offenbar eine neue Angriffswelle auf den SSH-Zugang läuft. Dabei fand ich relativ viele Warnungen der folgenden Art:

Code: Select all

2026-03-05 05:43:56,707 fail2ban.actions        [665]: WARNING [kh-postfix] 178.16.54.138 already banned

Das ist nur ein Beispiel, es kommt auch mit anderen Jails vor, derzeit naturgemäß meist mit dem sshd-Jail, seit die neue Welle angelaufen ist. Das Beispiel stammt noch aus einer älteren Logdatei, weil ich prüfen wollte, ob das auch schon vor meinen Umstellungen der Jails, Filter etc vorkam oder ob es vielleicht durch meine Änderungen verursacht wird. Wie man sieht, ja, es kam auch schon vor den Änderungen vor.

Habt ihr das auch? Oder liegt es ggf. am "aggressive" mode? Es besorgt mich jedenfalls etwas, da nach meinem Verständnis eine bereits gebannte IP keine neuen Angriffsversuche mehr starten können sollte. Es passiert jedenfalls sowohl auf dem Mailserver mit Upgrade von Debian 12 auf 13, als auch auf anderen Servern, die direkt mit Debian 13 installiert wurden. Und wie das obige Beispiel zeigt, war es wohl auch mit Debian 12 schon so, denn zum obigen Zeitpunkt (5.3.26) war das noch ein Debian 12. Nämlich mein Mailserver vor dem Upgrade.

Moin!

Nach meinem Verständnis entsteht das, wenn mehr als maxretry passende Einträge in sehr kurzen Zeiträumen im Logfile auftauchen.

Beispiel:
kh-postfix hat maxretry = 3

Es werden z. B. 6 passende Logeinträge gefunden, die in kürzester Zeit entstanden.
→ nach den ersten 3 Treffern erfolgt der Ban
→ die restlichen Logzeilen werden aber weiterhin verarbeitet
→ sobald erneut maxretry erreicht wird, versucht Fail2Ban wieder zu bannen
→ stellt fest: IP ist bereits gebannt
→ Ergebnis: "already banned"

Das passiert besonders dann, wenn viele Logeinträge in sehr kurzem Zeitraum entstehen, weil schnell auf den Dienst eingehämmert wird, oder Logeinträge aus mehreren Logs gleichzeitig kommen (z. B. bei kh-bad-bots).
Das sind in der Regel keine neuen erfolgreichen Angriffe/Zugriffe nach dem Bann, denn der funktioniert, sondern noch nicht vollständig abgearbeitete bzw. parallel entstandene Logeinträge.

Gruß, Thorsten

[Ralph]

Habt ihr das auch? Oder liegt es ggf. am "aggressive" mode? Es besorgt mich jedenfalls etwas, da nach meinem Verständnis eine bereits gebannte IP keine neuen Angriffsversuche mehr starten können sollte. Es passiert jedenfalls sowohl auf dem Mailserver mit Upgrade von Debian 12 auf 13, als auch auf anderen Servern, die direkt mit Debian 13 installiert wurden. Und wie das obige Beispiel zeigt, war es wohl auch mit Debian 12 schon so, denn zum obigen Zeitpunkt (5.3.26) war das noch ein Debian 12. Nämlich mein Mailserver vor dem Upgrade.

Moderne Botnet Attacken ... dabei werden über spezielle Anwendungen zum gleichen Zeitpunkt mehrere Requests gestartet (auch auf versciedene Services) und die IP Adresse wird gleich ausgetaucht durch eine neue aus dem Botnet Pool. F2B kommt dann mit logging u. Auswertung nicht so schnell hinterher, insbesondere wenn durch den Umfang der requests Services u. F2B selbst überlastet werden (Größe der Logs u. Jail findtime spielen auch eine Rolle). Aber es können sich auch Bedingungen von Filtern überschneiden bzw. verschiedene Jails, also ja ... diese Überschneidungen sind keine Seltenheit.

[tab-kh]

Ich schau mir heute Abend mal die Log-Einträge im Journal dazu an. Hatte eigentlich nicht den Eindruck, dass es da um einige Sekunden ging, aber reinschauen in die Logs hilft. Soweit ich gesehen habe, sind die fb-xxx Chains mittlerweile schon lange nicht mehr in iptables. Da habe ich die gebannten IPs jedenfalls nicht gefunden, sondern nur das, was ich in der Keyhelp-Oberfläche als Firewall-Regeln stehen habe. Die gebannten IPs finden sich nur direkt in nftables, was ja auch deutlich performanter sein sollte.

[Tiresias]

Sowas piekst mich ja auch an.

Ich bin dem Verhalten mit „already banned“ im Postfix-Jail mal anhand der Mail-Logs nachgegangen.

Das Postfix-Jail läuft auf dem Server mit maxretry = 2 (ist kein Mailserver, sondern nur Submission/Abwehr).

Ausgangspunkt war dieser Ablauf:

02:58:24 connect
02:58:26 authentication failed
02:58:26 lost connection after AUTH
02:58:26 disconnect
02:58:26 connect (neue Session)
02:58:26 Ban

Der Ban kommt hier also schon nach sehr wenigen Versuchen, wie gewünscht (im Mode "aggressive" durch „authentication failed“ und „lost connection after …“).

Im Fail2Ban-Log steht aber:

2026-03-19 03:03:26,938 fail2ban.actions [2460708]: WARNING [postfix] 34.....85 already banned

Im Mail-Log:

03:03:26 SSL_accept error ... Connection timed out
03:03:26 lost connection after STARTTLS
03:03:26 disconnect

Das sind ziemlich genau 5 Minuten Abstand → Postfix-Timeout.

Also:
Die zweite Verbindung um 02:58:26 wurde noch angenommen, bevor (oder genau während) der Ban aktiv wurde. Fail2Ban setzt zwar die Firewall-Regel, beendet aber keine bereits bestehenden Verbindungen.

Diese Session blieb dann im STARTTLS/SSL-Handshake hängen und lief nach dem Postfix-Timeout (standardmäßig ca. 300 Sekunden) einfach aus.

Und genau diese „sterbende“ Verbindung erzeugt dann die Logzeilen wie:

SSL_accept error
lost connection after STARTTLS
disconnect ... auth=0/1

Da der Postfix-Filter im Mode "aggressive" läuft, werden genau solche Zeilen ebenfalls als Treffer gewertet.

Das führt dann dazu, dass Fail2Ban erneut einen Bannversuch erkennt und schreibt: "already banned"

Das ist also kein neuer erfolgreicher Angriff nach dem Bann, sondern nur das Nachspiel einer bereits bestehenden Verbindung.

Kurz gesagt:
Fail2Ban blockiert neue Verbindungen, aber bestehende Sessions können noch auslaufen – und genau dabei entstehen diese zusätzlichen Logeinträge.

[Jolinar]

Kurz gesagt:
Fail2Ban blockiert neue Verbindungen, aber bestehende Sessions können noch auslaufen – und genau dabei entstehen diese zusätzlichen Logeinträge.

Das könnte man aber noch optimieren.
Entweder erstellt man einen custom Filter, der Timeout Logs ignoriert oder man setzt zB.

Code: Select all

findtime = 600

Das sollte die Session Timeouts abdecken.

[tab-kh]

Wenn das von @Tiresias beschriebene Szenario die tatsächliche Ursache ist, dann bin ich zumindest mal beruhigt. Denn dann habe ich im Endergebnis das, was ich haben will: Die IP ist tatsächlich blockiert und kann erst einmal für den eingestellten Zeitraum (bantime) keine weiteren Verbindungen mehr herstellen.

Der 5 Minuten Timeout wäre auch bei dem von mir beobachteten Ablauf so viel später, dass ich die entsprechenden Vorkommnisse mit der selben IP nie beide gleichzeitig im Terminal sehen konnte. Denn da war einiges los, wenn auch sicher keine Überlastung des Servers (nicht mal eine in Munin überhaupt sichtbare Belastung) vorlag. Da sieht alles ziemlich gelangweilt aus.

Wenn ich das in den Logeinträgen so nachvollziehen kann wie von Tiresias beschrieben, dann sehe ich für mich keinen dringenden Handlungsbedarf. Meine Befürchtung war, dass fail2ban eventuell nur glaubt, die IP bereits gebannt zu haben, diese aber nicht auch tatsächlich in der Firewall blockiert ist und von dieser IP dann munter weitere Angriffe gestartet werden können. Das wäre dann aber nicht der Fall.

[tab-kh]

Kurz gesagt:
Fail2Ban blockiert neue Verbindungen, aber bestehende Sessions können noch auslaufen – und genau dabei entstehen diese zusätzlichen Logeinträge.

Das könnte man aber noch optimieren.
Entweder erstellt man einen custom Filter, der Timeout Logs ignoriert oder man setzt zB.

Code: Select all

findtime = 600

Das sollte die Session Timeouts abdecken.

Das habe ich jetzt nicht wirklich verstanden. Was soll die findtime von 600 Sekunden bewirken? Session Timeouts will ich eigentlich auch nicht grundsätzlich ignorieren, die gibt es auch ohne vorherigen fehlgeschlagenen Authentifizierungsversuch. Da lebe ich lieber mit den Warnungen, die ja vermutlich sowieso kein Problem darstellen.

Sieht übrigens auch bei mir so aus, dass die Timeout-Zeilen die Warnungen triggern. Und die IP ist dann auch tatsächlich in der Firewall geblockt.