SSH Standardport 22 ändern - sinnvoll?

sterum

Well-Known Member
Ich hab ja ein Synology NAS. Seit kurzem gibt es dort ein neues Programm, das sich "Sicherheitsberater" nennt.
Nun meckert dieses Ding andauernd das der SSH Port noch auf Standardeinstellung (22) steht und geändert werden sollte.
Da das NAS nur über das lokale Netzwerk erreichbar ist sehe ich jetzt keinen Sicherheitsvorteil wenn ich den Port ändere.
Vielleicht täusche ich mich aber auch und es ist wirklich sinnvoll den Standardport zu ändern.
Was meint ihr dazu?
 
Nein bei dir im LAN spielt das keine Rolle. Das ist für Server im Internet gedacht, um die "script kiddie's" abzuhalten. Jemand der den Port für SSH finden will, findet ihn auch egal ob der jetzt 22 oder auf 40000 steht.
 
Das wäre mal so eine generelle Frage an alle die intensiver Server im Internet betreuen:

Wenn ich einen Server im Internet betreibe, und die üblichen vielen login-Versuche im log vermeiden möchte, "lohnt" es sich dann den ssh-port zu verlegen? Also rein um das log etwas übersichtlicher zu gestalten?

Mir ist bewusst das ich die Sicherheit selber dadurch nicht erhöhe, ich habe z.B. den root-login per ssh generell verboten und dann für einen einzelnen Benutzer ausschließlich key-authentifizierung erlaubt, das ist ja glaub ich best-practice?
 
Kann sein, aber man muss sich vorstellen, dass ein Botnetz bestimmt mind. 1 Node hat, der zuvor einen Portscan gemacht hat und es an andere dann kommuniziert, wo sie drauf SSH-Angriffe starten sollen. Ich hab's noch nicht ausprobiert, weil mir das den Ärger mit non-standard Einstellungen einfach nicht wert ist.

Was aber gegen Botnetze gut wirkt, ist Ports zu sperren, wenn sie viele Fehlversuche hatten (längere Sperren sind sinnvoll, einige Botnetze arbeiten adaptiv). Noch effektiver wird's wenn man mehrere IPs hat und die Sperrung verteilt wird über ganze Server/Jails.
 
Um das Log sauber zu bekommen ist das schon eine Möglichkeit. Klar sollte aber sein, dass ich damit keine ernsthaften Angriffe abhalten kann, sondern nur das Hintergrundrauschen durch automatisierte Scans etwas reduziere. Es ist faktisch kein Sicherheitsfeature.

Ich habe alle sshd auf den selben Highport gelegt und somit weniger "Rauschen" im Log als es mit Port 22 der Fall ist. Entsprechend ist auch in Synology der selbe Highport eingestellt, nicht, dass es im LAN einen Sinn hätte, aber damit laufen alle sshd auf dem selben Port.

Im LAN ist es mM nach völlig unsinnig den Port umzulegen, es sei denn man schafft damit Homogenität zu anderen Installationen. Im Internet finde ich es praktisch.
 
Wenn ich einen Server im Internet betreibe, und die üblichen vielen login-Versuche im log vermeiden möchte, "lohnt" es sich dann den ssh-port zu verlegen? Also rein um das log etwas übersichtlicher zu gestalten?

Seit dem ich den Port umgelegt habe, habe ich eigentlich gar keine Botnetz Login-Versuche mehr. Es wird also offensichtlich kein Portscan vorher gemacht.

Von daher ist mir die Lösung lieber als Random IPs zu sperren. Da hat man im Endeffekt mehr Ärger mit.
 
Mir ist ein Verschieben der Standardports auch nicht lieb und so sitzt meine kleine Wagenburg und sperrt einfach alles, was sich doof benimmt für bestimmte Zeitspannen. Das reduziert die Anfragen recht deutlich und kostet mich fast nichts.

Gut ein anderer Port würde das auch nicht, allerdings kommt bei meinem Glück dann schnell ein Fall, wo irgendwer oder was dann wieder nicht läuft, weil der Port ist ja leer ...
 
Naja, den Port trägt man, wie sein Zertifikat, einfach in die .ssh/config ein und dann ist gut.

Mit IP-Sperren hatte ich schon schlechte Erfahrungen gemacht (hatte ich nicht konfiguriert, lief schon so). Da hatte dann irgend eine Software auf irgend einem PC so einen halben Absturz und hat anscheinend sich "unüblich verhalten" und wurde gesperrt. Nur leider wurde nicht der PC gesperrt, sondern der Access Point und somit wurden ALLE Nutzer im Netz ausgesperrt.

Da darf man dann (mit Kabel bewaffnet) zum Server latschen und das beheben. Sicher, kann man alles konfigurieren usw. Aber es passiert halt mal :D
 
Hmmm, also ausser meinem Rechner zuhause zur Fernwartung greift nichts auf den Port zu, st halt ansonsten primär ein apache, jabber und ts server ;)

Irgendwelche Portsperr-Mechanismen nur um ein log sauber zu halten, halte ich nicht gerade für KISS ;)
 
Wenn ich einen Server im Internet betreibe, und die üblichen vielen login-Versuche im log vermeiden möchte, "lohnt" es sich dann den ssh-port zu verlegen? Also rein um das log etwas übersichtlicher zu gestalten?
Aus genau diesem Grund: definitiv ja!

Mir ist bewusst das ich die Sicherheit selber dadurch nicht erhöhe, ich habe z.B. den root-login per ssh generell verboten und dann für einen einzelnen Benutzer ausschließlich key-authentifizierung erlaubt, das ist ja glaub ich best-practice?
Genau.

Loginversuche gehen IMHO nicht gegen vorhandene offene ports einer IP, also IP:{open port} sondern gezielt nach dem ssh port {random IP || IPblock }: port 22. Da gibt's dann halt manchmal was zum einloggen.
Ein 'persönlicher' Angriff ist, glaube ich, anders. Und leiser.
 
Wenn ich ssh auf 22 laufen lasse, müllt mir das meine logs zu.
Seit ich das auf Port 42130 habe, 0 (Fremd)Einträge.
Ein Postscan auf alle Ports dauert halt den meisten einfach zu lange
 
Irgendwelche Portsperr-Mechanismen nur um ein log sauber zu halten, halte ich nicht gerade für KISS ;)

Warte, warte nur ein Weilchen, dann kommt Lennart auch zu Dir ...

Spaß beiseite, mir sind die Logs völlig egal und das Grundrauschen ebenso.
Ich sperre, weil die Kisten performanter sind und man sie nicht so schnell lahm legen kann. Der Rest ist mir recht wumpe, allerdings ist es manchmal interessant, wenn einer wirklich reinwill und mit Namenvarianten und Geburtstagen und so Zeug anrückt. Das ist schon interessant zu schauen, was der dann alles versucht und was sonst noch so passiert.
 
Ich weiß nicht was Ihr für Angriffchen da habt, wenn Ihr so doofe Botnetze habt. Normalerweise werde ich wach wenn bei mir ab ca 200 Bots auf dem SSH-Port sitzen (den größten Angriff hatte ich mit 2500 Bots). Das betrachte ich als einen Angriff erst. Und da gibt schon schon einiges was sie ausprobieren. Es lohnt sich das auch zu sperren, denn sie kommunizieren unter einander, dass die Angriffe langsamer gemacht werden müssen. Die Nodes verzörgern manchmal die Angriffe bis 1 pro 20 Minuten und wenn's dann so lahm wird, dann gibt es da erst Automatismen, die zum Aufgeben führen.

Einen SSH-Port kann man ganz leicht erkennen (meldet sich direkt mit einem Erkennungs-String) und ein verteilter Portscan ist wahnsinnig schnell. Manche Bots spazieren aber auch ganz langsam die Portrange entlang. So ein Angriff mit tausenden von Bots ist sehr hartnäckig. Das geht tage- und wochenlang, wenn man nichts unternimmt. Wenn man Sperren einrichtet, kann man direkt sehen, wie schnell sie alle weiterziehen.

