Wer unter Ubuntu 16.10 VirtualBox nutzen will, hat mindestens zwei Möglichkeiten: 1. Secure Boot ausschalten, damit der Linux Kernel das unsignierte Modul für VirtualBox laden kann, oder 2. das Modul selber signieren, damit Secure Boot weiterhin funktioniert.
Hier der Weg, um die zweite Möglichkeit umzusetzen:
Nach der Installation von VirtualBox mit „sudo apt-get install virtualbox“ generieren wir als erstes unseren eigenen MOK im Verzeichnis „/PFAD_ZUM_MOK/“ mit:
Dann die erzeugten Schlüssel für Secure Boot importieren:
sudo mokutil --import MOK.der
Dabei muss ein Passwort gesetzt werden, dass einmalig zur Sicherheit beim Neustart abgefragt wird.
Jetzt den Computer neu starten. Es erscheint ein blauer Screen, auf dem 1. eine Taste gedrückt, 2. „Enroll MOK“ ausgewählt, 3. „Continue“ ausgewählt, 4. „Yes“ ausgewählt, 5. das vergebene Passwort eingegeben und 6. „Ok“ ausgewählt werden muss (Hier der Prozess in Bildern).
Jetzt geht es an das Signieren des VirtualBox Moduls. Dazu brauchen wir das Skript „sign-file“. Unter Ubuntu finden wir dieses im Verzeichnis „/usr/src/linux-headers-KERNEL_VERSION/scripts/“ (bitte die Versionsnummer KERNEL_VERSION entsprechend des eingesetzten Kernels anpassen, die sich mit dem Befehl „uname -r“ anzeigen lässt). Eventuell müssen dafür zunächst die Header-Files installiert werden:
Die erste Barrier zum Schutz des eigenen Mac’s und insbesondere der eigenen Daten vor fremden Zugriffen besteht im simplen Anmelde-Management. Es darf nur für autorisierte Personen möglich sein, den Mac zu benutzen und auf gespeicherte Inhalte zuzugreifen. Für die Autorisierung benutzen wir die vorgesehenen Mechanismen von macOS. Diese bestehen zunächst in dem einfachen Setzen eines zur Anmeldung benötigten „Geheimnisses“: dem Passwort.
Abschnitt 1: Passwort
„Choosing a hard-to-guess, but easy-to-rememberpassword is important!“ Kevin Mitnick
Was macht ein gutes Passwort aus?
Damit ein Passwort gut ist, darf es nicht zu kurz sein. Kurze Passwörter lässt sich leicht mittels „durchprobieren“ aller möglichen Kombinationen herausfinden.
?
Wenn versucht wird, ein Passwort durch ausprobieren aller möglichen Kombinationen zu knacken, spricht man vom Einsatz der so genannten „Brute-Force-Methode“. Es wird „rohe Gewalt“ eingesetzt und nicht versucht, logisch auf mögliche Passwörter zu schließen.
Daher muss man lange Passwörter benutzen. Dabei sollte man aber nicht mehr auf den alten Tipp, mindestens 8 Zeichen zu benutzen, hören. Heutzutage sollten es mindestens 10, besser 12 oder mehr Zeichen sein.
Aber auch ein langes Passwort ist noch kein Garant für ein gutes Passwort. Besteht etwa ein acht Zeichen langes Passwort ausschließlich aus Zahlen (von 0 bis 9), gibt es insgesamt 10 hoch 8 + 10 hoch 7 + … + 10 hoch 1 mögliche Passwörter (= 111.111.111), die durchprobiert werden müssen. Auch wenn sich 111 Millionen Passwörter zunächst einmal viel anhört, ist es für einen Computer kein Problem, diese einfach durchzuprobieren. Eine moderne CPU mit mehr als 3 GHz kann vielleicht 150 Millionen Versuche in einer Sekunde durchführen. Ein Passwort mit 8 Zahlen wäre also in deutlich weniger als einer Sekunde geknackt.
Wenn nicht nur die 10 möglichen Zahlen an jeder Stelle des Passwortes stehen können, sondern auch noch 26 Groß- oder 26 Kleinbuchstaben, steigt die Zahl der möglichen Passworte schon einmal auf 62 hoch 8 + 62 hoch 7 + … + 62 noch 1 an (= 221.919.451.578.090). Um diese Passwörter alle durchzuprobieren, würde die CPU bereits 410 Stunden oder 17 Tage rechnen.
17 Tage hört sich doch schon einmal besser an. Allerdings braucht die CPU im Durchschnitt ja nur die Hälfte der Zeit, um ein Passwort zu finden. Wenn dann nicht nur eine CPU, sondern gleich mehrere parallel arbeiten (oder noch einmal deutlich schnellere GPUs von Grafikkarten benutzt werden), verringert sich die Dauer zum Durchprobieren dieser Passwörter wieder auf einige Stunden oder Minuten.
Also erweitern wir am besten das Passwort auch noch um etwa die folgenden 12 Sonderzeichen (!§$%&=?*+-#_), sind 74 hoch 8 + 74 hoch 7 + … + 74 hoch 1 Passwörter möglich (= 911.512.476.370.950). Jetzt benötigt die CPU schon 1687 Stunden oder 70 Tage. Hört sich viel an, aber wenn man mehr als eine CPU nutzt, schnurrt auch diese Zeitspanne schnell wieder zusammen. Daher sollte man sich merken: 8 Zeichen lange Passwörter sind heutzutage zu kurz. Wenn man die Passwortlänge von 8 auf 9 Zeichen erhöht (+ 74 hoch 9 Möglichkeiten), werden aus den 70 Tagen etwa bereits 5.204 Tage oder 14,3 Jahre.
Ein gutes Passwort ist kein gutes Passwort
Jetzt haben wir uns also ein gutes Passwort konstruiert, was man sich am auch noch irgendwie merken kann (denn nichts ist schlecht als ein Anmeldepasswort, dass direkt auf’s MacBook, den Schreibtisch oder den Monitor geklebt wird, damit man es nur abtippen braucht). Was man nun auf keinen Fall tun sollte: das gleiche Passwort für alle möglichen anderen Anmeldevorgänge verwenden.
Statt einem guten Passwort, brauchen wir eigentlich so viele gute verschiedene Passwörter, wie unterschiedliche passwortgeschützte Zugänge vorhanden sind. Insbesondere wenn es um Login-Daten für Webseiten geht ist dies wichtig. Und extrem wichtig wird es bei den Seiten, die bei missbräuchlicher Nutzung richtig Geld und Aufwand kosten wie die Webseiten für das Online-Banking oder Einkaufsportale. Würde wir für jede Webseite das gleiche Passwort verwenden, müssten wir uns sicher sein, dass jeder Seite das ihr anvertraute Passwort richtig – und damit sicher – verwahrt. Angesichts der gerade in den letzter Zeit gehäuften öffentlich gewordenen Passwortleaks selbst von großen Webseiten wie Yahoo, Twitter oder Dropbox lässt sich eigentlich nur eine Schlussfolgerung ziehen: vertraue keiner Webseite, die du nicht selber programmiert hast.
?
Warum sollte man Webseiten nicht generell vertrauen, dass sie das Passwort sicher verwahren? Was kann schief gehen, wenn wir unser Passwort in das Passwortfeld einer Webseite eingeben? Nur weil das Formularfeld, in das wir unser Passwort eingeben, Sternchen statt der tatsächlich eingegebene Zeichen anzeigt, heißt das noch lange nicht, dass das Passwort nicht sehr einfach abgegriffen werden kann. Mögliche kritische Implementierungsfehler sind:
1. Die Kommunikation mit der Webseite läuft über eine ungesicherte http statt https Verbindung. Wenn hier beim Klick auf den Login-Button tatsächlich das gerade in das Formularfeld eingetragene Passwort übertragen wird, kann wirklich jeder, der Zugriff auf einen Computer im gleichen Netzwerk oder auf einen der Rechner über die die Verbindung mit der Webseite läuft, das Passwort einfach im Klartext lesen. Es hilft auch wenig, wenn das Passwort zwar nicht im Klartext übertragen wird, sondern nur ein zuvor im eigenen Browser aus dem Passwort errechneter Hash-Wert (eine Hash-Funktion liefert für ein Passwort immer den gleichen Hash-Wert, der, von der Webseite gespeichert, statt des Klartextpassworts auf Korrektheit überprüft wird. Aus dem Hash-Wert lässt sich, bei aktuellen Algorithmen, nicht das Klartextpasswort zurückrechnen). Auch wenn der Angreifer hier also nicht ohne weiteres an das ursprüngliche Passwort herankommt, kann er sich natürlich ohne Probleme mit dem abgegriffenen Hash-Wert selbst jederzeit auf der aufgerufenen Webseite einloggen.
2. Das Passwort wird von der Webseite im Klartext und nicht als Hash-Wert in einer Datenbank gespeichert. Um das Passwort auf Korrektheit zu überprüfen, muss die Webseite dieses oder einen davon abhängigen Wert irgendwo speichern. Wenn diese Speicherung im Klartext erfolgt und nicht als Hash-Wert, kann bei einem unerlaubten Zugriff auf die Datenbank der Webseite jeder die Passwörter aller Nutzer lesen.
3. Die Webseite benutzt veraltete Hash-Algorithmen bzw. verwendet kein „Salt and Pepper“. Da jedem Passwort immer der gleiche Hash-Wert zugeteilt wird (sonst könnte dieser ja nicht anstelle des Passworts zum Vergleich der Korrektheit benutzt werden), können Angreifer Hash-Werte vorberechnen. Für ein mit dem veralteten und nicht sicheren Hash-Algorithmus md5 gehashtes Passwort namens „Passwort“ würde als Hash-Wert „3e45af4ca27ea2b03fc6183af40ea112“ in der Datenbank stehen. Der Angreifer könnte jetzt einfach alle häufig genutzten Passwörter selber hashen und dann alle diese Hash-Werte mit den aus der Datenbank geklauten Hash-Passwörtern vergleichen. So käme der Angreifer an potenzielle Klartextpasswörter die er dann auch bei anderen Webseiten zum Einloggen ausprobieren könnte. Dem kann eine Webseite entgegenwirken, indem sie nicht nur das Passwort hasht, sondern etwas „Salz und Pfeffer“ hinzufügt. Im Prinzip geht es dabei darum, dass von der Webseite an das Klartextpasswort eine beliebige Zeichenfolge vor dem Hashen angehängt wird. Bei Nutzung des Salt „Salz“ würde also im obigen Beispiel „PasswortSalz“ gehasht: „fedb6be7f8919b4f90a0b500d613fe69“. Jetzt könnte das ursprüngliche Passwort „Passwort“ nicht mehr einfach durch nachschlagen in einer vorberechneten Tabelle nachgeschlagen werden, da in dieser ja nur der Hash-Wert von „Passwort“ ohne Salz stehen würde.
In der Konsequenz sollte man für jeden Login ein eigenes gutes Passwort benutzen. Dabei sollten sich die verschiedenen guten Passwörter aber nicht trivial voneinander unterscheiden. Und damit wird es natürlich schwierig, alle Passwörter im „griffbereit“ im Kopf zu haben.
!
Warum es nicht gut ist, nur leichte Abwandlungen eines guten Passworts zu benutzen, ergibt sich aus den obigen Anmerkungen im Kasten. Wer aus dem guten Passwort „H4r7eQ1n!“ für die gehackte Seite Abcd.ef das Passwort „H4r7eQ1n!ABCD“ abgeleitet hat, hat ein echtes Problem, wenn das Passwort im Klartext gespeichert war und das Passwort für Amazon dem Schema entsprechend „H4r7eQ1n!Amazon“ heißt. Aus dem gleichen Grund verbietet es sich genauso, regelmäßig zu ändernde Passwörter einfach nur hoch zu zählen und statt „Passwort1“ einfache „Passwort2“ zu nutzen.
Rezept für gute Passwörter:
Mindestens 10, besser 12+ Zeichen lang
Beinhalten Großbuchstaben
Beinhalten Kleinbuchstaben
Beinhalten Zahlen
Beinhalten Sonderzeichen
Ein Passwort für jeden Dienst
Keine trivialen Unterschiede
Passwörter nicht „durchnummerieren“
Wann ein gutes Passwort doch ein gutes Passwort
Wer meint, dass sie ja niemand so viele gute Passwörter merken kann, hat wohl normalerweise recht. Daher der praktikable Tipp: nutzt einen Passwortmanager. Dann braucht man sich nur noch ein gutes Passwort, das Masterpasswort, merken, um damit alle anderen Passwörter aus dem Passwortmanager abrufen zu können. Dafür gibt es unterschiedliche Lösungen. Ja nach Nutzungsart können sich kostenpflichtige Angebote (etwa LastPass oder 1Password) oder kostenlose Angebote eignen. Wer Mozilla Firefox benutzen, kann etwa Mozillas Sync Funktion (Achtung, die Abfrage eines Masterpassworts muss extra eingestellt werden) nutzen.
Wer ohnehin bei Safari als macOS Standardbrowser bleibt, kann ohne weiteres die Arbeit dem Schlüsselbund von macOS überlassen. Dieser lässt sich zusätzlich über iCloud problemlos mit anderen Mac‘s und iOS-Devices abgeglichen. Die Passwörter werden dabei verschlüsselt und für Apple nicht lesbar auf deren Servern gespeichert. Sollte man Apple hier nicht vertrauen, sollte man vielleicht über den Kauf eines Rechners für GNU/Linux nachdenken, denn auf dem Mac läuft nun mal ein Apple Betriebssystem, das ohnehin alle Daten abgreifen könnte, wenn es das wollte (was natürlich genauso für Microsoft Windows gilt).
Safari und der Mac Schlüsselbund können aber nicht nur alle Passwörter speichern und automatisch einfügen. Bei vielen Webseiten bietet Safari bei der Neuvergabe von Passworten automatisch ein zufällig generiertes Passwort an, dass mit nur einem Klick übernommen werden kann (manchmal wird auch rechts im Passwortfeld ein kleiner Schlüssel mit Pfeil angezeigt, auf den man klicken und dann „neues Passwort vorschlagen“ auswählen kann). So kommt man gar nicht erst in Versuchung, überall das gleiche oder nur ein schwach abgeändertes Passwort zu verwenden. Die von Safari vorgeschlagenen Passwörter bestehen aus Groß-, Kleinbuchstaben, Zahlen und Bindestrichen und sehen so ähnlich aus:
Ab1-c2D-3Ef-G4h
Aber genug der Ausführungen zu Webseiten. Eigentlich geht es in diesem Kapitel ja um die Absicherung der Anmeldung am Mac.
Wie im vorhergehenden Abschnitt beschrieben, gibt es keine absolute Sicherheit. Das Ziel ist ein individuell „richtiges“, angemessenes Absicherungsniveau. Um dieses erreichen zu können, steht vor dem Umsetzen von Sicherungsmaßnahmen zunächst eine Risikoanalyse. Diese Artikelserie richtet sich explizit an Einsteiger und soll bei der grundsätzlichen Absicherung des Mac helfen. Damit kann der Inhalt und die Sicherheitstipps hier natürlich nur genereller Natur sein. Sie richten sich an den „normalen“ Nutzer und basieren gerade nicht auf einer individuellen Risikoanalyse. Ziel dieser Artikelserie ist vielmehr eine Grundsicherung. Nichts desto trotz stellt sich die Frage, wie es um das Risiko des „Normalnutzers“ bestellt ist.
Risikoanalyse
Eine Risikoanalyse ist notwendig, um das erforderliche Schutzniveau abschätzen zu können. Die möglichen Bedrohungsszenarien unterscheiden sich erheblich von Nutzer zu Nutzer. Wer als Dissidentin in einem autoritären Regime, regimekritische Texte auf dem Notebook verfasst und verwaltet, unterliegt nicht nur einer größeren Gefahr, tatsächlich von staatlichen Stellen überwacht und ausspioniert zu werden, als „normale“ Nutzerinnen (obwohl man nach den Snowden Veröffentlichungen natürlich davon ausgehen muss, dass eigentlich so ziemlich jede/r überwacht wird). Gleichzeitig drohen im Fall des Dissidenten aber erheblich ernsthaftere Konsequenzen, bis hin zum Tod, als der typische Mac-Nutzer sie wahrscheinlich zu fürchten hat. In einem solchen Fall ist natürlich eine ganz andere Form der Absicherung angemessen.
Aber die Bedrohungslage unterscheidet sich auch zwischen „normalen“ Nutzern. Es macht allein schon einen Unterschied, ob der Mac nur privat oder auch beruflich genutzt wird. Ebenso macht es einen Unterschied, ob wir über einen stationären Mac oder ein MacBook sprechen. Aus der tatsächlichen Verwendung des Mac ergeben sich also unterschiedliche Gefahren und Bedrohungen, denen man sich als Nutzer gegenübersieht. Diese Gefahren, gilt es zu kennen. Nur so kann jeder entscheiden, ob und wie, das heißt, mit welchem Aufwand (und Kosten), er sich gegen diese Gefahren schützen will. Das ist letztlich nichts anderes, als eine Risikoanalyse durchzuführen.
Bedrohungsszenarien
Was sind aber jetzt die realistischen Bedrohungen und Gefahren, denen sich ein „normaler“ Nutzer gegenübersieht?
Zunächst sind hier Gefahren zu benennen, die gänzlich ohne die Beteiligung von Dritten bestehen. Dazu gehören beispielsweise:
Geräteverlust: Ein MacBook kann, wie auch externe Festplatten oder USB-Sticks, unterwegs verloren gehen. Ein Geräteverlust bedeutet in diesem Fall zuerst einmal einen Datenverlust. Dieser kann auch entstehen, durch
Geräteausfall: Nicht nur, dass es schon die eine oder andere Festplatte gegeben haben soll, die just in dem Moment, in dem noch schnell die fertige Bachelor-/Master-/Doktorarbeit ausgedruckt werden sollte, den Geist aufgab. Mechanische Festplatten können schon beim Herunterfallen des Gerätes kaputt gehen. Und ein Wohnungsbrand kann gleichzeitig MacBook und eventuell vorhandene Sicherungsmedien zerstören.
Bedrohungen die von Dritten ausgehen sind unter anderem:
Diebstahl: Bei einem Einbruch ist hier zwar auch der stationäre Mac gefährdet, viel öfter dürfte Diebstahl aber für MacBooks-Nutzer eine Rolle spiele. Auch hier kommt zum Geräteverlust der Datenverlust als Risiko hinzu.
Unbefugter Zugriff: Es bestehen unterschiedliche Möglichkeiten, wie Fremde unbefugt auf die eigenen Daten zugreifen können. Problematisch ist nicht nur die Verbindung des Mac’s mit einem Netzwerk. Auch ein physischerZugriff auf den Rechner, etwa wenn der Arbeitsplatz kurz verlassen wird, ist möglich.
Viren: Gibt es prinzipiell auch für macOS, sind aber verglichen mit Windows kaum ein Problem.
Trojaner: Hier gilt ähnliches wie bei Viren. Das Risiko eines Trojanerbefalls ist relativ gering, bei geschäftlicher Nutzung aber als Spionagetool in der Konsequenz ungleich gefährlicher.
Ransomware: Verschlüsselungs- oder Erpressungstrojaner sind auch vornehmlich für Windowsnutzer ein Problem. Diese Programme verschlüsseln alle Daten des Nutzers. Erst gegen die Zahlung eines Lösegeldes (etwa in Bitcoin) wird (im besten Fall) das Passwort zum Entschlüsseln mitgeteilt. Neben dem finanziellen Risiko bleibt das Risiko des Datenverlustes auch bei Zahlung bestehen, wenn etwa kein Passwort herausgegeben wird oder sich nicht alle Daten wieder entschlüsseln lassen.
Kein Risiko für Mac-Nutzer?
Mac-Besitzer haben per se einen Vorteil gegenüber Nutzern von PCs mit Windows – und das, obwohl das oft gelesene (Vor)Urteil, dass macOS aufgrund seiner Unix-Abstammung grundlegend sicherer sei als Windows, so nicht richtig ist. Der große Vorteil von macOS besteht vielmehr darin, wie im Übrigen auch einer von GNU/Linux, die relativ geringe Verbreitung des Betriebssystems. Der Marktanteil von macOS ist schlicht nicht groß genug, als das es sich für einen relevanten Teil der Computerkriminelle lohnen würde, den Aufwand für die Programmierung von Schadsoftware für macOS zu betreiben.
Alle Ein- und Angriffe in und auf Computersysteme, von Industriespionage und nachrichtendienstlicher Tätigkeit einmal abgesehen, richten sich normalerweise unspezifisch gegen eine möglichst große Zahl von Nutzern. Sie sind also nicht gezielt auf einen individuellen Computer oder seinen Besitzer gerichtet. Nur durch einen massenhaften automatisierten Angriff auf viele System lohnen sich Aufwand und Risiko, da nur ein geringer Anteil der Angriffe letztlich erfolgreich ist. Damit sind die Nutzer von Windows ein wesentlich erträglicheres Ziel für Angriffe als macOS Nutzer.
Trotzdem sollte man die Hände nicht in den Schoß legen (oder in die Taschen stecken) und sich tatenlos den durchaus vorhandene Risiken aussetzen. Gerade dann nicht, wenn man die Wahrscheinlichkeit für ihr Eintreffen oder die von ihnen verursachten Kosten mit relativ wenig Aufwand verringern kann. Also machen wir uns ans Werk.
„Ich kann dir nur die Tür zeigen – hindurchgehen musst du allein.“
Morpheus (Matrix)
