Tag Archives: DSGVO

Laptop – SSD mit dm-crypt/Luks – Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen

Posted on by

Eine Verschlüsselung von Daten auf Laptops ist in Zeiten der DSGVO Pflicht, da Laptops verloren gehen oder gestohlen werden können. Mein in die Jahre gekommener Laptop benötigt eh’ eine neue SSD. Zudem muss ich auf Opensuse Leap 15 wechseln. Gute Anlässe, einmal die Verschlüsselung von Betriebssystem- und Daten-Partitionen unter Opensuse Leap 15 zu testen.

Die meisten Linux-Profis setzen die Kombination “dm-crypt/LUKS” zur Verschlüsselung von Partitionen oder Volumes ein. Dabei spielen verschiedene Parameter eine Rolle, für die unter Opensuse normalerweise der YaST-basierte Partitioner Default-Werte vorgibt.
Ich nahm mir allerdings die Freiheit, die LUKS-Partitionen selbst mit eigener Parameter-Setzung vorzubereiten. Danach wurde das ganze Unternehmen unerwartet abenteuerlich und es taten sich etliche Falltüren auf. Es gab u.a. Probleme mit dem SuSE-Installer; nicht mehr bootfähige Systeme, nicht funktionales Kryptographie-Setup, Dracut-Probleme sind nur einige Stichworte. Man glaubt, man hat eine Lösung und schon zieht ein Neuinstallieren des Bootloaders über YaST alles wieder in den Abgrund.

Ich denke, das Thema “Voll-Verschlüsselung eines Linux-Laptops” ist einige Blog-Posts wert … Viele der angestellten Überlegungen und Vorgehensweisen können auch auf Desktops oder einfache Server übertragen werden.

Der ganze Themenkreis erfordert neben praktischen Installations- und Konfigurations-Schritten einige “theoretische” Vorüberlegungen. Verschlüsselung allein bietet keine hinreichende Sicherheit … man muss u.a. auch an Konsequenzen für den praktischen Betrieb des Systems denken – besonders im falle von Laptops. Zudem kann man sehr verschiedene Wege bzgl. des System-Layouts einschlagen. Einige wichtige unter vielen Variationsmöglichkeiten ergeben sich etwa aus der Beantwortung folgender fragen:

  • Vollverschlüsselung unter Einschluss des root-Filesystems oder Einsatz von Daten-Containern?
  • Vollverschlüsselung des Hosts oder nur darunter virtualisierter Systeme?
  • LVM on LUKS oder LUKS on LVM?

Die entsprechende System-Konfiguration erfordert meist Entscheidungen im Vorfeld der praktischen Installation. Ich beginne die Artikelserie deshalb it einer Reihe grundsätzlicher Überlegungen, die praktische Auswirkungen auf die Sicherheit der Daten haben.

Um eine ständige Unterscheidung zwischen LVM-Volumes und Partitionen zu vermeiden, spreche ich nachfolgend generell von “Volumes“. An den Stellen, wo die Unterscheidung wichtig wird, werde ich sie explizit treffen. “Betriebssystem” kürze ich im Weiteren mit OS ab. Das root-Filesystem kürze ich mit “/”-FS ab.

Ich setze ein grundlegendes Verständnis der Arbeitsweise von LUKS voraus. Für Grundlagen können Interessierte einen Blick in frühere Blog-Posts werfen; dort sind auch Links zu weiterführender Literatur im Internet angegeben:
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – II

Unterscheidung Vollverschlüsselung – Teilverschlüsselung

Wir unterscheiden im Folgenden zwischen Voll- und Teil-Verschlüsselung. Unter einer Voll-Verschlüsselung verstehe ich einen Ansatz, in dem

  • sowohl das Volume für das OS, mit dem auf die zu schützenden Daten zugegriffen wird,
  • als auch separate Volumes zur Lagerung der zu schützenden Daten,
  • als
    auch Swap-Volumes

verschlüsselt werden. Bei Abweichungen spreche ich von Teil-Verschlüsselung.

Continue reading →

DSGVO – ja, aber? Ja!

Posted on by

Einige meiner Bekannte betreuen Webseiten von Kunden. Alle berichten von Nervosität bis Panik im Zusammenhang mit der DSGVO. Vor allem kleine Unternehmen schienen mit den Ansprüchen der DSGVO überfordert. Hinzu kamen aber auch externe Berater, deren Motivation für etliche aufwands- und kostenträchtige Ratschläge man wirklich hinterfragen muss. Wie die letzten Artikel in diesem Blog zeigen, bin ich auch selbst als Freelancer von Konsequenzen der DSGVO betroffen. U.a. durch Pauschalverträge, die die DSGVO zum Anlass nehmen, Datenschutz- und Datensicherheitsrisiken auf Externe zu verlagern.

