SSH Port ändern

Hugo Stiglitz

Ensign
Registriert
Aug. 2015
Beiträge
191
Schönen guten Tag liebe FB-Mitglieder!

Ich hab da wieder einmal eine Frage:

Und zwar greife ich auf meinen Ubuntu 16.04 vServer per SSH zu mit Termius.

Jetzt beschäftige ich mich gerade mit dem Thema Sicherheit.

Nun möchte ich den SSH Port ändern, also von Standard auf z.B. 2345
Ich habe in der sshd_config vorerst den Port zusätzlich angeführt und den Dienst neugestartet.
Port 22 Port 2345

Danach habe ich in ufw den Port freigegeben:
ufw allow 2345

Wenn ich mich nun über den neuen Port verbinden möchte, funktioniert das nicht.

Hat jemand eine Idee?


PS: Port 22 entferne ich dann, wenn der Zugriff über den neuen Port klappt.

Vielen Dank, LG
 
Änderung des Ports bringt dir ungefähr genau so viel für deine Figur wie Pommes statt Chicken Nuggets.
Da solltest du dir lieber sowas wie fail2ban anschauen.

mit ssh -vvv kannst du den Verbose-Mode einschalten und kannst besser auf entsprechende Fehlermeldungen reagieren.
 
  • Gefällt mir
Reaktionen: Raijin, PERKELE und chris_2401
fail2ban und nur mit ssh-key.
ports umstellen bringt keine zusätzliche sicherheit. jedes skript kiddy kann einen port scan machen.
 
  • Gefällt mir
Reaktionen: konkretor
Hugo Stiglitz schrieb:
Jetzt beschäftige ich mich gerade mit dem Thema Sicherheit.
Nun möchte ich den SSH Port ändern, also von Standard auf z.B. 2345
Das erinnert mich ein bisschen an Security by obscurity. Auch wenn viele Seiten im Internet dazu raten, der Sicherheitsgewinn geht gegen 0. Besser wäre der Zugriff mit Zertifikat und die Absicherung per fail2ban.

Zu deiner Frage, eigentlich ist nicht mehr notwendig und es sollte so funktionieren. Ist noch eine Firewall vor diesem Ubuntu vServer?
 
chris_2401 schrieb:
ports umstellen bringt keine zusätzliche sicherheit. jedes skript kiddy kann einen port scan machen.
Bei einem gezielten Angriff mag das Stimmen. Aber die unzähligen Botangriffe welche mit Passwortlisten vorgehen, gehen nur auf die Standardports. >99,9% kann man damit Schonmal abfangen.
Aber fail2ban und ssh-keys machen generell sinn, man kann sich halt nicht darauf verlassen dass da nur Bots kommen.
 
Teste mal, ob der Port auch vom Internet Provider freigegeben ist (nmap Onlinescanner). Ist mir aufgefallen. als bei mir von UPC auf Magenta umgestellt wurde und mein Server nicht mehr erreichbar war. Die Telekom blockiert da einiges. Natürlich nur für den Fall, dass du dich von außerhalb verbindest.
 
rocketworm schrieb:
99,9% kann man damit Schonmal abfangen.
Du meinst dieselben 99,9%, die an einem staken Passwort oder gar ssh-keys sowie fail2ban sowieso scheitern?

Die Standard-Ports zu ändern, bringt tatsächlich keinerlei zusätzliche Sicherheit. Genau genommen verleitet es sogar dazu, das Passwort nicht so stark zu wählen bzw. auf ssh-keys zu verzichten, "weil ja eh keiner den Port findet". Frei nach dem Motto: Ich schließe die Haustür nicht ab, weil der Schlüssel ja total super versteckt ist. Der einzige vermeintliche Vorteil eines Nicht-Standard-Ports ist das schlankere Log. Mit den 99,9% hat das aber ansonsten nichts zu tun, weil das sowieso nur Wörterbuch-Attacken sind mit admin/admin und dergleichen.
 
  • Gefällt mir
Reaktionen: Helge01
Hast du überprüft ob der SSHd auch auch beiden Ports lauscht? Das geht z.B. per sudo ss -tlpn
 
Hugo Stiglitz schrieb:
Wenn ich mich nun über den neuen Port verbinden möchte, funktioniert das nicht.
Machst du das denn direkt vom LAN aus über die lokale IP des Servers? Oder versuchst du es womöglich aus dem www oder ggfs aus dem LAN heraus über (d)eine potentiell vorhandene DDNS-Domain?

