SSH, Linux und die stetige Veränderung von Sicherheit – I

Setzt man sich mit IT-Sicherheit auseinander, so ist eine der faszinierenden, aber auch erschreckenden Tatsachen die, dass als sicher eingeschätzte Fundamente mit der Zeit erodieren. Das gilt für Open-Source-SW ebenso wie für Produkte proprietärer Hersteller. Auch bei konsequenter Update-Politik bleibt immer ein Rest an Unsicherheit.

Im Open-Source-Bereich erlebte SSL/TLS in der OpenSSL-Implementierung mit dem "Heartbleed-Bug" ein abruptes und unsanftes Erwachen aus dem Dornröschen-Schlaf. Dann kam der "Shellshock"-Bug. Ursache waren in beiden Fällen echte SW-Fehler, die sich beheben ließen. Für den Linux-Server-Administrator erschöpfte sich die notwendige Reaktion im Einspielen zeitnah bereitgestellter Updates der Linux-Distribution seines Vertrauens. Aber reicht das immer? Und wenn schon Bugs vorhanden sind - wer sagt einem, dass nicht auch viel grundsätzlichere, z.B. algorithmische Schwächen unsere aktuellen Security-Tools kennzeichnen? So fragt man sich als besorgter Admin immer mal wieder:

Wie sieht es eigentlich mit SSH - genauer OpenSSH - aus?

Unzweifelhaft gehört SSH zu den zentralen Handwerkszeugen, die den Alltag von Systemadministratoren nicht nur im Linux-Umfeld prägen. Ohne SSH kein SFTP, ohne SSH keine sichere Remote-Serveradministration, ohne SSH kein VPN over SSH (z.B. in problematischen Staaten). Es ist wohl keine Übertreibung zu sagen: Ist SSH bedroht, fallen Grundfesten der IT-Sicherheit. Auch im Linux-Umfeld. Trägt man konkrete Verantwortung für die Geheimhaltung von Unternehmensdaten steht deshalb früher oder später die Frage im Raum:

Muss man sich im Falle der Installation und Konfiguration von SSH neben Updates ggf. auch mit Kryptokomponenten befassen, die jenseits der praxisnahen Erzeugung von Schlüsseln für "Public Key"-Authentifizierungsverfahren liegen? Und wer gibt einem im Zweifel dafür vertrauenswürdige Richtlinien an die Hand? Fragen genug für ein paar Blog-Beiträge.

Begründeter Anlass zur Sorge?

Seit ziemlich genau einem Jahr gab es mehrfach Anlass, sich um die SSH-Konfiguration auf eigenen Servern Gedanken bis Sorgen zu machen. Das begann mit einer Untersuchung, deren Ergebnisse erstmals im Mai 2015 diskutiert und dann auf einer Sicherheitstagung im Herbst 2015 präsentiert und als Paper veröffentlicht wurden. Gegenstand des Papers sind potentielle Schwächen eines asymmetrischen Krypto-Verfahrens (Diffie-Hellman-Merkle [DHM]), das u.a. im Rahmen von SSH, TLS und IKE/IPsec zum Einsatz kommt. Ich fand es wenig beruhigend, wie die Studie nachvollziehbar vermittelte, dass ca. 25% aller SSH-Verbindungen mit den Ressourcen eines Staates angreifbar sein sollten.

Ich selbst ordne eine solche Thematik weniger unter dem Blickwinkel einer Totalüberwachung durch mehr oder weniger freundlich gesinnte Sicherheitsorgane irgendwelcher Staaten ein, als vielmehr unter dem Aspekt einer potentiellen und durch Staaten gestützten Wirtschafts- und Industriespionage. Ein wichtiger Punkt für unseren deutschen Mittelstand und darunter gerade für kleinere innovative Firmen, die auf Open-Source setzen.

Auch die praktischen Konsequenzen für System-Administratoren trugen nicht gerade zu meiner Nachtruhe bei:

