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 letzten Herbst 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 potentieller durch Staaten gestützten Wirtschafts- und Industriespionage. Ein wichtiger Punkt für unseren deutschen Mittelstand und darunter gerade 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. Das setzte in jedem Falle 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 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 Updates sondern auch Konfigurationseinstellungen von SSH zu befassen.
  • In einem zweiten 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 verfügbare Updates zu OpenSSH für eine bestimmte Opensuse-Variante.
  • Danach wende ich mich ein paar Details der diagnostizierten Schwächen im initialen Schlüsselaustausch zu.
  • Ein weiterer Teil stellt 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.