fail2ban: Wie viele Sperren sind normal?

[Sebbi]

Deswegen VPN, da hast du dann immer die gleiche IP

Welcher VPN Dienst garantiert dir immer eine Feste Ip als Exit?
Das hab ich bei noch keinen gesehen und selbst dann ... wenn der VPN Dienst zu macht, warum auch immer, kommst du auf einmal auch nicht mehr auf den Server, da der ja lle Verbingungen verweigert.

Sowas kannst du machen, wenn du physichen Zugriff auf den Server hast, nicht aber wenn der irgendwo in einen Rechenzentrum steht oder VM, wo du kein alternatives HW Interface hast, auf welches du zugreifen könntest im Notfall. Und sowas würde die monatlichen Kosten massiv in die Höhe treiben.

Ich sehe auch wo dein Fehler liegt - du denkst das der Server beim TE zu Hause steht, was aber mit den Aussagen "Webserver" vom TE ganz anders klingt. Heißt einfach per VPN @ home einwählen und auf den Server lokal zugreifen ist nicht.

 

[kieleich]

?

ist dein eigener ssh dienst

ist dein eigener vpn dienst

 

[CyborgBeta]

Ist mein eigener dedicated Server bei Hetzner. Für die Sicherheit bin ich verantwortlich.

Ich könnte zwar als Fallback ins Rescue System booten ... aber ob ich da weiter käme, ist fraglich.

@Sebbi hat schon recht, ein VPN mit immer der gleichen IP ist mit Kosten verbunden, und ich könnte mich selber ausschließen.

Zurzeit sind immer so 10 IPs gesperrt, und täglich gibt es ca. 1500 Versuche.

Ich nehme an, da wird automatisiert versucht. Ich könnte zwar noch einmal den Port ändern, aber dann wäre es nur eine Frage der Zeit, bis jemand noch einmal manuell Ports scannt.

Als Alternative gibt es noch Crowdsec, aber mWn. verwenden diese auch fail2ban.

 

[Pummeluff]

Nach paar Tagen hat man tausende Bans in der Liste die auch unnötig die Firewall belasten.

Nö. Die Bans sind bei mir im einstelligen Bereich. S.o.

Wär es nicht sinnvoller allen den Zugang zu versperren und via Whitelist nur die rein zu lassen, welche bekannt sind?

Ich greif auf die Server von verschiedenen Geräten aus zu, die auch dynamische Adressen haben. Eine Whitelist ist da ungünstig. Wireguard hab ich sowieso am Laufen. Aber der ssh-Zugang ist der Reparaturzugang, wenn die Wireguard-Verbindung mal spinnt.

Ich könnte zwar noch einmal den Port ändern,

Bringt auch nichts. Ich hab einen Server mit ssh auf 22 und zwei Server mit Port 222. Die Anzahl der Angriffe ist in etwa gleich.

Ich seh die Problematik aber auch nicht sonderlich kritisch. Bisher ist noch niemand unberechtigt auf die Server gekommen.

 

[K-551]

Ich sehe auch wo dein Fehler liegt - du denkst das der Server beim TE zu Hause steht, was aber mit den Aussagen "Webserver" vom TE ganz anders klingt. Heißt einfach per VPN @ home einwählen und auf den Server lokal zugreifen ist nicht.

Jup, exakt das war mein Gedanke.
Server steht zu Hause/Firma. Hab nicht weiter dran gedacht, dass das ja ext. sein kann...
Asche auf mein Haupt.

Bin da leider "verwöhnt" oder eher gestraft, je nach Standpunkt.
Bisher alles mit physischen Zugang. Oder halt Online-Services, wo man sich um sowas keine Gedanken machen muss...

 

[CyborgBeta]

Habe jetzt auch noch "ping", also das ICMP-Protkoll komplett deaktiviert, und blockiere bei Versuchen zusätzlich auch noch UDP-Ports. Jetzt ist nicht mehr so viel los in den Logs, aber die Anzahl der Bans steigt.

Wie hier beschrieben: https://serverfault.com/a/641239

Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 317
| `- Journal matches:
`- Actions
|- Currently banned: 1
|- Total banned: 101
`- Banned IP list:

Das sind die Stats von heute Morgen, 8 Uhr bis jetzt.

 

[Pummeluff]

Also 1 (currently banned) ist nicht sonderlich viel.

 

[CyborgBeta]

Ja, das schwankt immer, mal ist mehr, mal weniger los ... zurzeit ~10.

Btw., Docker verwendet die Forward-Chain, nicht die Input-Chain. Wenn man für eine IP also komplett alles "dicht" machen will, dann braucht man zwei Ban-Actions:

bantime.increment = true
bantime           = 15m
findtime          = 15m
maxretry          = 3

protocol           = all
banaction          = iptables-multiport
banaction_allports = iptables-allports

action_ = %(banaction_allports)s[actname="all-i", port="%(port)s", protocol="%(protocol)s", chain="INPUT"]
          %(banaction_allports)s[actanem="all-d", port="%(port)s", protocol="%(protocol)s", chain="DOCKER-USER"]

action = %(action_)s


[sshd]
enabled   = true
mode      = aggressive
logpath   = /var/log/auth.log
backend   = systemd

...

Das sind so meine wesentlichen Optionen ...

Zusätzlich filtere ich noch alle 4xy-Status-Codes, wenn jemand 10-mal eine ungültige Seite aufrufen möchte, und ein 404 zurückkommt.

Funktioniert gut, und beim Neustart sollte es auch keine Konflikte geben. Und, wie gesagt, "ping" ist auch noch verboten.

Man könnte sich noch streiten, ob ein Drop, Reject oder Reject with ... besser wäre. Beim Drop wartet der Client vielleicht, beim Reject ... bekommt er mit, dass keine Verbindung möglich ist. Aber das ist sehr theoretisch.

Zum Weiterlesen: https://unix.stackexchange.com/questions/109459/is-it-better-to-set-j-reject-or-j-drop-in-iptables

 

[Pummeluff]

logpath   = /var/log/auth.log
backend   = systemd

ist übrigens nicht unbedingt sinnvoll. Wenn du Systemd als einzigen Logger hast, wird kein /var/log/auth.log erstellt.

Allerdings hab ich so das Gefühl, dass du Dich zu intensiv auf dieses Thema stürzt. Wenn du oben meinen Log-Auszug mal ansiehst, erkennst du schnell, dass die IPs mittlerweile nach jedem 2. Aufruf wechseln. Die Skriptkiddieskriptersteller sind ja auch nicht blöd und kennen das Verhalten der IP-Sperren. Entsprechend schlägt fail2ban hier nur selten an.

 

[CyborgBeta]

Wenn du Systemd als einzigen Logger hast, wird kein /var/log/auth.log erstellt.

Habe mehrere:

Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd

Ergänzung (8. Mai 2025)

@Pummeluff Soll ich dann das Backend wieder austragen und auf "auto" lassen?

 

[Pummeluff]

Meine Config:

[DEFAULT]
ignoreip = 127.0.0.1/8 192.168.0.0/16
banaction =             nftables-multiport
banaction_allports =    nftables-allports
chain =                 input

[recidive]
banaction =             nftables-allports

[sshd]
enabled = true
backend = systemd
port    = ssh
filter  = sshd
maxretry = 3

Ich nutz nftables statt iptables. Und mir reicht auch das Verhalten. fail2ban ist nur ein kleiner, wohl eher kostmetischer Teil des Sicherheitskonzeptes. Wichtiger ist die Firewall selbst und das Absichern des SSH-Dienstes: nur bestimmte Nutzer zulassen + Passwort-Login deaktivieren.