Login
Newsletter
Werbung

Thema: OpenSSH 8.0 freigegeben

7 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Ghul am Di, 23. April 2019 um 21:25 #

So musste in OpenSSH 8.0 eine Sicherheitslücke (CVE-2019-6111) geschlossen werden, die es einem böswilligen SSH-Server erlaubte, Dateien mit anderen Namen als die angeforderten zu senden und damit lokale Dateien zu überschreiben.

Es ist wichtig, dass alle Sicherheitslücken geschlossen werden, dennoch muss man auch erwähnen, dass das ein sehr theoretisches Szenario ist, bei der diese Sicherheitslücke ausgenutzt werden könnte.

Denn wie viele bösartige SSH-Server kennt ihr, von denen ihr auch die Zugangsdaten kennt?


Am ehesten könnte ich mir diesen Szenario bei einem Man in the Middle Angriff vorstellen, wo man dem Nutzer zu der Akzeptanz eines neuen SSH Fingerprints und somit Keys auffordert und der das dann abnickt und somit auf dem falschen und bösen Server landet.
Das Problem ist somit vor allem bei remote Verbindungen zu Hochschulen akut, da Hochschulen dazu neigen, ständig den SSH Key zu ändern, aber den Fingerprint nirgends auf ihrer Webseite hinterlegen.
Also ein ganz klarer Fall von weniger Sicherheit, durch Sicherheitswahn, weil der Key zu häufig geändert wird und dann der Fingerprint nicht auf der Webpräsenz kommuniziert wird.

[
| Versenden | Drucken ]
  • 0
    Von ph1234 am Di, 23. April 2019 um 22:41 #

    Ja stimmt, übertriebener Sicherheitswahn geht schnell in die falsche Richtung. Nach dem Motto wir benutzen jetzt Technologie/Methode xy ohne dass man sich die zusätzliche Zeit nimmt diese auch sauber zu studieren und auch in der Anwendung eben dies auch entsprechend nutzt.

    Wie schon bei deinem genannten Beispiel. Keys wechseln kann man machen aber dann muss man auch den zusätzlichen Overhead regelmäßig machen, wie auf der Website publizieren und am besten die User per E-Mail informieren. Das ist wie regelmäßige Passwortwechsel vorschrieben für Personal ohne technischen Hintergrund aber dann keinen Workshop geben, in dem erklärt wird, wie ein Passwortmanager funktioniert. Was passiert? Die Passwörter sind bei manchen mit PostIts am Monitor befässt, super! ;)

    [
    | Versenden | Drucken ]
    • 0
      Von Bernhard M. Wiedemann am Mi, 24. April 2019 um 20:48 #

      Anstatt ssh pubkeys auf eine Webseite zu tun, kann man die auch als SSHFP Einträge im DNS zu den Hostnamen hinterlegen. Das können ssh-Clients dann sogar automatisch nutzen.
      Und wenn man genug Maschinen hat, dann lohnt es sich auch, das zu automatisieren, z.B. per saltstack.

      [
      | Versenden | Drucken ]
      • 0
        Von Ghul am Do, 25. April 2019 um 07:56 #

        Gilt das für alle DNS Server oder ist das nur als Intranet Insellösungen zu gebrauchen?

        Die Ablage des Fingerprints auf einer Webseite lässt sich auch ganz gut automatisieren und bei Bedarf auch hinter eine Loginmaske verwahren.
        Die einfachste Lösung wäre auf der Webseite für jeden Rechner einen statischen Link zu einer Textdatei, der jeweils dessen Fingerprint enthält anzulegen.
        Und an die Adresse dieses Links schiebt man dann die Datei hin, die den Fingerprint direkt aus den Servern auslesen kann.
        Damit muss man weder groß Fingerprints in HTML einbetten noch anderweitig irgendwas manuell machen, außer eben die erste Seite mit der Liste aller Links und den Namen der Server.

        [
        | Versenden | Drucken ]
        • 0
          Von Verfluchtnochmal_5987109 am Fr, 26. April 2019 um 22:38 #

          Von dns scheinst du null Ahnung zu haben oder wie kommst du auf die Schnapsidee dass es einen srv record interessiert ob er im dns server des LAN oder im public view hockt?

          https://de.m.wikipedia.org/wiki/SSHFP_Resource_Record

          [
          | Versenden | Drucken ]
    0
    Von Rolf am Mi, 24. April 2019 um 10:33 #

    Denn wie viele bösartige SSH-Server kennt ihr, von denen ihr auch die Zugangsdaten kennt?

    So einige Server sind mir bekannt! Ich würde diese aber nicht bösartig nennen, sondern falsch konfiguriert. Als Dienstleister muss ich Kunden regelmäßig darauf hinweisen, dass ihr Linux Setup nicht wirklich sicher ist.
    Das fängt zum Beispiel mit viel zu einfachen Kennwörtern an. Aber die Fallhöhe ist eben auch hoch, wenn man sich überschätzt und ahnungslos irgendwelche "Hinweise", oder "Anleitungen" (Howtos) zusammenkopiert, ohne einschätzen zu können, wie valide diese sind.

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung