Kennt jemand eine Möglichkeit ein komplettes System, welches mit LUKS
verschlüsselt ist live zu sichern? Also so, dass man das erzeugte Image
nur noch kopieren muss und auf einem neuen PC wieder starten kann, falls
der alte defekt ist?
Wenn das nicht live geht wäre mit auch eine nicht live Lösung recht. Ich
sehe das Problem bei live Systemen, dass man sicherstellen muss, dass
während eines Backups nicht auf die Platte geschrieben wird. Ich meine
mich zu erinnern, dass es dafür Dateisysteme gibt, die sowas können.
Das wird gehen mit jeder Linux-Live-CD.
Darin dann suchen, welche Platte gesichert werden soll (bspw. /dev/sda),
eine weitere externe formatierte und mit irgendeinem Linux-Dateisystem
(ext2/4 oder ähnliches) mounten (z.B. /dev/sdb1 nach /media/blabla) und
dann kopieren mit dd.
Sinnvoll ist es bestimmt, das kopierte Image gleich zu komprimieren.
Das könnte insgesamt so aussehen:
dd if=/dev/sda | gzip -9 >
/media/blabla/meine_Sicherung_vom_01.06.2022.image.gz
Ein solches Image könnte man umgekehrt wieder mit einer Live-CD auf
dieselbe oder eine mindestens gleich große Platte zurück kopieren.
Lars S. schrieb:> Wenn das nicht live geht wäre mit auch eine nicht live Lösung recht. Ich> sehe das Problem bei live Systemen, dass man sicherstellen muss, dass> während eines Backups nicht auf die Platte geschrieben wird. Ich meine> mich zu erinnern, dass es dafür Dateisysteme gibt, die sowas können.
das geht per Snapshot.
Wenn dein LUKS-Image auf einer LVM-VG liegt, "sync", snapshot anlegen,
snapshot-image wegsichern, snapshot auflösen.
Ja, das image ist dann nicht 100%ig sauber, weil es "im Betrieb" mit
offenen Dateien etc. gezogen wurde. Ein Journaling-Dateisystem kommt
damit aber klar.
Und das Restore ist leider nicht ganz so einfach, das image ist nicht
direkt startfähig, sondern muss erst wieder in ein LVM-Setup
zurückgespielt werden...
Eine Lösung wäre, die Backup-Platte soweit mit LVM und allem
vorzubereiten, und beim Backup-Erstellen jeweils nur das verschlüsselte
LV am Backup aus dem Snapshot zu aktualisieren.
Das ganze live zu machen dürfte schwierig sein. Da müsste man ja
eigentlich auf Dateiebene arbeiten, und das Image quasi nachbauen.
Mir fällt da gerade nichts fertiges ein. Eventuell selbst ein Script
schreiben. Irgendwie so (ungetestet und unfertig):
1
#!/bin/bash
2
set-e
3
4
# Parameter prüfen
5
device="$1"
6
image="$2"
7
if[$# -lt 2 ]||[!-f"$device"]||[-z"$image"]
8
then
9
echo"Usage: $0 /dev/sdX image.img"
10
exit 1
11
fi
12
device="$(realpath"$device")"
13
image="$(realpath"$image")"
14
15
set-x
16
17
# Arbeitsverzeichnis erstellen
18
tmproot="$(mktemp-d)"
19
cd"$tmproot"
20
21
cleanup(){
22
set +e
23
for x in t/* o/*
24
do umount "$x"||true
25
done
26
rm-rf t o
27
if[-n"$loop"];then losetup -D"$loop";fi
28
}
29
trap cleanup EXIT INT TERM
30
31
# Image & partitionen erstellen & file locken
32
size="$(blockdev --getsize64"$device")"
33
exec 5<>"$image"
34
flock -n 5 ||(echo"Error: image file already in use">&2;exit 1;)
35
truncate-s"$image"
36
sfdisk -d"$device" | sfdisk "$image"
37
38
# Image mounten
39
loop="$(losetup -Pf--show"$image")"
40
porig=("$device"?*)
41
ploop=("$loop"?*)
42
43
if["${#porig[@]}"!="${#ploop[@]}"]
44
then
45
echo"Error: OS Detected number of partitions missmatches">&2
46
exit 1
47
fi
48
49
copy_part(){
50
mkdir"o/$i"
51
mkdir"t/$i"
52
mount "$orig""o/$i"
53
mount "$target""t/$t"
54
cp--archive--one-file-system"o/$i/./""t/$t/"
55
umount "o/$i"
56
umount "t/$i"
57
}
58
59
# Partitionen anlegen & kopieren
60
i=0
61
n="${#porig[@]}"
62
while["$i"-le"$n"]
63
do(
64
orig="${porig[$i]}"
65
target="${ploop[$i]}"
66
eval"$(blkid -p"$target" | sed"s/^[^:]*: //")"
67
case"$TYPE"in
68
"swap") mkswap "$target";;
69
"crypto_LUKS");;## TODO. looksOpen usw.
70
"")echo"Ignoring $orig";;
71
ext4) mkfs.ext4 -U"$UUID"; copy_part ;;
72
*)echo"Warning: Don't know what to do with $TYPE: $orig";;
Klaus W. schrieb:> Sinnvoll ist es bestimmt, das kopierte Image gleich zu komprimieren.
Im Prinzip leistet Clonezilla live von USB gebootet genau sowas schon -
Komprimierung wird aber nicht gehen, wenn die Platte verschlüsselt ist,
weil das dann wie Rauschen aussieht (und auch so soll).
Komprimierung wäre nur möglich, wenn man das entschlüsselte Dateisystem
sichert, aber eine unverschlüsselte Kopie herumfliegen zu haben
konterkariert ja den Zweck der Verschlüsselung.
Nop schrieb:> Komprimierung wäre nur möglich, wenn man das entschlüsselte Dateisystem> sichert, aber eine unverschlüsselte Kopie herumfliegen zu haben> konterkariert ja den Zweck der Verschlüsselung.
Mag sein.
Wobei ich nicht weiß, ob bislang unbenutzte Bereiche bei einer
verschlüsselten Partition nicht doch vom Komprimieren profitieren;
müsste man probieren.
Schaden wird es jedenfalls nichts (außer der vielleicht verschwendeten
Rechenzeit).
Klaus W. schrieb:> Wobei ich nicht weiß, ob bislang unbenutzte Bereiche bei einer> verschlüsselten Partition nicht doch vom Komprimieren profitieren;> müsste man probieren.
Dazu muss das Kopierprogramm die Filesystem-Struktur analysieren können.
Das funktioniert aber nur bei Fileverschlüsselung wie z.B. in ecryptfs,
nicht aber bei einer Volume- oder Diskverschlüsselung wie LUKS.
Wenn man eine Partition komplett mit 0x00 beschreibt und dann einen LUKS
Container mit extx anlegt, dann werden nur die dabei geschriebenen
Blöcke verschlüsselt angelegt. Der Rest bleibt 0x00.
Ein Image dieser Partition - obwohl verschlüsselt - ließe sich
komprimieren. Oder auch als ›sparse‹-Datei kopieren.
Ein Angreifer sähe jedoch die Struktur und könnte Rückschlüsse ziehen.
Will man's sicher haben, so füllt man die Partition zuvor von
/dev/random und legt den LUKS Container dann an. Da ist dann aber nix
mehr mit komprimieren.
Norbert schrieb:> Will man's sicher haben, so füllt man die Partition zuvor von> /dev/random und legt den LUKS Container dann an. Da ist dann aber nix> mehr mit komprimieren.
Schneller: Man legt den Luks-Container an, und befüllt den dann mit
0x00, und legt dann das Dateisystem darauf an.
Verschlüsseln geht deutlich schneller als Zufallszahlen aus /dev/random
zu ziehen, selbst wenn man /dev/urandom verwendet.
Εrnst B. schrieb:> Schneller: Man legt den Luks-Container an, und befüllt den dann mit> 0x00, und legt dann das Dateisystem darauf an.>> Verschlüsseln geht deutlich schneller als Zufallszahlen aus /dev/random> zu ziehen, selbst wenn man /dev/urandom verwendet.
(prx) A. K. schrieb:> Das kann von Kernelversion und Processor abhängen.
Wenn der Prozessor zu lahmarschig ist, wird's mit der Verschlüsselung
auch nicht besser und schneller.
Die Frage ist doch eher: Wie oft am Tage legt man wie viele LUKS
Container an?
Norbert schrieb:> Ach, ich kann nicht klagen(prx) A. K. schrieb:> Das kann von Kernelversion und Processor abhängen.
Hier, am Desktop, i7-6700K, debian bullseye default kernel
Εrnst B. schrieb:> dd if=/dev/random of=/dev/null bs=1M count=1024 status=progress> 1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 28,6901 s, 37,4 MB/s>> dd if=/dev/urandom of=/dev/null bs=1M count=1024 status=progress> 1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 28,3858 s, 37,8 MB/s
Das sieht aber wirklich verdächtig schlecht aus.
Ich habe hier einen deutlich lahmeren Prozessor (i5-3470) und ebenfalls
ein Debian (old-stable) System:
$ uname -a
Linux x 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64
GNU/Linux
$ cat /etc/debian_version
10.12
Wieso sollte das zehnmal schneller sein?
Im übrigen gehört zur Performance-Beurteilung auch immer das Ziel.
Festplatten: ~150…200MB/s
SATA III: <= 580MB/s
Erst darüber wird es dann so schnell, das es interessant wird.
Ach die Jugend, Ungeduld ist ihre Tugend. ;)
Halten wir fest: Wie immer hier im Forum haben alle ein wenig Recht.
Immer aus ihrem jeweiligen Blickwinkel.
Norbert schrieb:> Wenn der Prozessor zu lahmarschig ist, wird's mit der Verschlüsselung> auch nicht besser und schneller.
Der Support für entsprechende Befehle ist nicht für alle Prozessoren
gegeben, sowohl für AES als auch für Zufallserzeugung. Und das kann es
bedeuten, dass ein lahmarschiger Prozessor der Atom-Reihe schneller ist,
weil der die Befehle hat, der Mainstream-Prozessor aber nicht, oder
deaktiviert.
(prx) A. K. schrieb:> Norbert schrieb:>> Wenn der Prozessor zu lahmarschig ist, wird's mit der Verschlüsselung>> auch nicht besser und schneller.>> Der Support für entsprechende Befehle ist nicht für alle Prozessoren> gegeben, sowohl für AES als auch für Zufallserzeugung. Und das kann es> bedeuten, dass ein lahmarschiger Prozessor der Atom-Reihe schneller ist,> weil der die Befehle hat, der Mainstream-Prozessor aber nicht, oder> deaktiviert.
Womit bewiesen ist das es fast immer irgendwelche Sonderfälle gibt die
eine Argumentation stützen. Man muss nur suchen und finden.
Just saying…
Norbert schrieb:> Ich habe hier einen deutlich lahmeren Prozessor (i5-3470)
Der hat AES-NI. Bei manch anderem Prozessor mit dem Ivy Bridge Core,
etwa dem Pentium G2020, in vielen billigen Office-Desktops zu finden,
sind diese Befehle deaktiviert. Bei dem Silvermont-Atom Z3775 des
gleichen Jahrgangs, für Tablets gebaut und an sich viel langsamer, ist
AES-NI hingegen drin.
(prx) A. K. schrieb:>> i5-3470> Der hat AES-NI. Bei manch anderem Prozessor mit dem Ivy Bridge Core,> etwa dem Pentium G2020, sind diese Befehle deaktiviert. Bei dem> Silvermont-Atom Z3775 des gleichen Jahrgangs, für Tablets gebaut und an> sich viel langsamer, ist AES-NI hingegen drin.
Na dann ist die Lösung ja ganz einfach. Den LUKS-Container auf dem
Tablett erzeugen und per Bluetooth zum Pentium senden… ;-)
Norbert schrieb:> Na dann ist die Lösung ja ganz einfach. Den LUKS-Container auf dem> Tablett erzeugen und per Bluetooth zum Pentium senden… ;-)
Die Random-Erzeugung ist in der gleichen AES-NI Befehlsgruppe wie die
AES Verschlüsselung. Das Tablet randomt nicht nur schneller, es
enc/decrypted auch schneller, wenn man den richtigen Algorithmus
verwendet hat. ;-)
Man sieht hier ja recht deutlich, wo Hardware wo Software:
Εrnst B. schrieb:> aes-cbc 128b 1178,9 MiB/s 3451,0 MiB/s (HW)> serpent-cbc 128b 96,6 MiB/s 751,9 MiB/s (SW)
Netbook mit N3350 (Goldmont Atom), ein Tablet-Prozessor
aes-cbc 128b 437,3 MiB/s 823,4 MiB/s (HW)
serpent-cbc 128b 42,7 MiB/s 143,2 MiB/s (SW)
Athlon II Neo N36L im HP Microserver:
aes-cbc 128b 75,5 MiB/s 84,3 MiB/s (SW)
Der HP Microserver liest eine externe USB-3 Disk mit 190 MB/s
unverschlüsselt, aber verschlüsselt verbleiben davon nur 62 MB/s, weil
der Prozessor zu langsam ist. Das Netbook hätte damit kein Problem.
Εrnst B. schrieb:> # dd if=/dev/urandom of=/dev/null bs=1M count=1024 status=progress> ..> 1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 28,3858 s, 37,8 MB/s
Hier wirds bizarr. Denn der olle Athlon, der bei AES unter alles Sau
schleicht, wirft dabei 122 MB/s aus. Ein i7 4770 liegt bei 267 MB/s:
i7-4770 267 MB/s
Athlon N36L 122 MB/s
i7-1165G7 86 MB/s
Als Benchmark sind /dev/(u)random offensichtlich hoffnungslos.
Den i7-8550U habe ich unter Windows11 in einer WSL2-VM vermessen,
insofern ist der Wert außer Konkurrenz.
Schaut aber so aus als hätte Intel bei der "urandom"-Performance die
Nase vorne. Nur bei meinem Desktop i7-6700K nicht...
Kann das vielleicht mit diesen ganzen unsäglichen Microcode Mitigations
zusammen hängen die über die neueren Prozessoren hereingebrochen sind?
Die, welche die enorme Menge an gravierenden Sicherheitsmängeln
zumindest etwas abschwächen sollen?
Nur mal so ins Unreine gedacht, da hier selbst ein ur-uralter Pentium-M
1.866GHz single core Laptop-Prozessor bei ~ 80MB/s liegt.
Norbert schrieb:> Kann das vielleicht mit diesen ganzen unsäglichen Microcode Mitigations
Diese beiden EPCY 2 sind sich recht ähnlich:
> AMD EPYC 7452 : 47,7 MB/s> AMD EPYC 7402 : 15,6 MB/s
Ich vermute, dass irgendwelche Kernel-Einstellungen und -Versionen mit
hinein spielen. Auf dem gleichen EPYC 2 gab es bei zwei verschiedenen
Distros zwar den gleichen Wert für /dev/urandom, aber bei einem davon
brach /dev/random um Faktor 3 ein. Das ist weder mit Microcode noch mit
Hardware erklärbar.
> Nur mal so ins Unreine gedacht, da hier selbst ein ur-uralter Pentium-M> 1.866GHz single core Laptop-Prozessor bei ~ 80MB/s liegt.
Eine gewisse zeitliche Verwandschaft sollte der Kernel schon haben. Die
Ansprüche an RNGs sind im Cryptozeitalter drastisch gestiegen, was zu
diversen Arbeiten am Linux-RNG führte.
Εrnst B. schrieb:> AMD EPYC 7452 : 47,7 MB/s> AMD EPYC 7402 : 15,6 MB/s
Sowohl /dev/random und /dev/urandom gemessen? Ich habe auf dem gleichen
EPYC 7742 unter zwei verschiedenen Linuxen gemessen.
Linux 1: /dev/urandom ~ 48 MB/s, /dev/random ~ 48 MB/s
Linux 2: /dev/urandom ~ 48 MB/s, /dev/random ~ 16 MB/s
(prx) A. K. schrieb:> Ich vermute, dass irgendwelche Kernel-Einstellungen und -Versionen mit> hinein spielen.
Kann auch an der sonstigen Last auf den Kisten liegen... die stehen ja
nicht nur zum Spaß rum, sondern hatten neben /dev/urandom auch noch
unterschiedlich viel Anderes zu tun...
(prx) A. K. schrieb:> Eine gewisse zeitliche Verwandschaft sollte der Kernel schon haben. Die> Ansprüche an RNGs sind im Cryptozeitalter drastisch gestiegen, was zu> diversen Arbeiten am Linux-RNG führte.
Ist zwar ein Laptop von - ich glaube 2009 - aber das Debian Linux ist
recht frisch, na ja halb-frisch, Version 10, Buster, old-stable. Wird
auch noch mit Updates versorgt.
Εrnst B. schrieb:> Kann auch an der sonstigen Last auf den Kisten liegen
In meinem Fall nicht. Klar, die sind am arbeiten, aber für einen aktiven
Core war reichlich genug Luft.
Norbert schrieb:> Ist zwar ein Laptop von - ich glaube 2009 - aber das Debian Linux ist> recht frisch, na ja halb-frisch, Version 10, Buster, old-stable. Wird> auch noch mit Updates versorgt.
Passt insoweit zu meinem Athlon. Demjenigen, der bei Randoms brilliert
aber bei AES durchfällt. Auch da läuft noch Debian 10, allerdings die
64-Bit Version.
(prx) A. K. schrieb:> In meinem Fall nicht. Klar, die sind am arbeiten, aber für einen aktiven> Core war reichlich genug Luft.
stimmt natürlich.
hab nochmal am EPYC 7452 geschaut, der ist hauptsächlich PCIe & IO-mäßig
gefordert (12×NVMe), die CPUs langweilen sich.
/dev/urandom: 47,7 MB/s
/dev/random: < 0.1 kB/s (da hab ich wohl den Entropy-Pool geleert. Ups.)
Es wird also wohl keine HW-Beschleunigung genutzt, trotz "rdrand" in den
cpuinfo-flags
Kernel ist ein 5.4.0-ubuntu.
Norbert schrieb:> Kann das vielleicht mit diesen ganzen unsäglichen Microcode Mitigations
Möglich.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543
Könnte dazu geführt haben, dass der HW-RNG nicht mehr so gerne verwendet
wird...