Die DSGVO ist aus solchen Gründen gerade bei Klein- und Kleinst-Unternehmen negativ belastet, weil man insgesamt erhebliche Anstrengungen und Ressourcen in die Umsetzung mancher kleinkariert wirkender und auch strafbewehrter Regeln investieren muss. Es gibt im Lande eine negative Stimmung gegenüber der DSGVO. Auch wir selbst haben geflucht und fluchen. Vergessen wird dabei, dass die DSGVO nur Regeln explizit mit Sanktionen belegt, die bereits vorher galten.

Interessant war in diesem Zusammenhang ein Streitgespräch zwischen einem der Väter der EU GDPR, nämlich Jan Philipp Albrecht, und Sascha Lobo im Podcast des letzteren; s. https://soundcloud.com/user-728223693/albrecht-lobo-und-das-dsgvo. Lobo hebt im Gespräch auf die übertriebene Regulierungssucht der Deutschen ab, die seiner Meinung nach noch Abmahnungen zeitigen würden, und markierte die erheblichen technischen Anstrengungen, die u.a. Blogger, Freelancer etc. belasten oder überfordern würden. Ein interessanter Punkt in der Debatte kam, als Albrecht schließlich auf den eigentlichen Kern der Sache einschwenkte. Ich gebe das verkürzt wie folgt wieder:

Auch Kleinstunternehmer und Privatpersonen müssten sich endlich mal Gedanken dazu machen, an welcher Stelle sie durch welche Tools der unkontrollierten Sammlung und Verwertung von Informationen, die beim Besuch Dritter auf den selbst betriebenen Webseiten/Blogs anfallen, durch Google, Facebook und Co. Vorschub leisten.

Zumindest beim bequemen Betrieb einer eigenen Site unter dem Dach von Facebook muss man diese Feststellung nicht weiter erläutern. Es scheint bereits aufgrund der Gescchäftsausrichtung von Facebook klar, dass der Traffic auf solchen Seiten überwacht wird und direkt dem Profiling sowohl der Site-Betreiber als auch der Besucher der Site durch Facebook dient. Facebook selbst macht daraus in seinen Nutzungsbedingungen ja auch keinen Hehl. Das ganze System Facebook lebt offenkundig vom Profiling seiner Nutzer und der Verknüpfung aller erreichbaren Daten zum Nutzerumfeld. Weniger offenkundig ist das u.U. bei Google Analytics. Hier tritt man ja selbst als Profiteur der Sammlung von Daten zu Nutzern und deren Verhalten auf eigenen Web-Präsenzen auf. Dass man damit gleichzeitig aber auch dem Datensammeln von Google selbst Vorschub leistet, verdrängt man dabei gerne.

Aber es gibt noch andere undurchsichtige Bereiche des heutigen Betriebs von Web-Sites: Überprüft man etwa nicht, wie WordPress-Plugins tatsächlich operieren, so unterstützt der eine oder andere Blogger unbeabsichtigt das Datensammeln durch Plugins, die z.T. unter dem Deckmantel von Sicherheit Daten über Besucher und Kommentatoren irgendwohin ins Ausland befördern.

Was habe ich im Zuge der DSGVO selbst gelernt?

Ich habe mich beim Fluchen über so manche Konsequenz der DSGVO selbst gefragt, wo ich dabei eigentlich stehe. Welche der im Lobo-Albrecht-Dialog ausgetauschten Argumente haben für mich ein großes Gewicht? Mir sind dabei mehrere Dinge aufgefallen:

  1. Ich habe angefangen, mich intensiver mit meiner eigenen “Schlamperei” bei der Erstellung von Web-Code auseinander zu setzen. So nutzt mein eigenes Framework Cookies in fragwürdiger, nämlich letztlich unnötiger Weise für einfache
    CMS-basierte Webseiten. Ich hatte bei der Entwicklung die notwendige Nutzung von Cookies für den webbasierten Pflegeprozess und zugehörige Pflegeseiten “der Einfachheit halber” gleich mal pauschal auf die Seitengeneratoren ausgedehnt, ohne die Notwendigkeit an dieser Stelle genauer zu hinterfragen.
  2. Ich habe zum ersten Mal richtig darüber nachgedacht, was eigentlich der Einsatz von Google Analytics bedeutet, wie die zugehörigen Verwertungsklauseln aussehen und welche Verantwortung ich in diesem Prozess für Besucher z.B. dieses Blogs habe. Ja, Google Analytics bietet viel – aber haben wir als Blogger und Webseiten-Betreiber eigentlich das Recht, das Sammeln von Daten durch Google zum Verhalten Dritter (!) ohne Vorwarnung zu veranlassen? Klare Antwort: Nein, das haben wir nicht.
  3. Ich habe mich intensiv mit den Nutzungsbestimmungen von Facebook und Google auseinandergesetzt – und habe leider meine schlimmsten Befürchtungen noch übertroffen gefunden.
  4. Ich habe mal nachgesehen, ob und wie Web-Hosting-Provider (wie etwa 1&1 oder Strato) konkret Log-Daten für gehostete Web-Sites bereitstellen und mich gefragt, in wie weit eine intelligente Auswertung in Kombination mit einer eigenen für den Nutzer verborgenen Datenerhebung über Cookies einen Ansatz von Mini-Profiling zu bestimmten Besuchern ermöglichen würde.
  5. Ich habe mir aufgrund der Strafbewehrung ernsthaft Gedanken darüber gemacht, welches Sicherheitsniveau ich eigentlich im Datenaustausch mit befreundeten Unternehmen leisten und bereitstellen kann. Meine Antworten darauf sind noch unbefriedigend; aber das ist ein aus meiner Sicht wichtiger Prozess, der letztlich den bewussteren und besseren Umgang mit Datensicherheit und Datenschutz auf beiden Seiten fördern wird.