Sprich: Wie genau testest du die Verbindung?



Wenn du unbedingt den Port ändern willst, würde ich persönlich aber den Weg über die Portweiterleitung gehen. Den Dienst auf dem Server würde ich stets auf dem Standard-Port belassen. Für den Zugriff von außen mit alternativem Port hätte ich dann in der Portweiterleitung einfach externer Port 12345 --> lokaler Port 22 weitergeleitet. So kannst du den alternativen Port jederzeit ändern, ohne großartig am Server rumfummeln zu müssen.
Aber wie gesagt, einen wirklichen Sicherheitsvorteil hast du davon so oder so nicht.
 
Also das Setup ist wie folgt:
Ich habe den "vServer" bei einen österreichischen Anbieter gemietet. Dieser hat eine fixe IP-Adresse.
Vom Büro aus wird am Mac via Termius per SSH zum vServer über das Internet verbunden.
Die Infrastruktur:
MACs/Windows PCs > Modem/Router vom Internetprovider (A1) > Hostinganbieter


Werde meinen Beitrag später ergänzen - jetzt ist Mittag :-)

Ergänzung:
Aufgrund eurer verschiedenen Meinungen weiß ich jetzt gerade nicht, ob ich das noch tun sollte.
Mir geht es wie gesagt darum, den vServer möglichst gut zu schützen.

fail2ban wäre dann mein nächster Schritt gewesen - darüber bin ich während der Recherche schon gestolpert.

Um ein paar Fragen zu beantworten:
1) Zugreifen tue ich mit Termius. Da kann ich einen neuen Host erstellen. Ich gebe dort die IP Adresse, Port, Username und Passwort ein. Das funktioniert auch.
Zum testen habe ich einen neuen Host erstellt, mit den gleichen Einstellungen wie alle anderen, nur den Port habe ich geändert. Termius schreibt mir "Socket is not connected".

2) Ich weiß nichts von einer weiteren Firewall....


3) Port wird auch von sshd gelauscht - gerade mit sudo ss -tlpn geprüft. Gelauscht werden demnach 3 Ports (443,22,2345)




Ich hoffe, soweit alles beantwortet zu haben.
 
Zuletzt bearbeitet: (Ergänzung)
Raijin schrieb:
Du meinst dieselben 99,9%, die an einem staken Passwort scheitern
Ein Starkes Passwort ist kein Sicheres Passwort. Admin123! ist ein starkes Passwort, aber nicht sicher und taucht in nahezu jedem Wörterbuch auf.
Man kann anhand von Kennwort Regeln festlegen, dass Anwender nur starke Kennwörter vergeben können. Aber in der realität nutzen die Anwender keine Sicheren Kennwörter sondern welche die Sie sich leicht merken können. Und dann wird halt sowas wie Pommes123 benutzt. Von daher, auch wenn Fail2Ban nach spätestens drei falschen eingaben die IP/den User erstmal ne weile sperrt. Die Chance dass man mit einem einfachen Passwort rein kommt ist da. Und die BOTS sind heute auch schon schlau genug, lange genug bis zum nächsten Versuch mit dem selben User zu warten, damit Fail2ban die Sperrzeit nicht Addiert/Multipliziert.
Oft stecken dahinter ganze BOT-Netze, wo dann beim nächsten Versuch der Angriff von einer anderen IP kommt.
Wenn Fail2Ban die IP für z.B. immer 10 Minuten sperrt, und man hat jedes mal 5 versuche bis die IP gesperrt wird, sind das immerhin auch 18 Versuche am Tag Multipliziert mit 365 sind das schon über 260.000 Versuche im Jahr von allein einer IP. Es kommen aber nicht nur Angriffe von einer IP.
Die 10 Minuten und 5 Versuche habe ich als Beispiel genommen, da diese bei Debian z.B. in der Standardconfig drin stehen.
Von daher, ja ich halte es für Sinnvoll, zusätzlich zu Fail2Ban den Port zu Ändern und Keys zu benutzen.

Wenn es nicht gerade ein einfacher Gemieteter Rootserver ist, um den es geht sondern die Maschine in einem eigenen Netz steht. Dann würde ich sehen das da noch ein VPN vor kommt.

Raijin schrieb:
Der einzige vermeintliche Vorteil eines Nicht-Standard-Ports ist das schlankere Log
Ja das ist ein weiterer Vorteil, das macht einem die Log Analyse und das erkennen der gezielten Angriffe wesentlich einfacher.
 
