{"id":1629,"date":"2016-09-10T14:51:24","date_gmt":"2016-09-10T14:51:24","guid":{"rendered":"http:\/\/iso-blog.anracom.com\/?p=586"},"modified":"2016-09-10T14:51:24","modified_gmt":"2016-09-10T14:51:24","slug":"ssh-linux-und-die-stetige-veraenderung-von-sicherheit-ii","status":"publish","type":"post","link":"https:\/\/www.kai-wittenburg.de\/?p=1629","title":{"rendered":"SSH, Linux und die stetige Ver\u00e4nderung von Sicherheit \u2013 II"},"content":{"rendered":"<p>In dieser Miniserie von Blog-Beitr\u00e4gen (s. auch <a href=\"http:\/\/iso-blog.anracom.com\/2016\/09\/10\/ssh-linux-und-die-stetige-veraenderung-von-sicherheit-i\/\">SSH, Linux und die stetige Ver\u00e4nderung von Sicherheit &#8211; I\/<\/a>) befasse ich mich ein wenig mit SSH. F\u00fcr mich liefert dieses Protokoll im Zeichen der letztj\u00e4hrigen Entwicklungen ein Beispiel daf\u00fcr, unter welchen Aspekten ein Systemadministrator heute Sicherheitsvorkehrungen einordnen und gestalten muss. Es liefert aber auch ein Beispiel daf\u00fcr, in welche Schieflage die Diskussion von Sicherheit in der IT insgesamt geraten ist und wie notwendig es w\u00e4re, eine grunds\u00e4tzliche Debatte \u00fcber die Rolle aller daran Beteiligten, inklusive staatlicher Organe, zu f\u00fchren. Aber ein Schritt nach dem anderen. <\/p>\n<p class=\"rmo_header\">Eine unruhe-weckende Publikation aus dem Jahr 2015<\/p>\n<p>Nach ersten ver\u00f6ffentlichten Ergebnissen im Mai letzten Jahres erschien im Oktober 2015 eine Publikation, die klar und deutlich vermittelte, dass zumindest damalige Implementierungen von TLS, SSH aber auch IPsec\/IKE einen <em>gemeinsamen<\/em> Schwachpunkt aufwiesen. Wer sich regelm\u00e4\u00dfig um Sicherheitsthemen k\u00fcmmert, kennt das entsprechende Paper unter dem Titel &#8222;<em>Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice<\/em>&#8220; von <strong>Adrian et al.<\/strong>, 2015, vermutlich schon. Es kann unter folgendem Link eingesehen werden:<br \/>\n<a href=\"https:\/\/weakdh.org\/imperfect-forward-secrecy-ccs15.pdf\">https:\/\/weakdh.org\/imperfect-forward-secrecy-ccs15.pdf<\/a>. <\/p>\n<p>Das Paper weist auf Schw\u00e4chen in bestimmten Varianten des grundlegenden <strong>&#8222;Diffie-Hellman-Merkle&#8220;<\/strong>-Verfahrens [DHM] zur  initialen Vereinbarung kryptographischer Schl\u00fcssel hin. Das asymmetrische DHM-Verfahren kommt in einer Reihe von Protokollen zur Verschl\u00fcsselung von Kommunikationskan\u00e4len zwischen Computern zum Einsatz. Passende \u00dcbersichtsartikel finden sich unter<br \/>\n<a href=\"https:\/\/weakdh.org\/\">https:\/\/weakdh.org\/<\/a><br \/>\n<a href=\"https:\/\/www.schneier.com\/blog\/archives\/2015\/05\/the_logjam_and_.html\">https:\/\/www.schneier.com\/blog\/archives\/2015\/05\/the_logjam_and_.html<\/a><br \/>\n<a href=\"https:\/\/www.schneier.com\/blog\/archives\/2015\/10\/breaking_diffie.html\">https:\/\/www.schneier.com\/blog\/archives\/2015\/10\/breaking_diffie.html<\/a><br \/>\n<a href=\"https:\/\/threatpost.com\/prime-diffie-hellman-weakness-may-be-key-to-breaking-crypto\/115069\/\">https:\/\/threatpost.com\/prime-diffie-hellman-weakness-may-be-key-to-breaking-crypto\/115069\/<\/a><br \/>\n<a href=\"http:\/\/thehackernews.com\/2015\/10\/nsa-crack-encryption.html\">http:\/\/thehackernews.com\/2015\/10\/nsa-crack-encryption.html<\/a><\/p>\n<p>Das Interessante an der genannten Ver\u00f6ffentlichung war f\u00fcr mich Folgendes: <\/p>\n<ul>\n<li>Sie zeigt auf, dass die Schw\u00e4che eines einzelnen grundlegenden kryptographischen Verfahrens Auswirkungen auf mehrere Standardprotokolle f\u00fcr den sicheren Datenaustausch in Netzwerken und im Internet haben kann. <\/li>\n<li style=\"margin-top:8px;\">Sie verdeutlicht, dass man bzgl. potentieller Angriffsszenarien immer <em>alle<\/em>  Voraussetzungen, Phasen und Umsetzungsebenen der eingesetzten Protokolle im Blick haben muss. Und das schlie\u00dft letztlich auch die benutzten mathematischen Algorithmen und daraus abzuleitende Konsequenzen ein. <\/li>\n<\/ul>\n<p class=\"rmo_header\">Worum ging es?<\/p>\n<p>Sichere Verbindungen zwischen Computern orientieren sich meist an dem Prinzip, dass das Brechen einer verschl\u00fcsselten Sitzung nicht zur Dekryptierung anderer bereits aufgezeichneter Datenstr\u00f6me f\u00fchren darf. Man spricht auch von sog. &#8222;Forward Secrecy&#8220;. Ein Ansatz dazu ist die <em>sitzungsspezifische<\/em> Vereinbarung von Schl\u00fcsseln hinreichender St\u00e4rke f\u00fcr die anschlie\u00dfende Kommunikationsverschl\u00fcsselung. Die Computer tauschen hierzu in einer initialen Kommunikationsphase \u00f6ffentlich zug\u00e4ngliche Informationen und Parameter aus, die dann u.a. zur Berechnung eines gemeinsam genutzten (symmetrischer) Krypto-Schl\u00fcssels herangezogen werden. Nat\u00fcrlich muss das sog. <strong>&#8222;Key-Exchange-Verfahren&#8220;<\/strong> [<strong>KEX<\/strong>] so sicher sein, dass der Schl\u00fcssel aus den ausgetauschten \u00f6ffentlich zug\u00e4nglichen Informationen f\u00fcr Dritte NICHT ableitbar ist. Wie man das macht, bespreche ich in einem Nachfolge-Artikel. <\/p>\n<p>An dieser Stelle sind f\u00fcr das Verst\u00e4ndnis zun\u00e4chst nur drei Dinge wichtig, wobei wir uns im Moment mehr um das Wording und nicht um Details k\u00fcmmern: <\/p>\n<ul>\n<li>Das DHM-Verfahren wird von SSH in <em>verschiedenen<\/em> Auspr\u00e4gungen genutzt. Darunter gibt es eine sog. FFC-Variante (&#8222;Finite Field Cryptography&#8220;), in deren Rahmen Gruppen von Parametern als Grundlage des konkreten KEX-Verfahrens ausgetauscht werden. Basis der FFC-Verfahren sind u.a. gro\u00dfe Primzahlen und bestimmte multiplikative Operationen auf endlichen Zahlengruppen, die sich durch Modulo-Operationen zyklisch reproduzieren lassen. Die Publikation von Adrian et al. bezog sich auf FFC-Verfahren. Daneben gibt es Verfahren, die Operationen auf sog. &#8222;elliptischen Kurven&#8220; \u00fcber definierten Zahlengruppen nutzen (EC : Elliptic Curve; ECC: Elliptic Curve Cryptography). Auch in EC basierten DHM-Verfahren spielen Primzahlen eine gro\u00dfe Rolle.<\/li>\n<li  style=\"margin-top:8px;\">In DHM-basierten KEX-Verfahren vom Typ FFC ist u.a. die <strong>Gr\u00f6\u00dfe der Primzahlen<\/strong> (genauer deren L\u00e4nge in Bits) entscheidend f\u00fcr die Sicherheit des gesamten Verfahrens. Diese Primzahlen und weitere Parameter m\u00fcssen bestimmte Eigenschaften erf\u00fcllen. Sie sind in der Praxis daher Teil sog. <em>vordefinierter Parametergruppen<\/em>. Ein bestimmtes definiertes DHM-KEX-Verfahren vom Typ FFC nutzt eine ganz bestimmte Parametergruppe und wird in der Regel auch nach dieser Gruppe bezeichnet. Welche Parametergruppen bereitstehen, h\u00e4ngt u.a. von der Implementierung des Protokolls ab &#8211; und nicht zuletzt auch davon, wer aus welchen Gr\u00fcnden solche Parametergruppen erzeugt und empfohlen hat.<\/li>\n<li style=\"margin-top:8px;\">Die konkrete KEX-Variante, die das SSH-Protokoll \u00fcber den DHM-Prozess zur Schl\u00fcsselvereinbarung f\u00fcr eine bestimmte neue Computer-Verbindung nutzt, ist das Ergebnis eines initialen Verhandlungsprozesses: Das KEX-Verfahren wird von den beiden betroffenen Computer-Systemen nach bestimmten Regeln <em>aus einer Menge m\u00f6glicher und verf\u00fcgbarer Verfahren<\/em> ausgew\u00e4hlt. Die verf\u00fcgbaren Verfahren k\u00f6nnen vom Systemadministrator festgelegt oder eingeschr\u00e4nkt werden. Die Auswahl eines konkreten FFC-Verfahrens bedeutet die Auswahl einer bestimmten vordefinierten Parametergruppe. <\/li>\n<\/ul>\n<p>Bei DHM-KEX-Verfahren geht es also um Methoden, wie zwei Systeme im Vorfeld einer z.B. unter SSH verschl\u00fcsselten Kommunikation aus ausgetauschten Parametern einen konkreten gemeinsamen und f\u00fcr Dritte nicht reproduzierbaren Schl\u00fcssel f\u00fcr die Kryptierung des nachfolgenden Informationsstroms berechnen k\u00f6nnen. Das ern\u00fcchternde Ergebnis der genannten Untersuchung war, dass es zumindest mit den Ressourcen eines Staates m\u00f6glich ist, <em>bestimmte<\/em> FFC-Varianten von DHM-KEX-Verfahren, die 2015 noch in der Praxis benutzt und von Servern angeboten wurden, zu brechen. N\u00e4mlich dann, wenn die verwendeten Primzahlen eine bis dato als sicher eingesch\u00e4tzte L\u00e4nge von 1024Bit oder weniger hatten. Dies betraf ganz bestimmte, im Einsatz befindliche vordefinierte Parametergruppen. <\/p>\n<p>Ein potentieller Angriff w\u00fcrde sich also nicht gegen das eigentliche Verschl\u00fcsselungsverfahren von SSH, sondern auf das initiale KEX-Verfahren richten &#8211; mit dem Ziel, den Schl\u00fcssel des sp\u00e4ter eingesetzten, an sich sicheren Verschl\u00fcsselungsverfahrens in Erfahrung zu bringen. Bei dieser Attacke lohnt es sich \u00fcbrigens durchaus, sowohl die initial \u00f6ffentliche als auch die nachfolgende verschl\u00fcsselte Kommunikation f\u00fcr einen sp\u00e4tere Auswertung aufzuzeichnen.  <\/p>\n<p class=\"rmo_header\">Wer war zur Behebung der erkannten Schw\u00e4chen zu addressieren?<\/p>\n<p>Nach der Untersuchung von Adrian et al. steht und f\u00e4llt die Sicherheit sowohl von SSH als auch anderen Protokollen damit, ob die kritisierten FFC-Parametergruppen durch das DHM-Verfahren de facto herangezogen werden oder nicht. Hierauf hat offenbar auch der <em><strong>Systemadministrator<\/strong><\/em> durch Konfigurationseinstellungen Einfluss &#8211; wenn auch begrenzt. Er muss aber nat\u00fcrlich wissen, dass und wo es da ein Problem gibt und was konkret bei der Konfiguration seines Sicherheitsprotokolls zu tun ist. <\/p>\n<p>Die genannte Untersuchung konnte im Zuge experimenteller Analysen aber auch belegen, dass die im Internet vorfindbaren Implementierungen von SSL\/TLS bzw. SSH noch weitere Schw\u00e4chen bis Fehler aufwiesen. Insgesamt wurde eine L\u00fccke zwischen Erkenntnissen der Kryptographie und der algorithmischen Umsetzung bzw. Implementierung in konkreten SW-Paketen beklagt. Ein wichtiger Nachweis wurde im SSL\/TLS-Umfeld durch die sog. &#8222;<em>Logjam<\/em>&#8222;-Attacke gef\u00fchrt. Neben Systemadministratoren sind also auch SW-Hersteller &#8211; und im Fall von Linux ggf. auch Distributoren anzusprechen. Im Falle von SSH sollten u.a. als schwach erkannte DHM-KEX-Verfahren standardm\u00e4\u00dfig aus der Implementierung f\u00fcr das jeweilige Betriebssystem ausgeschlossen werden. <\/p>\n<p class=\"rmo_header\">Eine erste Reaktion des BSI<\/p>\n<p>Wie ernst wurden nun die Ergebnisse der Untersuchung von offizieller Seite genommen? Man sollte meinen, dass die oben diskutierten Erkenntnisse eine dedizierte, klare und umfassende Warnung auch deutscher Bundesbeh\u00f6rden an Systemadministratoren zur Folge h\u00e4tten haben m\u00fcssen. Man w\u00fcrde auch meinen, dass eine solche Warnung konkrete Hinweise zur Konfiguration u.a. von (Open-) SSH h\u00e4tte beinhalten sollen. <\/p>\n<p>Nun schielt man bei solchen Fragen in Deutschland auch als Open-Source-Anh\u00e4nger fast zwangsl\u00e4ufig auf das BSI, das sich j\u00e4hrlich zur Sicherheitslage \u00e4u\u00dferst und dankenswerter Weise regelm\u00e4\u00dfig technische Richtlinien f\u00fcr sicherheitsrelevante Verfahren ver\u00f6ffentlicht bzw. aktualisiert. Ich m\u00f6chte an dieser Stelle einzelne Empfehlungen des BSI gar nicht in Frage stellen. Mir geht es im Moment nur darum, ob die Themen der oben genannten  Ver\u00f6ffentlichung in hinreichender Weise aufgegriffen wurden.    <\/p>\n<p>In seinem j\u00e4hrlichen Bericht &#8222;Die Lage der IT-Sicherheit in Deutschland 2015&#8243; vom November 2015 taucht auf S. 16 der Hinweis auf die sog. Logjam-Attake im TLS-Umfeld auf; nachgeordnet wird auch das allgemeinere und aus meiner Sicht wichtigere Thema der generellen Schw\u00e4che von KEX-Verfahren zur Festlegung von Kryptierungsschl\u00fcsseln unter DHM kurz angesprochen. Zitat: &#8230;&#8220; Sie konnten dadurch die beim TLS-Verbindungsaufbau ausgetauschten geheimen Schl\u00fcssel nahezu in Echtzeit berechnen. Die Ergebnisse sind auch auf andere Einsatzbereiche dieses Schl\u00fcsselaustauschverfahrens \u00fcbertragbar. Mit einem h\u00f6heren Aufwand f\u00fcr die Vorberechnungen lassen sich zudem potenziell auch DLP-F\u00e4lle l\u00f6sen, die eher dem Stand der Technik entsprechen. Die franz\u00f6sischen Forscher geben beispielsweise Argumente daf\u00fcr, dass die NSA in der Lage sei, das DLP auf ausgew\u00e4hlten Gruppen zu 1.024 Bit Primzahlen schnell zu l\u00f6sen.&#8220; Auf die Publikation von Adrian et. al. wird explizit hingewiesen. <\/p>\n<p>Benannt werden die &#8222;anderen Einsatzbereiche&#8220; (u.a. SSH, IPSec) aber nicht konkret. Vor allem aber Hinweise\/Links zu weiteren Informationen bzgl. konkret zu treffenden Ma\u00dfnahmen bzgl. der Konfiguration dieser Protokolle werden im BSI-Papier unverst\u00e4ndlicherweise nicht gegeben. <\/p>\n<p>Die im Februar 2016 erschienene technische Richtlinie BSI TR-02102-1 zum Thema &#8222;Kryptographische Verfahren: Empfehlungen und Schl\u00fcssell\u00e4ngen&#8220; und die Richtlinie TR-02102-4 f\u00fcr SSH sprechen das Thema hinreichender Primzahl- und Schl\u00fcssell\u00e4ngen nat\u00fcrlich an und die empfohlenen L\u00e4ngen sind sehr wohl hinreichend. Die Publikation von Adrian et al. wird dort aber leider \u00fcberhaupt nicht erw\u00e4hnt. Immerhin dr\u00e4ngt die TR-02102-4 darauf, bestimmte KEX-Algorithmen unter SSH nicht mehr zu nutzen oder zumindest in der Priorit\u00e4t herabzusetzen. <\/p>\n<p>Die Richtlinien arbeiten jedoch nicht klar heraus, wer eigentlich einen Einfluss auf die Liste bereitgestellter KEX-Verfahren sowie zugeh\u00f6riger Parametergruppen und Primzahll\u00e4ngen in bestimmten SSH-Implementierungen hat und wer diese Liste wie begrenzen bzw. wie beeinflussen kann: der Hersteller und\/oder der System-Administrator? Ich finde, solche Punkte sollten in einer technischen Richtlinie eigentlich klar und unmissverst\u00e4ndlich behandelt werden. Ferner w\u00fcrde ich mir neben grunds\u00e4tzlichen Empfehlungen auch ein Eingehen auf die wichtigsten am Markt vertretenen Implementierungen w\u00fcnschen.   <\/p>\n<p>Zur anderen Empfehlungen des BSI &#8211; im Besonderen zum Einsatz bestimmter sog. &#8222;Elliptischer Kurven&#8220; als Grundlage von DHM unter SSH sp\u00e4ter mehr.      <\/p>\n<p class=\"rmo_header\">Die sp\u00e4te, aber richtige Reaktion des CERT-EU<\/p>\n<p>Das offizielle Europa reagierte mit erheblicher Zeitverz\u00f6gerung. Das CERT-EU Security Whitepaper 16-002, &#8222;Weaknesses in Diffie-Hellman Key Exchange Protocol&#8220; vom Juli 2016 (!)<br \/>\n<a href=\"http:\/\/cert.europa.eu\/static\/WhitePapers\/CERT-EU-SWP_16-002_Weaknesses%20in%20Diffie-Hellman%20Key%20v1_0.pdf\">http:\/\/cert.europa.eu\/static\/WhitePapers\/CERT-EU-SWP_16-002_Weaknesses%20in%20Diffie-Hellman%20Key%20v1_0.pdf<\/a><br \/>\nnimmt aber explizit Bezug auf die Ergebnisse der Studie von Adrian et. al.. Deren gro\u00dfe Bedeutung auch f\u00fcr SSH, IKE\/IPSec etc. wird klar herausgearbeitet. <\/p>\n<p>Die Einordnung des DHM-Verfahrens als kritische und grundlegende Technologie verschiedener sicherheitsrelevanter Protokolle erfolgt aus meiner Sicht klar und deutlich; Zahlen aus der Studie f\u00fcr die verschiedenen betroffenen Sicherheitsprotokolle wurden zitiert. Die Logjam-Attake wurde als TLS-Besonderheit diskutiert. Im Rahmen der weitergehenden Empfehlungen (z.B. zum Einsatz &#8222;Elliptischer Kurven-Algorithmen&#8220; im Rahmen von DHM) wird explizit auf weitere kritische und aktuelle Untersuchungen hingewiesen. Danach wendet sich das CERT-EU-Papier explizit an Systemadministratoren und gibt Hinweise bzgl. verschiedener betroffene Systeme und Protokoll-Implementierungen &#8211; auch und vor allem im Open-Source-Umfeld. U.a. OpenSSH wird ein eigenes Kapitel gewidmet, in dem klare Vorgaben enthalten sind.    <\/p>\n<p class=\"rmo_header\">Einsch\u00e4tzungen<\/p>\n<p>In jedem Fall signalisierte die Ver\u00f6ffentlichung des CERT-EU White Papers eindr\u00fccklich, dass man das durch Adrian et al. aufgeworfene Problem ernst zu nehmen hatte &#8211; auch als Systemadministrator. Die Art der in der Untersuchung von Adrian et al. besprochenen Schw\u00e4chen der KEX-Verfahren ist zudem nicht geeignet, allein auf Updates zu vertrauen. Man muss sich als Administrator schon um die konkrete Konfiguration von SSH bzw. OpenSSH k\u00fcmmern. Daran l\u00e4sst das Cert-EU-Paper kaum Zweifel. <\/p>\n<p>Nach meiner Einsch\u00e4tzung kamen die Bedeutung und die Reichweite der Ergebnisse von Adrian et al. f\u00fcr die Praxis von Systemadministratoren in den BSI-Papieren dagegen leider nicht so recht zur Geltung. In den sp\u00e4ter aktualisierten technischen Richtlinien TR-02102-1 bzw. -4 kam die Studie gar nicht vor &#8211; auch wenn die Vorgaben f\u00fcr FFC-Verfahren (im BSI-Papier unter DLIES-Verfahren zu finden) selbst den Anforderungen aus der Studie Gen\u00fcge leisten. So blieb der Handlungsbedarf f\u00fcr Administratoren eher unklar. Man h\u00e4tte als Leser der BSI-Publikationen auch darauf vertrauen k\u00f6nnen, dass sich die notwendigen Ma\u00dfnahmen \u00fcber Updates der SW-Hersteller erledigen w\u00fcrden.   <\/p>\n<p>Das White Paper des CERT-EU hingegen zeichnete sich dadurch aus, dass es sich gezielt mit dem Thema DHM befasste (Titel: &#8222;Weaknesses in Diffie-Hellman Key Exchange Protocol&#8220;). Als Administrator wurde man sozusagen geordnet in Unruhe und danach in Aktivit\u00e4t versetzt. Die Hinweise zu den betroffenen Protokollen und notwendigen \u00c4nderungen waren hinl\u00e4nglich, um sich dann im Detail um die etwa f\u00fcr OpenSSH vorhandenen Konfigurationsm\u00f6glichkeiten zu k\u00fcmmern. Aus den Informationen zu OpenSSH in der damaligen Version ging zudem klar hervor, dass man als Administrator bestimmte KEX-Verfahren explizit ausschlie\u00dfen sollte. Ehrlich gesagt, h\u00e4tte ich mir eine \u00e4hnlich pr\u00e4gnante Publikation von Seiten des BSI gew\u00fcnscht. <\/p>\n<p class=\"rmo_header\">Das Thema Sicherheit umfassend adressieren<\/p>\n<p>F\u00fcr Administratoren ist die wichtigste Erkenntnis aus der Untersuchung von Adrian et al. die, dass sie gefordert sind, bei der konkreten Implementierung und Konfiguration von SSH entweder bestimmte KEX-Verfahren explizit auszuschlie\u00dfen oder mit eigenen, speziell generierten Parametergruppen zu unterf\u00fcttern. Mindestens f\u00fcr letzteres MUSS man sich aber um kryptographische Details k\u00fcmmern. SW-Pakete einzuspielen allein reicht in keinem Fall ! <\/p>\n<p>Ich habe das Paper insgesamt jedoch sehr viel weitergehender verstanden: Die ganze Kette der Herstellung, Bereitstellung, Installation und Konfiguration der heutigen zentralen, sicherheitsrelevanten Protokolle und Verfahren sowie die zugeh\u00f6rige Informationspolitik ist eigentlich einem Review zu unterziehen. <\/p>\n<p>Protokolle wie TLS oder eben SSH erfordern grunds\u00e4tzlich den Einsatz <em>verschiedener<\/em> kryptographischer Verfahren, die in unterschiedlichen Phasen der Computerinteraktion f\u00fcr spezifische Zwecke zum Einsatz kommen. Angriffe auf die Sicherheit und Manipulationen sind in allen Phasen der Protokollabwicklung und auf alle Ebenen der eingesetzten Verfahren m\u00f6glich. Deshalb sind auch zugrundeliegende mathematische Algorithmen zu hinterfragen. Konsequenzen bzgl. deren Implementierung bzw. die konkrete Konfiguration durch den Systemadministrator sind regelm\u00e4\u00dfig ins Verh\u00e4ltnis zu neuen M\u00f6glichkeiten der Kryptoanalyse zu setzen. Die Ver\u00f6ffentlichung von Adrian et al. adressierte letztlich all diese Ebenen; die einleitenden Ausf\u00fchrungen der Autoren stellten f\u00fcr mich auch eine Art Appell dar: <\/p>\n<p>Wenn es um Sicherheit in der IT geht, ist das Zusammenwirken vieler Glieder einer Kette zu betrachten. Und welches das schw\u00e4chste Glied und an welcher Stelle es zu Manipulationen kommt, ist nicht immer offenkundig. Hinzu kommt: Die Informationsverbreitung zu erkannten Schw\u00e4chen muss sich in ad\u00e4quater und expliziter Weise an <em>alle<\/em> wenden, die etwas zu tun haben, um die Schw\u00e4chen in der Praxis zu beheben.<\/p>\n<p>Der n\u00e4chste Beitrag behandelt am Beispiel von Opensuse, dass Systemadministratoren dabei nicht allein auf Updates des Distributors in Standard-Repositories vertrauen sollten. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>In dieser Miniserie von Blog-Beitr&auml;gen (s. auch SSH, Linux und die stetige Ver&auml;nderung von Sicherheit &#8211; I\/) befasse ich mich ein wenig mit SSH. F&uuml;r mich liefert dieses Protokoll im Zeichen der letztj&auml;hrigen Entwicklungen ein Beispiel daf&uuml;r, unter welchen Aspekten &hellip; <a href=\"http:\/\/iso-blog.anracom.com\/2016\/09\/10\/ssh-linux-und-die-stetige-veraenderung-von-sicherheit-ii\/\">Weiterlesen <span>&rarr;<\/span><\/a><\/p>\n","protected":false},"author":37,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1176,10,5,1177,1178,1179,6,3,7,1180,1181,4,12,17,15,1182,1,16,14,1183,8],"tags":[],"class_list":["post-1629","post","type-post","status-publish","format-standard","hentry","category-adrian-et-al","category-allgemein","category-bsi","category-cert-eu","category-diffie-hellman-merkle","category-ffc","category-isms","category-isms-bsi-iso-27001","category-iso27001","category-kex","category-key-exchange-protocol","category-notfallmanagement","category-penetrationstest","category-penetrationstests","category-risikomanagement","category-ssh","category-uncategorized","category-unternehmen","category-veranstaltungen","category-weaknesses-in-diffie-hellman-key-exchange-protocol","category-zertifizierung-audit"],"_links":{"self":[{"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=\/wp\/v2\/posts\/1629","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=\/wp\/v2\/users\/37"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1629"}],"version-history":[{"count":4,"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=\/wp\/v2\/posts\/1629\/revisions"}],"predecessor-version":[{"id":5333,"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=\/wp\/v2\/posts\/1629\/revisions\/5333"}],"wp:attachment":[{"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kai-wittenburg.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}