Interessant ist, dass man sich bei einer genaueren Analyse der Anforderungen der DSGVO dem Kern der Frage nähert, wie man heute eigentlich Daten, die einem anvertraut werden, gegenüber dem Zugriff Unbefugter schützen kann. Leute, genau das ist der Kern der DSGVO: Verantwortung für den Schutz von bewusst oder unbewusst anvertrauten Daten Dritter.

Als sicherheitsbewußter Linuxer kommt man dabei schnell auf Grundsätzliches: Was geschieht, wenn ein Einbruch in die eigenen Räumlichkeiten erfolgt? Wie sicher sind dann die dir anvertrauten Daten dann noch? Müsste man hier nicht gerade auf externe Provider mit geschützten Rechenzentren zur Datenhaltung ausweichen?

Oder du wirst gehackt – wie sieht es dann aus? Oder: Dein Laptop mit einer SSD wird geklaut – wie sicher sind Daten, die dort in Krypto-Containern aufbewahrst? Oder: Kann man eigentlich die Nutzung von Betriebssystemen im Kontext geheinzuhaltender Daten verantworten, wenn doch der OS-Hersteller selbst in seinen Nutzungsbedingungen unverblümt ankündigt, mit dem System erfasste Daten auf allen elektronischen Nutzungsebenen aus der EU hinaus auf eigene Server zu befördern? Und hat man sich mal mit Penetration-Testing befasst, stellt sich die Frage, ob nicht Browser und Mail-Clients Haupeinfallstore für Schad-SW sind. Wie geht man mit dieser Erkenntnis eigentlich auf Systemen um, auf denen geheimzuhaltene Daten verarbeitet werden?

Und schon verschiebt sich die Perspektive dahin, wo sie im Zeitalter totaler Vernetzung auch hingehört: Wie bewahrt man eine elektronische Schutzsphäre, wenn Eindringlinge an jeder Ecke auf einen Fehler lauern oder du mit der Nutzung von Internet-Diensten den anbietenden Unternehmen direkte Zugangskanäle zu eigenen Daten und Daten Dritter eröffnest?

Leute, wir alle umgeben uns selbst laufend aus Bequemlichkeit freiwillig mit Systemen, die nicht zuletzt dazu dienen, Unternehmen mit Daten von uns, über uns und über unsere Kontaktpersonen zu versorgen. Diese Datenversorgung dient primär kommerziellen Interessen; aber das angehäufte Wissen über uns alle hat auch das Potential zur
Manipulation ganzer Bevölkerungsgruppen, wie wir im Zusammenhang mit Cambridge Analytics lernen durften.

Die Erstellung von Personenprofilen ist heute eine und in vielen Fällen gar die wichtigste Grundlage des Geschäfts von globalen IT-Konzernen. Man muss überhaupt nicht paranoid sein, um festzustellen, dass wir heute kontinuierliche Datenlieferanten sind – ohne einen Funken Kontrolle darüber zu haben, was genau mit den von uns bereitsgestellten Daten geschieht. Sprich: Durch die Nutzung von Android und zugehöriger Dienste etwa liefern wir laufend Daten – aber wir haben über die Verarbeitung keine Kontrolle. Gehen wir auf eine Website liefern wir eine ganze Menge Daten über uns ab – nicht nur unsere IP-Adresse. Sind verschlüsselte Cookies und Javascript im Spiel wissen wir nicht mehr, was über unsere Interaktion mit den Elementen einer Website erfasst und später verarbeitet wird. Speziell über Cookies werden wir jedenfalls potentiell als elektronische Identität identifizierbar. Diejenigen, de argumentieren, dass ein Serviceprovider im Internet nur genau die Daten verarbeiten kann, die wir ihm sowieso schon liefern, übersieht, dass u.a. erst über Cookies ein zusammenhängendes Bild entsteht – auch wenn wir uns nicht in Services einloggen.

IPs kann man mit Tor und VPN-Diensten ggf. verschleiern. Cookies muss man löschen oder automatisch löschen lassen. Für uns selbst können wir solche Entscheidungen treffen und entsprechende Einstellungen vornehmen – wenn wir denn überblicken, was abläuft. Aber wir tragen auch Verantwortung für die, die unsere Seiten besuchen und dabei z.B. in die Fänge von Google Analytics geraten.

Die DSGVO hat – trotz alle Schwächen ihrer Artikel, aus meiner Sicht nicht das Verbot des Umgangs mit personenbezogenen Daten zum Ziel, sondern das Aufstellen von “Warnschildern”, die Nutzer von Websites zumindest darauf hinweisen, wo sie Gefahr laufen, die Kontrolle über die von ihnen automatisch abgelieferten elektronischen Daten zu verlieren.

