@manuel Poste mal bitte die Config von fail2ban (jail.local), sowie welche Version du von Raspberry OS nutzt (basierend auf Debain 11 oder Debain 12).

@marci 

In der Confic habe ich das:

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:

# normal (default), ddos, extra or aggressive (combines all).

# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.

#mode   = normal

maxretry  = 3

findtime  = 600

bantime   = 3600

port    = ssh

logpath = %(sshd_log)s

backend = %(sshd_backend)s

Habe bereits verschiedene Einträge getestet. Hatte mal noch das Beispiel aus deinem Blog drin. Erhalte leider immer den selben Error.

@manuel Probiere mal die Konfiguration von hier aus:

https://secure-bits.org/jetzt-linux-server-absichern-debian-basiert-von-a-z-2024/#fail2ban

Einfach so wie beschrieben übernehmen (wenn du ufw als Firewall nutzt und den Standardport für SSH (22))

Syslog gibt es bei Debain 12 nicht mehr und die Logs werden über journald abgehandelt.

Nach Anpassung der jail.local bitte fail2ban und sshd neu starten, dann sollte es funktionieren.

Viel Erfolg!

@marci Hallo Marcel, ok werde ich später mal versuchen. Ich nutze nicht den Standart aport bei SSH. Muss ich das noch inder confic angeben?

Gruss Manuel

@manuel Hallo Manuel,

du kannst einfach das folgende in die Conf eintragen:

[DEFAULT]
bantime = 3600
backend = systemd




[sshd]
enabled = true
filter = sshd
# Beispiel
port = 2223 

banaction = ufw
backend = systemd
maxretry = 3
findtime = 600
bantime = 3600
ignoreip = 127.0.0.1/8

@marci Hallo Marcel

Sorry für die vielen Fragen, ich habe da ein par Notizen und deine Anleitung vermischt was etwas ein Chaos verursacht hat. UUUPS  

Der Error ist jetzt natürlich weg.

Was noch nicht funktioniert, ist das ich gebannt werde, ich kann im Moment noch >4x einloggen und es geschieht nichts. ignoreip habe ich noch weggelassen da ich kurz testen wollte.

Hast du dazu auch die Lösung?  

Gruss Manuel

@manuel Guten Morgen Manuel!

Ich denke, ich weiß wo der Hund begraben liegt. Ab Debian 12 nutzt das System nftables anstatt iptables und daher funktioniert ufw in fail2ban nicht mehr.

Daher versuche bitte diese Konfiguration für fail2ban (jail.local):

[DEFAULT]
bantime = 3600
backend = systemd


[sshd]
enabled = true
filter = sshd
# Beispiel
port = 2223 

banaction = nftables-multiport
banaction_allports = nftables-allports
backend = systemd
maxretry = 3
findtime = 600
bantime = 3600
ignoreip = 127.0.0.1/8

 Das sollte klappen

Grüße Marcel

@marci

Hallo Marcel

Das hat nicht funktioniert.

Der will mich einfach nicht bannen  

 Gruss Manuel 

@manuel Hallo Manuel,

dass ist mit fail2ban ein echtes kreuz unter Debain 12!  

[DEFAULT]
bantime = 3600
backend = systemd

[sshd]

mode = aggressive
port = ssh
logpath = %(sshd_log)s
banaction = nftables-multiport
banaction_allports = nftables-allports
backend = systemd
enabled = true
maxretry = 2
findtime = 3600
bantime = 2W
ignoreip = 127.0.0.1/8

Wichtig! Der Bann erfolgt erst nach 4-5 fehlgeschlagenen Anmeldungen und nicht wie in der Config, nach 2!

Habe diese Konfiguration auf einen meiner Tor-Relays via Bruteforce-Attacke über diverse IP-Adressen getestet und es funktioniert (siehe Screenshot).

Es funktioniert das Blocken bei Anmeldung via Passwort sowie mit Anmeldung via publickey.

Das Problem ist, dass fail2ban nicht wirklich mehr weiter gepflegt wird und unter Debian 12 (nutzt kein Syslog, sondern journald), die Standard-Config nicht mehr funktionieren.

Ich hoffe, das hilft dir jetzt weiter...

Grüße Marcel

@marci Hallo Marcel

Habe gerade kurz getestet.

Ob ich beim Port 'ssh' eintrage oder mein geänderter Port, spielt keine Rolle. Fail2Ban zählt die versuche auf jeden fall mit. Jedoch habe ich 3 versuche mit dem Public Key, diese 3 zählt Fail2Ban als einen Fehlversuch.

Im jail.local habe ich zum testen folgendes:

maxretry = 1

findtime = 600

bantime = 2

Status:

Geblockt werde ich nicht, kann mich mit dem passenden PW zum Publickey immer wider anmelden.

Echt ein komisches verhalten  

Gruss Manuel

@manuel Guten Morgen Manuel,

ich habe mich mal ein wenig kundig gemacht.

Ich denke, dass dieses merkwürdige Verhalten, mit der Komptabilität von fail2ban in Version 1.02 und dem aktuellen Debian zu tun hat. 

Wenn ich im Changelog von fail2ban auf Github schaue, werden Probleme mit sshd beschrieben und in der aktuellen Version Unstable-Version (also noch vor Testing unter Debian) 1.1.0-4 sollen diese Probleme behoben worden sein.

Quelle: https://github.com/fail2ban/fail2ban/blob/1.1.0/ChangeLog

Vielleicht wäre auch noch Crowdsec eine Alternative für dich?!

Hier eine Anleitung dazu:

https://docs.crowdsec.net/docs/getting_started/install_crowdsec/

Viele Grüße 

Marcel

@marci Hallo Marcel

Oke, danke für deine Hilfe.

Werde mir CrowdSec mal anschauen, so nach dem ersten Blick sieht das schonmal sehr spannend aus

Gruss Manuel