ssh-Port ändern. Sinnvoll oder nicht?

  • Hallo zusammen.


    Ich ändere ja in der Regel den ssh-port von 22 auf was anderes, wenn ich einen neuen Server aufsetze, bei dem ich nicht alle Benutzer zu ssh-keys verpflichten kann und somit die Passwortauthentifizierung nicht abschalten kann. Das hält zumindest die weniger intelligenten bots, die auf Portscans verzichten ab. (Und das sind die meisten)


    Ob das sinnvoll ist oder nicht, darüber kann man ja durchaus unterschiedlicher Meinung sein. (Ich z.B. halte es für mehr als nur security by obscurity)

    Was haltet ihr z.B. von den Argumenten aus diesem blog?


    why-putting-ssh-on-another-port-than-22-is-bad-idea

  • Ich halte es für hokus pokus. Du legst ja deinen HTTPS Port nicht auf 63731 für die Sicherheit.


    Meiner Meinung nach langen Jahren Linux in Rechenzentren ist das man sich das schenken kann. Es hält nur dumme Bots fern die nur 22 angreifen können. Die schlaueren probieren durch, sieht man auch in den Logs. Den einzigen Effekt den ich sehen konnte das es deutlich weniger Port 22 auth. denied in den logs gibt da die dummen ausgesperrt werden.


    Entweder Whitelisten von deinen IPs für 22 oder ein IDS davor

  • Ich ändere bei meinen Servern auch ganz gerne den SSH Port. Dies reduziert das übliche "Grundrauschen" doch erheblich. Hat bei mir aber auch weniger mit Security zu tun als dass ich es angenehmer empfinde, wenn es in den Logs etwas ruhiger zu geht. Dazu schränke ich auch die erlaubten Ciphers etwas ein. Das hält auch den ein oder anderen Bot auf Distanz.


    Aber ich würde es jetzt nicht empfehlen, wenn es derjenige es nicht schon selbst macht oder mit dem Gedanken spielt.


    Wenn man sich selbst die Frage stellt, ob man von Standards abweichen soll oder nicht, sollte man es meist besser nicht machen ;). Damit fährt man in der Regel besser. Wenn man es doch macht, dann meist aus bestimmten Gründen, aber dann stellt sich auch die Frage erst gar nicht.

  • Wenn du davon ausgehen musst, dass ein Bot da reinkommt, dann reduziert das Verlegen des Ports ein wenig die Wahrscheinlichkeit. Aber du musst immer noch davon ausgehen, dass einer reinkommt. Die Argumente aus dem Blog (fake sshd, Anwendungsprobleme) halte ich nicht für falsch, aber das passiert auch alles nicht so leicht.


    Ich denke, man kann den Port schon verlegen, um mehr Ruhe im Log zu haben (wenn es geht, lasse ich sshd nur auf ipv6 lauschen, das bringt noch mehr Ruhe). Als Sicherheitsfeature ist es bei weitem nicht ausreichend.

  • Ich finde man sollte zwischen Sicherheit und Schutz vor unnötiger Last unterscheiden.


    Ein Server muss sicher sein, egal wie der Angreifer versucht reinzukommen. Ein Änden des SSH-Ports ändert nach meiner Einschätznung nicht die Sicherheit. Es macht nur die Anzahl der dummen Angriffe etwas geringer, die sollten aber eh keine Chance haben.


    Aber ein Server soll auch nicht mit unnötigen Aufgaben belastet werden. Gut, die SSH-Scans erzeugen wohl keine große Last. Aber es ist auch lästig, wenn die Logfiles mit Einträgen von Einbruchsversuchen geflutet werden.


    Allerdings macht die Nutzung eines alternativen Ports die gewollte Nutzung etwas umständlicher. Aus meiner Sicht sollte man beide Aspekte abwägen und sich entsprechend entscheiden, beide Alternativen sind überlegenswert.

  • 46201 Logins sind es bei mir seit dem 12. Juli 13:22 Uhr. Port 22, kein IDS, keine Vorgeschaltete Firewall oder Fail2Ban. So default ein Server nur sein kann. Kommt auch immer darauf an welche Leistungsdaten ein Server hat. Ich kann mir gut vorstellen das ein ganz ganz kleiner VPS da nur noch am Loggen ist uns man das auch merkt. Auf diesem sehr üppig ausgestattetem System juckt es mich überhaupt nicht wenn die dummen Bots da ihre Anfragen schicken. Mal ein Auszug meiner /var/log/secure, hier sieht man ganz gut wie verschiedene Ports ausprobiert werden. Also das "Verstecken der Haustür" hält nur stark begrenzt den Ärger ab.


    Okay doch kein Auszug, Pastebin, PrivateBIN und github streiken bei meinem 27 MB Logfile. Kennt da jemand einen Dienst?


    EDIT: Jetzt doch https://privatebin.at/?8c37bcb…aGKwvbqRt98Krzx8u8oiPE1zL

  • Okay doch kein Auszug, Pastebin, PrivateBIN und github streiken bei meinem 27 MB Logfile.

    will hier einer 27 MB Logfiles lesen? ;)


    Ich für mich habe auch den ssh-Port verlegt aber aus dem Grund um die logs zu entlasten und auch fail2ban.

    ehlers hat das perfekt zusammen gefasst

    It's me, only me, pure michi

    RS 500 SAS G8 Ostern 2019

    VPS: 50 G7 |B Ostern 2017|200 G8 Aktion

    WH: SmallEi | Adv17 Webhosting Spezial Family | Expert Spezial 2016

  • will hier einer 27 MB Logfiles lesen? ;)


    Ich für mich habe auch den ssh-Port verlegt aber aus dem Grund um die logs zu entlasten und auch fail2ban.

    ehlers hat das perfekt zusammen gefasst

    Du magst das offensichtlich genau so wenig wie ich, allerdings tummeln sich hier auch Anfänger die sich über sowas eventuell freuen. Da sieht man genau was für ein Wilder Westen da draußen ist.


    Wer wirklich nachhaltig Ruhe will dem sei AIDE ans Herz gelegt.

  • mach ich wie gesagt seit knapp 23 Jahren so....


    hält die logs frei, sorgt dafür das fail2ban weniger zu tun hat. Das reicht mir schon.

    Bekomme sonst noch für jeden Login ne push notification.


    Hab mal ne zeitlang auf SSH Logins verzichtet, Port knocking verwendet, oder logins nur mit keys und key files... alles auf Dauer wenig komfortabel.


    Auf meinen Servern läuft aber auch nix lebenswichtiges. Es gibt regelmäßige Backups, wichtige Sites sind gespiegelt auf nem offline VPS vorhanden und sensible Daten liegen Daheim auf dem NAS.


    Also ich bleib dabei und änder bei jedem neuen Server zu Beginn den SSH Port.


    Ob das sinnvoll ist oder nicht ist mir relativ egal. Passt wie gesagt für mich so 👌☺️

  • Sicherer wird's dadurch nicht, aber man verhindert auf jeden Fall, dass Bots den Server die ganze Zeit mit Loginversuchen traktieren, was Ressourcen frisst und Logs füllt. Da ich den abweichenden Port in meine ssh.conf eingetragen habe, merke ich davon kaum noch was.

  • Ist die Änderung des Ports besser/sicherer als per Firewall wie iptables nur bestimmte IP-Bereiche überhaupt zu zulassen?

    Sicherer sicher nicht. Aber wie gesagt es hält die logs frei, entlastet fail2ban und hält zumindest die dummen bots überhaupt von den Versuchen ab

  • Das Hauptargument im oben verlinkten Artikel scheint zu sein, dass ein nicht-privilegierter Nutzer einen Prozess auf dem SSH Port starten könnte.

    Das ließe sich umgehen indem per iptables eine simple Portweiterleitung aufgeschaltet wird. Wenn mein öffentlicher SSH port 12345 ist wird dieser per iptables auf localhost:22 weitergeleitet und SSHd angewiesen nur auf localhost zu lauschen. iptables-persistent zu verwenden ist sicher eine empfehlenswerte Idee in dieser Kombination ;)


    Man könnte natürlich das ganze auch noch etwas weiter treiben und einfach für den Spaß-Faktor beispielsweise ein cowrie auf Port 22 schalten (natürlich auch per iptables o.ä. weitergeleitet auf einen nicht-privilegierten Port), aber das geht doch etwas richtig Off-topic ;)


    Schöne Grüße

  • Man kann auch den sshd nur auf localhost lauschen lassen und den Webserver als Proxy dafür konfigurieren oder den Zugriff per Websocket weiterleiten. Natürlich nur wenn ein Webserver auf dem Server läuft, der das unterstützt und man das auf der Client-Seite geregelt bekommt. Weiterer Vorteil: Damit kommt man auch per ssh auf den Server, wenn der momentane Internetzugang das eigentlich sperren will (.z.B. Fritz Gäste-Wlan in der Standard-Konfig, viele Zwangsproxies). Vorsicht, wenn der Webserver nicht läuft, klappt das auch mit ssh nicht mehr.

  • Vielen Dank für die zahlreichen Antworten. :thumbup:


    und weil es zum Thema passt, mal zwei Fragen an die Profis: :)

    1) Dreht ihr auch an MaxStartups? Die Standardeinstellung ist ja 10:30:100. Wie weit kann man das gefahrlos runterschrauben?

    2) Welchen Wert von LoginGraceTime (Die Voreinstellung von 120s erscheint doch recht hoch) sollte man erfahrungsgemäß nicht unterschreiten?

  • Ich hab' schon mit MaxStartups 3:30:10 ohne Probleme gearbeitet. Zur Zeit verwende ich 10:30:30. Wenn man das nur selbst nutzt, reicht es locker. LoginGraceTime kann man auch auf drei Sekunden runter setzen, wenn man nur mit Schlüsseln einloggt.


    Wenn der Port belegt ist, kann ein nicht privilegierter Benutzer darauf nichts starten. Sollte der Daemon doch aus irgendeinem Grund mal nicht laufen, und es jemandem gelingen, bringt ihm das bei der Authentifizierung mittels öffentlichem Schlüssel ebenfalls nichts.


    Prinzipiell ist SSH schon von Haus aus sehr sicher. Da muss man nichts mehr davor murksen, um irgendwas sicherer zu machen.

  • Sollte der Daemon doch aus irgendeinem Grund mal nicht laufen, und es jemandem gelingen, bringt ihm das bei der Authentifizierung mittels öffentlichem Schlüssel ebenfalls nichts.

    Nicht getestet, daher nur gefährliches Halbwissen: Der Fake-Server könnte den Key ignorieren und die Passwort-Authentifizierung verlangen. Der Client gibt in diesem Fall standardmäßig keine gesonderte Meldung aus. Wenn der Passwortprompt nun so angepasst wird, dass es aussieht, als ob der Client nach der Passphrase fragt…


    Dafür müsste der Angreifer aber halbwegs den lokalen Pfad des Keyfiles kennen, sonst fällt es auf. Ein Key-Agent darf natürlich auch nicht verwendet werden. Letzten Endes wäre es halt ein kleines potentiell mögliches Puzzleteilchen bei einem sehr gezielten Angriff. Insofern wohl zu vernachlässigen.

  • Der Fake-Server könnte den Key ignorieren und die Passwort-Authentifizierung verlangen.

    Vorausgesetzt man hat die aktiviert. Da ich die Passwörter der Accounts nicht im Kopf habe und der Client ebenfalls so konfiguriert ist, dass er bei meinen Servern keine PasswordAuthentication zulässt, würde ich sofort merken, dass was faul ist. Wenn die Passphrase zum Schlüssel einem Angreifer bekannt würde, hätte er davon auch herzlich wenig, weil er den Schlüssel nicht hat, und in der Zwischenzeit hätte ich dafür gesorgt, dass der, der das versucht hat, sich nie wieder auf irgendeinem Weg auf dem Server einloggt. :D Und dann ist da noch der Host-Key, auf den ein unprivilegierter Nutzer keinen Zugriff hat.

    Insofern wohl zu vernachlässigen.

    So sieht's aus. ;)

  • Und dann ist da noch der Host-Key, auf den ein unprivilegierter Nutzer keinen Zugriff hat.

    Stimmt, den Teil habe ich nicht bedacht. Man müsste (als Angreifer) zusätzlich also auch noch hoffen, dass sich der User über ein neues Gerät verbindet und z.B. keine SSHFP-Records eingerichtet sind.

  • Quote

    But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords.

    Das kann nur passieren wenn man schon im Vorhinein drei Fehler begangen hat:


    • Passwort-Auth
    • Host-Keys nicht überprüft (der OpenSSH-Client schreit laut, wenn sich dieser geändert hat)
    • keine Firewall, die irgendwelche lauschenden Ports von Usern blockiert


    Das Szenario im Artikel scheint mir doch arg an den Haaren herbeigezogen um Klicks zu generieren.