You are here

Computersicherheit

openSUSE 13.1 mit UEFI und Vollverschlüsselung auf openSUSE Leap 42.1 migrieren

Da der offizielle Support für openSUSE 13.1 am 5.1.2015 endet war es höchste Zeit meine Workstation mal auf openSUSE Leap 42.1 zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig.

Da der offizielle Support für openSUSE 13.1 am 5.1.2015 endet war es höchste Zeit meine Workstation mal auf openSUSE Leap 42.1 zu migrieren. Solche Migrationen mache ich mit SUSE schon seit es noch einstellige Versionsnummern hatte. Diesmal war die Migration allerdings ungewohnt holprig. Meine Workstation nutzt ein vermutlich nicht ganz gewöhnliches Set-Up. OpenSUSE ist parallel zu Windows 10 installiert, und beides wird per UEFI Secure Boot gestartet. Den UEFI-Boot habe ich dann auch gleich mal genutzt um mir mit Anlauf selbst in den Fuß zu schießen: OpenSUSE unterstützt es zwar schon seit Ewigkeiten eine Upgrade aus dem laufenden System durchzuführen, da es mir aber immer als der sauberere Ansatz vorkam – und sicher auch aus Nostalgie – mache ich solche Updates immer noch ganz altmodisch per DVD. Allerdings bietet mein ASUS-EFI in der Bootmedienauswahl das Blu-Ray-Laufwerk immer zwei mal an. Einmal ganz oben in der Liste als BIOS-Boot, und einmal ganz unten als echten UEFI-Boot. Natürlich habe ich – wollte ja nur schnell mal das Update starten – den oberen Eintrag genommen und mein EFI-System dann mal schön im BIOS-Modus aktualisiert. Leider fängt openSUSE diesen PEBKAC aktuell nicht ab und hat mir dann mal schön die Bootloaderkonfiguration kaputtgeschrieben. Zum Glück ist der Fehler – wenn man erst mal verstanden hat, was man falsch gemacht hat – trivial zu korrigieren. Einfach nochmal das Upgrade im UEFI-Modus starten, von Leap 42.1 auf Leap 42.1 aktualisieren (ja, das geht). Danach ist der Bootloader korrekt geschrieben. Leider tritt einem beim Versuch die DVD mit openSUSE Leap 42.1 per UEFI zu booten Bug 950569 in den Weg. Der Bootcode auf der DVD ist nicht korrekt signiert, was auf meinem System zufolge hat, dass der Bildschirm einfach schwarz bleibt. Das Problem lässt sich lösen, indem man Secure Boot im BIOS temporär deaktiviert. Zum Glück installiert openSUSE Leap 42.1 bei der Installation bzw. dem Upgrade bereits die aktuellsten Version aller Pakete. So bleibt Nachzüglern wie mir nicht nur die Updateorgie nach der Installation erspart, sondern es landet auch korrekt signierter Code auf der Platte, so dass Secure Boot nach dem Update gleich wieder aktiviert werden kann. Ein weiteres Problem bei openSUSE Leap 42.1 ist, dass es zumindest bei Upgrades nicht korrekt mit verschlüsselten Root-Partitionen umgehen kann. Beim Boot „vergisst“ das System nach der Passphrase zu fragen. Wechselt man durch die Konsolen findet zeigt sich folgende Fehlermeldung: Failed to start systemd-cryptsetup@luks<codierte ID>.service:. Ich habe die ID in der Fehlermeldung mal gekürzt ;). Wie in Bug 904987 lässt sich das Problem lösen, indem man dem Kernel explizit sagt, dass er die entsprechende Partition entschlüsseln soll, indem man ihm die ID des LUKS-Containers per Kernelparameter rd.luks.uuid mitgibt. Die ID des LUKS-Containers lässt sich mit Cryptsetup herausfinden. Liegt die Root-Partition z.B. auf /dev/sda2, so lässt sich die ID wie folgt herausfinden. > cryptsetup luksUUID /dev/sda207246af2-915a-bd54-6a5s-6a5c35d15f45 Der Bootparameter muss dann in /etc/sysconfig/bootloader zum Wert DEFAULT_APPEND hinzugefügt werden. Dieser sollte dann z.B. wie folgt aussehen: DEFAULT_APPEND="splash=silent quiet showopts rd.luks.uuid=07246af2-915a-bd54-6a5s-6a5c35d15f45" Anschließend einmal den Bootloader neu schreiben lassen und das System fragt wieder nach dem Passwort. Idealerweise wird dieser Workaround schon vor dem Update implementiert. Nicht, weil dann der Bootloader sowieso neu geschrieben wird, sondern weil man sich dann das Herumgewurschtel mit einem Recovery-System spart.

Threema

Nach dem NSA-Skandal scheint sich jetzt mit Threema endlich mal ein Messanger fürs Handy zu implementieren, welcher aus Datenschutzsicht nicht eine komplette Katastrophe ist. Anders als WhatsApp, Google Hangouts, Facebook und SMS läuft hier die Kommunikation nicht unverschlüsselt durchs Netz, sondern wird für den Empfänger verschlüsselt.

Nach dem NSA-Skandal scheint sich jetzt mit Threema endlich mal ein Messanger fürs Handy zu implementieren, welcher aus Datenschutzsicht nicht eine komplette Katastrophe ist. Anders als WhatsApp, Google Hangouts, Facebook und SMS läuft hier die Kommunikation nicht unverschlüsselt durchs Netz, sondern wird für den Empfänger verschlüsselt. Da Threema auch nur dann ein beruhigendes Grün für den Kontakt anzeigt, wenn der Schlüssel des Kommunikationspartners einmal per QR-Code-Scan verifiziert wurde, trägt die App auch anders als solche welche die Schlüssel zentral verteilen nicht in trügerischer Sicherheit. Dennoch hat natürlich auch Threema Probleme. Da der Quellcode nicht offen liegt ist es unmöglich sicherzustellen, dass der geheime Schlüssel nicht doch irgendwie nach außen geleaked wird. Wichtiger ist aber, dass die Verkehrsdaten, oft auch Metadaten genannt, weiterhin an einer zentralen Stelle anfallen. Es reicht also immer noch eine Stelle anzugreifen um an diese Daten zu kommen. Als Alternative zu Whatsapp, Google Hangouts und Konsorten ist Threema definitiv ein Schritt in die richtige Richtung. Langfristig benötigt es aber eine ähnlich komfortable Lösung welche auf offenen Standards beruht, so dass eine komplett vertrauenswürdige Kette aufgebaut werden kann. Eine freie Implementierung würde es erlauben nach Hintertüren zu suchen. Insbesondere muss aber die Serverstruktur dezentralisiert werden, so dass nicht alle Verkehrsdaten an einem Punkt anfallen. Betreibt man einen eigenen Server, so müssen Nachrichten zu anderen Nutzen desselben die eigene Infrastruktur nie verlassen, und ein aufgemachter Server würde nur Verkehrsdaten von Nachrichten welche über diesen liefen betreffen, aber nicht die dritter. Im Prinzip gibt es Jabber und PGP ja auch schon die zugrundeliegende Infrastruktur für eine solche Lösung. Allerdings muss hier noch am Bedienkomfort gearbeitet werden. So bin ich beispielsweise mit den bisherigen Möglichkeiten Jabber-Nachrichten aufs Handy zu schieben unzufrieden, und auch die einfache Validierung des Kommunkationsschlüssels via QR-Code habe ich in einem solchen Setup bisher noch nicht gesehen. Ich bin natürlich auch per Threema zu erreichen. Fragt mich einfach nach meiner ID. Meine alte ID YYYZBANM solltet ihr bitte nicht mehr verwenden. Nach einem kuriosen Androidfehler habe ich diese verloren und hatte leider auch kein Backup. Selbst mit letzterem würde ich ihr allerdings auch nicht mehr trauen.

USB-Stick als Schlüssel für die Festplattenverschlüsselung

OpenSUSE bietet seit einigen Versionen die Möglichkeit bei der Installation die Festplatte komplett zu Verschlüsseln. In Anbetracht der großen Menge an Daten macht dies heutzutage nicht nur bei Laptops, sondern auch bei stationären Rechnern Sinn. Wird der Rechner aber als Server — ohne Tastatur und Monitor — betrieben stört hierbei allerdings die notwendige Passworteingabe beim Starten des Rechners.

Rootkits und Rootkit-Erkennung

Im Mai 2006 hielt ich im Seminar Computersicherheit für Paranoiker diesen Vortrag, in dem ich zunächst über die Klassifikation und Funktionsweise von Rootkits sprach um dann Abwehrstrategien und Software zur Erkennung von Rootkits vorzustellen.

Zum Herunterladen:

Sollten dir die Artikel auf dieser Seite gefallen und du Bitcoin für ein interessantes Experiment halten, so schicke doch eine kleine Spende an 14pQyjx5EFQCwPBkXMTz5nTcfPsnjHmWqA.

Subscribe to RSS - Computersicherheit