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

In dieser Miniserie von Blog-Beiträgen (s. auch SSH, Linux und die stetige Veränderung von Sicherheit - I/) befasse ich mich ein wenig mit SSH. Für mich liefert dieses Protokoll im Zeichen der letztjährigen Entwicklungen ein Beispiel dafür, unter welchen Aspekten ein Systemadministrator heute Sicherheitsvorkehrungen einordnen und gestalten muss. Es liefert aber auch ein Beispiel dafür, in welche Schieflage die Diskussion von Sicherheit in der IT insgesamt geraten ist und wie notwendig es wäre, eine grundsätzliche Debatte über die Rolle aller daran Beteiligten, inklusive staatlicher Organe, zu führen. Aber ein Schritt nach dem anderen.

Eine unruhe-weckende Publikation aus dem Jahr 2015

Nach ersten veröffentlichten 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 gemeinsamen Schwachpunkt aufwiesen. Wer sich regelmäßig um Sicherheitsthemen kümmert, kennt das entsprechende Paper unter dem Titel "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" von Adrian et al., 2015, vermutlich schon. Es kann unter folgendem Link eingesehen werden:
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf.

Das Paper weist auf Schwächen in bestimmten Varianten des grundlegenden "Diffie-Hellman-Merkle"-Verfahrens [DHM] zur initialen Vereinbarung kryptographischer Schlüssel hin. Das asymmetrische DHM-Verfahren kommt in einer Reihe von Protokollen zur Verschlüsselung von Kommunikationskanälen zwischen Computern zum Einsatz. Passende Übersichtsartikel finden sich unter
https://weakdh.org/
https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html
https://www.schneier.com/blog/archives/2015/10/breaking_diffie.html
https://threatpost.com/prime-diffie-hellman-weakness-may-be-key-to-breaking-crypto/115069/
http://thehackernews.com/2015/10/nsa-crack-encryption.html

Das Interessante an der genannten Veröffentlichung war für mich Folgendes:

  • Sie zeigt auf, dass die Schwäche eines einzelnen grundlegenden kryptographischen Verfahrens Auswirkungen auf mehrere Standardprotokolle für den sicheren Datenaustausch in Netzwerken und im Internet haben kann.
  • Sie verdeutlicht, dass man bzgl. potentieller Angriffsszenarien immer alle Voraussetzungen, Phasen und Umsetzungsebenen der eingesetzten Protokolle im Blick haben muss. Und das schließt letztlich auch die benutzten mathematischen Algorithmen und daraus abzuleitende Konsequenzen ein.

Worum ging es?

Sichere Verbindungen zwischen Computern orientieren sich meist an dem Prinzip, dass das Brechen einer verschlüsselten Sitzung nicht zur Dekryptierung anderer bereits aufgezeichneter Datenströme führen darf. Man spricht auch von sog. "Forward Secrecy". Ein Ansatz dazu ist die sitzungsspezifische Vereinbarung von Schlüsseln hinreichender Stärke für die anschließende Kommunikationsverschlüsselung. Die Computer tauschen hierzu in einer initialen Kommunikationsphase öffentlich zugängliche Informationen und Parameter aus, die dann u.a. zur Berechnung eines gemeinsam genutzten (symmetrischer) Krypto-Schlüssels herangezogen werden. Natürlich muss das sog. "Key-Exchange-Verfahren" [KEX] so sicher sein, dass der Schlüssel aus den ausgetauschten öffentlich zugänglichen Informationen für Dritte NICHT ableitbar ist. Wie man das macht, bespreche ich in einem Nachfolge-Artikel.

An dieser Stelle sind für das Verständnis zunächst nur drei Dinge wichtig, wobei wir uns im Moment mehr um das Wording und nicht um Details kümmern:

  • Das DHM-Verfahren wird von SSH in verschiedenen Ausprägungen genutzt. Darunter gibt es eine sog. FFC-Variante ("Finite Field Cryptography"), in deren Rahmen Gruppen von Parametern als Grundlage des konkreten KEX-Verfahrens ausgetauscht werden. Basis der FFC-Verfahren sind u.a. große 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. "elliptischen Kurven" über definierten Zahlengruppen nutzen (EC : Elliptic Curve; ECC: Elliptic Curve Cryptography). Auch in EC basierten DHM-Verfahren spielen Primzahlen eine große Rolle.
  • In DHM-basierten KEX-Verfahren vom Typ FFC ist u.a. die Größe der Primzahlen (genauer deren Länge in Bits) entscheidend für die Sicherheit des gesamten Verfahrens. Diese Primzahlen und weitere Parameter müssen bestimmte Eigenschaften erfüllen. Sie sind in der Praxis daher Teil sog. vordefinierter Parametergruppen. 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ängt u.a. von der Implementierung des Protokolls ab - und nicht zuletzt auch davon, wer aus welchen Gründen solche Parametergruppen erzeugt und empfohlen hat.
  • Die konkrete KEX-Variante, die das SSH-Protokoll über den DHM-Prozess zur Schlüsselvereinbarung für 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 aus einer Menge möglicher und verfügbarer Verfahren ausgewählt. Die verfügbaren Verfahren können vom Systemadministrator festgelegt oder eingeschränkt werden. Die Auswahl eines konkreten FFC-Verfahrens bedeutet die Auswahl einer bestimmten vordefinierten Parametergruppe.

Bei DHM-KEX-Verfahren geht es also um Methoden, wie zwei Systeme im Vorfeld einer z.B. unter SSH verschlüsselten Kommunikation aus ausgetauschten Parametern einen konkreten gemeinsamen und für Dritte nicht reproduzierbaren Schlüssel für die Kryptierung des nachfolgenden Informationsstroms berechnen können. Das ernüchternde Ergebnis der genannten Untersuchung war, dass es zumindest mit den Ressourcen eines Staates möglich ist, bestimmte FFC-Varianten von DHM-KEX-Verfahren, die 2015 noch in der Praxis benutzt und von Servern angeboten wurden, zu brechen. Nämlich dann, wenn die verwendeten Primzahlen eine bis dato als sicher eingeschätzte Länge von 1024Bit oder weniger hatten. Dies betraf ganz bestimmte, im Einsatz befindliche vordefinierte Parametergruppen.

Ein potentieller Angriff würde sich also nicht gegen das eigentliche Verschlüsselungsverfahren von SSH, sondern auf das initiale KEX-Verfahren richten - mit dem Ziel, den Schlüssel des später eingesetzten, an sich sicheren Verschlüsselungsverfahrens in Erfahrung zu bringen. Bei dieser Attacke lohnt es sich übrigens durchaus, sowohl die initial öffentliche als auch die nachfolgende verschlüsselte Kommunikation für einen spätere Auswertung aufzuzeichnen.

Wer war zur Behebung der erkannten Schwächen zu addressieren?

Nach der Untersuchung von Adrian et al. steht und fällt 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 Systemadministrator durch Konfigurationseinstellungen Einfluss - wenn auch begrenzt. Er muss aber natürlich wissen, dass und wo es da ein Problem gibt und was konkret bei der Konfiguration seines Sicherheitsprotokolls zu tun ist.

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ächen bis Fehler aufwiesen. Insgesamt wurde eine Lücke 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. "Logjam"-Attacke geführt. Neben Systemadministratoren sind also auch SW-Hersteller - und im Fall von Linux ggf. auch Distributoren anzusprechen. Im Falle von SSH sollten u.a. als schwach erkannte DHM-KEX-Verfahren standardmäßig aus der Implementierung für das jeweilige Betriebssystem ausgeschlossen werden.

Eine erste Reaktion des BSI

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örden an Systemadministratoren zur Folge hätten haben müssen. Man würde auch meinen, dass eine solche Warnung konkrete Hinweise zur Konfiguration u.a. von (Open-) SSH hätte beinhalten sollen.

Nun schielt man bei solchen Fragen in Deutschland auch als Open-Source-Anhänger fast zwangsläufig auf das BSI, das sich jährlich zur Sicherheitslage äußerst und dankenswerter Weise regelmäßig technische Richtlinien für sicherheitsrelevante Verfahren veröffentlicht bzw. aktualisiert. Ich möchte 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öffentlichung in hinreichender Weise aufgegriffen wurden.

In seinem jährlichen Bericht "Die Lage der IT-Sicherheit in Deutschland 2015" 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äche von KEX-Verfahren zur Festlegung von Kryptierungsschlüsseln unter DHM kurz angesprochen. Zitat: ..." Sie konnten dadurch die beim TLS-Verbindungsaufbau ausgetauschten geheimen Schlüssel nahezu in Echtzeit berechnen. Die Ergebnisse sind auch auf andere Einsatzbereiche dieses Schlüsselaustauschverfahrens übertragbar. Mit einem höheren Aufwand für die Vorberechnungen lassen sich zudem potenziell auch DLP-Fälle lösen, die eher dem Stand der Technik entsprechen. Die französischen Forscher geben beispielsweise Argumente dafür, dass die NSA in der Lage sei, das DLP auf ausgewählten Gruppen zu 1.024 Bit Primzahlen schnell zu lösen." Auf die Publikation von Adrian et. al. wird explizit hingewiesen.

Benannt werden die "anderen Einsatzbereiche" (u.a. SSH, IPSec) aber nicht konkret. Vor allem aber Hinweise/Links zu weiteren Informationen bzgl. konkret zu treffenden Maßnahmen bzgl. der Konfiguration dieser Protokolle werden im BSI-Papier unverständlicherweise nicht gegeben.

Die im Februar 2016 erschienene technische Richtlinie BSI TR-02102-1 zum Thema "Kryptographische Verfahren: Empfehlungen und Schlüssellängen" und die Richtlinie TR-02102-4 für SSH sprechen das Thema hinreichender Primzahl- und Schlüssellängen natürlich an und die empfohlenen Längen sind sehr wohl hinreichend. Die Publikation von Adrian et al. wird dort aber leider überhaupt nicht erwähnt. Immerhin drängt die TR-02102-4 darauf, bestimmte KEX-Algorithmen unter SSH nicht mehr zu nutzen oder zumindest in der Priorität herabzusetzen.

