KeyHelp Community

Hallo zusammen,

wie einige hier mitbekommen haben, musste ich mein System mit Ubuntu 24.04 neu aufsetzen, weil das Update von 22.04 fehlgeschlagen ist. Seitdem ist mir aufgefallen, dass bei Fail2Ban nicht mehr die Einträge von kh-recidive anwachsen, also es immer nur den Eintrag 0 bei kh-recidive gibt. Das kann doch an und für sich gar nicht sein, wenns zuvor anders war? Oder musste ich da noch einmal irgendwas aktivieren?

Ich weiß es leider nicht mehr.

Liebe Grüße von

Björn

Guggst du hier und benutze bitte die Suche!

viewtopic.php?p=50403#p50403

Den Beitrag kenne ich von mir. Ist ja noch nicht so lange her. Aber der angefragte Filter für Widerholungstäter wird trotzdem nicht bedient.

In den Standardeinstellungen muss ein anderer Filter 4 mal eine IP sperren innerhalb von 24 Stunden, bis die IP übers recidive geblockt wird.
Ich vermute das ist bei dir einfach noch nicht der Fall gewesen.

Der gemeine Bot aus dem normalen Hintergrundrauschen probiert seine 5 Standardpasswörter aus, merkt das er gesperrt wird und zieht weiter. Der versucht es nicht den ganzen Tag über mit der selben IP nur bei deinem Server, dafür hat er viel zu viele andere Server-IPs, die er ausprobieren kann.

Kannst auch auch den maxretry der recidive Regel runterstellen, dann sollte er häufiger anschlagen.

Hallo Alexander,

vielen lieben Dank für deine tolle und ausführliche Erklärung. ich sehe nur, dass eben sehr viele SSH-Versuche stattfinden - also überproportional repräsentiert sind. Wenn es im jail.d die keyhelp.local ist, dann habe ich die Eintragung wohl richtig gemacht?

--
[kh-recidive]
enabled = true
filter = recidive
logpath = /var/log/fail2ban.log
action = iptables-allports[name=recidive]
maxretry = 3
bantime = 1w
findtime = 1d
--

Nachteil ist dann wohl nur, dass beim nächsten Update die Änderung (vorher stand maxretry = 4) wieder zurück gesetzt wird?

Liebe Grüße von

Hahni

goldene-zeiten wrote: ↑Thu 7. Nov 2024, 21:25 ......

Nachteil ist dann wohl nur, dass beim nächsten Update die Änderung (vorher stand maxretry = 4) wieder zurück gesetzt wird?

Liebe Grüße von

Hahni

Mach Dir eine eigene jail.local unter /etc/fail2ban/jail.d/ dann ist das auch Update sicher

Dann müsste ich doch aber die Regel von keyhelp.local in meine eigene Config-Datei übernehmen? Oder eine zweite anlegen? Im ersten Fall würde die ja dann beim Update auch wieder angelegt und es würden wieder zwei existieren?!?

goldene-zeiten wrote: ↑Fri 8. Nov 2024, 11:58 Dann müsste ich doch aber die Regel von keyhelp.local in meine eigene Config-Datei übernehmen? Oder eine zweite anlegen? Im ersten Fall würde die ja dann beim Update auch wieder angelegt und es würden wieder zwei existieren?!?

Die keyhelp.local sollte natürlich bestehen bleiben. Aber du kannst im selben Verzeichnis (etc/fail2ban/jail.d/) zum Beispiel zusätzlich eine Datei "mykeyhelp.local" anlegen und darin alle Änderungen gegenüber der keyhelp.local definieren. Der Dateiname ist weitgehend egal, muss aber lexikalisch nach "keyhelp.local" kommen, da die .local Dateien in diesem Verzeichnis - wie allgemein üblich - in dieser Reihenfolge eingelesen und bearbeitet werden. Hiesse deine Datei also aaa.local, dann würde zwar alles was drinsteht auch eingelesen, aber durch einen gleichen Eintrag in der keyhelp.local gleich wieder überschrieben werden. Bei einem Update von Keyhelp wird dann nur die keyhelp.local (eventuell) geändert, deine mykeyhelp.local wird sich beim Keyhelp-Update nicht ändern und die Einträge darin werden weiterhin benutzt und überschreiben die Werte aus der keyhelp.local.

Vielen lieben Dank für deine tolle und ausführliche Erklärung. Das hat mir sehr weitergeholfen. Die Lösung, die bestehenden Regeln von KeyHelp updatesicher zu überschreiben, ist perfekt. Den Weg werde ich gehen und mich zudem auch noch mal in die Regelwerke einarbeiten. Scheinbar ist fail2ban nicht restriktiv genug eingestellt im Standard oder die Brute-Force-Versuche sind nicht so wild, wie ich sie bewerte.

