LUKS: Wie man einen Cloud-Container erstellt.

Posted on 13. September 2020 by marius

Wer kennt das Bedürfnis nach Synchronisation des Dateibestandes von verschiedenen Geräten über einen Cloudanbieter aka Webhoster nicht? Ok, Ihr könnt jetzt zur nächsten OSBN News wechseln, außer Ihr möchtet an einem Zweitstandort eine sicher aufgehobene Kopie Eurer Daten haben, auf die nur Ihr Zugriff habt, dann lest jetzt weiter …

LUKS: Wie man einen Cloud-Container erstellt.

Verschlüsselungssysteme gibt es ja viele, aber nicht alle sind bei jeder Distro onboard und osübergreifend verfügbar, LUKS schon. Deswegen heute ein kleiner Beitrag wie man seine Daten bei einem Webhoster so parkt, daß man sie von überall aus einbinden kann.

ACHTUNG: Bei einer Cloud-Container-Lösung auf Basis von Luks oder Truecrypt darf nur ein PC das System aktiv einbinden, sonst Datenverlust! Möglich ist aber ein READ-ONLY-Einbinden mehrerer Rechner gleichzeitig. Ich warne ausdrücklich davor so etwas zu versuchen und es dann zu versemmeln!

Der Hintergrund für die Warnung ist ganz einfach der, daß Eurer PC der Meinung ist, daß er den Datenträger exklusiv hat und daher Sachen im RAM vorhält, die nicht auf den Datenträger synchronisiert sind um die Leistung zu steigern. Wenn zwei Rechner das machen und dann vermeidliche freie, aber vom anderen PC schon im RAM anvisierte Blöcke beschreibt, kommt es unweigerlich zum Datenverlust. Wer schon einmal mit SSHFS gearbeitet hat, das einen entfernten PC als Laufwerk einmountet, der wird bemerken, daß da keine lokale Pufferung stattfindet, weil der PC hier nicht wissen kann, ob und wer sonst noch so auf die Datenquelle zugegriffen hat. SSH greift auf der anderen Seite auch nicht als Filesystem, sondern über die OS API auf Dateien zu und simuliert Euch nur ein Laufwerk.

Anders ist das, wenn zwar der Container per SSHFS verfügbar gemacht wird, aber das Einbinden des entschlüsselten Filesystems dann lokal stattfindet. Das findet dann wieder mit den OS eigenen IO-Steigerungsamethoden statt. Beim Mounten von Datenträgern kann man über die Mount-Options noch einiges abändern, da geht vielleicht sogar was, aber empfehlen kann ich das definitiv nicht.

Die Ausgangslage

Wir behandeln daher einen PC der auf einen Webserver zugreift, dort seinen Container lagert und die ganze Ent- und Verschlüsselung auf dem eigenen PC auflaufen lässt.

Wir brauchen: CryptSetup, einen Webserver, schnelles Internet ( ist von Vorteil )

Der Webserver

Der Webserver muß eine der folgenden Anbindungen unterstützen: SSH, SAMBA oder NFS und zwar genau in der Reihenfolge sollte man das auswählen. Für diesen Artikel nehme ich SSH, da das auf jedem LinuxPC vorhanden ist und der Transportweg so zusätzlich verschlüsselt ist. Da sieht man dann auch nicht, was da eigentlich auf dem Webserver gemacht wird.

Samba ist zwar mittlerweile auch im Datentransport verschlüsselt, aber viele Router halten das auf, damit die Windowskisten nicht das Providernetz vollspammen, die sind sehr mitteilungsbedürftig 😉

NFS kennt keine Authentifizierung außer IPs, ist unverschlüsselt und ist im allgemeinen bestenfalls zwischen Servern einzusetzen.

Das PRE-SETUP

Wir machen das alles als ROOT, weil CryptSetup und mount das gern so möchten. Da hier FUSE nur sekundär im Einsatz ist, weil es sich um normale Filesysteme des Kernels handelt (kommt gleich), kommt mount zum Einsatz, welches zwingend als ROOT laufen möchte. Das Ergebnis der Aktion kann aber dann von jedem User benutzt werden. Wenn man sich da nicht besonders blöd im Rechtemanagement anstellt, dann ist das auch auf einem Mehrbenutzersystem kein Problem. Kommen wir zu …

Schritt 1: Einen Mountpoint für den Container erstellen

mkdir -p /media/container/server

Der Ort ist in der Regel für jeden Benutzer erreichbar, was z.b. beim Mounten im eigenen Home nur für den aktuellen Benutzer gelten würde.

Schritt 2: Der Server als Laufwerk einbinden

sshfs demo@meine.demo.de:/home/demo /media/container/server -o allow_other

Je nachdem was man als Authmechnismus eingestellt hat ( KEY oder PASSWORD ) macht da der SSH-AGENT, der hoffentlich in irgendeiner Form bei Euch läuft ( gpg-agent, ssh-agent, gnome-keyring-daemon ) das mit dem Schlüssel automatisch für Euch, oder Ihr müßt ein Passwort eingeben.

Schritt 3: Das Containerfile anlegen

Hier im Beispiel benutze ich jetzt ein 100MB File ( 1M * 100 ) :

# dd if=/dev/zero of=/media/container/server/container.luks bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
104857600 bytes (105 MB, 100 MiB) copied, 29,0354 s, 3,6 MB/s

Wer da übers Netz GBweise Dateien anlegt, der sollte sich fragen, ob er verstanden hat, was er da gerade tut, denn das dauert Stunden und man könnte es ja auch auf dem Webserver erledigen lassen, daß dauert nur Sekunden, denn noch ist da weder Crypto noch ein Filesystem dran beteiligt, es wird nur ein BLOCK mit NULLEN erzeugt.

Schritt 4: Den Container mit LUKS formatieren

Der nächste Schritt sollte allerdings zwingend vom PC aus erledigt werden, da dazu ein Passwort nötig ist, welches, solange der Vorgang dauert, auch im Speicher des Webservers verfügbar wäre, würde man es dort tun. Das Formatieren dauert dann auch ein gutes Weilchen.

# cryptsetup -y luksFormat /media/container/server/container.luks
WARNING!
========
Hiermit werden die Daten auf »/media/container/server/container.luks« unwiderruflich überschrieben.
Are you sure? (Type ‚yes‘ in capital letters): YES
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************
Passphrase bestätigen: ***********************

Ein sinnvoll langes Passwort > 20 Zeichen ist angeraten! Es sollte nicht 123456789… lauten 😉

Schritt 5: Den Container öffnen und zum Mounten bereitstellen

Dieser Schritt geht dann recht zügig von statten. Ihr müßt nicht zwangsweise den gleichen Cryptocontainernamen benutzen wie ich, da seid Ihr flexibel.

# cryptsetup luksOpen /media/container/server/container.luks cryptocontainer
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************

Schritt 6: Das Filesystem erstellen

Beim ersten mal muß man jetzt das Filesystem einrichten:

# mkfs.ext4 -j /dev/mapper/cryptocontainer
mke2fs 1.45.5 (07-Jan-2020)
Ein Dateisystem mit 86016 (1k) Blöcken und 21560 Inodes wird erzeugt.
UUID des Dateisystems: bcbccb1b-794e-4700-bd64-cd021a42bf32
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729
beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden geschrieben: erledigt

ich habe jetzt EXT4 ausgewählt, weil das in jedem Kernel vorkommt und als Journalingfilesystem keine ellenlangen Reparaturen vor dem Mounten braucht, was gerade bei einem Netzwerkcontainer ein wichtiger Entscheidungsgrund ist, sonst wartet Ihr da auch schon mal Stunden auf den Mount.

Schritt 7: Den Containerinhalt ins System einbinden

Das Einbinden in das System ist dann denkbar einfach:

# mount /dev/mapper/cryptocontainer /mnt
# df -h | grep mnt
/dev/mapper/cryptocontainer 78M 1,6M 70M 3% /mnt

Das wärs schon, wenn da nicht das Zugriffsproblem wäre. Also muß Root da jetzt z.B. noch ein Verzeichnis anlegen, weil die User keine Schreibrechte haben:

# ls -ls /mnt/
insgesamt 12
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found
# ls -lad /mnt/
drwxr-xr-x. 3 root root 1024 13. Sep 12:01 /mnt/
# mkdir /mnt/demo
# chown demo:demo /mnt/demo
# chmod 700 /mnt/demo/
# ls -ls /mnt
insgesamt 14
2 drwx——. 2 demo demo 1024 13. Sep 12:10 demo
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found

Nun kann der Benutzer „demo“ da machen was auch immer er möchte.

Einbinden beim System-Boot

Das ist nicht ganz ohne. Man könnte dem Cron sagen, daß er das nach dem Boot machen soll, indem man da ein kleines Script benutzt, daß alle Schritte als Root macht, aber wer sagt uns, daß das auch passiert, wenn ein Netzwerk vorhanden ist? Niemand, also müssen wir das wohl oder übel an den Systemd übergeben. D.b. Ihr schreibt einfach ein kleines Start/Stop Script nach /etc/init.d/ oder direkt eine Unit für Systemd direkt, in dem die Anhängigkeiten zum erfolgreichen Netzwerkstart angegeben sind z.b. wie hier:

xl2tpd.service:After=network.target

So ist sichergestellt, daß es auch klappen kann, sofern alles mit dem Netzwerk und dem Server ok ist.

Sicherheitsanalyse

Wo liegen hier die Vorteile zu einem USB Stick? Zum Einen macht der Hoster normalerweise ein Backup von dem Server oder bietet Euch zumindest an, daß Ihr eins machen könnt. Dann ist das von überall aus erreichbar und i.d.R. kann man das nicht verlieren. Auch ein „Diebstahl“ wäre nicht tragisch, da der Dieb nicht an den Inhalt kommt, außer Eurer Passwort war „123456“ 😀

Die gesamte Ver- und Entschlüsselung der Daten findet zur Laufzeit auf Eurem PC statt, d.b. jemand muß sich Zugang zu Eurem PC verschaffen und dann auf die Daten zugreifen, wenn diese lokal verfügbar sind. Das könnt Ihr mit Updates und Festplattenvollverschlüsselung leicht kontern, denn dann können Euch lokale Angreifer mal am ….. . Auf diese Sicherheit müßt Ihr sowieso bauen, da ansonsten der Aufwand die Daten verschlüsselt im Netz zu speichern kompletter Unfug wäre. Also ganz klar: Entweder alles oder nichts verschlüsseln, sonst nützt es im Zweifel nichts.

VeraCrypt vs LUKS

Aus Benutzersicht ein klares Ja zu VeraCrypt: Kommt mit GUI und bindet sich ohne Root auch beim Login automatisch per FUSE ein.. 1a!

Der LUKS Container hat aber den Vorteil, daß man damit nur den Leuten vertrauen muß, die sowieso schon Eurer OS zusammenbauen. Wenn man denen nicht trauen würde, könnte man auch VeraCrypt nicht einsetzen, weil wenn das OS unsicher ist, wozu dann noch Verschlüsseln?

Über die /etc/crypttab kann LUKS Medien auch automatisch ins System einbinden lassen, allerdings muß zu dem Zeitpunkt das Netzlaufwerk mit dem Container verfügbar sein, sonst ist Essig. Hat also alles Vor- und Nachteile. Welche davon für Euch interessant sind, müßt Ihr entscheiden.

Wie bekomme ich den Container wieder zu?

Wichtige Frage, einfache Antworten:

umount /media/container/server
cryptsetup luksClose cryptocontainer
fusermount -u /media/container/server

Neue Platte automatisch entschlüsseln lassen

Posted on 9. März 2020 by marius

Ich hab eine neue Platte im PC und die soll sich natürlich beim Hochfahren automatisch ins System integrieren, wenn ich das Passwort kenne. Leider klappt das mit den Automatiken nicht so ganz, daher müssen wir da kurz Hand anlegen.

Automatisch LUKS-Platten beim Boot einbinden