Der Kern der DSVO ist – bei aller Unvollkommenheit – dass wir uns darüber bewusst werden, dass wir im Umgang mit Diensten und eigenen Webpräsenzen dabei ggf. auch die Daten unserer Besucher weiterschleusen. Es ist ja in diesen Tagen viel von verabscheuenswürdigen Menschenschleusern zu hören. Wir sollten die DSGVO als Mittel begreifen, uns selbst zu fragen, wo und an welchen Stellen wir Daten zu Personen anhäufen und wie wir dazu beitragen, dass wir selbst zu fragwürdigen Datenschleusern im Interesse von Konzernen werden.

Insofern stehe ich auf der Seite von Jan Phillip Albrecht – und appelliere gleichzeitig für eine Verbesserung von Umsetzungsverordnungen für KMU. Insbesondere Blogger und Freelancer müssen gegenüber pauschalen Ansprüchen und einseitigen Anforderungen zur Risikominimierung und Risikoübernahme besser geschützt werden. Im Spiel Groß gegen Klein muss klar werden, dass die Großen ihren Teil zur Definition und Absicherung von Schutzniveaus für die Verarbeitung von personenbezogenen Daten nicht im Rahmen von Auftragsweiterverarbeitungs-Verträgen auf die Schultern der Kleinen abschieben dürfen. Zu den Großen rechne ich dabei übrigens auch den Staat.

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – III

Posted on by

Das Thema der vorhergehenden Artikel dieser Serie

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – I
DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – II

war eine allgemeine Diskussion darüber, warum man sich spätestens nach der DSGVO als Freelancer um Schutzmaßnahmen für E-Mails und um entsprechende vertragliche Vereinbarungen kümmern sollte. Eine reine Verschlüsselung von Transportwegen ist meiner Meinung nach nicht hinreichend; eine Lagerung von Mails in verschlüsselten Dateicontainern ist mit zu vielen Gefahrenpunkten verbunden. An einer Verschlüsselung von Volumes oder Partitionen der mail- und datei-verarbeitenden Systeme führt bei der Aufbewahrung von Mails und Anhängen kein Weg vorbei.

Als Freelancer steht man also womöglich vor der Aufgabe, sowohl den eigenen Mail-Server im LAN als auch Clients zur Mail- und Auftragsbearbeitung auf einen Unterbau aus verschlüsselte Partitionen umzustellen. Als Linuxer, die auf effiziente Ressourcennutzung bedacht sind, greifen wir zur Lösung auf virtualisierte Systeme zurück. Sprich: Meine Reaktion auf die von etlichen Kunden an mich gestellten pauschalen DSGVO-Anforderungen ist, die Auftragsverarbeitung für Kunden nur noch über besonders geschützte virtualisierte Systeme auf verschlüsselten Volumes durchzuführen. Der aufmerksame Leser hat sicher bemerkt, dass dieser Gedanke über die Mail-Verarbeitung hinaus weist.

Ich gehe kurz auf die Grenzen eines solchen Vorgehens ein; anschließend kümmern wir uns (endlich) um den Umzug eines bereits virtualisierten Mailservers auf eine verschlüsselte HD/SSD-Plattform.

Ist Volume- und Partitionsverschlüsselung einer Systeminstallation für Datensicherheit hinreichend?

Der Grundgedanke einer Partitions- oder Volume-Verschlüsselung ist: Nur verschlüsselte Daten sollen über verschiedene Zugriffsschichten Plattencontroller und Magnet- wie Flash-Speicher erreichen; eine vollständige Entschlüsselung von Dateien soll ausschließlich im RAM des Betriebssystems [OS] stattfinden. So schön das sein mag – es hilft nicht, wenn sich jemand bereits unbefugt auf dem System eingenistet hat und munter mitliest:

Die Verschlüsselung von Datenträgern, Partitionen oder Volumes bietet keinen Schutz auf gehackten Systemen. Sie bietet “nur” Schutz gegen unbefugten Zugriff im nicht-entschlüsseltem und/oder nicht-gemountetem Zustand der Volumes also z.B. im heruntergefahrenen Zustand des Systems.

Volume-Verschlüsselung ist also nur eine – wenn auch eine wichtige Maßnahme – zur Ausschaltung bestimmter Risiken. Auch das sollte aus meiner Sicht in einem Vertrag mit einem Auftraggeber festgehalten werden. Natürlich muss man sich u.a. auch um die Integrität der Virtualisierungshosts selbst kümmern – wir reden da aber über Systeme mit einer sehr begrenzten Anzahl an OS-Komponenten, die selbst keine direkte Verbindung zum Internet aufnehmen müssen.

