Lege doch einfach einen Container oder Partition an und nutze dort eine Verschlüsselung.

https://wiki.ubuntuusers.de/LUKS/

Hi, mit Luks bekommst du eine "Data-at-rest encryption".

Für welches Szenario soll das helfen, bei einem Server, der vermutlich permanent durchläuft ?

Server ist aus: ok, Daten sind sicher, keiner kommt dran, aber auch du nicht. Dafür kaufst du aber keinen RS8000

Server ist an: Daten sich für den User lesbar, sind für root lesbar, sind theoretisch für netcup lesbar, ist für Malware lesbar.

Netcup könnte einfach ein RAM dump machen und den Schlüssel auslesen oder die mirrorn einfach dein VM. Wie ulf8000 schon bereits erwähnt hatte, sind die Daten nur Encrypted at rest. Ich bezweifle stark das du für über 50 Euro im Monat einen Server anmietest um den Server ausgeschaltet zu lassen.

Mit der Verschlüsselung ist der Festplatteninhalt allerdings überall geschützt, wo er losgelöst vom Hostsystem gespeichert oder übertragen wird, z.B. im SAN, in Backups, auf defekten ausgetauschten Festplatten...

Zitat von X-Nightmare-X

Sorgt für ein ruhiges Gewissen, sagen zu können, dass alles voll verschlüsselt ist.

Nein ... sorgt nur für eine Scheinsicherheit, wenn Du Dir nicht genau bewusst bist, gegen welche Angriffsvektoren die eingesetzte Verschlüsselung schützt. Und ein eingebildeter Schutz ist manchmal gefährlicher als ein bewusstes Risiko.

Ich bin kein Feind von Verschlüsselung per se, aber die "Vollverschlüsselung" eines laufenden Servers schützt nur vor wenigen Szenarien, erhöht aber Komplexität und damit das Betriebsrisiko.

Ich würd's mir überlegen...

Es ist aber eine "Scheinsicherheit". Daran gibt es nichts zu rütteln. Statt Veracrypt könntest du aber auch auf Rclone mit der crypt Funktion zurückgreifen.

Bitte auch berücksichtigen, dass durch eine Vollverschlüsselung der Server nicht mehr bootfest ist. Du wirst das Passwort dann bei jedem Start eingeben müssen, also bei jedem Patching oder Neustart. Dafür musst du dich dann jedes Mal im SCP einloggen und die VNC Konsole bedienen. Da diese für solche Eingaben ein wenig umständlich ist, wird das dazu führen, dass du hier ein sehr einfaches Passwort wählen wirst, was der Sicherheit der Verschlüsselung nicht gerade zuträglich ist. Das will sich eigentlich niemand freiwillig antun für einen solch marginalen Nutzen.

Data at-rest encryption ist bei diversen Cloudanbietern Standard und das ist auch gut so. Mir sträuben sich die Fußnägel, wenn ich hier etwas von Scheinsicherheit lese. Gerade beim Verarbeiten von Block- / Objektstorage in Form von Snapshots oder Backups macht das nämlich absolut Sinn.

Zitat von dodeka

Data at-rest encryption ist bei diversen Cloudanbietern Standard und das ist auch gut so. Mir sträuben sich die Fußnägel, wenn ich hier etwas von Scheinsicherheit lese. Gerade beim Verarbeiten von Block- / Objektstorage in Form von Snapshots oder Backups macht das nämlich absolut Sinn.

Snapshots oder Backups zu verschlüsseln ist auch vollkommen legitim. Backups vom Server zu machen und das z.B. mithilfe von Rclone und Crypt auf einen anderen Cloudanbieter zu transferieren macht Sinn weil der andere Cloudanbieter keinen Zugriff auf deinen Schlüssel hat. Das ist absolut nicht vergleichbar mit der Situation von OP.

Spezifiziere doch mal lieber den Angriffsvektor wovor du dich schützen willst.

Zitat von Hamsterbacke

Das ist absolut nicht vergleichbar mit der Situation von OP.

Stimmt, da hast du recht! Ich ging davon aus, dass die Snapshots nicht auf dem Server selbst gespeichert werden. Habe mir erst jetzt die Produktseite angeschaut.😑

Zitat von Paul

Dafür musst du dich dann jedes Mal im SCP einloggen und die VNC Konsole bedienen. Da diese für solche Eingaben ein wenig umständlich ist, wird das dazu führen, dass du hier ein sehr einfaches Passwort wählen wirst, was der Sicherheit der Verschlüsselung nicht gerade zuträglich ist. Das will sich eigentlich niemand freiwillig antun für einen solch marginalen Nutzen.

Das ist so nicht ganz korrekt. Es gibt auch Möglichkeiten einen rudimentären SSH-Server beim Bootvorgang zu starten, der das Passwort entgegen nimmt, sodass das SCP gar nicht verwendet werden muss. Auch funktioniert so das Copy-Pasten von Passwörtern wunderbar. (Für die, die es noch nicht kennen: Ich rede von Dropbear-SSH und dessen initramfs-Konfiguration. Verwende ich auf verschiedenen physischen Hosts ohne Probleme.)

Auch meine ich mal gelesen zu haben, dass es Möglichkeiten gibt, dass der verschlüsselte Server sich seinen Key bei einer vertrauenswürdigen Stelle beim Booten abholt, aber damit kenne ich mich nicht aus.

Zitat von cltrmx

dass der verschlüsselte Server sich seinen Key bei einer vertrauenswürdigen Stelle beim Booten abholt