Zunächst brauchen wir mal eine mit LUKS verschlüsselte Platte. Um eine Platte mit LUKS zu verschlüsseln eignet sich das Laufwerketool. Die zu formatierende Partition auswählen und auf „Partition formatieren“ klicken:

Ihr geht den neuen Namen für die Platte an, damit meldet die sich dann später im System, und wählt „Passwortgeschützter Datenträger (LUKS)“ aus. Ggf. habt Ihr die Wahl zwischen LUKS und LUKS2, aber F30 hat die noch nicht. Wenn ja, nehmt ruhig LUKS2.

Ein ordentlich langes Passwort ist Pflicht. Danach dürft Ihr das noch einmal bestätigen und ein paar Sekunden später die Platte mit Hilfe des Lazy-Inits bereits bereit. „Lazy-Init“ meint, daß die Platte dort formatiert wird, wo Daten geschrieben werden sollen und nicht jetzt gleich die ganze Platte von Vorn bis Hinten formatiert wird. Das hätte nämlich bei 8TB 23 Stunden gedauert, da hatte ich wirklich keine Lust zu 😉

Die UUID ermitteln

Zwei Möglichkeiten eröffnen sich Euch: Ihr fragt das Laufwerkstool nach der UUID der neuen Platte ( Luks-Teil ) oder Ihr bemüht „blkid“ in der Konsole. Da wir diese eh gleich brauchen, bietet sich das an:

Erstmal ROOT werden:

$ su

dann suchen wir uns die UUID raus:

# blkid|grep sdd
/dev/sdd: UUID=“c16596bf-b40d-4c57-a46d-93b98d4bac47“ TYPE=“crypto_LUKS“

„sdd“ ist hier meine Platte. Eine UUID ist eine einmalige ID ( daher das zweite U ) die aufgrund eines einheitlichen Verfahrens ( das erste U ) erzeugt wird. Mehr müßt ihr darüber eigentlich nicht wissen.

Nun nehmen wir die UUID und tragen das passend in /etc/crypttab und /etc/fstab ein:

$ echo „/dev/mapper/luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 /media/Huge ext4 defaults,x-systemd.device-timeout=0 1 2″ >>/etc/fstab

Da es sich um ein LUKS Laufwerk handelt und Devmapper das für uns managen wird, tragen wir den Devmapperpräfix und die UUID als Laufwerkspfad ein. „/media/Huge“ ist der Mountpoint, den Ihr bei Euch ggf. vorher noch anlegen müßt. Natürlich könnt Ihr auch einen anderen Pfad dafür nehmen, müßt Ihr wissen. Für alle Einsteiger: Der Mountpoint ist nichts weiter als ein leeres Verzeichnis. Das kann liegen wo Ihr wollt, aber /mnt/directory oder /media/directory bieten sich an. Wichtig ist, daß da nichts anderes gemountet ist und der Pfad nicht in einem anderen Mountpoint ist.

Beispiel:

/media/Small
/media/Bigger
/media/Huge

„ext4“ ist das Filesystem. Ihr werdet gemerkt haben, daß nach dem Formatieren der LUKS Partition ein weitere Partition unter der LUKS-Partition aufgetaucht ist. Da liegen Eure Daten dann wirklich drin. Das sieht so aus:

Diese Partition muß von Euch jetzt auch erst noch formatiert werden, dann natürlich passend zu dem Eintrag in der /etc/fstab, den wir gerade besprochen haben. Nehmt einfach Ext4, könnt Ihr praktisch nichts falsch machen. Wie Ihr sehen könnt, bekommt diese Partition eine eigene neue UUID. Aber das muß Euch jetzt nicht weiter belasten.

Damit die Platte jetzt auch beim Booten entschlüsselt wird und damit das Mounten/Einhängen des Laufwerks überhaupt erst möglich wird, tragt Ihr die UUID noch in die /etc/crypttab ein:

echo „luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 UUID=c16596bf-b40d-4c57-a46d-93b98d4bac47 none“ >> /etc/crypttab

Das wars schon. Beim nächsten Booten ist die Platte dann sofort verfügbar.

„Keine Panik!“

Ok, eine freundliche Schriftart habe ich jetzt auf die Schnelle nicht zur Hand und großer geht es auch nicht, aber falls Ihr mal etwas vergessen oder Euch vertippt habt und Euer System nicht bootet.. KEINE PANIK!

Das löst sich ganz einfach:

1. den PC von einer USB-LIVE Disk booten.
2. Das Laufwerketool starten.
3. Eure Systempartition ggf. erst entschlüsseln und dann direkt im Tool mounten/einhängen.
4. TERMINAL öffnen
5. „su“ eingeben
6. „blkid“ eingeben
7. UUID in /etc/fstab und /etc/crypttab vergleichen
8. Tippfehler beheben und Rechner neu booten.

99% aller Fehler in dem Bereich sind Vertipper oder man hat es schlicht und ergreifend nicht abgespeichert 🙂

Bitlocker unter Linux öffnen

Posted on 15. Oktober 2018 by marius

Ihr erinnert Euch noch diesen c’t Uplink Beitrag, wo die Heise Redakteure über Bitlocker und Luks schwadroniert haben? Damals wurde Bitlocker als „properitär“ eingestuft und sinngemäß gesagt: „Um Festplatteverschlüsselung zu machen, brauchst Du eh die PRO Version, die Home kann das nicht“. Da hat sich was getan 😉

Bitlocker für Linux

Vor drei Tagen kam eine Updatemeldung von Fedora zu einem Produkt namens „Dislocker“ rein. Der Name versprach etwas spannendes, also habe ich mir die Meldung angesehen:

Name        : dislocker
Product     : Fedora 28
Version     : 0.7.1
Release     : 10.fc28
URL         : https://github.com/Aorimn/dislocker
Summary     : Utility to access BitLocker encrypted volumes
Description :
Dislocker has been designed to read BitLocker encrypted partitions ("drives")
under a Linux system. The driver has the capability to read/write partitions
encrypted using Microsoft Windows Vista, 7, 8, 8.1 and 10 (AES-CBC, AES-XTS,
128 or 256 bits, with or without the Elephant diffuser, encrypted partitions);
BitLocker-To-Go encrypted partitions (USB/FAT32 partitions).

Das Tool gibts als FUSE Modul, so daß die Bitlocker-Partition zur Laufzeit eingebunden und Gelesen sowie Geschrieben werden kann, und als Einmal-Komplett-Entschlüssler. So oder so, man kommt an die Daten ran. Damit ist Linux jetzt Windows offiziell voraus 😀

Ob das eine gute Idee war/ist wird sich zeigen, aber eins kann man Bitlocker damit nicht mehr nennen: properitär. Zumindest nicht mehr im ganz engen Sinn. Es wird natürlich nur von M$ produktiv eingesetzt, aber immerhin, wie auch bei NTFS, kann man es jetzt auf anderen Plattformen ( Ja, Macs machen auch mit ) benutzen.

@Heise-Redaktion: Wird Zeit für einen neuen c’t Uplinkbeitrag zu dem Thema. Da könnt Ihr gleich die ganzen Gerüchte vom letzten mal berichtigen, von wegen Luks wäre unpraktisch, keine Passworteingabe usw. usw. 😀 PS: wenn Ihr schon dabei seid: Mit LUKS einen USB Stick verschlüsseln und Double Layer Encryption mit Veracrypt falls Euch die Beispiele ausgehen 😉

Fehler in der Security

Der Grund für das Update war dann übrigens das Beheben von drei CVE-Schwachstellen in der genutzten Cryptobibliothek, wie man auf der Projektseite nachlesen konnte u.a. :

ID: CVE-2018-0497
Impact: Allows a remote attacker to partially recover the plaintext
Severity: High

Im Bereich Crypto ist das quasi eine 11 von 10 möglichen Punkten auf der Richterskala (+1 weils Remote geht 😉 ).

Den Schlüssel für die Bitlocker Partition könnt Ihr bei Microsoft erfragen, falls Ihr den vergessen haben solltet 😉

Marius Welt

Tag Archives: LUKS