LUKS Entschküssekung per remote Cron Job

[DFFVB]

Hallo zusammen,

ich habe einen kleinen Futro auf welchem ich die Systempartition per LUKS verschlüsselt habe. Da der Rechner headless läuft, habe ich remote Entschlüsselung per Dropbear eingerichtet. Das funktioniert soweit so gut, nun würd eich das gerne mit einem CronJob automatisieren. Hat da jemand ne Idee wie?

 

[Tornhoof]

Dropbear ist doch beim Boot zuständig, danach sind doch alle entschlüsselt. Was willst du dann mit nem CronJob machen?

 

[Nero1]

Ich hab zwar keine Ahnung wie genau deine Dienste da funktionieren, aber ich nehme mal an:
Remote-Rechner (mit SSH-Zertifikat) -> SSH-Connect auf Futro inkl. Zertifikatübermittlung -> LUKS-Decrypt?

Wie machst du das aktuell? Einfach per Kommandozeile? Dann kannst du dir da ja ein Skript schreiben und das auf dem Remote per Cronjob starten. Wenn du was anderes willst, dann solltest du präzisieren, was du genau erreichen möchtest.

Ob das alles dein Sicherheitskonzept untergräbt oder nicht, musst du selber wissen.

 

[Donnerkind]

Ich versteh nicht ganz. Willst du auf einem anderen Gerät einen Cronjob einrichten, der regelmäßig auf das geLUKSte System geht und versucht, das zu entschlüsseln? Ich habe mir das für mein NAS in die andere Richtung überlegt (aber noch nicht umgesetzt): das System versucht beim Hochfahren, eine Schlüsseldatei aus dem lokalen Netzwerk zu ziehen. (Aktuell liegt da der Schlüsesl einfach in /root. Die Verschlüsselung dient nur dem Schutz der Daten, falls ich die Platten wegschicken muss.)

 

[tdbr]

Ich habe auf meinem mini PC (FedoraServer) TPM2 LUKS aktiv.
Ich hatte mal auf meinem mini PC Clevis & Tang am laufen um über Netzwerk zu entschlüsseln (Desktop PC entschlüsseln)


Ich verstehe die Problematik nicht ganz. Willst du permanent den Futro überwachen ob er entschlüsselt ist?

 

[DFFVB]

Erstaml Danke für die Rückmeldungen.

Remote-Rechner (mit SSH-Zertifikat) -> SSH-Connect auf Futro inkl. Zertifikatübermittlung -> LUKS-Decrypt?

Korrekt

Wie machst du das aktuell? Einfach per Kommandozeile?

Korrekt

Dann kannst du dir da ja ein Skript schreiben und das auf dem Remote per Cronjob starten.

Da wollte ich hier um Inspiration bitten, bzw. gerne auch ne Vorlage, weil ich nicht skripten kann :-)

Ob das alles dein Sicherheitskonzept untergräbt oder nicht, musst du selber wissen.

Das Problem bei Unix Kerneln ist ja, dass die noch nicht so gut mit TPM können, daher käme der Unlock von einem Windows NUC mit ner Ubuntu VM.

TPM2 LUKS aktiv

Kannst Du das mal etwas näherausführen, dachte das wäre noch beta?

 

[Nero1]

Da wollte ich hier um Inspiration bitten, bzw. gerne auch ne Vorlage, weil ich nicht skripten kann :-)

Empfehle da gerne die Seite hier mitsamt dem dort vorhandenen Wissen. Die wichtigsten Sachen findest du recht weit oben.
Im Kern müsste es vermutlich reichen, wenn du sowas machst, wie

#!/bin/bash
Dein Befehl des bisherigen Decrypt

Bsp.:

#!/bin/bash
ls -al ~ #zeigt beim Ausführen alle Dateien im Home-Verzeichnis an

Heißt: Skript-Datei anlegen, erste Zeile hinzufügen, deinen Befehl hinzufügen, chmod +x deinSkript.sh, um es ausführbar zu machen, mit ./deinSkript.sh testen, ob's klappt.

Falls nicht, müsste man genauer hinschauen, das hängt aber stark von deinen genauen Befehlen ab, die du da verwendest.

 

[tdbr]

Kannst Du das mal etwas näherausführen, dachte das wäre noch beta?

Beta ist mir nichts bekannt. TPM2 ist auto decrypt beim booten. Der Key sitzt auf dem TPM Chip vom Mainboard. Wenn das System jetzt geklaut wird kommt man dann auch auf das System drauf bis zur Anmeldung. Also ist Nutzer + Passwort die Hürde. Wird die Systemplatte ausgebaut ist sie verschlüsselt. In anderen Systemen kannst du weiterhin die Platte ausbauen und mit dem Passwort entschlüsseln.

