Mont-Bit
Anmeldungsdatum: 4. Januar 2011
Beiträge: Zähle...
|
Hallo, ich betreibe ein Minecraft BungeeCord Netzwerk am PC und ein Owner hat über SSH Zugriff auf seinen Server (Account). Es ist Fail2Ban installiert und die Log-Datei mit Ban/Unban wird immer länger. Nun wollte ich Länder wie China, Russland, Indien u.s.w. in der /etc/hosts.deny eintragen, da von dort massiv Brute-Force auf das Root Passwort versucht wird. Seit gut 6 Wochen versucht eine IP aus Indien hartnäckig nach Unban weiterhin das Root Passwort zu hacken. Dürfte bei der Länge des Passwortes eher unwahrscheinlich sein, dass er es innert Jahresfrist schafft. Trotzdem möchte ich jetzt bestimmte Länder in der hosts.deny eintragen, damit diese gar keinen Zugriff mehr haben. Wie wird richtig eingetragen? Trennen mit Leerzeichen oder Doppelpunkt, dann landen die ungebetenen Gäste immer noch auf der Log-Datei von Fail2Ban. Mit Komma wie in Zeile 4 + 5 habe ich eine Fehlermeldung in der auth.log (warning: /etc/hosts.deny, line 18: missing ":" separator).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 | # /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID
#
ALL: .cn: .ru: .us: .in: .pl
|
Danke im Voraus monti
|
jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
Mont-Bit schrieb: Nun wollte ich Länder wie China, Russland, Indien u.s.w. in der /etc/hosts.deny eintragen, da von dort massiv Brute-Force auf das Root Passwort versucht wird.
Entschuldige, aber das ist Unsinn. Nicht das von dort versucht wird das Passwort zu knacken, sondern ganze Länder auszusperren. Solche Angriffe können genauso gut auch über ein VPN geleitet werden oder aus anderen Ländern kommen. Ein sinnvoller Weg SSH sicherer zu machen wäre zum Beispiel root gar keinen Zugriff zu erlauben. Dann wird mit sudo gearbeitet, ist unter Ubuntu ja sowieso Standard. Der zweite Schritt besteht dann darin keine Passwörter für den Login zu verwenden, sondern Public Keys. Wer keinen Schlüssel hat kommt nicht mehr rein, es gibt also kein Passwort, was man Brute-Forcen könnte. Dann können dir das Thema eigentlich egal sein und schreiben höchstens die Logfiles voll. ~jug
|
Mont-Bit
(Themenstarter)
Anmeldungsdatum: 4. Januar 2011
Beiträge: Zähle...
|
IP's von China, Russland u.s.w. haben nichts auf meinem System verloren! Ich musste länger tüfteln, bis ich dank der "grossartigen Hilfe" zur Lösung kam. Nun zeigt die auth.log folgendes: refused connect from 5*.***.***.***
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Du hast offensichtlich keine große Erfahrung mit Servern. Kack nicht Andere an, die diese haben und Dir sinnvolle Ratschläge geben. 🙄
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Mont-Bit schrieb: IP's von China, Russland u.s.w. haben nichts auf meinem System verloren!
OK, man kann die hosts.allow oder die hosts.deny benutzen um bestimmte IP-Adressen zu blocken, aber m. E. geht das mit den hosts.*-Dateien nur dann, wenn reverse DNS für diese IP-Adresse(n) möglich ist. Z. B. die IP-Adresse:
:~$ dig -x 27.251.94.73 +short
;; Truncated, retrying in TCP mode.
abs-static-73.94.251.27.aircel.co.in.
kann geblockt werden und die indische IP-Adresse:
:~$ dig -x 202.91.73.30 +short
;; Truncated, retrying in TCP mode.
kann mit:
sshd : .cn .ru .us .in .pl : deny
mit der hosts.allow nicht geblockt werden.
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5350
|
Ich stimme hier mit jug undV_for_Vortex ueberein: Blockiere nicht haendische x-beliebige IPs, sondern lass die Arbeit fail2ban erledigen. Das ist 1) deutlich weniger Arbeit 2) weniger fehleranfaellig. Mont-Bit schrieb: dank der "grossartigen Hilfe"
Die "grossartigen Hilfe" besteht aus dem dringenden Abraten vor der Umsetzung deines Vorschlags. jug hat schon beschrieben, wie ein SSH-Server richtig abgesichert wird. Public Key, kein root und fail2ban.
|
Mont-Bit
(Themenstarter)
Anmeldungsdatum: 4. Januar 2011
Beiträge: 205
|
Entschuldigt, ich habe gereizt reagiert, da ich nicht die Lösung zu meiner Frage erhielt. Ich hatte mir PublicKeys durchgelesen, jedoch bei der Umsetzung erwarte ich erheblich Probleme. Vor allem, wie dann noch einem Windows Anwender geholfen werden soll, dies umzusetzen. lubux schrieb: kann mit:
sshd : .cn .ru .us .in .pl : deny
mit der hosts.allow nicht geblockt werden.
Danke, das ist ein Wort. IP's von Hand eintragen wollte ich nicht, habe es jedoch getestet, ob es funktioniert. Root ist jetzt blockiert und ich logge mich mit meinem Namen ein. Dann lasse ich Fail2Ban seine Arbeit weiter erledigen.
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
Mont-Bit schrieb: Ich hatte mir PublicKeys durchgelesen, jedoch bei der Umsetzung erwarte ich erheblich Probleme. Vor allem, wie dann noch einem Windows Anwender geholfen werden soll, dies umzusetzen.
Geht auch mit Putty problemlos!
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Mont-Bit schrieb: Entschuldigt, ich habe gereizt reagiert, da ich nicht die Lösung zu meiner Frage erhielt.
Danke für Deine Einsicht. 👍 Sorry im Gegenzug für meine Anfuhr.
|
Mont-Bit
(Themenstarter)
Anmeldungsdatum: 4. Januar 2011
Beiträge: 205
|
TheDarkRose schrieb: Mont-Bit schrieb: Ich hatte mir PublicKeys durchgelesen, jedoch bei der Umsetzung erwarte ich erheblich Probleme. Vor allem, wie dann noch einem Windows Anwender geholfen werden soll, dies umzusetzen.
Geht auch mit Putty problemlos!
Du kennst Murphis Gesetz? Was schiefgehen kann, geht auch schief. Ich bin kein IT-Guru, und der Server lief auch nicht auf Anhieb problemlos.
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5350
|
Mont-Bit schrieb: TheDarkRose schrieb: Mont-Bit schrieb: Ich hatte mir PublicKeys durchgelesen, jedoch bei der Umsetzung erwarte ich erheblich Probleme. Vor allem, wie dann noch einem Windows Anwender geholfen werden soll, dies umzusetzen.
Geht auch mit Putty problemlos!
Du kennst Murphis Gesetz? Was schiefgehen kann, geht auch schief. Ich bin kein IT-Guru, und der Server lief auch nicht auf Anhieb problemlos.
Kommst du nun mit Keyfiles in Putty klar oder nicht?
|
Mont-Bit
(Themenstarter)
Anmeldungsdatum: 4. Januar 2011
Beiträge: 205
|
Nein, ich komme damit nicht klar. Da ich auch kein Windows mehr habe, wüsste ich nicht einmal, wie ich dem Windows Anwender helfen müsste.
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5350
|
|
Mont-Bit
(Themenstarter)
Anmeldungsdatum: 4. Januar 2011
Beiträge: 205
|
Ich komme damit nicht klar: Jeder einzelne Minecraft Server und auch BungeeCord im Netzwerk hat einen eigenen Usernamen auf ein und demselben PC . Eingeloggt wird bisher mit "ssh username@server-ip" + Passworteingabe. Ich verstehe dabei nicht, wie ein Schlüssel nun die verschiedenen User + Passwörter voneinander unterscheiden kann. Ein User darf doch nicht mit einem einzigen Systemschlüssel in einen anderen Useraccount einloggen können. Dann kommt das andere Problem. User X soll temporär Zugang auf Account Y bekommen und später keine Loginrechte mehr haben. Momentan ändere ich das Passwort und gut ist. Wenn ich mit einem Schlüssel arbeite, muss der doch immer wieder geändert werden und dann dem User Y (Servereigentümer) gesendet werden. Dann ist noch ein Problem. Wenn bei den Schlüsseln kein Passwort mehr nötig ist, kann z.B. der kleine Bruder von User Z einfach so einloggen und Unfug treiben. Wie so oft hat ein Familien-PC einen einzigen Account, an dem alle ransitzen und rumwerkeln.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Mont-Bit schrieb: Jeder einzelne Minecraft Server und auch BungeeCord im Netzwerk hat einen eigenen Usernamen auf ein und demselben PC . Eingeloggt wird bisher mit "ssh username@server-ip" + Passworteingabe. Ich verstehe dabei nicht, wie ein Schlüssel nun die verschiedenen User + Passwörter voneinander unterscheiden kann. Ein User darf doch nicht mit einem einzigen Systemschlüssel in einen anderen Useraccount einloggen können.
Schlüssel sind nichts anderes als „Passwörter in Dateiform“. D.h. wie normalerweise jeder Benutzer ein Passwort hat, so hat jeder Benutzer seinen eigenen Schlüssel.
Dann kommt das andere Problem. User X soll temporär Zugang auf Account Y bekommen und später keine Loginrechte mehr haben. Momentan ändere ich das Passwort und gut ist. Wenn ich mit einem Schlüssel arbeite, muss der doch immer wieder geändert werden und dann dem User Y (Servereigentümer) gesendet werden.
Wo ist da der Unterschied zur Änderung des Passworts? Wobei in ~/.ssh/authorized_keys auch mehrere Schlüssel eingetragen werden können. Du kannst dort also den temporären Schlüssel ein- und austragen, ohne den/die eigentlichen Schlüssel des Kontos zu verändern.
Dann ist noch ein Problem. Wenn bei den Schlüsseln kein Passwort mehr nötig ist, kann z.B. der kleine Bruder von User Z einfach so einloggen und Unfug treiben. Wie so oft hat ein Familien-PC einen einzigen Account, an dem alle ransitzen und rumwerkeln.
Der Schlüssel ist normalerweise mit einer Passphrase geschützt, siehe SSH: Authentifizierung über Public-Keys im ersten Absatz. Weiter unten wird sogar explizit von einer leeren Passphrase abgeraten, aus den von Dir genannten Gründen.
|