Man erkennt, dass ein vernünftiger DSGVO-bezogener Vertrag zum Schutz personenbezogener und anderer geheim zu haltender Daten im Endeffekt wesentlich mehr beinhalten muss als nur Hinweise auf die Mailbehandlung und zugehörige Krypto-Verfahren für Transport und Lagerung. U.a. wird man eine Begrenzung ein- und aus-gehender Kommunikation von (virtualisierten) Servern und Clients, die bei der Auftragsbearbeitung eingesetzt werden, auf nur sehr wenige erlaubte Adressen im Internet
umsetzen müssen. Z.B. gilt: Völlig offene HTTP(S)- / SMTP(S) – / IMAP(S)- oder gar UDP-basierte Kanäle nach außen zu beliebigen Zieladressen sind im Zeitalter von strafbewehrten DSGVO-Verträgen überhaupt keine gute Idee! Zumindest nicht auf denjenigen Server- und Client-Systemen, auf denen man mit geheim zu haltenden Informationen operiert.

Virtuelle KVM/QEMU-Systeme auf verschlüsselten Volumes

Will man aus anderen grundlegenden Risikoerwägungen heraus nicht gleich alle “Volumes” auf allen Systemen im Haus-/Firmen-Netz verschlüsseln, bleibt nur der Weg über virtuelle Maschinen. Das betrifft dann Server- wie Client-Systeme gleichermaßen.

Im Besonderen Linux-E-Mail-Server sind dabei recht komplexe Systeme; eine Neuinstallation der vielen Einzel-Komponenten auf verschlüsselten Platten/Partitionen mag man sich daher wirklich ersparen. Es geht somit um System-Migration. Nachfolgend betrachte ich deshalb den Umzug eines (virtuellen) (E-Mail-) Servers auf einem KVM/QEMU-Host von unverschlüsselten Partitionen/Volumes auf verschlüsselte Volumes.

Ich gebe einige wichtige Befehle am Beispiel eines KVM/QEMU-Hosts unter Opensuse an. Das ist insofern nützlich, weil man hierfür mit YaST allein nicht auskommt und auf die Kommandozeile runter muss. Für einen Umzug voll ausgestatteter virtueller Clients (KVM/QEMU-Linux-Gastsysteme) zur Mail- und Auftragsbearbeitung gelten die Ausführungen dann analog.

Übrigens: Durch voll-virtualisierte KVM/QEMU-Systeme (für Mailserver und Clients),

  • die netzwerktechnisch weitgehend abgeschottet sind,
  • über die kein freier Internetzugang mit Browsern erlaubt ist
  • und die auch nur spezielle Mail-Accounts bedienen

kann man auch Hackern das Eindringen ein wenig erschweren!

Umzug eines physikalischen Linux-E-Mail-Servers in eine Virtualisierungsumgebung?

Das erste Problem besteht für manchen Leidensgenossen ggf. darin, einen schon vorhandenen physikalischen Server in eine Virtualisierungsumgebung zu bringen. Ehrlich gesagt, habe ich das noch nie selbst gemacht – und leider auch keine Zeit, das mal testweise auszuprobieren. Server für spezielle Aufgaben sind in meinem begrenzten Netz schon seit langem aus guten Gründen virtualisiert 🙂 .

Ich verweise für diese Aufgabe unter Linux deshalb auf sog. “P2V-Tools” (physical to virtual) und entsprechende Literatur. Die ganz unten aufgeführten Links geben hierzu Hinweise und Anleitungen. Für die nachfolgenden Schritte setze ich voraus, dass es bereits einen unter KVM/QEMU virtualisierten Server gibt – allerdings auf unverschlüsselten Partitionen/Volumes.

Vorüberlegung A: Wie sieht es mit der Performance und der Flexibilität auf verschlüsselten Plattformen aus?

Kann man sich auf seinen Systemen eigentlich eine Verschlüsselungsschicht zusätzlich zur Virtualisierung leisten? Das ist eine gute Frage, die man pauschal schlecht beantworten kann. Unter Linux kommt meist eine Kombination aus dm-crypt und LUKS zum Einsatz. Für Systeme mit Prozessoren der letzten 5 Jahre sieht es dabei hinsichtlich der reinen Krypto-Performance recht gut aus. Bei Virtualisierungshosts im Heim-Bereich (also eher mit begrenzten Ressourcen) sind aber ein paar zusätzliche Punkte zu beachten:

Schichtung
Hat man als Plattenunterbau Raid-Systeme im Einsatz, so stellt sich etwa die Frage der Schichtung der verschiedenen Zugriffsverfahren. Aus meiner Sicht ist folgende Reihenfolge für virtualisierte Serversysteme sinnvoll:

  • Plattenpartitionen für Raid   >>  
  • Raid 10   >>  
  • LVM  &
    nbsp;>>  
  • Volumes für KVM-Host-OS   >>  
  • dm-crypt/Luks für ein LVM-Raw-Volume   >>  
  • KVM/QEMU- und Gastsystem mit Zugriff auf das Raw-Volume als virtuelle Platte   >>  
  • LVM /Volumes (oder Partitionen) im Gastsystem   >>  
  • ext4-Filesysteme im Gastsystem