http://0pointer.net/blog/unlocking-...-pkcs11-security-hardware-on-systemd-248.html

 

[foofoobar]

Das TPM rückt einfach mal so den Key für die Platten raus?

 

[Donnerkind]

Warum möchtest du das eigentlich per Cron machen, @DFFVB? Ein Cronjob weiß nicht, ob das Gerät an ist (würde also dauernd ins Leere feuern wenn nicht) oder ob LUKS schon geöffnet ist. Und wenn du keine zu hohe Verzögerung zwischen anschalten und entschlüsseln haben willst, müsste dieser Job im Prinzip so oft wie möglich, also minütlich, laufen. Das ist nicht elegant.

Als einfache Alternative (also nicht so hochentwickelt wie die native Integration einer remoten Schlüsseldatei in luks bzw. die initrd, was ich aus dem Kopf auch nicht erklären kann) könntest du ein Skript auf deinem Rechner anlegen, das diesen SSH-Befehl, den du bisher ausführst, enthält. Und diesen Skript kannst du dann von deinem Server aus ebenfalls über ssh starten. Dadurch wird das nur dann ausgeführt, wenn es wirklich benötigt wird.

Also Rechner A enthält das Unlock-Skript, z.B. unter /usr/local/bin/unlock-server.sh:

#!/usr/bin/sh

# Werte einsetzen
SERVER=<Hostname oder IP des Servers>
NAME=<Name des entschlüsselten LUKS-Devices>
KEYFILE=<Pfad zum Keyfile>
MOUNTPOINT=<Mountpfad des LUKS-Containers>

cat "$KEYFILE" | ssh root@$SERVER "cryptsetup luksOpen --key-file - /path/to/device $NAME && mount /dev/mapper/$NAME $MOUNTPOINT"

Und dein Server führt beim Hochfahren einmal ssh rechnerA /usr/local/bin/unlock-server.sh aus. Wenn du paranoid sein willst, kann man in ssh den Zugriff für einen User auf einen Befehl begrenzen, sodass man den SSH-Schlüssel nur für das Ausführen dieses einen Skripts nutzen kann.

 

[Marco01_809]

@foofoobar Ja, wenn das TPM glaubt noch im gleichen System zu sein. Siehe dazu meine Posts
https://www.computerbase.de/forum/t...allation-fragen-zur-verschluesselung.1821096/
https://www.computerbase.de/forum/threads/bitlocker-tpm-setup.1911887/#post-23481112
Zur Funktionsweise: https://www.computerbase.de/forum/t...chiebung-von-partition.2113866/#post-27524977
Ein zufallsgeneriertes Passwort ist in jedem Fall die sicherere Wahl, TPM-only Verschlüsselung schützt einfach nicht in vielen Angriffsszenarios.

@Donnerkind Da er schreibt das er die Systempartition verschlüsselt hat wird so ein Skript nicht ohne weiteres funktionieren. Außer dem Bootloader, Kernel-Image und initramfs ist alles verschlüsselt. Man müsste also mit den initramfs tools basteln um das Skript ins initramfs aufzunehmen und dort im early boot auszuführen.

Finde das ganze Vorhaben aber sowieso gefährlich. Egal ob dein externer Server nun ständig versucht deinem Futro das Passwort aufzuzwängen oder ob der Futro einfach so das Passwort anfragen kann torpedierst du damit doch total den Sicherheitsgewinn deiner Verschlüsselung. Bedenke dass das initramfs unverschlüsselt ist. Wenn du also auf den initramfs-dropbear verbindest kannst du nicht wissen ob das initramfs manipuliert wurde mit einem Keylogger oder ob jemand einfach die SSH private keys aus dem initramfs kopiert hat und deine Verbindung MITM'ed. Beides ist möglich mit physischem Zugriff auf das System, ohne irgendein Passwort zu kennen.

 

[Donnerkind]

@Donnerkind Da er schreibt das er die Systempartition verschlüsselt hat wird so ein Skript nicht ohne weiteres funktionieren. Außer dem Bootloader, Kernel-Image und initramfs ist alles verschlüsselt. Man müsste also mit den initramfs tools basteln um das Skript ins initramfs aufzunehmen und dort im early boot auszuführen.

Und wenn er das mittels externem Cronjob machen wollen täte, dann müsste zumindest ein ssh-Key ins initramfs rein sowie irgendeine Logik, die den Boot anhält bis von außen das LUKS geöffnet worden ist. Jacke wie Hose also.

