ssh anderer Port

[strobocom]

Hallo,

ich will zu unserem Server ins Internet über ssh connecten was nie ein Problem war.

Jedoch haben wir jetzt den Port auf dem Server im Internet geändert seitdem komme ich nicht mehr auf meinen Server.

Welchen befehl muss ich denn im Terminal eingeben um meinen Server zu erreichen.

Früher ging das immer so

ssh meinedomain.bs

jetzt liegt der ssh aber auf dem port 111



Danke

 

[Irgendein Held]

Mit nmap kannst du nach dem Port scannen. Und Ports umlegen ist security by obscurity. #FAIL

Achja, die Parameter um den Port anzugeben findest du in der manpage (man ssh).

 

[quarx]

Und Ports umlegen ist security by obscurity. #FAIL

Den SSH-Port umlegen schützt aber vor 99% aller automatisierten ssh-Einbruchsversuche.

 

[bezierkurve]

manpage says …:

-p port
Port to connect to on the remote host. This can be specified on
a per-host basis in the configuration file.

 

[Irgendein Held]

Es schuetzt nicht, es ist nur Glueck, dass da nicht jemand mit mehr Logik rangeht.
Wenn deine benannten 99% der Angriffe erfolg haetten, dann haettest du ganz andere, viel schwerwiegendere, Probleme. Ich wuerde sogar fast behaupten, dass bei jemandem, der seinen shh-Port umlegt, die Chance groesser ist reinzukommen, weil er, je nachdem, noch genug Anderes gefrickelt hat, was fuer mich hilfreich sein kann.

 

[quarx]

Es schuetzt nicht, es ist nur Glueck, dass da nicht jemand mit mehr Logik rangeht.

Natürlich schützt es, weil fast alle ssh-Angriffe ins Leere laufen (automatisiertes Abklappern von Benutzer-Passwortlisten durch irgendwelche Bots). Das führt zu unnötig großen Log-Dateien, die ein Aufspüren anderer Fehler erschweren.

Wenn deine benannten 99% der Angriffe erfolg haetten, dann haettest du ganz andere, viel schwerwiegendere, Probleme.

Wofür ist das ein Argument? Die Angriffe sind nunmal DA, egal ob ich den Port umlege oder nicht.

Ich wuerde sogar fast behaupten, dass bei jemandem, der seinen shh-Port umlegt, die Chance groesser ist reinzukommen, weil er, je nachdem, noch genug Anderes gefrickelt hat, was fuer mich hilfreich sein kann.

Dann gib mir mal ein Beispiel. Mit Polemik kann ich nichts anfangen. Ich fühle mich mit umgelegten SSH-Ports sowie Login via Public Key Authentication recht sicher.

 

[Irgendein Held]

Den umgelenkten ssh-Port brauchst du garnicht. Lediglich public key authentication zu gewaehren ist vorbildlich.

Umgelenkter ssh-Port.. mhh... direkt mal pruefen ob der nicht einen Mailservice laufen hat (open relay), oder einen offenen Nameserver, etc.
Rein subjektiv, und aus Erfahrung anderer, kann ich sagen, dass sowas Interesse weckt.

Fuer deine Angriffe gibt es Fail2Ban und weitere Alternativen.

 

[quarx]

Umgelenkter ssh-Port.. mhh... direkt mal pruefen ob der nicht einen Mailservice laufen hat (open relay), oder einen offenen Nameserver, etc.
Rein subjektiv, und aus Erfahrung anderer, kann ich sagen, dass sowas Interesse weckt.

Und wenn schon, sowas hab' ich auf den von mir admistrierten Linux-PCs nicht am Start.

Fuer deine Angriffe gibt es Fail2Ban und weitere Alternativen.

Danke für den Tipp, das schaue ich mir mal an. Allerdings scheinen mir die meisten Angriffe von häufig wechselnden IPs zu kommen. Dann müsste fail2ban häufig aufgerufen werden, oder?

 

[Irgendein Held]

Es laeuft Service, ja.
Fail2Ban sperrt IPs, die unter die Filterregeln fallen, nach definierten Regeln, fuer einen angegebenen Zeitraum, via iptables.

Damit wirkst du dann gleich auch motivierteren Angreifern, als Scriptkiddies, entgegen.

 

[pepi]

Ich muß hier quarx zustimmen, daß ein geänderter [tt]ssh[/tt] Port für definitiv mehr Ruhe in den Logs sorgt. Automatisierte Angriffe machen sich erfarhrungsgemäß nicht die Arbeit die Maschinen komplett zu scannen, sondern suchen nach einfachen Zeilen. Das sind nunmal Geräte die [tt]ssh[/tt] auf Port 22 betreiben und evt. auch noch simple Accounts (wie admin oder root) zulassen. Ein geänderter Port schützt somit erstaunlich definitiv vor primitiven Scannern und tonnenweise User enumeration oder Login Fehlversuchen in den Logs.

Es geht dabei nicht darum die Sicherheit des [tt]ssh[/tt] daemons zu erhöhen sondern das Grundrauschen im [tt]secure.log[/tt] und [tt]system.log[/tt] zu verringern um diese im Bedarfsfalle einfacher auswerten zu können.

Eine gute [tt]sshd[/tt] Konfiguration läßt selbstverständlich nur unprivilegiere Accounts einloggen, kein root oder sonstiges Admin Login zu, und das auch nur per Key authentication. Zusätzlich sollten nur die User überhaupt zum Einloggen berechtig sein für die es unbedingt notwendig ist.

iptables gibts unter Mac OS X nicht, mittels [tt]denyhosts[/tt] funktioniert das aber auch unter Mac OS X mit der [tt]ipfw[/tt]/[tt]ip6fw[/tt]. Unter Mac OS X Server kümmert sich außerdem der adaptive Firewall und der Password Server automatisch darum Bruteforce Angriffe sehr erfolgreich zu unterbinden.
Gruß Pepi