Verschlüsselung vor Raid scheint mir aus naheliegenden Gründen wenig performance-optimierend zu sein. Bzgl. der Reihenfolge “LVM <> dm-crypt/Luks” kann man streiten. Für die eine oder andere Wahl ist aus meiner Sicht dabei nicht die Performance sondern die Flexibilität ausschlaggebend. Bei der von mir gewählten Vorgehensweise verschlüsseln wir LVM-Raw-Volumes und nicht die sie tragenden Platten-Partitionen. Das erlaubt den Einsatz unterschiedlicher Krypto-Algorithmen und individueller Passphrases für die zu verschlüsselnden Volumes. Ein Nachteil ist, dass Größenänderungen der Volumes und Filesysteme danach nicht im Online-Betrieb möglich sind. Das stört im semi-professionellen Umfeld aber weniger (s.u.).
Siehe auch:
https://superuser.com/questions/1193290/best-order-of-raid-lvm-and-luks

Einsatz von virtio-Treiber
Für optimale Performance setze ich auf dem KVM-Host für die Vermittlung des Zugriffs des KVM-Gast-Systems auf die als virtuelle HDs bereitgestellten Volumes den QEMU-eigenen “VirtIO”-Treiber ein. Das sieht im “virt-manager” dann etwa so aus:

Übernahme der Verschlüsselung durch den Virtualisierungs-Host!
Man erkennt an der oben angegebenen Schichtung, dass ich die Verschlüsselung vollkommen dem Virtualisierungs-Host überlasse. Das erscheint mir sinnvoll, da ihm normalerweise mehr CPU-Cores als dem Gastsystem zur Verfügung stehen.

Ich kann jedenfalls mit diesem Setup auf einem schon sehr betagten Host mit einem KVM-Gast-Mail-Server, der nur um die 10 Mails pro Minute verarbeiten muss, sehr gut leben. (Der Host beherbergt dabei noch mehr aktive virtualisierte Systeme!) Der Unterschied zur Situation ohne Verschlüsselung ist gefühlt klein. Soviel zum Mail-Server und Performance.

Vorüberlegung B: Verschlüsselung eines (LVM-) “Raw”-Devices? Verzicht auf “qcow2”?

Gem. der oben propagierten Schichtung möchte ich das Gastsystem für meinen E-Mail-Server offenbar auf einem “Raw-Volume” der LVM-Schicht betreiben – also direkt auf einem LVM-Volume, das vom Gast-System aus formatiert wurde, und nicht auf einem “qcow2”-Loopback-File eines übergeordneten Filesystems des Hosts. Was spricht gegen ein Vorgehen mit “qcow2”-Dateien auf einem KVM-Host für einen virtualisierten Server?

“qcow2”-Dateien – mit internem Filesystem für den Gast – sind zwar hochflexibel einsetzbar – der Zugriff des Gastes auf seine virtuelle Platte erfolgt dabei aber immer über die Filesystem-Schicht des KVM/QEMU-Hosts UND über die Filesystem-Schicht des KVM-Gastes; das kostet Performance!

Der entsprechende Overhead ist nicht unerheblich – vor allem dann nicht, wenn der Server ggf. von mehreren Clients gleichzeitig genutzt werden soll. Die QEMU-Leute haben deshalb schon immer vorgesorgt und erlauben den direkten Zugriff eines Gastes auch auf nicht gemountete Volumes oder Partitionen des Hosts.

Der zweite
Grund entspringt ein wenig Sicherheitsüberlegungen.

Auf eine “qcow2”-Datei muss vom Gast-System über ein Mount-Verzeichnis des Host-Dateisystems aus zugegriffen werden. Die Datei liegt dann also bereits in einem unverschlüsselten Dateisystem, das auf einem Verzeichnis des Hosts gemountet ist, vor. Damit besteht aber auch – je nach Rechtesetzungen – die potentielle Gefahr, dass ihr Inhalt im laufenden Betrieb auch anderweitig ausgelesen werden kann (z.B. mit qemu-mount).

Die Situation ist im Fall von Raw-Devices komplexer. Das LVM-Volume wird nach einer Entsperrung des Verschlüsselungsverfahrens (s.u.) zwar wie eine Platte als Device unter “/dev/mapper” bereitgestellt. Aber dieses Device ist auch bei laufendem Gastsystem nicht direkt im Verzeichnisbaum des laufenden Host-Systems verankert. Ein evtl. durchgeführter Mountvorgang auf dem Host ist aber gar nicht so einfach zu verschleiern. Er wäre unnötig und würde bei entsprechender Protokollierung Alarmglocken auslösen.

Dennoch gilt:

Verschlüsselung von LVM-Volumes und Einsatz von qcow2 müssen bei hinreichenden Performance-Reserven kein Widerspruch sein.

Eine Schichtung

Raid 10   >>   LVM   >>   dm-crypt/Luks-Volume mit ext4   >>   Gemountetes LUKS/ext4-Volume mit qcow2-Datei auf dem KVM/QEMU-Host   >>   KVM/QEMU-Gast mit Zugriff auf qcow2-Loopback-Device   >>   LVM-Volumes des Gastsystems auf qcow2-Device   >>   ext4-Gast-Filesystem auf LVM-Volumes des Loop-Devices

funktioniert auf schnellen Hosts auch gut und bietet Verschlüsselung samt qcow2-Flexibilität. Ich nutze diese Variante u.a. auf Linux-Workstations für virtualisierte Clients.

Ich verfolge nachfolgend für unseren geplanten (Server-) Umzug aber die Variante ohne qcow2-Loopback-Device. Auch unser bisheriger virtualisierter (Mail-) Server mag bereits direkt auf einem unverschlüsselten Volume des Hosts verankert sein.

Vorüberlegung C: Größe des neuen kryptierten Raw-Volumes für den Umzug?

Wir können nun z.B. über den LVM-Volume-Manager von YaST oder über LVM-CLI-Kommandos (vgcreate, lvcreate) ein Raw-Volume kreieren, das nach seiner Verschlüsselung eine Kopie des alten Systems aufnehmen soll. Wie groß muss dieses logische Volume sein?

Naiverweise könnte man davon ausgehen, dass genau die Größe des alten Volumes (oder der alten Partition) in GiB hinreichend ist. Das wäre falsch. LUKS hinterlegt Informationen zum verschlüsselten Plattenplatz und zu 8 möglichen Passphrase-Keys in einem sog. “Verschlüsselungsheader“. Dieser Header benötigt zusätzlichen Platz jenseits der verschlüsselten Nutzlast. Der Platzbedarf ist zwar nicht groß (ca. 2 MB) – aber er ist eben zu berücksichtigen. Man muss dem neuen Volume etwas mehr Platz als dem alten spendieren. Ich vergebe meist gleich 1 GB extra.

Verschlüsselung des Raw-Volumes

In unserem Beispiel heiße das neue logische LVM-Volume für das virtuelle Plattendevice des KVM-Gastes “lvimap_hd0” und sei Teil einer LVM-Volume-Group “volgrp4”. Als Device erscheint dieses Volume dann unter “/dev/mapper” als “volgrp4-lvimap_hd0”. 

myserv:~ # la /dev/mapper 
...
lrwxrwxrwx  1 root root       8 Jun 10 09:40 volgrp4-lvimap_hd0 -> ../dm-14
...

Der zugehörige Link verweist im Beispiel dann ebenso wie “/dev/volgrp4/lvimap_hd0” auf “/dev/dm-14”.

Wir setzen zur Kryptierung “dm-crypt” ein. “dm-crypt” nutzt
LUKS über gut integrierte Module.

Die Aufgabe, ein (LVM-basiertes) “Raw-“-Device mit dmcrypt/LUKS zu verschlüsseln, lässt sich unter Opensuse Leap (42.2/42.3) entgegen jeder Erwartung mit YaST leider nicht erfolgreich durchführen. YaST wickelt die Anlage eines verschlüsselten Volumes nur dann korrekt ab, wenn das Filesystem bereits vorgegeben wird – also NICHT bei der Verschlüsselung für Raw-Devices innerhalb der Reihenfolge :

Partition   >>   LVM-Group   >>   Raw LVM-Volume   >>   dm-crypt/LUKS   >>   KVM-guest   >>   LVM im Gast   >>   Filesystem

Das ist bereits von anderen beklagt worden; siehe etwa:
https://forums.opensuse.org/ showthread.php/ 528938-installation-with-LUKS-cryptsetup-installer-gives-error-code-3034

Man muss also auf der Kommandozeile arbeiten und das Kommando “cryptsetup” bemühen. Für unser Beispiel-Volume “lvimap_hd0” (erste virt. Platte des künftigen E-Mail-Servers) lautet ein mögliches Kommando zur Verschlüsselung dann: 

myserv:~ # cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/volgrp4/lvimap_hd0

Für Details zu den verfügbaren Verschlüsselungs- und Hash-Verfahren werfe man einen Blick in die man-Seiten zum Kommando. Man muss die künftige Passphrase zweimal eingeben. Damit ist die Verschlüsselung aktiv. Ein anschließender Blick auf das Volume mit dem YaST-Partitioner zeigt entsprechend ein Verschlüsselungssymbol an.

Altes KVM-Gast-System mit “dd” kopieren oder mit “virt-manager” klonen?

Bzgl. des geplanten Umzugs unseres unter KVM/QEMU virtualisierten (Mail-) Servers auf das neue Krypto-Device stellt sich nun die Frage, wie wir das am besten bewerkstelligen:

Sollen wir “dd” einsetzen? Das ist zwar möglich, erfordert anschließend aber wegen kopierter UUIDs, MAC-Adressen etc. etliche manuelle Nacharbeiten im geklonten System und auf dem Host.

