Am Tag 2-3 x Mails von Fail2Ban mit Loginversuchen
- AquaPhantom
- Thread is marked as Resolved.
-
-
Fair, da bin ich aber zu Faul für. Und das Grundrauschen stört mich ehrlich gesagt nicht.
-
Zu faul den SSH-Port zu ändern? Das ist eine simple Änderung in /etc/ssh/sshd_config
-
Und dann halt noch in allen Clients. Den offensichtlichen und denen, die ich vergessen werde. Also mich stört das Grundrauschen mittlerweile auch nicht mehr. Zumal man sich mit Ports oberhalb von 1024 auch geringe, zusätzliche Sicherheitsrisiken einhandelt, bei denen ich zwar keinen Schweissausbruch bekomme, weil da zumindest die Rechte eines normalen Users benötigt werden um auf dem Port z.B. einen eigenen Service starten zu können, der dann wiederum für weitere böse Dinge benutzt werden kann. Bei Systemports ist das mit den Rechten eines Standardbenutzers nicht möglich.
-
Zu faul den SSH-Port zu ändern? Das ist eine simple Änderung in /etc/ssh/sshd_config
Schon klar. Aber dann jedes Mal den Port mit angegeben zu müssen ist mir zu doof.
-
Schon klar. Aber dann jedes Mal den Port mit angegeben zu müssen ist mir zu doof.
Mit welchem Programm loggst du dich denn ein? Bei mir ist der Port gespeichert.
-
Mit welchem Programm loggst du dich denn ein? Bei mir ist der Port gespeichert.
Wirklich unterschiedlich, je nach Rechner. Habe die Sitzungen grundsätzlich auch nicht gespeichert.
-
Das ist eine simple Änderung in /etc/ssh/sshd_config
Aber dann jedes Mal den Port mit angegeben zu müssen ist mir zu doof.
man ssh_config
-
Zu faul den SSH-Port zu ändern? Das ist eine simple Änderung in /etc/ssh/sshd_config
Das ist so lange nur eine kleine Änderung, bis man sich mal aus einem restriktiv konfigurierten Netz einloggen muss. Beispiel dafür war bei mir damals ein Hochschulnetz, aus dem man keine beliebigen Ports erreichen konnte. SSH auf 22 war aber freigeschaltet. Die Änderung bringt nicht immer nur Verbesserungen mit sich.
Schon klar, kann einem auch mit dem Standardport passieren, aber ist halt eine weitere Erhöhung der Wahrscheinlichkeit, dass es nicht funktioniert.
-
Das ist so lange nur eine kleine Änderung, bis man sich mal aus einem restriktiv konfigurierten Netz einloggen muss. Beispiel dafür war bei mir damals ein Hochschulnetz, aus dem man keine beliebigen Ports erreichen konnte. SSH auf 22 war aber freigeschaltet. Die Änderung bringt nicht immer nur Verbesserungen mit sich.
Schon klar, kann einem auch mit dem Standardport passieren, aber ist halt eine weitere Erhöhung der Wahrscheinlichkeit, dass es nicht funktioniert.
Deshalb VPN. Tailscale oder selfhosted headscale bzw. Wireguard VPN auf Port 443. SSH dann nur auf dem lauschen lassen und Ruhe ist. Klar gibt‘s Firewalls die Deep Inspection mit Application Control machen, dann müsste man das noch obfuscaten, aber man kann nicht alles haben.
-
Wireguard VPN auf Port 443.
Das ist meines Erachtens nicht optimal, weil Wireguard mit UDP arbeitet. UDP Port 443 ist in den meisten Firewalls nicht offen, sondern nur TCP.
Wenn man Wireguard nativ machen will, dann eher auf Port 500 UDP. Der ist in vielen Firewalls offen für IPSec. Alternativ OpenVPN auf TCP Port 443, das klappt sehr häufig.
-
Das ist meines Erachtens nicht optimal, weil Wireguard mit UDP arbeitet. UDP Port 443 ist in den meisten Firewalls nicht offen, sondern nur TCP.
Wenn man Wireguard nativ machen will, dann eher auf Port 500 UDP. Der ist in vielen Firewalls offen für IPSec. Alternativ OpenVPN auf TCP Port 443, das klappt sehr häufig.
Stimmt, OpenVPN - die Idee mit 500 UDP ist gut!
-
Das ist meines Erachtens nicht optimal, weil Wireguard mit UDP arbeitet. UDP Port 443 ist in den meisten Firewalls nicht offen, sondern nur TCP.
"Dank" http3 kommt das jetzt aber auch nach und nach, dass neben TCP auch UDP offen sein muss. Aber prinzipiell hast du schon recht, gerade weil es in Umgebungen, die das in der FW sperren sehr oft dauern kann, bis neue Protokolle wie http3 dann tatsächlich aufgenommen werden.
-
Das ist so lange nur eine kleine Änderung, bis man sich mal aus einem restriktiv konfigurierten Netz einloggen muss. Beispiel dafür war bei mir damals ein Hochschulnetz, aus dem man keine beliebigen Ports erreichen konnte. SSH auf 22 war aber freigeschaltet.
Bei uns war das ähnlich, aber auch 22 war dicht. Aus dem Schulnetz heraus konnte man bei den tieferen Ports im Wesentlichen nur 80 und 443 erreichen. 22 war dicht. Um sich von der Schule aus auf Servern einzuloggen, musste der ssh-Port also sogar auf einem hohen Port liegen oder man musste einen jumphost wie z.B. cockpit nutzen.
-
Wenn man sich auf ssh über IPv6 beschränken kann, dann ist das Grundrauschen auch leicht zu beseitigen: sshd nur auf eine IPv6-Adresse lauschen lassen, die für nichts anderes benutzt wird. Und natürlich nicht ...::1, ...:22 und dergleichen nehmen.