Hat jemand von euch ein Regelwerk, welches weit über das von KeyHelp hinaus geht? Ich würde gerne stringenter vorgehen wollen mit Fail2ban.

Was die Angriffe per SSH betrifft, hat Alexander ja bereits die Vorgehensweise der meisten Bots erklärt. Mit den heutigen Botnetzen haben dese Angreifer heute leider sehr viel mehr IPs für ihre Versuche zur Verfügung, diese kommen auch nicht unbedingt alle aus der selben Region.

Wenn du SSH-Verbindungen nur mit Public Key zulässt, bist du gegen die allermeisten dieser Versuche auch schon abgesichert. Das sind die Kandidaten, die irgendwelche Usernamen mit Passwortlisten durchprobieren damit aber schon daran scheitern, dass zur Anmeldung kein Key mitgeschickt wird. Ich erlaube zur weiteren Absicherung auch keinen Login als root, auch nicht mit Key. Damit ist SSH eigentlich schon gründlich gesichert. Der Rest ist dann eigentlich nur noch zur Vermeidung von aufgeblähten Logs zuständig.

Die Default-Einstellungen von Keyhelp sind wohl weniger restriktiv ausgelegt, damit sich auch ungeübte Kunden nicht täglich durch irgendwelche Fehlversuche aussperren und dann anrufen. Ich gehe mal davon aus, du hast keine Kundenlogins auf deinem Server. Dann kannst du natürlich weit restriktiver agieren. Ich habe z.B. bei sshd und kh-recidive den Parameter max_retry auf 2 stehen, das macht schon mal einen Unterschied. Da ich in der Regel nur von zuhause zugreife, mache ich für die von dort verwendeten IPs, bei mir ein festes /64 IPv6 Subnetz, das mir vom Provider zugewiesen ist, eine Ausnahme für alle Jails. Das sieht dann so aus in meiner server.local Datei: Damit komme ich zumindest schon mal von zuhause immer wieder in Keyhelp rein und kann versehentlich gesperrte IPs dort entsperren. Das ist deutlich bequemer, als das über die VNC-Konsole beim Serveranbieter machen zu müssen, was aber dafür im Notfall von überall aus funktioniert. Feste IPv4 habe ich zuhause nicht, sonst würde ich die da ebenfalls angeben. Das gesamte IPv4 Netz des Providers möchte ich nicht freigeben.

Je nachdem, von wo aus du im Normallfall per SSH zugreifen musst, kannst du eventuell auch einfach nur die entsprechenden IPs in der Firewall für Port 22 (SSH) freigeben und alle anderen IPs nicht. Damit herrscht dann Ruhe und du kannst das SSHD-Jail in fail2ban ggf dann auch ganz stilllegen.

Vielen lieben Dank für deine ausführliche Erklärung. Ich werde noch einmal darüber nachdenken, wie ich das verbessern kann. SSH ist aber derzeit nicht mein Thema. Da gibt es zwar ein gewisses Grundrauschen, aber keine besonderen Auffälligkeiten, was die Versuche betrifft. Nichtsdestotrotz will ich die Anzahl auf 0 legen. Den Port umverlegen wäre doch auch eine Option?

Ich möchte aber gerne auf einer Webseite den Zugang zum Admin-Panel (KeyHelp) hinterlegen. Hier würde ich auch wollen, dass nach 2 oder 3 Fehlversuchen die IP gesperrt wird, wenn sich dort jemand versucht, mit BruteForce anzumelden. Das Regelwerk meine ich, ist aber noch nirgends hinterlegt oder vorgesehen?

KeyHelp selbst ist nicht auf Fail2Ban angewiesen und bringt seine eigenen Schutzmachanismen mit.
Alles konfigurierbar unter "Konfiguration" -> "Login & Sitzungen".
Zusätzlich gibts unter den Profileinstellungen noch den Punkt "Anmeldebenachrichtigung senden"

Vielen lieben Dank für deine Erklärung, Alexander.


Aber was genau heißt die Einstellung dann tatsächlich?

Brute-Force-Schutz
Anmeldeversuche werden gedrosselt, wenn das System zu viele ungültige Anfragen von einem IP-Subnetz erkannt hat. Hier können Sie festlegen, um wie viele Sekunden weitere Anfragen aus diesem IP-Subnetz maximal gedrosselt werden sollen.

Wenn jemand versucht sich wiederholt mit falschen Daten anzumelden, wird die Zeit, bis er seinen nächsten Anmeldeversuch durchführen darf gedrosselt.
Ein fiktiver Bot, der es auf den KeyHelp Login abgesehen hat versucht innerhalb von kürzester Zeit tausende Passwörter. Wenn dieser nun bei jedem Zugriffsversuch X Sekunden warten muss, ist das für ihn nicht mehr erfolgsversprechend.