kleine Anmerkung. fail2ban geht nicht standardmäßig in Kombination mit ssh key authentication da fail2ban was ich gelesen hab nur auth.log prüft und solange du den falschen Schlüssel hast kommt nicht mal eine fehlgeschlagene Anmeldung zustande. Man hat unbegrenzte Versuche. Hab mich persönlich dann nicht mehr mit fail2ban auseinandergesetzt. Ich persönlich hab einen anderen Port und key only Authentication. Also Password = no

https://www.reddit.com/r/linuxadmin/comments/2lravs/fail2ban_does_not_detect_my_ssh_privatekey/ glaub da wird das besser erklärt
 
Danke für den Link.

Okay, wie ich sehe gibt es hier unterschiedliche Meinungen, deshalb frage ich jetzt kurz und knapp:

Wie kann ich meinen vServer am effizientesten absichern?
Ich frage jetzt deshalb, weil ich will nicht umsonst Zeit mit unnötigen Dingen verballern....

Gibt es da ein paar Punkte?
  • root Login ist verweigert
  • root PW ist sicher und laaange
  • ufw - ja
 
Zuletzt bearbeitet:
Hugo Stiglitz schrieb:
Wie kann ich meinen vServer am effizientesten absichern?
Wäre viel einfacher zu beantworten, wenn Du sagst was für ein System darauf läuft (die Erwähnung von ufw könnte auf ubuntu hindeuten) und was Du alles installieren willst (die wenigsten Angriffspunkte bietet oft das System ansich, sondern die Software die drauf läuft).

Wenn da zum Beispiel Debian Linux drauf läuft (was bei Servern häufig ist) bietet das Securing-Debian-Handbuch ein guten Überblick (und trifft weiten Teilen für abgeleitete Distributionen wie ubuntu zu). Es gibt auch automatische Tools (wie z.B. Lynis) die einem dabei helfen mögliche Schwachpunkte aufzudecken und zu eliminieren.

Wichtig ist aber, das man mit dem System halbwegs vertraut ist. Wenn man Null Plan von Linux hat ist es keine gute Idee nen Linux vServer am Internet zu betreiben. Dann sollte man damit erst mal in-house mit einem Linux-System rumspielen, um sich damit vertraut zu machen.
Ich sag das einfach mal so. Denn wer nicht in der Lage ist den Port vom sshd zu ändern oder sich diese Information selbstständig zu besorgen (was trivial ist, wenn man sich halbwegs auskennt) der hinterlässt nicht gerade den Eindruck dazu befähigt zu sein.

Verstehe den Hinweis auch nicht als Angriff gegen Dich oder als arrogante Belehrung, sondern als hilfreicher Hinweis. Denn wenn da irgendwelches Kriminelles Zeug auf Deinem Server läuft weil Du Crackern offene Türen hinterlassen hast, hast Du auch erst mal den Ärger damit.
 
  • Gefällt mir
Reaktionen: Raijin und snaxilian
Ich spare mir weitere Beiträge und Fragen. Danke für sämtliche Informationen.
 
Hast du geprüft ob UFW auch korrekt läuft und die Regel eingetragen ist? ufw status ist das Zauberwort. Stumpfes ufw allow $port erlaubt eben tcp als auch udp. Bei einer Firewall lautet die wichtigste Regel aber: Nur das öffnen, was auch notwendig ist.
Hast du ggf. Syntaxfehler in der sshd config? https://www.cyberciti.biz/tips/checking-openssh-sshd-configuration-syntax-errors.html
Termius sollte wie jeder andere vernünftige SSH Client auch pubKey auth unterstützen. Nutze dies und deaktiviere Anmeldung per Kennwort am SSH-Server.
Nur weil du nix von einer weiteren Firewall weißt heißt das nicht, dass da keine ist. Vielleicht erlaubt dein Hostingprovider standardmäßig ja nur bestimmte oder nur well-known Ports und blockiert alles andere komplett oder solange bis man es sich frei schalten lässt.
 
Zuletzt bearbeitet:
rocketworm schrieb:
Ein Starkes Passwort ist kein Sicheres Passwort. Admin123! ist ein starkes Passwort, aber nicht sicher und taucht in nahezu jedem Wörterbuch auf.
Das ist Wortklauberei. Du magst Admin123! als stark, aber nicht sicher bezeichnen, ich halte es weder für stark noch sicher, weil stark und sicher synonym verwendet werden.

Wie dem auch sei. Du kannst natürlich keinen ssh mit geändertem Port und "sicherem" Passwort mit ssh mit Standard-Port und "unsicherem" Passwort vergleichen. Wenn überhaupt, führt der geänderte Port dazu, dass der Laie sich denkt, dass er dann ja ein einfacheres Passwort nehmen kann, "wenn eh keiner den Port findet". Aber das sind Mutmaßungen. Grundvorraussetzung für den Betrieb von ssh - egal auf welchem Port - ist ein adäquates Passwort.

Das Passwort - wenn man denn ssh überhaupt mit Passwort-Login nutzt - muss also so oder so stark/sicher/unerratbar sein, egal ob auf Standard-Port oder nicht. Der Großteil der ssh-Attacken ist nur auf Bauern mit 08/15 Passwort oder einer Abwandlung dessen aus. Selbst wenn da einer 24/7/365 Dauerfeuer - durch fail2ban limitiert - startet, sind 260.000 Versuche bei einem langen und "sicheren" Passwort nicht mal ein Tropfen auf den heißen Stein. Die 99,9%, die man sich durch den geänderten Port vom Hals hält, kommen durch ein anständiges Passwort oder gar einen key-geschützten ssh eh nicht durch. Diejenigen, die das können und auch explizit wollen, haben den geänderten ssh-Port binnen kürzester Zeit gescannt.

Es gibt aber durchaus noch einen weiteren Aspekt warum ein geänderter Port nicht wirklich zur Sicherheit beiträgt, sondern sogar das Gegenteil der Fall sein kann. Ports <1024 sind System-Ports, die nur von root bzw. mit root-Rechten geöffnet werden dürfen. 2222 darf im Prinzip jeder öffnen. Wenn nu ein Angreifer einen beliebigen sonstigen Dienst auf dem Server unter seine Kontrolle bringt, kann er einen eigenen Dienst auf 2222 laufen lassen, um den ssh zu faken und alle Passwörter abzugreifen - egal wie super sicher sie sind.

Um sich vor der schieren Flut an 08/15-Bots, die einem gut gesicherten System wie gesagt nur längere Logfiles bescheren, zu schützen, würde ich dann eher Port-Knocking nutzen, um den ssh-Port zu kaschieren.



Diese Diskussion könnten wir nu aber noch ewig weiterführen, ohne den jeweils anderen von der eigenen Meinung zu überzeugen - is ja auch nicht schlimm. Jeder muss damit umgehen wie er es für richtig hält, sollte sich aber darüber im Klaren sein, dass Security by Obscurity - der geänderte Port - kein sicheres Passwort/keys ersetzen kann. Du und ich wissen das, aber der Laie neigt dazu, zuviel Sicherheit als lästig zu empfinden. Und wenn man schon ständig einen anderen Port eintippen muss, kann man sich ja wenigstens ein simples Passwort "gönnen", gell? Ich habe solche Leute im Bekanntenkreis, das kommt also nicht von ungefähr... :rolleyes:


Ich schließe mich aber grundsätzlich der Meinung von @andy_m4 an was das Administrieren eines Mietservers im www angeht. Wenn man sich das KnowHow dazu aus einem Forum, bei Youtube oder sonstigen Tutorials ziehen muss, bekomme ich Bauchschmerzen. Genau das sind dann nämlich die Server, die von $hackergroupxy gekapert und in deren Botnetz aufgenommen werden....
 
  • Gefällt mir
Reaktionen: snaxilian
Hugo Stiglitz schrieb:
Hugo Stiglitz schrieb:
Wenn ich mich nun über den neuen Port verbinden möchte, funktioniert das nicht.
vServer sind meist keine echten Server, eher viele kleine virtuelle auf einem Rechner. Das kann bedeuten, dass sie nicht direkt am Netz hängen, sondern explizit (durch Portweiterleitung) mit der Außenwelt verbunden werden müssen. Das kann nur der Administrator des Systems machen. In deinem konkreten Fall kann das bedeuten, dass keine Portweiterleitung (für diesen Port) eingerichtet und die ankommende Verbindung bereits abgewiesen wurde bevor sie deinen vServer erreichen konnte. Das ist so ähnlich wie bei NAT Routern, die viele zu Hause stehen haben. Schau am besten bei deinem Anbieter nach, welche Ports zu deinem vServer weitergeleitet werden und nimm einen davon.

Absichern würde ich SSH mit Public-Key-Verfahren.
 
Zuletzt bearbeitet:
Zurück
Oben