Aufm Webserver sollte man aber keine Connect-Rate-Sperren machen. Da gibt es andere Mechanismen als Web-Server-Module.
 
Ich hatte auf meinen Server auch eine Weile auf ssh auf Port 22, aber das wurde wirklich exzessiv zugemüllt.
Ich hab den Port dann verlegt, seither ist komischerweise Ruhe, gescannt wird bei mir also offensichtlich auch nicht.
Natürlich kann man die Fremdversuche auch ignorieren, allerdings fand ich die Logdaten dann so unglaublich nutzlos, dann hätte ich auch gleich das Logging komplett abschalten können.
 
Nunja ich bin der Meinung, dass ich wirklich interessante Meldungen dann in der Fülle von Schrott einfach schnelle übersehe... Und wenn man mal was nachvollziehen will und sich jede Zeile einzeln aus dem Suppentopf ziehen muss ist das einfach nervig.

Einen kompletten Portscan macht, mM nach fast keiner. Das lohnt für Zufallsziele einfach nicht. iA werden eine Hand voll interssant wirkender Ports oder Portbereiche abgescannt... Im Highportbereich scant eigentlich fast keiner rum, bin ich der Meinung. Zufallsangriffe haben ja sehr oft Standardinstallationen oder schlecht/nicht administrierte Kisten zum Ziel die man billig übernehmen kann. Der Feld-Wald-Wiesen-Hansel der nach dem durchklicken der Installation sich nicht mehr um die Kiste kümmert legt auch keine Ports um.
 
Meiner Meinung nach nicht sinnvoll.
Falls mich die Einträge in den Logs stören würden, würde ich eher schauen ob man nicht den Loglevel anpassen kann, so das gescheiterte Login Versuche nicht aufgezeichnet werden (LogLevel in sshd_config?).
 
Wir leben in Zeiten, in denen ich in 44 Minuten den Port 22 für das komplette Internet scannen kann.
Ist doch logisch, dass da immer mehr Leute bei einem anklopfen werden und solange der Dienst nur für mich oder einen ausgewählten Personenkreis ist, sehe ich auch keinen tieferen Sinn, den auf 22 fest zu binden.
 
Hallo,
gibt es für zeitsperren der Loginversuche ein HOWTO ich habe auf die schnelle nur Fail2ban gefunden gibt es noch ander möglichkeiten
zb. nach 2 Fehlversuche 1200 Sek kein erneutes anmelden per ssh/http usw..

Guß
Jörg
 
Ich block per GeoIP schonmal alles, was nicht aus DE kommt. Rest ist rate-limited.

Mein authlog hat seit 2 Tagen grade mal 16 Zeilen.
 
Bei meinen Servern darf SSH auch auf Port 22 lauschen - allerdings nur auf IPv6, und da sorgt PF schon dafür, dass nur Traffic aus meinem eigenen Subnetz reinläuft. Von unterwegs läuft dann der Zugriff über VPN zu meinem "Heimnetz", und von da dann auf gewohntem Wege zu den Servern.
Eine Zeit lang (bevor ich durchgängig IPv6 hatte) funktionierten overload-Regeln ganz gut, um die Connection Rates zu begrenzen - inzwischen gibt's aber einige Angreifer mit viel Geduld (Hail Mary, anyone?), wo das nur noch begrenzt hilft oder eben dazu führt, dass man sich selbst aufgrund zu niedriger Schwellwerte aussperrt.
 
Code:
anchor "ext" quick on $ext_if {
    [...]
    anchor "in" in quick {
        [...]
        block return-rst                 log (to pflog1) quick inet proto tcp from ! <GeoIP_DE>
        block return-icmp(filter-prohib) log (to pflog1) quick inet           from ! <GeoIP_DE>

        pass quick proto tcp from ! <overload_ssh> to <...> port 22 modulate state (max-src-conn-rate 2/30, overload <overload_ssh>)
        [...]
    }
    [...]
}

Mehr mach ich nicht.
 
Zurück
Oben