Z.b. clevis und hier beim server-szenario mit tang

Zitat von dodeka

Data at-rest encryption ist bei diversen Cloudanbietern Standard und das ist auch gut so.

Welche wären das?

Zitat von cltrmx

Auch meine ich mal gelesen zu haben, dass es Möglichkeiten gibt, dass der verschlüsselte Server sich seinen Key bei einer vertrauenswürdigen Stelle beim Booten abholt, aber damit kenne ich mich nicht aus.

Vgl. bei Interesse an Clevis/Tang auch meine Beiträge hier im Forum.

Persönlich bin ich auch ein großer Freund von voll verschlüsselten Platten.
Man kann den Key auch direkt mit in /boot oder so speichern.
Dann "kann" der Hoster die Daten zwar entschlüsseln, aber die Daten liegen nicht automatisch und ohne Aufwand "blank" auf der Platte und werden zufällig mal gefunden.

Aber, wie hier schon mehrfach geschrieben wurde, erhöht das auf keine weise die Sicherheit.

Am Ende kann man auch sagen, dass services die permanent laufen sollen, sollten nicht auf voll-verschlüsselten Platten laufen sollten und Daten die Verschlüsselt sein sollten, sollten nicht auf einem vServer laufen

Zitat von Homwer

[…] Daten die Verschlüsselt sein sollten, sollten nicht auf einem vServer laufen

Es wird noch eine Weile dauern, bis diese Generation bei Massenhostern ankommt, aber die neuen Serverprozessoren sorgen dafür, dass Daten auch im laufenden Betrieb besser geschützt/verschlüsselt sind (vgl. "Ampere Strategy & Product Roadmap Update, 2023 [00:17:35]"), was den Abstand bzgl. Sicherheit zwischen einer angemieteten VM und echtem Blech im Käfigen, zu welchen man selbst den Schlüssel besitzt, verringern wird.

Es muss ja auch nicht unbedingt eine "Vollverschlüsselung" sein,

je nach Anwendungsfall reicht es ja auch auch nur die Daten, z.B. die Kundendaten zu verschlüsseln.

Das gilt auch für Datenbanken, Stichwort SQL-Funktion AES_ENCRYPT().

Zitat von cltrmx

Es gibt auch Möglichkeiten einen rudimentären SSH-Server beim Bootvorgang zu starten, der das Passwort entgegen nimmt[.]

Absolut richtig, habe ich selber spaßeshalber mal für ein mit LUKS verschlüsseltes System durchexerziert. Ich dumpe hier einfach mal meine Notizen dazu:

Dropbear für Remote-Unlocking verschlüsselter Festplatten

Benötigt werden die Pakete dropbear und dropbear-initramfs, welche ihre Konfigurationsdateien im Ordner /etc/dropbear/ bzw. /etc/dropbear/initramfs/ hinterlegen.

# auf Debian basierten Systemen
sudo apt install dropbear dropbear-initramfs

# auf RHEL basierten Systemen
sudo dnf install dropbear

Einrichtung

Nach Installation müssen die Start-Optionen angepasst und ein SSH-Schlüssel angelegt werden.

Optionen

In /etc/dropbear/initramfs/dropbear.conf wird die Zeile mit #DROPBEAR_OPTIONS= entkommentiert und die Optionen -s und -c cryptroot-unlock angefügt, um eine Passwort-Authentifikation zu verhindern und bei Verbindung das cryptroot-unlock Kommando zu erzwingen.

Am Ende sollte dort so etwas wie DROPBEAR_OPTIONS='-s -c cryptroot-unlock' stehen, eventuell ergänzt um weitere Optionen.

sed -i "s/#DROPBEAR_OPTIONS=/DROPBEAR_OPTIONS='-s -c cryptroot-unlock'/"

Möglicherweise muss auf dem Server noch eine IP-Adresse und ein Hostname konfiguriert werden. Bei mir läuft das aber über meinen Router, der eine statische IP anhand der MAC-Adresse vergibt.

Schlüssel

Die Schlüssel für Dropbear liegen in /etc/dropbear/ und /etc/dropbear/initramfs/ und haben die Form dropbear_<algorithm>_host_key.

Wir benutzen dieselben Keys wie OpenSSH, um nicht verschiedene Keys für den Host zulassen zu müssen.

Zunächst sollten die alten Keys gelöscht werden.

rm /etc/dropbear/dropbear_*_host_key
rm /etc/dropbear/initramfs/dropbear_*_host_key

Nun werden mit dropbearconvert die gewünschten OpenSSH-Keys (bei mir nur ed25519) in das Dropbear-Format überführt und im initramfs Verzeichnis hinterlegt und zusätzlich eine authorized_keys Datei angelegt. Wo die zugelassenen Schlüssel herkommen muss natürlich individuell angepasst werden.

dropbearconvert openssh dropbear /etc/ssh/ssh_host_ed25519_key /etc/dropbear/initramfs/dropbear_ed25519_host_key
cp ~/.ssh/authorized_keys /etc/dropbear/initramfs/authorized_keys

Anschließen wird das initramfs regeneriert, um die Änderungen anzuwenden und ein Neustart durchgeführt, um die Funktion zu testen.

update-initramfs -u
reboot

Danach kann auf dem Client ein Verbindungsversuch gestartet werden.

ssh -4 root@host

Ich muss mit -4 IPv4 erzwingen, ansonsten funktioniert es in meinem Netzwerk nicht.