Finde das ganze Vorhaben aber sowieso gefährlich. Egal ob dein externer Server nun ständig versucht deinem Futro das Passwort aufzuzwängen oder ob der Futro einfach so das Passwort anfragen kann torpedierst du damit doch total den Sicherheitsgewinn deiner Verschlüsselung. Bedenke dass das initramfs unverschlüsselt ist. Wenn du also auf den initramfs-dropbear verbindest kannst du nicht wissen ob das initramfs manipuliert wurde mit einem Keylogger oder ob jemand einfach die SSH private keys aus dem initramfs kopiert hat und deine Verbindung MITM'ed. Beides ist möglich mit physischem Zugriff auf das System, ohne irgendein Passwort zu kennen.

Naja, es funktioniert solange das Gerät im Heimnetz steht, weil der Schlüssel dort zu finden ist (oder in DFFVBs Kopf). Und wenn der Private Key ausschließlich für den Aufruf der Entschlüsselung verwendet werden kann, birgt dessen Verlust kein weiteres Risiko. Ich gehe beim Bedrohungsszenario hier hauptsächlich von nem Einbrecher aus, der das Ding mitnimmt.

 

[tdbr]

Also übers Netzwerk macht es Sinn sich Clevis & Tang anzuschauen. Ganz einfach über docker aufzusetzen. Der Boot Server/PC stellt dann die Anfrage und nicht anders herum. Man kann damit auch Virtuelle Maschinen entschlüsseln.

 

[DFFVB]

@Nero1 Danke das ist ein guter Startpunkt, re Script bin ich nicht sicher, ob das schon abgerufen werden kann?


@tdbr Laut dem Link ist da snoch experimentell, aber das ist für mich der ideale Kompromiss aus Sicherheit und Komfort. Kannst Du zufällig sagen, ob die ANmeldung einen Brute Force Schutz hat? Bei Winwods ist es wohl so: Bitlocker TPM + PIN: Brute Force Schutz. TPM + Passowort (bei Boot) kein Schutz. TPM und Anmeldescreen = Brute Force, ABER cold boot Attacke anfällig.

Das TPM rückt einfach mal so den Key für die Platten raus?

Tut es, ggf in abhängigkeit von Secure Boot und geänderter HArdware auch nicht.

Warum möchtest du das eigentlich per Cron machen, @DFFVB?

In erster Linie um Strom zu sparen :-)

Ein Cronjob weiß nicht, ob das Gerät an ist

Der Futro geht per Zeitschaltuhr an, also wenn der um 07:15 Uhr angeht, und davor ein NUC der mit Bitlokcer verschlüsselt ist, kann der aus einer Linux VM den Befehl senden

oder ob der Futro einfach so das Passwort anfragen kann torpedierst du damit doch total den Sicherheitsgewinn deiner Verschlüsselung.

Bedenke dass das initramfs unverschlüsselt ist. Wenn du also auf den initramfs-dropbear verbindest kannst du nicht wissen ob das initramfs manipuliert wurde mit einem Keylogger oder ob jemand einfach die SSH private keys aus dem initramfs kopiert hat und deine Verbindung MITM'ed.

Jein, Du meinst, in jedem Szenario wo ich es nicht am Gerät selber eingebe? Dann ja. Remote sehe kaum ein anderes Risiko als wenn ich es händisch mache? Und ist mir MITM nicht egal wenn der private Key auf entsperrenden Gerät liegt und der Futro lediglich den Public Key hat?

Ich gehe beim Bedrohungsszenario hier hauptsächlich von nem Einbrecher aus, der das Ding mitnimmt.

Korrekt

Clevis & Tang

Guter Tipp schau ich mir mal an. Danke

 

[Marco01_809]

Jein, Du meinst, in jedem Szenario wo ich es nicht am Gerät selber eingebe? Dann ja. Remote sehe kaum ein anderes Risiko als wenn ich es händisch mache? Und ist mir MITM nicht egal wenn der private Key auf entsperrenden Gerät liegt und der Futro lediglich den Public Key hat?

Jeder SSH-Server hat auch private keys (die sog. host keys). Daran erkennt der Client den Server wieder - die public keys (bzw. dessen fingerprints) werden bei der ersten Verbindung in der known_hosts Datei gespeichert um den Server wiederzuerkennen und MITM-Angriffe auszuschließen. Die private keys vom dropbear liegen unverschlüsselt im initramfs.

 

[foofoobar]

Tut es, ggf in abhängigkeit von Secure Boot und geänderter HArdware auch nicht.

Klingt scheiße und wirr und ist es wahrscheinlich auch weil man Wissen und Besitz ohne Wissen implementieren möchte, das kann nur in die Hose gehen.

 

[DFFVB]

werden bei der ersten Verbindung in der known_hosts Datei gespeichert

Ja aber das spuckt ja openssh einen Fehler aus, wenn sich der ändert?

Klingt scheiße und wirr und ist es wahrscheinlich auch

Also wnen man bendekt, dass Du das Konzept bis vor kurzem gar nicht kanntest und nun etwas, sind das gewagte Aussagen :-)