Aus meiner Sicht waren über Konfigurationseinstellungen mathematische Verfahren einzuschränken oder zumindest zu priorisieren, die unter DHM und damit auch SSH zum Einsatz kommen. Ein besseres Verständnis setzte eine intensivere Auseinandersetzung mit Krypto-Verfahren und deren Vertrauenswürdigkeit voraus. Das Ergebnis entsprechender Recherchen war wiederum nicht als Beruhigungsmittel geeignet. Und zu guter Letzt äußerten sich NSA-Vertretern vor kurzem ganz grundsätzlich zur Zukunft asymmetrischer kryptographischer Verfahren. Die getroffenen Aussagen betreffen u.a. auch SSH und wurden von Experten unterschiedlich gewertet, was wiederum eher zur Verwirrung bzgl. der praktischen Konsequenzen beitrug.

Zeit also für eine kleine Auseinandersetzung mit diesen Punkten. Eine Grundsatzdiskussion, ob man nicht-europäischen Herstellern proprietärer Betriebssystem-Software, die aufgrund der Gesetzeslage im eigenen Land ggf. mit Geheimdiensten zusammenarbeiten müssen, bzgl. der sicheren Implementierung von kryptographischen Systemkomponenten trauen kann, erspare ich mir dabei. Ich beschränke mich hier auf Konsequenzen für Linux-Systeme.

Gliederung der Beitragsserie

Nicht jeder Linux-Admin kennt Grundlagen der Kryptographie. Um die Risiken klarer einzuordnen, ist aber zumindest ein oberflächlicher Blick hinter die Kulissen notwendig. Leser, die mit den Grundlagen (symmetrische Kryptographie, asymmetrische Verfahren, Faktorisierung großer Zahlen, Primzahlen, Modulo-Operationen) vertraut sind, werden sich dagegen mit einigen Ausführungen langweilen. Ich teile deshalb die Auseinandersetzung in mehrere Beiträge auf, die je nach Lust und Laune auch übersprungen werden können.

  • Zunächst möchte ich oben genannte Schlüsselpublikation aus dem letzten Jahr in Erinnerung rufen - und hierzu ein paar Links zusammenstellen. Dabei möchte ich auch einen Blick darauf werfen, wie die Untersuchung vom BSI bzw. CERT-EU verarbeitet wurde. Für Systemadministratoren war die Konsequenz abzuleiten, sich nicht nur mit SSH-Updates sondern auch mit Konfigurationseinstellungen von SSH zu befassen.
  • In einem weiteren Beitrag wende ich mich dann ein paar Details der diagnostizierten Schwächen im initialen Schlüsselaustausch zu. Aus den dortigen Ausführungen sollte einerseits klar werden, wie wichtig die Absicherung des initialen "Key Exchange"-Verfahrens ist [KEX]. In Kombination mit den Untersuchungen aus 2015 ergibt sich, dass der vorsichtige Administrator bestimmte KEX-Verfahren in seiner SSH-Konfiguration eigener Server ausschließen wird; selbst wenn der SSH-Standard sie erfordert.
  • Anschließend möchte ich kurz auf Alternativen zum klassischen Diffie-Hellmann-Verfahren eingehen. Ohne auf Details einzugehen, ist auch dort darauf hinzuweisen, dass bestimmte sog. Elliptic Curve basierte KEX-Verfahren u.U. mit Vorsicht zu genießen sind, selbst wenn sie nicht die 2015 entdeckten Schwächen aufweisen. Dies deuten zumindest andere Untersuchungen an.
  • In einem weiteren Teil möchte ich dann auf etwas Banales hinweisen, das aber in der Praxis von sog. "günstigen" Linux-Implementierungen durchaus eine Rolle spielen kann - nämlich die Kollision von Upgrade- und Update-Politik in nur zeitweise mit Sicherheitsupdates versorgten Linux-Distributionen. Ich werfe dabei einen Blick auf 2016 offiziell verfügbare Updates zu OpenSSH für eine bestimmte Opensuse-Variante.
  • Ein weiterer Teil stellt dann konkrete Hinweise zur Konfiguration von SSH bzgl. DHM zusammen.
  • Ein letzter Artikel befasst sich mit dem Abrücken ausgerechnet der NSA von bestimmten Grundlagen asymmetrischer Krypto-Verfahren.

Die Kommentarfunktion ist geschlossen.