Skip to content

Auswahl des SSH-Ports auf Servern

Damit zwei Rechner über das Internet kommunizieren können, müssen sie ihre IP-Adressen kennen; will man einen bestimmten Dienst auf einem Rechner ansprechen, muss man auch den Port kennen, unter dem dieser Dienst angeboten wird. Damit das nicht zu einem Ratespiel gerät, gibt es für die meisten Dienste Standardports - der Webserver läuft auf Port 80 (kann aber auch mal auf Port 8080 oder anderswo lauschen), SMTP funktioniert über Port 25 (oder 465 oder 587), und SSH-Verbindungen werden standardgemäß auf Port 22 erwartet.

Dienste auf ungewohnte Ports zu verlegen macht meist nur wenig Sinn, weil der Rest der Welt damit nicht rechnet - wer seinen SMTP-Server auf Port 2525 laufen lässt, wird nicht allzuviel Mail erhalten. Beim SSH-Dienst kann das aber schon sinnvoll sein, weil SSH-Zugänge üblicherweise nicht öffentlich verfügbar sind, und den Berechtigten kann man neben dem Hostnamen, ihrer Benutzerkennung und ggf. dem Passwort dann auch den richtigen Port mitteilen.

Das erhöht natürlich nicht wirklich die Sicherheit gegen Angriffe, hatte aber über lange Jahre immerhin den Vorteil, das Logfile zu entlasten: statt Dutzender Meldungen täglich über unbefugte Zugriffsversuche auf Port 22, der routinemäßig gescannt wird, herrscht Ruhe, wenn der sshd eben auf Port 2022 lauscht. Für die notwendige Sicherheit sorgt dann die Beschränkung des Zugriffs auf per SSH-Key authentifizierte Nutzer und ggf. ein Dienst wie fail2ban, der nach mehreren Fehlversuchen die betreffende IP für einen beschränkten Zeitraum bereits auf Ebene der Hostfirewall blockt.

Über die Jahre funktioniert dieser “Trick” aber immer weniger. War 2004 dann noch Ruhe im Karton (bzw. Logfile), sind mir 2009 bzw. 2010 bereits vereinzelte Zugriffsversuche auf den an einem nicht standardisierten Port lauschenden SSH-Server aufgefallen. Mittlerweile erfolgen Dutzende dieser Zugriffe täglich.

Daher frage ich mich: lohnt es sich überhaupt noch, den sshd auf einen anderen Port zu verlegen, oder kann man es bei Port 22 belassen (und sich damit die gesonderte Konfiguration des Ports in allen verwendeten Programmen und Diensten sparen)?

Eine Antwort auf diese Frage hat - genau einen Tag, nachdem ich sie mir das erste Mal gestellt hatte - Felix bereits auf Twitter gegeben:

Ich möchte die Frage aber nochmals in die Runde stellen - welche Erfahrungen und Empfehlungen hat die werte Leserschaft?

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Dirk Deimeke am :

Dirk Deimeke

Ich halte von einer Verlagerung des Ports gar nichts. Lieber gute Ciphers, "sichere" Keys und aktuelle Verschlüsselungsverfahren einsetzen.

Egal wohin Du den Port legst, ich brauche keine Minute herauszufinden, auf welchem Port der SSH-Daemon läuft.

Wenn Du stärker absichern möchtest, lohnt sich vielleicht via Hostfirewall (oder authorized_keys) nur Zugriff von bestimmten IP-Adressen oder IPv6 zuzulassen. Alternativ dazu lohnt es sich die Dienst-IP von der Management-IP zu trennen. Webserver läuft auf IP-Adresse x und ssh lauscht auf IP-Adresse y.

Ich betreibe nun schon einige Jahre öffentliche Server ohne Einbrüche und bis auf Logfile-Kosmetik und eventuell Schutz vor Skript-Kiddies hat die Verlagerung des Ports keinen Nutzen, den ich sehen würde.

Hilko Bengen am :

Hilko Bengen

"There were X failed login attempts since the last successful login"

Zunächst einmal ist festzustellen, daß dieses Zählen in Zeiten billigst zu habender internet-weiter Portscans keinen Erkenntnisgewinn bringt (Stand der Technik vor 5 Jahren mit zmap war 0/0, ein Port, 45min), aber das nur nebenbei.

Danach wirft das natürlich immer noch Fragen auf: So viele Loginversuche auf einen Unix-Account? (Doch hoffentlich nicht root?) Und warum würde man an der Stelle überhaupt noch Passworte zum Login zulassen wollen?

Thomas Hochstein am :

Thomas Hochstein

Ich halte von einer Verlagerung des Ports gar nichts. Lieber gute Ciphers, "sichere" Keys und aktuelle Verschlüsselungsverfahren einsetzen.

Eine Änderung des Ports ist kein Sicherheits-Feature, das ist klar. Login ist nur für definierte Accounts möglich - meistens nicht die, die geraten werden -, nicht für Root und nur per Key.

Dennoch lohnt es sich m.E., Angriffsversuche mit wenig Aufwand ins Leere laufen zu lassen - zumindest erspart es etliche Einträge im Log (und in dessen täglicher Zusammenfassung). Dazu nutze ich fail2ban, und bisher eben einen anderen Port.

Insofern könnte man meine Frage vielleicht einfacher anders stellen: Gibt es auf Port 22 immer noch (so) deutlich mehr unberechtigte Loginversuche, dass es sich lohnt, den SSH-Port zu verlegen?

Jens Link am :

Jens Link

Schonmal an fail2ban gedacht? Das schaut in die Log (nicht nur für ssh sondern auch für diverse andere Protokolle) und setzt nach n fehlgeschlagenen Logins von einer IP in einer bestimmten Zeitspanne eine iptables regel die die IP blockt. Auf meinem Heimrouter sind das gerade 22 IPs.

Funktioniert bei mir auch gut für postfix, dovecot und wordpress.

Thomas Hochstein am :

Thomas Hochstein

Schonmal an fail2ban gedacht?

Klar. Das ist schon seit langem installiert und deckt neben SSH auch Dovecot, Exim u.a. ab.

Insofern: Die simplen Scanner geben auf, wenn Port 22 zu ist. Der Rest läuft gegen fail2ban. All das ist aber mehr Logkosmetik und kein Sicherheitsfeature, jedenfalls, was SSH betrifft, weil ich dort nur Key-Auth zulasse.

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen