Verschlüsselten File-Container mittels cryptsetup und LUKS erstellen


Datenschutz wird im Jahr 2018 so groß geschrieben wie nie zuvor. Verschiedene Anforderungen an die Absicherung der Daten zwingen Admins, sich elegante und sichere Setups einfallen zu lassen. Ich nehme das zum Anlass, eine neue Serie zur Dateiverschlüsselung zu eröffnen, bei der es um die verschiedensten Möglichkeiten geht, die gespeicherten Daten gegen den Zugriff Unbefugter abzusichern.
Oftmals ist eine Verschlüsselung der Daten aufgrund bestehender Infrastrukturen oder mangels Rechten (z. B. bei extern angemieteten Storages) nicht so einfach möglich. Früher war hier ECryptFS im Linux-Umfeld und TrueCrypt bei Windows State of the Art. Heute haben sich die Anforderungen geändert und ECryptFS ist wegen einer zu restriktiven Beschränkungen der Dateinamen nicht mehr alltagstauglich. Daher stelle ich hier eine moderne Alternative mit cryptsetup in Ergänzung mit LUKS vor.

Vorbereitung

Installation von cryptsetup (Beispiel Debian-Derivate)

sudo apt-get install cryptsetup

Laden des Kernel-Moduls (nur bei initialer Einrichtung)

sudo modprobe dm-crypt

File-Container erstellen

Zunächst wird mittels dd ein File-Container mit 1GB Größe erstellt, der Wert kann natürlich je nach Anforderung angepasst werden

dd if=/dev/zero of=/storage/my_container bs=1M count=1024

File-Container mittels cryptsetup initialisieren

 cryptsetup -y luksFormat /storage/my_container

Nun die gewünschte Passphrase eingeben. Aber Achtung, ohne ein gut gewähltes Passwort nutzt die stärkste Verschlüsselung nichts!
Verschlüsselten Container öffnen und Dateisystem erstellen

cryptsetup luksOpen /storage/my_container my_mount

hier wird das Kennwort abgefragt, dies sollte man sich natürlich zuvor gut merken. Der Container ist nun unter /dev/mapper/my_mount eingebunden.  Anschließend wird ein ext4-Dateisystem in dem Container erzeugt.

mkfs.ext4 -j /dev/mapper/my_mount

File-Container am Wunschort mounten

Ordner zum mounten erstellen

mkdir /my_data
mount /dev/mapper/my_mount /my_data

Fertig – alle Daten die nun in /my_data erzeugt werden, landen am Ende verschlüsselt im Container, wie in meinem Beispiel unter /storage/my_container

Mount aushängen und File-Container schließen

Damit die Daten während der Nichtnutzung auch wirklich sicher sind, empfehle ich, den Container wieder abzuschließen.

umount /my_data
cryptsetup luksClose my_mount

Protip

Ich habe auf diese Art der Verschlüsselung bei meiner Nextcloud zurückgegriffen, da mir die Bordmittel von Nextcloud nicht gefallen, oder zu langsam sind. Im nächsten Artikel werde ich auch erklären, wie man den Container entsprechend vergrößern kann. Alle mit my_ verwendeten Variablen, können natürlich auf die jeweiligen Bedürfnisse angepasst werden.

Haben wollen?

Wir bieten natürlich bei uns im Managed-Hosting individuelle Lösungen an. Falls unsere (potentiellen) Kunden ein solches Setup wünschen, so sind wir natürlich für jeden Spaß zu haben.

Disclaimer

LUKS verwaltet die Verschlüsselungsdaten im Header. Ohne den Header (oder im Falle einer Beschädigung), ist ein Zugriff auf die Daten nicht mehr möglich. Es gibt verschiedene Tools, wie beispielsweise zuluCrypt, mit denen die Schlüssel und Header verwaltet und gesichert werden können, doch dazu in einem späteren Artikel mehr. Die Anleitung wurde nach bestem Wissen und Gewissen erstellt, testet bitte jedoch selbst ausreichend, bevor diese Lösung in die Produktion geht, damit das ihr die Funktionsweise versteht und Datenverlust vermeidet.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Drei Wege um virtuelle Maschinen zu migrieren

OpenNebulaConf Grafiken 09Neue Storage-Lösungen sprießen wie Tulpen im Frühling aus dem Boden. Jede einzelne ist flexibler, schlanker und hochverfügbarer.
Da kommt meine Cloud ins Spiel, die eigentlich gut läuft aber so ein schnelleres Storage ist eine willkommene Abwechslung.
So ein neues Storage ist schnell aufgesetzt, was uns dann aber vor eine neue Aufgabe stellt,
denn unsere VMs laufen… nur nicht auf unserem hippen Storage.
Nun gibt es diverse Methoden um eine virtuelle Maschine in ein neues Image bzw. neues Storage zu transferieren.
Da haben wir zum einen die altbewährte Methode, mit dem Urgestein aller blockorientierten Kopiervorgänge dd.
Dazu muss die virtuelle Maschine komplett ausgeschaltet sein. Da sich der Zustand der VMs nicht mehr ändert, kann man beruhigt die VM kopieren.
dd if=/path/to/input/file of=/path/to/output/file bs=4096
Zum anderen die Methode ein qcow2 Image in ein Blockdevice zu schreiben.
In Worten gesagt: das Image wird mit “qemu-img convert” in Raw umgewandelt und danach mit dd auf das neue Blockdevice kopiert. (Auch hier sollte die VM nicht mehr laufen!)
qemu-img convert -p -f qcow2 -O raw /path/to/input/file /path/to/outputfile.raw && dd if=/path/to/outputfile.raw of=/path/of/device bs=4M
Da die beiden genannten Arten eine lange Downtime benötigen, sind sie nur für VMs geeignet die nicht zeitkritisch sind.
Ein UNIX System kann mit guten Kenntnissen, mit relativ kurzer Ausfallszeit migriert werden. Ein hilfreiches Werkzeug dabei ist Rsync.
Leider kann ich hierzu kein fixes Beispiel vorzeigen, da die einzelnen Schritte von System zu System unterschiedlich ausfallen.
Die essentiellen Schritte sind:
1. Neues Device in der VM mounten und das gewünschte Filesystem erstellen.
2. Systemverzeichnisse auf dem neuen Device erstellen.
3. Das komplette System mit Rsync auf das neue Device kopieren. Hier muss man natürlich etwas aufpassen und Verzeichnisse wie /proc oder ggf. /mnt exkludieren. Auch auf bind Mounts sollte man achten, damit man Daten nicht ausversehen doppelt kopiert.
4. Die grub.cfg natürlich im neuen /boot Pfad aktualisieren. (grub-install und update-grub sind hierfür hilfreich)
5. Das “alte Device” als read-only einbinden und die neue fstab anpassen.
6. Und last but not least, einen weiteren Rsync in dem die restlichen Files auf das neue Image übertragen werden. (auch hier bitte das Exkludieren von wichtigen Pfaden nicht vergessen. z.B.: /etc/fstab oder auch /boot !!)
Der Vorteil hierbei ist: die Downtime erstreckt sich dabei nur über den zweiten Rsync, bei dem die Festplatte im “read-only” Modus ist.
Habt Ihr weitere coole Möglichkeiten einen VM zu migrieren?
Dann dürft ihr euch in den Kommentaren dazu äußern.
Oder seid Ihr interessiert an dem Thema Cloud und alles was damit zu tun hat? Dann besucht uns einfach auf der OpenNebula Conf 2014

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.