Fail2Ban SSHD Anzeige

Hallo,

ich habe mir eben eine frische Kiste mit Debian 12 installiert. Folgende Dinge habe ich bereits gemacht: RootLogin verboten, Login mittels Passwort verboten und den SSHD Port geändert.

Jetzt wollte ich trotzdem gerne noch den Server mittels Fail2Ban absichern. Dabei stolpere ich aber über folgende Sache die mich nicht in Ruhe lässt: Laut journalctl geht UFW schon hin und bannt fröhlich IPs wie sonst was. Das sieht zensiert so aus: Apr 04 21:56:35 ts3server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=xxx SRC=xxx DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=63200 PROTO=TCP SPT=5176 DPT=23 WINDOW=25408 RES=0x00 SYN URGP=0.

Jetzt dachte ich also, wenn ich mir die Fail2Ban Info zu SSHD anschaue, müsste ich da ja eine Anzahl sehen. Aber das kommt dabei rum:

root@ts3server:/var/log# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:

Also nichts... Und jetzt frage ich mich wieso... Die Jail Einstellung sieht so aus:

[sshd]
#mode   = normal
port    = YYY
#logpath = %(sshd_log)s
backend = systemd

Ich hoffe da kann mir wer Licht ins Dunkel bringen. Ich bin da nämlich sehr verunsichert, ob das ganze überhaupt so

Nein, liegt auf einem viel höherem.

Zitat von tab

Warum denkst du dann, dass der Logeintrag etwas mit SSHD zu tun hat?

Das ist eigentlich eine gute Frage... Ich dachte halt, dass Fail2Ban dafür zuständig ist, weil sonst auf diesem Server nichts läuft.

Zitat von DerRené

Das Beispiel zeigt ja keinen Ban, sondern lediglich einen Block im UFW Log auf dem offenbar ohnehin ungenutzten Port 23. Bannen kann in dem Sinne UFW ohnehin nicht im Alleingang. Wenn dann bannt fail2ban, indem es z.B. UFW dafür nutzt und temporäre Blocks für sonst offene Ports hinzufügt.

Also ich sehe halt das minütlich mehrere Einträge habe mit UFW Block. Der DPT als auch IP sind immer unterschiedlich, was auffällt ist das die MAC fast immer identisch ist.

Zitat von DerRené

Joa das ist halt das norrmale Grundrauschen, das durch deine default policy in UFW geblockt wird. Nehme ich zumindest an, da du sagst dass du Port 23 nirgends verwendest.

Wird bei dir ähnlich eingerichtet sein nehme ich an?

Code

$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Alles anzeigen

Der springende Punkt ist der Default-Wert für incoming Traffic: deny (incoming). UFW blockt halt alles, außer das was du explizit freigibst (in meinem Beispiel http/https). Das taucht dann auch je nach Loglevel in den Logs auf. Dank des allwärtigen Grundrauschens sind das üblicherweise viele Einträge, vor allem auf Standardports.

Fail2Ban wiederum fügt erst eigene Block-Regeln hinzu, wenn einer seiner Filter etwas in deinen Logs (zb /var/log/auth.log für ssh) findet und sperrt dann gezielt Ports und IPs, die sonst die eigenen Regeln passieren würden. Und erst hier spricht man dann üblicherweise halt auch von einem (temporären) Ban.

Wie gesagt, löse ruhig selbst einen Ban gezielt aus und prüfe, ob deine Filter auch sauber arbeiten. Vor allem wenn man keine Standardports verwendet, ist es wichtig, dies an allen Stellen zu berücksichtigen und zu testen.

Alles anzeigen

Ja habe tatsächlich eine ähnliche Ausgabe:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

Das mit dem eigenen Ban werde ich mal testen.