Die Richtlinien arbeiten jedoch nicht klar heraus, wer eigentlich einen Einfluss auf die Liste bereitgestellter KEX-Verfahren sowie zugehöriger Parametergruppen und Primzahllängen 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ändlich behandelt werden. Ferner würde ich mir neben grundsätzlichen Empfehlungen auch ein Eingehen auf die wichtigsten am Markt vertretenen Implementierungen wünschen.

Zur anderen Empfehlungen des BSI - im Besonderen zum Einsatz bestimmter sog. "Elliptischer Kurven" als Grundlage von DHM unter SSH später mehr.

Die späte, aber richtige Reaktion des CERT-EU

Das offizielle Europa reagierte mit erheblicher Zeitverzögerung. Das CERT-EU Security Whitepaper 16-002, "Weaknesses in Diffie-Hellman Key Exchange Protocol" vom Juli 2016 (!)
http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_16-002_Weaknesses%20in%20Diffie-Hellman%20Key%20v1_0.pdf
nimmt aber explizit Bezug auf die Ergebnisse der Studie von Adrian et. al.. Deren große Bedeutung auch für SSH, IKE/IPSec etc. wird klar herausgearbeitet.

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ür die verschiedenen betroffenen Sicherheitsprotokolle wurden zitiert. Die Logjam-Attake wurde als TLS-Besonderheit diskutiert. Im Rahmen der weitergehenden Empfehlungen (z.B. zum Einsatz "Elliptischer Kurven-Algorithmen" 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 - auch und vor allem im Open-Source-Umfeld. U.a. OpenSSH wird ein eigenes Kapitel gewidmet, in dem klare Vorgaben enthalten sind.

Einschätzungen

In jedem Fall signalisierte die Veröffentlichung des CERT-EU White Papers eindrücklich, dass man das durch Adrian et al. aufgeworfene Problem ernst zu nehmen hatte - auch als Systemadministrator. Die Art der in der Untersuchung von Adrian et al. besprochenen Schwächen 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ümmern. Daran lässt das Cert-EU-Paper kaum Zweifel.

Nach meiner Einschätzung kamen die Bedeutung und die Reichweite der Ergebnisse von Adrian et al. für die Praxis von Systemadministratoren in den BSI-Papieren dagegen leider nicht so recht zur Geltung. In den später aktualisierten technischen Richtlinien TR-02102-1 bzw. -4 kam die Studie gar nicht vor - auch wenn die Vorgaben für FFC-Verfahren (im BSI-Papier unter DLIES-Verfahren zu finden) selbst den Anforderungen aus der Studie Genüge leisten. So blieb der Handlungsbedarf für Administratoren eher unklar. Man hätte als Leser der BSI-Publikationen auch darauf vertrauen können, dass sich die notwendigen Maßnahmen über Updates der SW-Hersteller erledigen würden.

Das White Paper des CERT-EU hingegen zeichnete sich dadurch aus, dass es sich gezielt mit dem Thema DHM befasste (Titel: "Weaknesses in Diffie-Hellman Key Exchange Protocol"). Als Administrator wurde man sozusagen geordnet in Unruhe und danach in Aktivität versetzt. Die Hinweise zu den betroffenen Protokollen und notwendigen Änderungen waren hinlänglich, um sich dann im Detail um die etwa für OpenSSH vorhandenen Konfigurationsmöglichkeiten zu kümmern. Aus den Informationen zu OpenSSH in der damaligen Version ging zudem klar hervor, dass man als Administrator bestimmte KEX-Verfahren explizit ausschließen sollte. Ehrlich gesagt, hätte ich mir eine ähnlich prägnante Publikation von Seiten des BSI gewünscht.

Das Thema Sicherheit umfassend adressieren

Für 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ßen oder mit eigenen, speziell generierten Parametergruppen zu unterfüttern. Mindestens für letzteres MUSS man sich aber um kryptographische Details kümmern. SW-Pakete einzuspielen allein reicht in keinem Fall !

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örige Informationspolitik ist eigentlich einem Review zu unterziehen.

Protokolle wie TLS oder eben SSH erfordern grundsätzlich den Einsatz verschiedener kryptographischer Verfahren, die in unterschiedlichen Phasen der Computerinteraktion für 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öglich. Deshalb sind auch zugrundeliegende mathematische Algorithmen zu hinterfragen. Konsequenzen bzgl. deren Implementierung bzw. die konkrete Konfiguration durch den Systemadministrator sind regelmäßig ins Verhältnis zu neuen Möglichkeiten der Kryptoanalyse zu setzen. Die Veröffentlichung von Adrian et al. adressierte letztlich all diese Ebenen; die einleitenden Ausführungen der Autoren stellten für mich auch eine Art Appell dar:

Wenn es um Sicherheit in der IT geht, ist das Zusammenwirken vieler Glieder einer Kette zu betrachten. Und welches das schwächste Glied und an welcher Stelle es zu Manipulationen kommt, ist nicht immer offenkundig. Hinzu kommt: Die Informationsverbreitung zu erkannten Schwächen muss sich in adäquater und expliziter Weise an alle wenden, die etwas zu tun haben, um die Schwächen in der Praxis zu beheben.

Der nächste Beitrag behandelt am Beispiel von Opensuse, dass Systemadministratoren dabei nicht allein auf Updates des Distributors in Standard-Repositories vertrauen sollten.

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 große Passwort-Sammlung … Wi-Fi Sense unter Win 10

Es ist schon interessant, wie unterschiedlich die im Moment im Entstehen befindliche und am Ende wohl recht umfassende Passwort-Sammlung zu Wi-Fi-Geräten dieser Welt wie auch die zugrunde liegenden "Features" eines seit kurzem auf dem Markt erhältlichen PC-Betriebssystems von Sicherheitsexperten beurteilt werden. Ja, Sie erraten es schon: Es geht um "Wi-Fi Sense" unter MS Windows 10/Windows Phone 8.1.

Siehe hierzu auch

https://grahamcluley.com/2015/08/windows-10-wifi/
http://krebsonsecurity.com/2015/07/windows-10-shares-your-wi-fi-with-contacts/
http://www.silicon.de/41615267/windows-10-sicherheitsexperte-kritisiert-wlan-sharing/
http://www.zdnet.de/88242223/windows-10-wlan-sharing-greift-auf-kontakte-zu/
http://www.spiegel.de/netzwelt/web/microsoft-windows-10-ist-die-neue-wlan-teilen-funktion-sicher-a-1041996.html
http://www.extremetech.com/extreme/209208-windows-10s-new-wifi-sense-shares-your-wifi-password-with-facebook-outlook-and-skype-contacts
http://www.pcgameshardware.de/Windows-10-Software-259581/News/FAQ-zur-WLAN-Passwortfreigabe-1166576/
http://reviews.gizmodo.com/why-the-hell-is-windows-10-sharing-my-wi-fi-passwords-1719900675
http://www.rockpapershotgun.com/2015/07/28/windows-10-wifi-sharing/
http://www.computing.co.uk/ctg/news/2415787/windows-10-wi-fi-sense-security-warning-over-automatically-shared-passwords
https://www.404techsupport.com/2015/06/windows10-network-security-wifisense/
http://www.cnet.com/how-to/how-to-kill-wi-fi-password-sharing-in-windows-10/
http://www.geek.com/microsoft/windows-10-wifi-sense-does-not-share-your-passwords-1630014/
http://money.cnn.com/2015/07/30/technology/windows10-wifi-sense/
http://www.networkworld.com/article/2956393/windows/microsoft-windows-10-wi-fi-sense-an-astoundingly-bad-idea.html
http://arstechnica.com/gadgets/2015/07/wi-fi-sense-in-windows-10-yes-it-shares-your-passkeys-no-you-shouldnt-be-scared/
http://www.pcworld.com/article/2943752/wifi-passwordsharing-feature-in-windows-10-raises-security-concerns.html
https://itauditsecurity.wordpress.com/2015/07/30/no-sense-using-win10-wifi-sense/
http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/
http://www.langer.ws/2015/07/sicherheit-nein-danke-windows-10-teilt-wlan-passwoerter-mit-der-welt/
http://www.golem.de/news/it-sicherheit-windows-10-kann-wlan-passwoerter-an-kontakte-verteilen-1507-115107-2.html
http://www.net-security.org/secworld.php?id=18584

 
Die Beurteilungen reichen von "Desaster" bis hin zu "nützlich" und "doch nicht so gefährlich, weil man schließlich ja etwas dagegen tun könne". Auch wenn ich selbst nie Win 10 auf einem Desktop oder Laptop einsetzen würde, ist das Thema aus einer generellen IT-Sicherheitsperspektive hochinteressant und fordert zur Meinungsbildung geradezu auf. Dazu möchte ich einige Überlegungen beisteuern.

Zunächst mal sei gesagt: Als Internet-Nutzer vertraut man auch anderen Organisationen und deren technischer Präsenz Passwörter an. Aber da entscheide in der Regel ich selbst im Rahmen von Anmeldevorgängen, ob ich anonym bleiben will und welches Risiko ich damit verbinde. Ferner ist die Information, die ich z.B. in einem Forum hinterlasse, genau in dem Maße begrenzt wie ich bereit bin, sie preiszugeben.

Viel wichtiger ist aber aus meiner Sicht: Ich bin bei vielen Internet- und Cloud-Diensten von Haus aus nicht der Illusion ausgesetzt, dass ich Herr über die eingesetzte Technik und die Sicherheit meiner Daten wäre. Es handelt sich nicht um eigene, persönliche und physikalisch greifbare technische Systeme in meinem Besitz. Geht es um gehostete Computer-Systeme wie Server, machen sich interessierte fachkundige Anwender denn auch sehr wohl intensiv mit den Sicherheitsvorkehrungen des Hosters und meinen eigenen Einflussmöglichkeiten auf die Sicherheit vertraut.

Im Falle von PCs oder Laptops unterliegen viele normale Nutzer jedoch der Ansicht, dass dort gelagerte Daten von ihnen selbst kontrolliert würden. Auch wenn dies im Fall von Closed Source Betriebssystemen im Kern natürlich als kaum beweisbare Annahme anzusehen ist - zumindest für den heute fast obligatorischen Fall, dass das Gerät regelmäßig ans Internet angeschlossen wird. In Wirklichkeit wussten/wissen wir ohne explizite Prüfung des Datenverkehrs unserer Systeme nach außen nie, wie privat welche unserer Daten wirklich noch waren oder sind. Die Admins des Bundestages können ein Lied hiervon singen ..ö. aber da ging es um Hacking von Passwörtern und nicht um das Betriebssystem als Passwort-Schleuder.

MS öffnet mit WI-FI Sense aus meiner Sicht nun die Büchse der Pandora für private Netze, PC-Systeme und deren Sicherheit. WI-FI-Sense ist aus Sicherheitsperspektive nicht nur wegen der Verbreitung von MS Win als kritisch anzusehen - sondern vor allem deshalb, weil wir es im Falle von Win 10 mit einer bereits recht weitgehenden Verschmelzung von Internet und PC-Betriebssystem zu tun haben. Das eröffnet einen unschönen Blick auf noch kommende, künftige Cloud-Entwicklungen.

Ich führe nachfolgend einige Gründe für meine wachsende Besorgnis an.

Passwörter zu WLAN-Access Points oder WLAN-Routern sind sicherheitsrelevant

Offenbar ist diese Binsenweisheit beim Design von Win 10 unter den Tisch gefallen. Deshalb nochmal im Klartext:

Passwörter für WLAN/Wi-FI Access Points und/oder WLAN-Router sind u.U. hoch sicherheitsrelevant - nicht nur für den Zugang zum Internet über Wi-Fi-Geräte, sondern für alle angeschlossenen Systeme im betroffenen Netzwerk (WLAN, aber auch per Router angeschlossene LANs) und seinen Segmenten insgesamt. Ich will das gar nicht im Detail begründen; wäre die Aussage falsch, dann hätte man weder WPA2 noch andere Netzwerksegemente, noch spezielle Firewalls für WLAN-Router erfinden müssen. Auch die vielen Artikel, in denen Heimanwender zum Einsatz von WPA/WPA2 aus guten Gründen gedrängt wurden, wären überflüssig. Zeil der Schutzmaßnahmen im Wi-FI-Zeitalter - wie u.a. eine verschlüsselte Passwortübertragung über Funk - war immer die Verhinderung einer unfreiwilligen Preisgabe von Passwörtern an unbefugte Dritte

Ein ungeschützter WLAN-Zugang eröffnet Angreifern eine Vielzahl von Angriffsvektoren auf dahinter liegende Systeme. Ein kluger Anwender, der die Passphrase für den Netzwerkzugang kennt, kann im betroffenen Netz beliebig viel Schaden anrichten, wenn er die dortigen Computersysteme erstmal auf Netzwerkebene direkt ansprechen kann. Dies gilt im Besonderen und gerade für MS-Systeme. Wer es nicht glaubt, mache sich mal mit Metasploit und den dort verfügbaren Tools vertraut.

Aber auch jemand der gar keine PC-- oder Server-Systeme im Netz angreifen will, sondern "nur" den Internet-Zugang selbst über den WI-FI-Access Point einer Firma oder Privatperson für illegale Zwecke (wie illegale Downloads oder aber das Übermitteln von bösartigen Nachrichten)nutzen will, kann erheblichen Schaden mit enormen rechtlichen Folgen anrichten.

Das sind - wie gesagt - Binsenweisheiten. Sie gelten in jedem Fall für Heimnetzwerke, aber leider auch für viel kleine Firmen, die für echte Sicherheitsvorkehrungen in ihren Mini-Netzen mit MS PCs kaum Zeit und Geld aufwenden können. Deswegen ist die Verwahrung und Nicht-Zugänglichkeit von Passwörtern ein hochsensibles Thema - daheim wie im Beruf. Die Weitergabe von Passwörtern für WLAN-Zugangspunkte und Router ist schon im privaten Bereich eine sehr persönliche Entscheidung und Vertrauenssache - in kleinen Firmen ist sie in jedem Fall sicherheitskritisch.

MS stellt diese Binsenwahrheiten jedoch mit den Standardeinstellungen von Win 10 auf den Kopf:

Wenn einem Betriebssystem für einen PC ( "Private (!) Computer") in der Standardeinstellung nicht einmal mehr Passwörter heilig sind, die den Zugänge zu offenkundig sicherheitskritischen technischen Systemen, welche sich in meinem Besitz und Zugriff befinden, eröffnen, und wenn solche Passwörter in der Standardeinstellung (!) des Systems in die Cloud verlagert und ggf. sogar durch ganze Gruppen von Dritten "geshared" werden, dann fragt man sich, welches Verständnis von Privatsphäre und Sicherheit die Erfinder eines solchen Systems überhaupt haben.

Jedenfalls ist dieses Verständnis nicht vom elementaren Prinzip "privacy by design" für Software und Betriebssysteme geleitet. Der "Standard" ist in Zukunft bei MS offenbar: Share everything with me and also third parties - ich nutze deine privaten Daten (s.u.) und verwalte zudem auch Passwörter für deine technischen Geräte in der Cloud - genauer auf MS-Servern. Zudem sorge ich dafür, dass auch andere diese Passwörter nutzen können, wenn du oder ein Dritter (s.u.) diese Passwörter an andere verteilen wollen. Ich sage dir aber nicht, was genau ich für die Sicherheit deiner Daten tue.

Die Gefahr durch unbedarfte oder böswillige Dritte

Ein entscheidender Punkt der Kritik ist nicht allein der Transfer von sicherheitsrelevanten Passwörtern durch ein Win 10 System über das Internet auf die Server des Betriebssystemherstellers. Hinzu kommt, dass ich selbst dann potentiell betroffen sein kann, wenn ich Win 10 gar nicht benutze:

Es reicht, einem Mitarbeiter/Bekannten, der sich mit einem Win10-Gerät (und möglicherweise sogar Smartphone mit Win 8.1) in Reichweite meines WLANs befindet, die Nutzung meines eigenen WLAN Access Points oder WLAN-Routers zu gestatten und ihm hierzu das Passwort "im Vertrauen" mitzuteilen. Das Passwort findet auch dann seinen Weg in die Cloud und wird ggf. von meinem Bekannten mit anderen geteilt. Auch wenn das Passwort selbst für die Beteiligten nicht direkt sichtbar ist, bleibt doch Fakt: Das Passwort ist von Dritten und Vierten einsetzbar, wenn ich es einmal einem Bekannten, der Win 10 Benutzer ist, für den Zugang zum WLAN gegeben habe. Selbst, wenn der betreffende Bekannte das gar nicht will oder weiß - aber mit der Standardinstallation von Win 10 auf seinem Wi-Fi fähigen Gerät wurde die Sache auf den Weg gebracht. Siehe für die Details die oben angegebenen Artikel, u.a. :
https://grahamcluley.com/2015/08/windows-10-wifi/

Dies bedeutet, dass ich die Kette der Personen, die ggf. ungewollt in den Besitz meines Passwortes gelangen, nicht mehr kontrollieren kann.

So wird dann etwa der Angestellte, der das lokale Firmen-WLAN auch schon mal mit dem privaten Laptop nutzt, weil er ja das Passwort kennt - und weil ggf. der Admin seinen Job bzgl. der Firewall nicht ordentlich gemacht hat - schon mal gewollt oder ungewollt zum Sicherheitsrisiko. Und denjenigen, die meinen, das Problem über MAC-Filter auf ihren Access Points oder WLAN-Routern lösen zu können, sei gesagt: Es gibt kaum etwas, das leichter und schneller zu fälschen ist als eine MAC-Adresse.

Will man sich gegen Wifi-Sense schützen, so muss man lt. MS seine SSID abändern und den Zusatz "_optout" hinzufügen. Ich empfinde das einerseits als Zumutung - wegen eines Upgrades eines PCs muss die Bezeichnung von Netzen geändert werden - wo sind wir denn? Andererseits: Woher weiß ich als Privatanwender oder Admin eigentlich, dass ich mich auf diese Vorgabe von MS dauerhaft verlassen kann?

Glauben statt überprüfbare Sicherheit

Zudem ist ja überhaupt nicht klar, welche Sicherheitsmaßnahmen MS eigentlich genau für den Transfer durchs Internet oder für die Lagerung auf den MS Servern einsetzt und was diese Maßnahmen wert sind.

De facto wird also mit der Standardinstallation von Win 10 "Sicherheit" für den Anwender durch "Glauben" des Anwenders an hinreichende Maßnahmen des Betriebssystem-Herstellers wie auch die Ver- und Bewahrung meiner Daten gegenüber Dritten ersetzt. Bin ich ganz naiv, "glaube" ich dann auch daran, dass meine Daten nicht (kommerziell) verwertet werden.

Die krude Grund-Haltung zur Sicherheit ist bei Win 10 wenigstens konsistent umgesetzt - denn Win 10 überträgt bekanntermaßen ja auch massenweise private Daten zur Nutzung des Systems, IT-Konten jeder Art, Freunden, Adressen, etc. auf eigene Server. Siehe für entsprechende Internet-Links etwa:
http://linux-blog.anracom.com/2015/08/11/win-10-linux-im-namen-der-informationellen-selbstbestimmung/

Insgesamt verfestigt sich beim Lesen aktueller Publikationen der Eindruck, dass MS mit Win 10 zumindest die elementare Regel für sichere SW - nämlich "privacy by design" - nicht nur im Bereich Wifi-Sense ignoriert. Nun gut, MS ist weiß Gott nicht allein, wenn es um die Abschaffung von Privatsphäre über die Cloud geht. Aber durch die Verlagerung und die potentiell einkalkulierte Verbreitung von sicherheitsrelevanten Passwörtern ist hier schon von einer Orwell'schen Umdefinition der Begriffe "Sicherheit" und Privatsphäre" auszugehen, die ich persönlich keinesfalls teilen kann.

Verschmelzung von Betriebssystem und Cloud

MS Win 10 ist ein Betriebssystem, in dem PC und Cloud "erstmalig" eng miteinander verschmolzen werden sollten. Nun ist die "Cloud" ja keineswegs etwas Abstraktes - es handelt sich i.d.R. um Server-Konglomerate, die jemandem gehören und von jemandem verwaltet werden. In unserem Fall von MS.

Das vorliegende Ergebnis der Cloud/Betriebssystem-Verschmelzung verheißt in puncto IT-Sicherheit jedenfalls nichts Gutes für die Zukunft: Wenn MS schon bestimmte Passwörter für technische Geräte, deren Sicherheit für die Netz-Infrastruktur daheim oder in der Firma essentiell sind, auf eigene Server verschiebt, warum sollte ich dann eigentlich daran glauben, dass dies in Zukunft nicht auch mit anderen Passwörtern passiert?

Genauer betrachtet ist das ja sowieso das ultimative Cloud-Ziel: Der Anwender lädt sein "Betriebssystem" in Miniform aus dem Netz auf einen Thin-Client herunter - alle wesentlichen Programme laufen aber auf Servern des Betriebssystem-Providers. Dann liegt die Passwortverwaltung auf den Cloud-Servern zwingend nahe. MS WIN 10 ist ein Schritt in diese Richtung. Voraussetzung für derartig umfassende Cloud-Dienste sollten jedoch immer klare Verträge und ein hinreichender Kenntnisstand des Anwenders sein.

Der Unterschied zur jetzigen Situation ist der:
Bislang glaubten wir, dass Passwörter auf unseren lokalen PCs liegen - und zwar verschlüsselt und für andere nicht nutzbar. Unter Linux kann ich das prüfen - unter MS Win nur partiell. Wir gingen ferner davon aus, dass Dritten die Passwörter nicht zugänglich gemacht werden. Unter Win 10 gilt dies zumindest für wichtige technische Infrastrukturkomponenten schon nicht mehr. Hinzu kommt, dass diese Änderung in der verlockenden Form eines kostenfreien Betriebssystem-Upgrades an den unaufgeklärten Anwender herangetragen wird, der natürlich auf Standardeinstellungen während des Installationsvorgangs vertraut.

Wäre MS WIN vollständig in die Cloud verlagert, so könnte der Benutzer das Risiko des Passwortverlagerns und -sharens mit andern Internetkonten vermutlich besser einschätzen. Im Falle der Verführung zu einem kostenfreien Upgrade seines "Privaten Computers" kann man sich fragen, ob die Masse der Anwender die substanzielle Änderung einer bislang etablierten Sicherheitspolitik bzgl. der Handhabung von Passwörtern überhaupt wahrnehmen.

Der Privatanwender ist meist überfordert

Vielleicht stimmt es ja, das man zumindest im Prinzip etwas gegen den Transfer der sensiblen Wi-FI-Passwörter zu MS Servern tun kann. Viele der oben angegebenen Artikel zeigen ja auf, was man gem. der Angaben von MS (!) dafür tun muss. Es stellt sich einem dennoch die Frage: Wer ist denn im Alltag des privaten Anwenders "man"? Ist "man" denn wirklich zu effektiven Gegenmaßnahmen fähig?

"Man" ist wohl letztlich er - also der Anwender - selber ... Damit wird aber weltweit Privatsphäre und Sicherheit vom Ausbildungsstand und dem (technischen) Wissen der Anwender abhängig gemacht. Meine Erfahrung mit Standard-Windows-Benutzern in meinem Bekanntenkreis ist leider: Die meisten sind bereits mit viel einfacheren Dingen als den Schritten zur Anstellung von Wi-Fi Sense überfordert - und haken in der Regel Systemrückfragen im Rahmen einer Betriebssysteminstallation einfach ab, weil sie die Sicherheitsimplikationen nicht übersehen können oder wollen ...

Gewiss: Große Firmen werden Wifi-Access Points mit zentralen Auth-Verfahren über z.B. 802.1x, EAP und Radius-Servern verbinden und damit zunächst (hoffentlich) vor Wifi-Sense geschützt sein - aber ich kenne haufenweise kleinere Firmen, die mit konventionellen WPA/WPA2 auf WLAN-Routern (z.B. Fritzboxen von AVM) arbeiten. Die sind somit alle potentiell von den neuesten "Segnungen" des Marktführers für Desktop-Systeme betroffen ....

Deswegen ist insgesamt davon auszugehen, dass MS beim Aufbau seiner weltumfassenden Datenbank für Wi-Fi-Passwörter letztlich Erfolg haben wird, zumal alle unsere lieben Freunde, Verwandte und Bekannte ja zur (ungewollten und unbewußten) Verbreitung von Wifi/WLAN-Passwörtern beitragen können - selbst wenn man selbst gar nicht WIN 10 benutzt.

Was haben wir da also eigentlich vor uns?

Die Verbreitung von Win 10 ist aus meiner Perspektive und aus den genannten Gründen mit einer Maschinerie gleichzusetzen, die u.a. dem Aufbau einer der größten Passwort-Datenbanken der Welt auf amerikanischen Servern dient. Hinzu kommen technische Informationen über die WIFI-Ausstattung weltweit. Die Datenübertragung und Verschlüsselung findet zudem über die SW eines Unternehmens statt, von dem einige Experten schon in der Vergangenheit bezweifelt haben, dass Datensicherheit die Top-Leitlinie des technischen und kommerziellen Handelns ist.

Mal abgesehen davon, welche mächtige Position MS selbst durch eine solche Datenbank erhält .... Wir müssen - ganz unabhängig von MS's Sicherheitsvorkehrungen - in jedem Fall mit Fug und Recht annehmen, dass eine solche Datenbank für Passwörter und technische Information zu WI-FI-Netzen und die Übertragungswege zu dieser Datenbank für viele Organisationen - darunter auch verbrecherische - von größtem Interesse sein dürfte. Den finanziellen Wert einer solchen Datenbank kann man gar nicht überschätzen. Sie ist sicher sehr viel mehr wert als ein paar Steuersünder-CDs. Im schlimmsten Fall ist es deshalb wohl nur eine Frage der Zeit, bis irgendein Böser entweder die Wifi-Sense Transfer-SW in Win 10 oder Win Phone 8.1 knackt oder Zugang zu der Wifi-Sense Datenbank selbst erhält.

Was sollte man also als Firma oder kundiger Anwender eines komplexeren Heimnetzes tun?

Als sicherheitsorientierter Admin wird man dafür sorgen, dass man von der ganzen potentiellen Misere möglichst gar nicht betroffen ist. Die eigentlich richtige Konsequenz, nämlich Win 10 in der Home-Version gar nicht erst zum Einsatz zu bringen, stellt sich für viele Admins kleiner Firmen leider von Haus aus nicht.

Netzwerksegmentierung
Aber auch in einer MS dominierten Welt zeigen so elementare Sicherheitsregeln wie die strikte Separation von Netzen/Netzwerksegmenten mit öffentlich zugänglichem Access Point (z.B. für externe Mitarbeiter) einerseits von privaten oder firmeninternen Netzen/Netzwerksegmenten andererseits Wirkung. Diese fundamentale Regel gewinnt mit Win 10 an Bedeutung - und ist technisch angemessen umzusetzen.

Ob einem Admin das aber rechtlich wirklich hilft, wenn etwa ein böser Facebook-Freund eines externen Mitarbeiters oder Freundes in Zukunft den öffentlichen Wifi-Zugang zum Internet einer Firma für illegale Zwecke nutzt, sei mal dahingestellt ....

Passwortwechsel
Eine weitere elementare Regel ist deshalb schlicht das häufige, nicht vorhersehbare Wechseln von Passwörtern zu den zu administrierenden Wireless-Netzen.

MAC-Filter
Zugangsfilter auf MAC-Ebene sind nur begrenzt wirksam und schrecken echte Hacker nicht ab. Aber warum nicht?

Zentralisierte Authentifizierungsverfahren über 802.X1
Ferner sieht es zur Zeit wohl (noch) so aus, dass MS die Finger von Passwörtern zu WIFI/WLAN-Access Punkten oder -Routern lässt, bei denen die Authentifizierung über zentrale Systeme läuft. Für Firmen, die mit Gedanken spielen, Win 10 Clients einzusetzen oder Win 10 Clients Zugang zum WLAN zu geben, kann die technische Devise im Moment wohl nur so lauten:

Weg von direkter WPA2/WPA-Authentifizierung gegenüber dem WIFI/WLAN-Access Point/Router und statt dessen hin zum Einsatz zentraler Authentifizierungsverfahren über IEEE 802.1x, EAP, Radius Server. Etliche WLAN AccessPoints/Router unterstützen schon seit längerem "WPA2 Enterprise", das solche Lösungen ermöglicht. Leider aber z.B. nicht die Produkte des Marktführers in Deutschland für die breite Allgemeinheit - nämlich AVMs Fritzboxen - und dies trotz mehrfacher Aufforderung von besorgten Anwendern. Aber es gibt ja Alternativen für Access-Points auch im preiswerten Consumer-Segment und Sicherheit sollte auch in kleinen Firmen eine überschaubare Investition wert sein ....

Flankiert müssen Vorkehrungen zur zentralen Authentifizierung in WLANs allerdings auch

  • durch umfassende Aufklärung der Win 10 Nutzer,
  • das systematische Abstellen von Wi-Fi-Sense auf Geräten, die wir kontrollieren können
  • sowie durch rigide Policies zur Wi-Fi/WLAN-Nutzung im Unternehmen.

Kein BYOD für WIN 10 Geräte
Ich war noch nie ein Freund von BYOD - aber "Bring your own (!) Win 10 Device or Win 8.1 Mobile Device" ist in einer Firma mit Sicherheitsanspruch sicher keine gute Idee.

Überwachung ausgehenden Datenverkehrs
Und wenn man sich auf Dauer nicht auf die Versicherung von MS verlassen will,dass 802.1X-Netze unangetastet bleiben, wird man wohl nicht darum kommen, ausgehenden Netzwerkverkehr von Win 10-Systemen daraufhin zu kontrollieren. Ich denke, es wird nur einen Frage der Zeit sein, bis entsprechende automatisch verwertbare Muster für den Datentransfer bekannt werden.

Konsequenz für Sicherheitsaudits

Das Feature "Wifi-Sense" von Win 10/Win Phone 8.1 sollte im Risiko-Management von Firmen und in zugehörigen Sicherheits-Audits einen festen Platz bekommen. In Kombination mit der Upgrade-Politik ist das Thema sogar ein idealer Prüfstein dafür, ob das Risiko-Management im Rahmen des Change Managements für das technischen Umfeld hinreichend funktioniert.

Ein paar Links zu 802.1X, EAP, Radius: