Vorwort:
Ich freu mich wie ein Schnitzel: Dies ist mein erster selbst gestarteter Thread hier im Forum und zudem hab' ich Fail2Ban für Uptime Kuma eingerichtet bekommen. 
Da es weder hier im Forum noch in diesem Internet eine Anleitung dafür gibt, schreibe ich hier mal zur Doku meine Anforderungen, die Ausgangssituation und als Beitrag für die Community die implementierte & getestete Lösung.
Gerne darf dieser Thread themenbezogen für die Verwendung von Fail2Ban mit Uptime Kuma genutzt werden.
Diskussionen über das böse systemd und den tollen Docker aber bitte woanders führen, denn hier geht es um Uptime Kuma auf Debian ohne Docker mit systemd. 
Einleitung und Ausgangssituation:
Während KrisAusEU die letzte Nacht mit seinem Windows-USB-Stick verbrachte, habe ich mir die Nacht mit etwas Sinnvollem um die Ohren geschlagen und wollte "nur kurz auf die Schnelle" Fail2Ban für meinen Uptime Kuma Server(-dienst) auf Debian 12 einrichten. Schlussendlich ging es dann doch nicht ganz so schnell, sondern ging nur in kleinen Schritten mit eingen "Aha-Momenten" voran.
- Betriebssystem: Debian GNU/Linux 12 (bookworm) Linux version 6.1.0-25-amd64 (Debian 12.2.0-14)
- Server: netcup Piko VPS piko G11s (KVM Server / x86-64)
- Uptime Kuma: Monitoring tool zur Überwachung anderer Server, Webseiten und Dienste
- Fail2Ban: Dienst der potentielle Angreifer (die z.B. durch fehlerhafte Passworteingaben auffallen) mittels IP-Ban ausschließt
Debian 12 wurde letztes Jahr mittels des netcup-Images auf den Server installiert.
Uptime Kuma habe ich mir (weil ich es schon immer so gewohnt bin) ohne Docker als Standalone-Dienst in Anlehnung an dieses Tutorial installiert.
Dabei habe ich jedoch teilweise auf jüngere Softwareversionen gesetzt:
Mit dieser Installation läuft Uptime Kuma nun ohne Docker mit systemd Logging.
Auf die Installation von Fail2Ban wird z.B. in diesem Tutorial hier beschrieben. Mein Problem war die Konfiguration für Uptime Kuma.
Leider gibt es Seitens der Uptime Kuma Entwicklungstruppe scheinbar kein Interesse an einer Implementierung bzw. Förderung zur Verwenung mit Fail2Ban.
Dieser Thread auf Github bietet keine Lösung die für mich als Endanwender verständlich ist. Es wird zwar angedeutet, dass jemand Fail2Ban mit Uptime Kuma ans Laufen bekommen hat, aber leider ohne konkrete Hinweise wie das mit systemd läuft.
Stattdessen wird dort auf das Rate-Limiting innerhalb von Uptime Kuma verwiesen, welches Angreifer nach einer nicht einstellbaren Anzahl von Fehlversuchen in einem nicht einstellbaren Beobachtungszeitraum, für eine nicht einstellbare vorübergehende Zeit ausschließlich für Uptime Kuma aussperrt (banned).
Fail2Ban bin ich gewohnt und ich möchte auch für Uptime Kuma im laufenden Setup die fein einstellbaren Parameter (maxretry, findtime und bantime) und vor allem die banaction selbst einstellen.
Ich halte es nämlich wie #JohnWick - wer sich an meinem Server zu schaffen macht, hat seine Privilegien für sämtliche Dienste und Ports für lange Zeit verwirkt 
Umsetzung / Implementierung:
Folgende Einstellungen haben mir zu einem funktionsfähigen Setup von Fail2Ban mit Uptime Kuma verholfen.
Nach drei falschen Passworteingaben werde ich ausgesperrt und meine dynamische IP erscheint als banned:
#
# HTTP servers
#
# selbst geschriebenes Uptime-Kuma Jail:
[uptimekuma]
enabled = true
filter = uptimekuma
backend = systemd[journalflags=1]
journalmatch = _SYSTEMD_UNIT="uptimekuma.service"
port = http,https
maxretry = 3
# Angreifer hat seine Zugriffsbefugnisse durch eigenes Tun vollständig verwirkt #JohnWickDen Filter uptimekuma muss man selbst anlegen, indem die Datei uptimekuma.conf z.B. mit nano angelegt wird.
Im Ordner /etc/fail2ban/filter.d liegt dann die Datei mit dem Inhalt:
[Definition]
failregex = Incorrect username or password for.+IP=<HOST>
ignoreregex =Fail2Ban wird dann neu gestartet und die neue uptimekuma-Jail geprüft:
systemctl restart fail2ban.service
fail2ban-client status
fail2ban-client status uptimekuma
fail2ban-client status sshdEs ist sicher empfehlenswert (zumindest habe ich das so gemacht) wenn man nach diesen Änderungen SSH-Angriffe und Uptime Kuma mit falschen Passwörtern testet.
Hierzu helfen dann die üblichen Logeinträge bei der Analyse während und nach den Angriffen weiter.
journalctl -r -u uptimekuma
journalctl -r -u ssh
iptables -L f2b-uptimekuma -n -v
iptables -L f2b-sshd -n -v
iptables -vnLFazit:
Uptime Kuma hat einen eigenen Rate-Limit-Algorithmus für unberechtigte Loginversuche.
Dieser wird durch die zusätzliche Verwendung von Fail2Ban nicht untergraben. Die Sicherheit bleibt schlimmstenfalls gleich.
Ungeachtet dessen dürfte die Filter-Sicherheit von Fail2Ban mit der _SYSTEMD_UNIT und dem failregex aus meiner naiven Sicht halbwegs sicher sein.
Verbesserungsvorschläge die über das Optische hinaus gehen nehme ich gerne an.
Mit Fail2Ban kann ich Angreifer besser aussperren als mit Uptime Kuma. Ich habe meine obige Konfiguration auf eine banaction mit allen Ports erweitert. Damit werden sämtliche Pakete des Angreifers gedropped. Dann kann man den Server nichtmal mehr anpingen.
Das hat aber nichts mit dieser Anleitung zu tun. Andere verwenden regionenspezifische IP-Sperrlisten - man macht das was einem am besten gefällt...
Ich selbst kann mich praktisch nicht aussperren: Durch die Verwendung von Passwortmanagern ist es unwahrscheinlich dass ich mehrmals das falsche Passwort an den Server schicke.
Falls dies doch geschen sollte, ziehe ich mir eine neue dynamische IP oder logge mich über einen ignored-IP Jumphost mit SSH ein.
fertig bin. Einen Piko habe ich noch in Reserve, zur Not auch den Cyber Quack.