KeyHelp: Fail2Ban-Verwaltung nutzen, gesperrte IPs freigeben und eigene Adressen ausnehmen

Fail2Ban sperrt Adressen, die sich zu oft falsch anmelden. Das schützt den Server, trifft aber gelegentlich die Falschen: einen Kunden mit falsch gespeichertem Postfach-Passwort, das Büro hinter einer gemeinsamen IP oder Sie selbst. KeyHelp zeigt alle Sperren unter „Sicherheit“, „Fail2Ban-Verwaltung“ und gibt sie dort frei. Diese Anleitung zeigt, wie Sie gesperrte Adressen finden und entsperren, was dabei technisch passiert und wie Sie eigene Adressen dauerhaft ausnehmen. Für Letzteres hat das Panel in der getesteten Version kein Feld, es geht nur über eine Konfigurationsdatei. Grundlage ist ein Server wie in KeyHelp installieren und absichern.

Voraussetzungen

• KeyHelp-Server mit Admin-Zugang, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15 mit Fail2Ban v1.0.2.
• Root-Zugang per SSH oder Konsole für die Ausnahmeliste.
• Für den Test haben wir auf dem Server selbst einen Network Namespace mit zwei simulierten Clients angelegt, 198.51.100.10 und 198.51.100.20, und von dort fehlerhafte SSH- und IMAP-Anmeldungen ausgelöst. Das simuliert Angreifer und Kunden, ist aber kein Test über das Internet.

Schritt 1: Jails und Grenzwerte kennen

KeyHelp liefert Fail2Ban fertig eingerichtet aus. Die Jails stehen in /etc/fail2ban/jail.d/keyhelp.conf, aktiv waren im Test neun:

fail2ban-client status

Status
|- Number of jail:	9
`- Jail list:	kh-database, kh-dovecot, kh-ftp, kh-phpmyadmin, kh-postfix, kh-postfix-sasl, kh-roundcube, kh-snappymail, sshd

Die Grenzwerte gelten für alle Jails gemeinsam (Auszug aus keyhelp.conf):

[DEFAULT]
bantime              = 10m
findtime             = 10m
maxretry             = 4
bantime.increment    = true
bantime.maxtime      = 2w
bantime.overalljails = true

Vier Fehlversuche innerhalb von zehn Minuten führen also zu einer Sperre von zehn Minuten. Laut der kommentierten Fail2Ban-Vorlage jail.conf verlängert bantime.increment die Sperre bei Wiederholungstätern, bantime.maxtime begrenzt sie hier auf zwei Wochen. Das haben wir nicht getestet. Die Jails kh-apache (Filter apache-auth) und kh-bad-bots sind in der Datei vorhanden, aber mit enabled = false abgeschaltet.

Wichtig für eigene Anpassungen: Die Datei beginnt mit dem Hinweis DO NOT CHANGE ANYTHING IN THIS FILE, und CHANGES WILL BE LOST ON NEXT UPDATE!. Ändern Sie also nicht keyhelp.conf, sondern legen Sie eigene Werte in /etc/fail2ban/jail.local ab (Schritt 5).

Verifizieren: fail2ban-client get sshd maxretry lieferte 4, fail2ban-client get sshd bantime lieferte 600. Eine Ausnahmeliste gab es ab Werk nicht: fail2ban-client get sshd ignoreip meldete No IP address/network is ignored.

Schritt 2: Sperre auslösen und im Panel finden

Wir haben von 198.51.100.10 fünf SSH-Anmeldungen mit nicht existierenden Benutzern versucht. Nach dem vierten Fehlversuch sperrte Fail2Ban die Adresse:

2026-10-01 20:38:03,024 fail2ban.actions        [437]: NOTICE  [sshd] Ban 198.51.100.10

Technisch hängt Fail2Ban eine eigene Kette in die Firewall. Die Sperre gilt nur für die Ports des Jails, hier Port 22:

-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 198.51.100.10/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
.10 Port 22 gesperrt
.10 HTTPS: 302

Die gesperrte Adresse erreichte das Panel per HTTPS also weiterhin, nur SSH war zu. Im Panel öffnen Sie „Sicherheit“, „Fail2Ban-Verwaltung“. Oben steht je Jail die Zahl der Sperren, hier „sshd“ mit „1 x“. Darunter listet die Tabelle „IP-Adresse“, „Blockiert durch Jail“, „Blockiert seit“, „Blockiert bis“ und „Sperrdauer“.

Die IP-Adresse ist ein Link zur Whois-Abfrage des Panels. Mit „Anzeigeoptionen“ suchen Sie nach „IP-Adresse“ oder „Jail“, das hilft bei vielen Sperren.

Verifizieren: Die Zeiten im Panel stimmen mit Fail2Ban überein. Bei der zweiten Sperre lieferte fail2ban-client get sshd banip --with-time zum Beispiel 198.51.100.10 2026-10-01 20:38:54 + 600 = 2026-10-01 20:48:54, das Panel zeigte „01. Okt. 2026, 20:38:54“ bis „01. Okt. 2026, 20:48:54“.

Schritt 3: Gesperrte Adresse freigeben

Setzen Sie den Haken vor der Adresse, wählen Sie unter „- Mehrfachaktionen -“ den Eintrag „Ausgewählte IPs entsperren“ und klicken Sie auf „Übernehmen“. KeyHelp fragt: „Sind Sie sicher, dass Sie die Sperre für die ausgewählten Elemente aufheben möchten?“ Nach „Ja“ verschwindet der Eintrag, eine eigene Erfolgsmeldung zeigte das Panel im Test nicht.

Im Journal ist zu sehen, was KeyHelp dabei per sudo ausführt:

/usr/bin/fail2ban-client unban 198.51.100.10
/usr/bin/fail2ban-client status

Die rote Schaltfläche „Alle IPs entsperren“ fragt „Sind Sie sicher, dass Sie die Sperre für alle Elemente aufheben möchten?“ und ruft /usr/bin/fail2ban-client unban --all auf. Laut Fail2Ban-Befehlsreferenz hebt das die Sperren in allen Jails auf, nicht nur die von SSH. Im Test waren nur SSH-Sperren aktiv.

Verifizieren: Nach dem Entsperren war die Kette leer und Port 22 wieder erreichbar:

|- Currently banned:	0
   |- Total banned:	1
   `- Banned IP list:	
-N f2b-sshd
-A f2b-sshd -j RETURN
.10 Port 22 offen

Freigeben beseitigt nur die aktuelle Sperre. Meldet sich dieselbe Adresse wieder viermal falsch an, ist sie sofort erneut gesperrt. Im Test war 198.51.100.10 nach weiteren fünf Fehlversuchen wieder in der Liste. Klären Sie also die Ursache, zum Beispiel ein altes Passwort im Mailprogramm.

Schritt 4: Typischer Fall, ein Postfach mit falschem Passwort

Häufig betroffen sind Mailnutzer, deren Programm ein altes Passwort verwendet. Das haben wir mit dem simulierten Client nachgestellt: Von 198.51.100.20 fünf IMAP-Anmeldungen über Port 993 für info@kunde1.example.de mit falschem Passwort.

for i in 1 2 3 4 5; do ip netns exec client curl -sk -m 8 --interface 198.51.100.20 "imaps://198.51.100.1/" --user "info@kunde1.example.de:falsch$i" -o /dev/null -w "IMAPS-Login $i: %{exitcode}\n"; done; sleep 3; fail2ban-client status kh-dovecot | tail -3; iptables -S | grep "f2b-kh-dovecot" | head -3

   |- Currently banned:	1
   |- Total banned:	1
   `- Banned IP list:	198.51.100.20
-N f2b-kh-dovecot
-A INPUT -p tcp -m multiport --dports 110,995,143,993,587,465,4190 -j f2b-kh-dovecot
-A f2b-kh-dovecot -s 198.51.100.20/32 -j REJECT --reject-with icmp-port-unreachable

Das Jail kh-dovecot sperrt nicht nur IMAP und POP3, sondern auch die Versandports 587 und 465 sowie 4190 (ManageSieve). Der Kunde kann also weder abrufen noch über 587 und 465 senden. Fünf Versuche über unverschlüsseltes IMAP auf Port 143 zählten im Test dagegen nicht: Die Anmeldung kam gar nicht bis zur Passwortprüfung, Dovecot protokollierte no auth attempts, und Fail2Ban zählte Total failed: 0.

Fail2Ban sperrt nicht nur Mailprogramme, sondern auch fremde Mailserver, die wiederholt abgelehnt werden (Jail kh-postfix). Wie Sie das erkennen, zeigt KeyHelp: Mailzustellung debuggen.

Im Panel stand nun „kh-dovecot“ mit „1 x“ und in der Tabelle „Blockiert durch Jail“ „kh-dovecot“. Freigeben funktioniert genauso wie bei SSH, KeyHelp rief wieder /usr/bin/fail2ban-client unban 198.51.100.20 auf.

Verifizieren: Während der Sperre brach curl mit Exitcode 7 ab (laut curl-Dokumentation „Failed to connect“), nach der Freigabe kam wie bei der nicht gesperrten Adresse 198.51.100.10 wieder eine Verbindung zustande (Exitcode 21, curl erreichte den Server, der Testaufruf enthielt keine Zugangsdaten):

IMAPS .20: 7
IMAPS .10: 21

IMAPS .20 nach Freigabe: 21

Schritt 5: Eigene Adressen dauerhaft ausnehmen

Eine Ausnahmeliste für Fail2Ban gibt es im Panel der getesteten Version nicht. Wir haben „Sicherheit“, „Fail2Ban-Verwaltung“ und alle Punkte unter „Konfiguration“ durchgesehen. Die „Zugriffsbeschränkung auf Administratorkonten“ unter „Konfiguration“, „Login & Sitzungen“ regelt nur die Anmeldung am Panel und hat mit Fail2Ban nichts zu tun. Legen Sie die Ausnahme deshalb als root in /etc/fail2ban/jail.local an. Im Test gab es diese Datei ab Werk nicht.

printf "[DEFAULT]\nignoreip = 127.0.0.1/8 ::1 198.51.100.10\n" > /etc/fail2ban/jail.local; cat /etc/fail2ban/jail.local; fail2ban-client reload; fail2ban-client get sshd ignoreip; fail2ban-client get kh-dovecot ignoreip

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 198.51.100.10
OK
These IP addresses/networks are ignored:
|- 127.0.0.0/8
|- ::1
`- 198.51.100.10

Ersetzen Sie 198.51.100.10 durch Ihre feste IP-Adresse oder Ihr Büronetz, mehrere Einträge trennen Sie durch Leerzeichen. Behalten Sie 127.0.0.1/8 ::1 bei. Ein Eintrag unter [DEFAULT] gilt für alle Jails, auch für kh-dovecot, kh-postfix und kh-ftp.

Verifizieren: Wir haben danach von beiden Test-Adressen je sechs falsche SSH-Anmeldungen ausgelöst. Gesperrt wurde nur die nicht ausgenommene Adresse:

|- Currently banned:	1
   |- Total banned:	4
   `- Banned IP list:	198.51.100.20
2026-10-01 20:39:39,848 fail2ban.filter         [437]: INFO    [sshd] Ignore 198.51.100.10 by ip

Auch nach systemctl restart fail2ban war die Ausnahme aktiv. Eine schon bestehende Sperre hebt ignoreip übrigens nicht auf: 198.51.100.20 blieb nach dem Neustart gesperrt, bis wir sie freigegeben haben.

Typische Fehler

Adresse nach dem Freigeben sofort wieder gesperrt. Die Ursache läuft weiter, etwa ein Gerät mit altem Passwort. Im Test führten nach der Freigabe erneut fünf Fehlversuche sofort zur nächsten Sperre.

Eigene Adresse in die Ausnahme eingetragen, aber weiter gesperrt. ignoreip verhindert neue Sperren, löst aber keine bestehende. Geben Sie die Adresse zusätzlich im Panel frei oder mit fail2ban-client set sshd unbanip ADRESSE.

Änderung in keyhelp.conf verschwunden. Der Dateikopf warnt: CHANGES WILL BE LOST ON NEXT UPDATE! Eigene Werte gehören in jail.local.

Ausnahmeliste ohne Wirkung. Prüfen Sie mit fail2ban-client get sshd ignoreip, ob Fail2Ban die Datei gelesen hat. Führen Sie nach jeder Änderung an jail.local wie im Test fail2ban-client reload aus.

Häufige Fragen

Sperrt Fail2Ban den ganzen Server oder nur den Dienst?

Im Test nur die Ports des jeweiligen Jails. Eine im Jail „sshd“ gesperrte Adresse erreichte Port 22 nicht mehr, das Panel per HTTPS aber schon.

Kann ich die Ausnahme auch nur für ein Jail setzen?

Laut Fail2Ban-Vorlage jail.conf lässt sich ignoreip auch in einem einzelnen Jail-Abschnitt setzen. Getestet haben wir nur den Eintrag unter [DEFAULT], der für alle Jails galt.

Werden Sperren nach einem Neustart von Fail2Ban vergessen?

Nein. Nach systemctl restart fail2ban war die Sperre von 198.51.100.20 mit unveränderter Ablaufzeit wieder aktiv. Als Datenbank meldete fail2ban-client get dbfile die Datei /var/lib/fail2ban/fail2ban.sqlite3.

Testumfang

Wir haben in KeyHelp 26.1.1 SSH- und IMAP-Sperren mit zwei simulierten Client-Adressen im Network Namespace ausgelöst, sie im Panel einzeln und gesammelt freigegeben und eine Ausnahme per jail.local geprüft. Auffällig: Das Panel bietet keine Ausnahmeliste. Nicht geprüft: Sperren in Postfix-, FTP- und Webmail-Jails (zu kh-postfix siehe die Anleitung zur Mailzustellung), die verlängerte Sperrzeit für Wiederholungstäter und ob jail.local ein KeyHelp-Update übersteht. Prüfen Sie Ihre Ausnahme nach jedem Update mit fail2ban-client get sshd ignoreip.

Fazit

Die Fail2Ban-Verwaltung in KeyHelp ist eine übersichtliche Oberfläche für fail2ban-client: Sie sehen jede Sperre mit Jail und Ablaufzeit und geben sie mit zwei Klicks frei. Die Werkseinstellung mit vier Fehlversuchen in zehn Minuten ist streng, eine Sperre läuft aber nach zehn Minuten von selbst ab. Wer eine feste IP-Adresse hat, sollte sie trotzdem ausnehmen, damit ein Tippfehler nicht SSH und Postfach blockiert. Das geht nur auf der Konsole über jail.local. Im Test übernahmen alle aktiven Jails die Ausnahme, und die ausgenommene Adresse wurde bei SSH nicht mehr gesperrt.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• KeyHelp: Mailzustellung debuggen
• Linux-Server absichern: UFW-Firewall und Fail2ban
• VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban
• Fail2Ban-Vorlage jail.conf
• Keyweb: KeyHelp, alle Funktionen im Überblick