Besser ist deshalb aus meiner Sicht ein Cloning mit Hilfe von virt-manager! Dabei ist folgende Schrittfolge einzuhalten:

  • Schritt 1 : Öffnen des neuen dm-crypt-Devices unter einem verständlichen Namen
     
    myserv:~ # cryptsetup open /dev/mapper/volgrp4-lv_imap_hd0  cr_imap_encr

    Dabei muss natürlich die bereits gesetzte Passphrase für das Crypto-Device eingegeben werden. “cr_imap_encr” steht dann als ansprechbares Device unter “/dev/mapper/” bereit

  • Schritt 2 : virt-manager öffnen und in der Liste der Gäste mit der rechten Maustaste auf den zu klonenden Gast klicken. Dann die Option “Clone …” wählen. Das führt uns dann zu einer Maske, die in etwa so aussieht und die zu klonende virtuelle Platte (vm2_hd1) des vorhandenen Gastes anbietet:
     

    Bzgl. der zu klonenden Disk öffnet man die Drop-Down Box und wählt “Details” :

  • Schritt 3 : In der sich neu öffnenden Maske trägt man den Pfad zum
    geöffneten “dm-crypt”-Decvice ein:
     

    Dann in der aktuellen Maske den “OK”-Button und anschließend in der Ausgangsmaske den Button “Clone” drücken.

Je nach Größe unseres virtuellen Servers und der Schnelligkeit der Plattensysteme wie des Prozessors dauert das etwas. Anschließend erhalten wir allerdings einen Clone, den man sofort booten kann. (Vorher den ursprünglichen Mail-Server natürlich runterfahren, um IP-Konflikte zu vermeiden. Das geklonte System hat immer noch die gleiche IP-Adresse wie das alte! )

Das war es im Wesentlichen schon. Wir haben erfolgreich ein virtualisiertes Server-System auf einen verschlüsselten LVM-Volume-Unterbau umgezogen!

Wie schließt man das verschlüsselte System manuell?

Unsere manuelle Vorgehensweise hat dazu geführt, dass das verschlüsselte Volume nicht in Systemdateien eingetragen wurde. Es steht daher nach einem Boot-Vorgang des Hosts nicht automatisch zu Verfügung. Auch das Passwort für die Entschlüsselung wird im Bootvorgang nicht automatsich abgefragt.

Ein aktivierter “libvirtd”-Service kann daher nach seinem Start im Zuge eines Bootens des Hosts auch nicht auf das Volume für den umgezogenen Gast zugreifen. Ein automatisches Hochfahren des Gastes über libvirt-Einstellungen ist somit ebenfalls nicht möglich. Das sind Probleme, um die wir uns in nachfolgenden Artikeln kümmern müssen.

An dieser Stelle möchte ich aber wenigstens den notwendigen manuellen Befehl für das Schließen des Crypto-Devices im Zuge eines Herunterfahrens angeben:

  • Schritt 1 – Herunterfahren des Gastsystems: Dies geschieht entweder über Standard-Befehle im Gast selbst oder z.B über virt-manager.
  • Schritt 2 – Schließen des Crypto-Devices :
      
    myserv:~ # cryptsetup close cr_imap_encr

Ausblick

In folgenden Artikeln möchte ich im Nachgang zu unserem “Umzug” ein wenig auf das Thema eingehen, wie man das Hochfahren des KVM-Hosts mit Gastsystemen auf verschlüsselten Volumes gestalten kann. Zudem wollen wir den “Verschlüsselungsheader” sichern und uns mit den Themen Backup und “fstrim” für SSDs als Basis der beschriebenen Schichtung befassen. Sinnvoll ist auch ein Blick auf (Mail-) Client-Systeme: Von irgendwo aus muss ja auch mal grafisch auf die virtualisierten Systeme zugegriffen werden. Dann werden z.B. Spice oder X2GO-Clients samt zugehörigen Protokollen zu einem Sicherheitsthema auf dem System, von dem aus wir auf virtualisierte Clients für die Auftragsbearbeitung zugreifen. Verschieben wir mit der Virtualisierung im Client-Umfeld also nur die Sicherheitsebene?

Links

P2V-Tools
http://manuel.kiessling.net/2013/03/19/converting-a-running-physical-machine-to-a-kvm-virtual-machine/
http://libguestfs.org/virt-p2v.1.html
https://access.redhat.com/ documentation/ en-us/ red_hat_enterprise_linux/ 6/html/ v2v_guide/ chap-v2v_ guide-p2v _migration_ converting _physical _machines _to_virtual _machines
http://events17.linuxfoundation.org/sites/events/files/slides/virt-v2v-rjones-backup-slides.pdf
http://qemu-buch.de/de/index.php?title=QEMU-KVM-Buch/ _Speichermedien/ _Physical-to-Virtualp2v _migration _converting _physical _machines _to _virtual _machines
https://access.redhat.com/articles/1351473

dm-crypt/Luks und die Reihenfolge von Zugriffsschichten
https://superuser.com/ questions/ 1193290/ best-order-of-raid-lvm-and-luks
https://blog.raptor2101.de /2009/09/23/ verschlusselung-von-raids/
http://www.andreas-janssen.de/cryptodisk.html
http://linux-club.de/wiki/opensuse/Verschluesselung:_dm-crypt/luks_unter_openSUSE
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties