SSH Port ändern lohnt sich - die Statistik

  • Wie die meisten sicher eh schon wissen, lohnt es sich den SSH Port zu ändern. Man ist viel weniger Angriffen ausgesetzt.


    Nachdem mein frisch installierter Root Server einige Tage unverändert gelaufen ist, konnte man im SCP schön sehen, wie viel Ressourcen ein frisch installierter Server benötigt, der sonst nichts zu tun hat.

    Mehr Details in diesem Thread: verbesserungsvorschlag-vm-inaktiv-scp-autostart-einstellung-bei-vm-migration-beachten

    Besonders verwundert hatten mich die IOPS-Spikes.


    Jetzt hat mich interessiert, wie stark wirkt sich das Ändern des Standard Ports in der Praxis aus.

    Und für den Fall, dass es jemand anderes auch interessiert, kommen jetzt die Bilder dazu.


    Die letzten 19 Tage ist der Server also mit geändertem Port weiter gelaufen.


    nc-cpu.pngnc-iops.pngnc-pps.pngnc-nw.png


    Wie man an den SCP Statistiken schön sehen kann, sind besonders die Spikes bei den IOPS verschwunden. Was so ein paar Logfiles doch ausmachen können.

    Die anderen Ressourcen wurden auch etwas entlastet. Sehr angenehm :)


    Aus Spaß/Interesse hab ich noch ein paar Minuten lang "stress" laufen lassen, um die CPU G-Skala etwas besser einschätzen zu können:


    nc-cpu-6.pngnc-cpu-31.png



  • Danke für den interessanten Link!!!

    Ich finde zwar, dass er mit den meisten Punkten recht hat, aber nicht mit allen. Und das, zusätzliche, ändern des SSH Ports hat, manchmal, durchaus seine Daseinsberechtigung. Auf welchen Port ist natürlich eine ganz andere Frage ;)

    Wie meistens halt. Man muss seine eigene Situation analysieren, und sich dann entscheiden. Hat halt alles seine Vor- und Nachteile.

  • Zählst Du security through obscurity als Vor- oder als Nachteil? Wenn Dich die IO-Spikes stören, solltest Du eher Dein Logging überdenken.

    Oh je, oh je. Ich wollte eigentlich keine Grundsatzdiskussion lostreten.

    Aber da bin ich selbst Schuld, wenn ich so was schreibe wie "Wie die meisten sicher eh schon wissen, lohnt es sich den SSH Port zu ändern".

    Offensichtlich schlecht gewählt Worte.


    Das mit den IO-Spikes fand ich einfach nur interessant. Der Server hätte ja eigentlich gar nicht laufen sollen (siehe verlinkten Thread).


    Ich minimiere gerne die Angriffsfläche, soweit ich sie erkennen kann.

    Dazu verwende ich gerne auch, zusätzlich, security through obscurity.

    Ich verwende einfach alles, von dem ich Denke, dass es mir hilft. Den Link von ___ hab ich mir auch gleich gebookmarkt. Die iptables Verwendung finde ich klasse, und auch sonst fand ich den Artikel sehr lesenswert.


    Bei einigen meiner Linux-Maschinen habe ich den SSH-Port geändert, bei einigen nicht. Das hängt von verschiedenen Faktoren ab.

    Aber bei allen habe ich u.a. die Verwendung von Passwörtern verboten, lasse nur bestimmte User überhaupt zu, verbiete root, ...

  • Ich ändere meinen SSH-Port auch, solange ich der einzige SSH-Nutzer bin. Nicht als Sicherheitsmaßnahme sondern einfach für die Übersicht.


    Ich würde gerne wissen, wenns jemand speziell auf meinen Server abgesehen hat, ich schaue also durchaus mal das sshd und andere Logs an, wer da so klingelt.


    Der Standardport wird sowas von sinnlos zugespammt, und das Logfile dementsprechend vollgemüllt. Mit geändertem Port ist das deutlich übersichtlicher.


    Andere sorgen mit fail2ban o.ä. Geschichten für diese Übersicht. Dabei ist fail2ban im Prinzip auch nur reine Obscurity. Wenn du eine Sicherheitslücke hast, dann kommen die beim ersten Versuch rein bzw. holen sich einfach eine neue IP, das ist ja kein Problem. Aber das ist halt "kulturell akzeptierte" Obscurity wogegen die Leute Hautausschlag bekommen wenn du nur anfängst, was von geändertem SSH-Port zu faseln. ;)

  • Seh ich auch so, ich hab deutlich mehr Ruhe, wenn ich den SSH Port ändere. Fail2Ban läuft trotzdem und behält eben den neuen Port im Auge ;)

    Ich muss mich nicht immer per Port 22 von überall aus auf meine Server einloggen können. In Deutschland(EU+Schweiz) und China habe ich dank Mobilfunktarifen mit mehreren GB inkl. Volumen und Tethering zur Not immer noch die Option, sollten die Ports irgendwo geblockt sein, oder um Sicher zu gehen, dass ich der einzige User bin, der gerade auf Port XYZ zugreifen will.

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Andere sorgen mit fail2ban o.ä. Geschichten für diese Übersicht. Dabei ist fail2ban im Prinzip auch nur reine Obscurity. Wenn du eine Sicherheitslücke hast, dann kommen die beim ersten Versuch rein bzw. holen sich einfach eine neue IP, das ist ja kein Problem. Aber das ist halt "kulturell akzeptierte" Obscurity wogegen die Leute Hautausschlag bekommen wenn du nur anfängst, was von geändertem SSH-Port zu faseln. ;)

    Warum ist fail2ban bitte Obscurity!? "Security through Obscurity" heißt zu deutsch "Sicherheit durch Unklarheit" und das ist hier definitiv nicht der Fall, im Gegenteil: ein Ban nach einer gewissen Zahl an fehlerhaften Logins ist absoluter Standard eigentlich.


    Das ist eine echte Sicherheitsmaßnahme, die effektiv Brute-Force Attacken verhindert. Und sich eine neue IP zu besorgen ist auch nicht all zu einfach ;) Aber z.B. fail2ban ist ein echter Sicherheitsgewinn, genau wie eine Funktion beim Login nach 3-maligen falschen Passwort eine "Zwangspause" einlegen zu müssen, wie es z.B. bei vielen Online-Banking Portalen der Fall ist. Und das hat nichts mit "kulturell akzeptierte" zu tun.


    Wenn man eine IP nach 5 fehlerhaften Logins für 48h sperrt (bzw bei versuchtem root-login direkt) spart einem das etliche Einträge im Logfile und sperrt fast alle "bösen Buben" effektiv aus 8)

    Obscurity wäre eher, wenn man so etwas wir Portknocking nutzt um den SSH-Port freizugeben.

  • Das ist eine echte Sicherheitsmaßnahme, die effektiv Brute-Force Attacken verhindert.





    Das System muss sicher sein, egal ob dein SSH auf Port 22 oder 222 läuft, egal ob du fail2ban benutzt oder nicht. Ist das so, dann hast du Security. Der ganze Rest ist Obscurity.


    Wenn du ausschließlich mit Key-Auth arbeitest und nicht mit "passwort123", und du deine Keys nicht vor X Jahren mit Debian erzeugt hast die da so einen lustigen Bug hatten in ihrem Zufallsgenerator mit nur 32768 möglichen Ergebnissen, dann ist Bruteforce von vorneherein ausgeschlossen.


    Umgekehrt kann man sich nicht darauf verlassen, daß mit fail2ban schwache Passwörter nicht trotzdem erraten werden können. Du musst immer davon ausgehen, daß ein Angreifer auf einen entsprechend großen IP-Pool zurückgreifen kann, mit dem ein Brute-Force dann keineswegs verhindert wird. Detailfragen kommen dann noch hinzu, wie gehst du mit IPv6 um, sperrst du da gleich ganze Subnetze, wenn ja in welcher Größe?


    Die einzige praktische Auswirkung von fail2ban ist eigentlich, daß man sich gelegentlich selbst aussperrt. Bei allen anderen ist es egal ob du sie sperrst oder nicht, solange dein System sicher ist, kommen die eh nicht rein. Das ist dann nur Schönung von Traffic/Logs/... aber keine echte Sicherheitsmaßnahme mehr.


    Das heißt nicht daß du auf fail2ban verzichten sollst. Im Gegenteil, kann jeder gerne machen. Ditto bei Portänderungen, jeder wie er will. Auf "Sicherheit" als solches hat das aber nur sehr begrenzt Auswirkung.


    Gefährlich wird es dann wenn man sich auf unwirksame Maßnahmen verlässt. Ein offener SSHD wird nicht sicher wenn er auf einem anderen Port läuft oder wenn fail2ban ins Log schaut. Der SSHD muss zuerst sicher sein und dann kannst du das andere Zeug machen wie dir beliebt.






    Es ist auch ein Unterschied ob du alleine am Server bist oder beliebige User darauf ihr Unwesen treiben. Wenn du "aus Gründen" unsichere Passwortlogins für Hinz und Kunz erlaubst, dann ist fail2ban natürlich der verzweifelte Versuch, Sicherheit herzustellen wo keine Sicherheit möglich ist.






  • Das System muss sicher sein, egal ob dein SSH auf Port 22 oder 222 läuft, egal ob du fail2ban benutzt oder nicht. Ist das so, dann hast du Security. Der ganze Rest ist Obscurity.

    Und da sind wir beim Punkt: 100% Sicherheit gibt es nie, was gerade die jüngste Vergangenheit gezeigt hat, sei es Spectre, Meltdown, Heartbleed oder sonst was. Und dann ist es doch besser, wenn man potentielle Angreifer frühzeitig aussperrt, anstatt sie "unendlich lange" probieren zu lassen. Auf jedem System läuft ja Drittsoftware bei der du dir nie 100% sicher sein kannst, dass es keine Sicherheitslücken gibt. Und das Verwenden von fail2ban hat schlichtweg nichts mit Obscurity zu tun sonder ist "reale" Security, keine Ahnung warum du fail2ban mit diesem Begriff schlechtreden willst.


    Was gefährlich an deinem Post ist: Du vermittelst den Eindruck, fail2ban zu benutzen wäre was für "Anfänger" und echte Profis bräuchten das nicht weil deren Systeme zu 100% sicher sind, was totaler Schwachsinn ist; zudem sagst du fail2ban bringt "keine zusätzliche Sicherheit". Und selbst wenn der Key sicher erzeugt ist, kann er immer mal abhanden kommen, in irgendwelchen Datenbanken landen oder sonst wo enden weil der "Login-PC" infiziert ist/war. Und dann will man nicht das ein Angreifer alle Zeit der Welt hat alle jemals geleakten Keys zu testen. Oder Rainbow-Tables an Passwörtern. Laut deiner Argumentation wären ja auch IPS (Intrusion Prevention System) und IDS (Intrusion-Detection-Systeme) völlig unnötig, da ja jeder alles 100% sicher machen kann.


    Ich sehe absolut keinen Grund, Bruteforce "zu dulden" einfach nur weil man sagt "pff mein System ist sicher macht nur" und Methoden, um dies effektiv zu verhindern, abwertend als "Obscurity" darzustellen. Schon nur weil Bruteforce Attacken eine Systemlast erzeugen, die Logs zumüllen und das Netzwerk belasten (wenn auch nur minimalst). Außerdem, wer weiß, vielleicht Schütz fail2ban dich vor einer Sicherheitslücke die noch nicht entdeckt wurde in deinem perfekt sicheren Setup weil sie noch keiner kennt außer ein paar böse Buben ;)


    Und nirgendwo wurde geschrieben, das fail2ban schwache Passwörter "stark" macht. Natürlich ist eine zusätzliche Maßnahme wie fail2ban kein Grund, andere Sicherheitsmaßnahmen zu ignorieren. Zum Thema IP: IPv6 ist generell verboten für SSH, da fail2ban in Debian das noch nicht supported (wenn dann würde ich den ganzen 64er-Block sperren), und bei IPv4 hat man als Angreifer auch nicht mal auf die schnelle ein paar Millionen Adressen zum durchprobieren, außer der Angreifer ist ein großer Brocken der es ernst meint.


    Gerne kannst du mich aber auch vom Gegenteil überzeugen indem du mir beweist, dass es niemals eine Sicherheitslücke geben wird oder kann in der fail2ban dir ein Plus an Sicherheit gibt :P

  • fail2ban hat leider einen Nachteil, den man nicht unerwähnt lassen sollte: Das Auswerten von Logfiles kostet Ressourcen. Firewallregeln abzuarbeiten ebenfalls. Wenn man es als Angreifer darauf anlegt, könnte man manche Server ganz schön belasten.


    Ich will fail2ban nicht schlecht reden, es hat seine Daseinsberechtigung, aber sehr oft brauchen solche Dienste deutlich mehr Ressourcen, als ein gescheiterter Loginversuch. Insofern sind gute Passwörter (oder Keyfiles bei SSH) tatsächlich der einzig gute Tipp. Um diese Absicherung kommt man sowieso nicht herum, wenn man kein offenes Scheunentor haben möchte.

    Obscurity wäre eher, wenn man so etwas wir Portknocking nutzt um den SSH-Port freizugeben.

    Das kommt darauf an, wie Du Portknocking definierst. Mit einer modernen kryptografischen Lösung wie sie z.B. fwknop(d) bietet, würde ich das nicht verteufeln! :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Das Auswerten von Logfiles kostet Ressourcen.

    Ein Beispiel aus der Praxis: Eines meiner Projekte hat in 7 Tagen zirka 5 Millionen Hits. Hier habe ich versucht übermütige User mit Fail2ban auszufiltern. Kann man voll vergessen. Es kommen schneller Log Einträge dazu als sie analysiert werden können.


    Das einzige was hier wirklich funktioniert sind Rate Limits. Und die müssen von der Firewall kommen oder tief im jeweiligen Service verankert sein, sodass man nicht den Umweg über eine Logdatei gehen muss.

  • Das kommt darauf an, wie Du Portknocking definierst. Mit einer modernen kryptografischen Lösung wie sie z.B. fwknop(d) bietet, würde ich das nicht verteufeln!

    fwknop sieht ja richtig interessant aus, wobei die Autoren es selbst ja schon als "Single Packet Authorization > Port Knocking" bezeichnen, was im Grunde alles sagst. Und im Gegensatz zum "simplen" Port Knocking ist fwknop definitiv nicht Obscurity: wenn ich meinem Angreifer alle Details offenbare außer meinem geheimen Key, bringt ihm das immer noch rein gar nichts.


    Das steht auf jeden Fall mal auf meiner Liste zum näher anschauen, vielleicht als "Login-Schutz" wenn ich nicht im internen VPN bin :/

  • Ein Beispiel aus der Praxis: Eines meiner Projekte hat in 7 Tagen zirka 5 Millionen Hits. Hier habe ich versucht übermütige User mit Fail2ban auszufiltern. Kann man voll vergessen. Es kommen schneller Log Einträge dazu als sie analysiert werden können.

    Du sprichst hier aber nicht über SSH, oder? Über SSH hatte ich das Problem noch nie schon nur weil fehlgeschlagene Login-Versuche sowieso einen kurzen Timeout haben, aber du hast Recht, für Gewisse Dienste ist fail2ban unbrauchbar: Vor allem HTTP-Logs bei größeren Projekten oder ähnliches sind nicht be­wäl­tig­bar mit fail2ban, da muss man einen anderen Schutz gegen Brute-Force/DoS-Attacken implementieren.

  • Zitat

    Du vermittelst den Eindruck, fail2ban zu benutzen wäre was für "Anfänger"


    Zunächst einmal ist das nicht der Eindruck den ich vermitteln möchte. Ich sag gar nichts gegen fail2ban. Ich sag auch nix gegen Portänderungen. Mach ich ja eh selber. Ich sag nur daß das im Prinzip beides in die gleiche Richtung geht, das eine wird verteufelt, das andere auf ein Podest gehoben. Das eine ist eben angesehener/akzpetierter als das andere. Viele Leute installieren Linux, haben ganz schräge Firewall-Sachen am Start und "ohne Firewall wirst du sofort gehackt" und... das ist eben nur sehr oberflächlich betrachtet so.


    Und da sind wir beim Punkt: 100% Sicherheit gibt es nie, was gerade die jüngste Vergangenheit gezeigt hat, sei es Spectre, Meltdown, Heartbleed oder sonst was. Und dann ist es doch besser, wenn man potentielle Angreifer frühzeitig aussperrt, anstatt sie "unendlich lange" probieren zu lassen.


    Ja, ist ja auch ein Argument für Portänderungen. Für den Fall daß mal eine unbekannte Sicherheitslücke alle SSHDs der Welt angreifbar macht, ist es doch besser, der SSHD läuft nicht auf dem Standardport sondern woanders, wo du dann vielleicht nicht so schnell gefunden wirst. Kann so passieren. Ändert nichts daran, daß das alles als Security by Obscurity anzusehen ist.


    Bei Sicherheitsmaßnahmen geht man immer von einem theoretischen Angreifer aus, dem maximale Resourcen zur Verfügung stehen. Bei Festplattenverschlüsselung investiert man X-hunderttausend Iterationen (und bald massenhaft RAM) in die Schlüsselableitung, um es rein rechnerisch und technisch unmöglich zu machen, das in sinnvoller Zeit zu knacken, auch mit 100-Millionen-Dollar Hardware. Bei SSH & Co analog mit Keys die soviel Entropie-Zufallsbits haben daß es schlichtweg völlig unmöglich ist, da durchzukommen. Bei IPv4 gibt es 4294967296 IPs, 1 davon gehört dir, der Rest dem Gegner. Dein Sicherheitskonzept muss dieses Szenario überleben und deswegen heißt es überall: mach SSH nicht mit Passwörtern sondern mit 4096-BIt-Keys. Auch wenn ein ausreichend langes Passwort (z.B. 12 Zufallswörter) genauso wenig zu knacken und praktisch kein Unterschied machen würde, man tut das einfach nicht weil es eine bessere Lösung gibt.


    fail2ban kann soll darf man ruhig machen. Aber man braucht sich nicht einbilden, daß es eine starke Sicherheitsmaßnahme ist. Wer das umgehen möchte der kann das einfach tun. Wer 100'000 geleakte Keys hat und weiß, einer davon gehört dir, dann wird der sich ein Botnetz mieten und von 100'000 IPs je eine Anfrage zu dir schicken, kein Ding. Wenn es jemand wirklich auf dich abgesehen hat und was in der Hand hat gegen dich, dann bringt das mit fail2ban gar nichts.

  • fail2ban hat leider einen Nachteil, den man nicht unerwähnt lassen sollte: Das Auswerten von Logfiles kostet Ressourcen. Firewallregeln abzuarbeiten ebenfalls. Wenn man es als Angreifer darauf anlegt, könnte man manche Server ganz schön belasten.

    fail2ban ist ja auch eher für hobby Projekte gedachte.

    iptables hat aber kein Problem mit z.B. 1 Millionen Adressen. Da lädt man im Zweifelsfall ganze blocklisten rum. Da spricht nichts gegen ein kleines Skript, was bei iptables gleich mal bekannten Blocklisten den gesamten Traffic von bösen IPs dropt. Für privat ist das ausreichend ;)


    Wenn du etwas professionell unterwegs bist, dann loggst du im Backend mit, was die Firewall im Frontend sperren darf. Oder du fackelst das ganze mit SSL Offloading vorher ab, dann siehst schon vorne an der Firewall wer dich ärgert.


    Ansonsten läuft pfSense jetzt auch auf den QNAPs, da setzt man dann auf so was: https://www.netgate.com/docs/pfsense/packages/pfblocker.html

    "Security is like an onion - the more you dig in the more you want to cry"

  • Ja, ist ja auch ein Argument für Portänderungen. Für den Fall daß mal eine unbekannte Sicherheitslücke alle SSHDs der Welt angreifbar macht, ist es doch besser, der SSHD läuft nicht auf dem Standardport sondern woanders, wo du dann vielleicht nicht so schnell gefunden wirst. Kann so passieren. Ändert nichts daran, daß das alles als Security by Obscurity anzusehen ist.

    "Security by Obscurity" meint ein System, bei dem die Sicherheit darauf beruht das der Angreifer nicht deine Konfiguration/Algorithmen weiß. Das geht oft bzw. immer schief, ganz krasses Beispiel war der Crypto-1 Algorithmus der Mifare Classic Karten. Aber im Grunde ist auch das ändern des SSH-Portes, wie von dir erwähnt, Security by Obscurity, da der Angreifer bei Kenntnis der Config keinen Nachteil hat und einfach den Port ändert. Zudem dürfte es recht leicht sein den SSH-Port zu finden, selbst das scannen des IPv6 Adressraumes ist machbar.


    Dagegen ist ein Aussperren nach zu vielen Fehlversuchen nicht "Security by Obscurity", da der Angreifer selbst bei Kenntnis der Config nichts dagegen unternehmen kann, nach 3/5/10 Fehlversuchen ausgesperrt zu werden und sich immer eine neue IP holen muss, was den Einsatz von Ressourcen auf Seiten des Angreifers erhöht. Aus genau dem gleichen Grund hat man auch stetig die Länge der Schlüssel erhöht, um den Ressourcen Einsatz auf Seiten des Angreifers zu erhöhen. Ob fail2ban ein geeignetes Mittel ist (weil wenig Angriffe erwartet werden) oder "überfordert" ist (wie bei http-logs) weil nicht das richtige Werkzeug für den Fall ist erst mal egal, aber es ist halt nicht "Security by Obscurity", was negativ besetzt ist (zu Recht). Quasi jeder mir bekannte Dienst nutzt einen solchen Brute-Force Schutz, ob mit fail2ban umgesetzt oder nicht. Und ein grundlegender Brute Force Schutz ist meiner Meinung nach ein muss, und damit bin ich wohl nicht alleine unterwegs, und am einfachsten geht das mit fail2ban für SSH.


    Bei IPv4 gibt es 4294967296 IPs, 1 davon gehört dir, der Rest dem Gegner.

    Korrekt, sofern man nicht über GeoIP etliche aussperrt. Kostet aber Firewallresourcen und ist ebenfalls eine zusätzliche Maßnahme und blieb bisher auch unerwähnt. Aber wenn man solch mächtige Angreifer fürchten muss sollte man sich dagegen wappnen (oder der Angreifer kann das Netzwerk im RZ übernehmen).


    fail2ban kann soll darf man ruhig machen. Aber man braucht sich nicht einbilden, daß es eine starke Sicherheitsmaßnahme ist. Wer das umgehen möchte der kann das einfach tun. Wer 100'000 geleakte Keys hat und weiß, einer davon gehört dir, dann wird der sich ein Botnetz mieten und von 100'000 IPs je eine Anfrage zu dir schicken, kein Ding. Wenn es jemand wirklich auf dich abgesehen hat und was in der Hand hat gegen dich, dann bringt das mit fail2ban gar nichts.

    Klar mag fail2ban nicht die Barriere für den größt möglichen Angreifer sein (wobei vielleicht doch, indem die Rechenlast den Server down gehen lässt und somit sicher vor dem Angriff ist :D), aber schon nur das andere nicht 100.000 Passwörter und Keys ausprobieren können dürfte ein Plus an Performance sein, für das einmalige scannen der Log Files und anlegen der Firewall-Regel (i.d.R. lassen die Angreifer ab sobald der Port gesperrt ist).


    Wobei ich ehrlich sagen muss, ich weiß nicht wie die Logfiles ohne fail2ban bei SSH aussehen würde, aber bei mir sind meist ständig 50-100 IPs gesperrt von fail2ban (48h bantime). Und damit sind diese schon mal raus und können keine Zero-Day-Exploits oder ähnliches ausnutzen. Abschließend müsste man eigentlich analysieren was mehr Performance kostet: fail2ban die logs analysieren lassen und das mehr an Firewall-Regeln oder einfach das Zulassen von BruteForce und der zusätzliche Aufwand für größere Logs und fehlgeschlagene Login-Versuche :/