Dirks Logbuch

Zu dem SSH-Beitrag: Aus meiner Sicht geht er von falschen Voraussetzungen aus. Passwort-basiertes login sollte aus sein. Wenn jemand SSH auf einem anderen Port startet, erhält man eine Meldung. Ausserdem läuft auf dem Port ja schon der "richtige" SSH-Daemon.

Ich ändere den port, weil ich weniger Rauschen in den Logs will. Wenn immer es geht, binde ich den Dienst an den localhost.

Ja, und genau wegen dieser nervenden Logeinträge verlege ich SSH immer auf einen non-standard-Port (sinnvollerweise allerdings mittlerweile < 1024, das hatte ich anfangs nicht bedacht). Das schadet nichts, und es kommen selten bis nie (ich erinnere mich aus den letzten 10 Jahren an genau einen Fall) die üblichen Testläufe mit ausprobierten Accountnamen vor. Die üblichen Verdächtigen scannen nämlich nicht mit nmap, sondern beschränken sich auf die ungezählten Maschinen mit SSH auf Port 22.

Natürlich ist das Verlegen des sshd keine Schutzmaßnahme und unwirksam gegen einen gezielteren Angriff oder auch nur das Scannen typischer Mietserver-IP-Bereiche (der genannte eine Fall betraf binnen kurzer Frist verschiedene Server beim selben Anbieter). Natürlich nutzt man daneben Maßnahmen wie fail2ban und/oder Abschaltung von Anmeldung per Passwort zugunsten von SSH-Keys pp., aber das spricht ja nicht gegen die Verlegung des sshd. Und simpler als Port Knocking ist das allemal.

Unter einer Minute? Das halte ich für eine gewagte Schätzung.
Nach meiner Erfahrung dauert das Scannen der kompletten Portrange mehrere Minuten mit nmap (oder nutze ich vllt. die fchalsen Optionen?).

Erst jetzt verstehe ich, was ihr meint, glaube ich. Spricht ihr von dem Scannen nach Backdoors, die ein Angreifer installiert hat, nachdem er schon Root-Zugriff auf eurem Server erlangt hat? Falls ja: das ist keine wirklich zuverlaessige Methode, dem Angreifer auf die Schliche zu kommen und hat doch außerdem gar nichts mit dem verlinkten Artikel zu tun.

Fuer den Fall, dass man vergessen hat, auf welchen Port der SSH-Dienst des Servers laeuft?

Mir ging es ja um Jens's Satz "Wenn jemand SSH auf einem anderen Port startet, erhält man eine Meldung".

Der Satz bezog sich auf den Originalbeitrag. Dort behauptete der Autor, dass ein User auf einem Port >1024 einen Fake-SSH-Daemon starten kann.

Ich gehe erstmal davon aus, dass der Original-Daemon dauerhaft läuft. Da fragt man sich, wie es der Nutzer schaft, den zu verdrängen. Wenn er es dann irgendwie geschafft hat und einen anderen Dienst startet, so bringt der Verbindeversuch au Nutzerseite eine Meldung, dass der Schlüssel cfhlas ist. Wenn auch der Nutzer es schafft, die Schlüssel auf dem Rechner auszulesen (und den SSHd zu beenden), hat man vermutlich ganz andere Probleme als der Port, der verlegt ist.

Also insgesamt finde ich das Szenario, dass ein User auf dem Port, wo sonst regulär der SSHd läuft, etwas gewagt.

Man darf gar nicht annehmen, dass der SSHd dauernd laeuft. Was ist, wenn der SSHd neustarten muss, weil er zum Beispiel aktualisiert wurde? Ich zitiere den Autor: "It would be easy enough to create a simple application that would scan for a listing port, and start your own non-privileged server as soon as the port is free.".

Ein weiterer Angriffspunkt waere der Reboot des ganzen Servers. Bei der Vielzahl an einsetzbaren Softwarekombinationen koennte doch manchmal die Moeglichkeit bestehen, dass beim Booten ein Non-Root-User noch vor dem Start des SSHd's dessen Port belegen kann. Oder vielleicht ist auch manchmal es eine Sache von Zufall, ob der SSHd oder die Malware zuerst startet.

Klar, alle diese Angriffe sind nicht ganz trivial. Trotzdem sind sie machbar. Wuerde man diese Probleme nicht an ihrer Wurzel packen, muesste man darum nach jedem Neustart des SSHd's pruefen, ob der Port nicht gekapert wurde. Man muesste außerdem gewaehrleisten, dass beim Serverboot der SSHd in jedem Fall gestartet wird, bevor ein normale User Programme starten kann. Und vielleicht gibt es noch Dinge, die man beachten muss, auf die man aber nicht gekommen ist. In meinen Augen ist das unnoetige Komplexitaet und kein sicheres Fundament.

Und sicher, das scheint erst gefaehrlich zu werden, wenn Public-Key-Auth deaktiviert ist. Das geht im verlinkten Artikel tatsaechlich etwas unter, siehe die dortigen Kommentare. Aber selbst wenn PW-Logins deaktiviert sind, kann man bei Verwendung eines unprivilegierten Ports geaergert werden: mit den oben erwaehnten Methoden kann ein Angreifer einem immerhin den SSH-Login blockieren.