Disk Image Debian Linux

[Lars S. (Gast)]

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.

[Klaus W. (mfgkw)]

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.

[Εrnst B. (ernst)]

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.

[pp (Gast)]

Schau mal nach REAR - Relax and Recover...

[🐧 DPA 🐧 (Gast)]

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):

#!/bin/bash
set -e

# Parameter prüfen
device="$1"
image="$2"
if [ $# -lt 2 ] || [ ! -f "$device" ] || [ -z "$image" ]
then
  echo "Usage: $0 /dev/sdX image.img"
  exit 1
fi
device="$(realpath "$device")"
image="$(realpath "$image")"

set -x

# Arbeitsverzeichnis erstellen
tmproot="$(mktemp -d)"
cd "$tmproot"

cleanup(){
  set +e
  for x in t/* o/*
    do umount "$x" || true
  done
  rm -rf t o
  if [ -n "$loop" ]; then losetup -D "$loop"; fi
}
trap cleanup EXIT INT TERM

# Image & partitionen erstellen & file locken
size="$(blockdev --getsize64 "$device")"
exec 5<>"$image"
flock -n 5 || ( echo "Error: image file already in use" >&2; exit 1; )
truncate -s "$image"
sfdisk -d "$device" | sfdisk "$image"

# Image mounten
loop="$(losetup -Pf --show "$image")"
porig=( "$device"?* )
ploop=( "$loop"?* )

if [ "${#porig[@]}" != "${#ploop[@]}" ]
then
  echo "Error: OS Detected number of partitions missmatches" >&2
  exit 1
fi

copy_part(){
  mkdir "o/$i"
  mkdir "t/$i"
  mount "$orig" "o/$i"
  mount "$target" "t/$t"
  cp --archive --one-file-system "o/$i/./" "t/$t/"
  umount "o/$i"
  umount "t/$i"
}

# Partitionen anlegen & kopieren
i=0
n="${#porig[@]}"
while [ "$i" -le "$n" ]
do (
  orig="${porig[$i]}"
  target="${ploop[$i]}"
  eval "$(blkid -p "$target" | sed "s/^[^:]*: //")"
  case "$TYPE" in
    "swap") mkswap "$target";;
    "crypto_LUKS") ;; ## TODO. looksOpen usw.
    "") echo "Ignoring $orig";;
    ext4)  mkfs.ext4 -U "$UUID"; copy_part ;;
    *) echo "Warning: Don't know what to do with $TYPE: $orig" ;;
  esac
); done

[Nop (Gast)]

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.

[Klaus W. (mfgkw)]

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).

[(prx) A. K. (prx)]

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.

[Norbert (Gast)]

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.

[Εrnst B. (ernst)]

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.

[Norbert (Gast)]

Ε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.

$ pv </dev/urandom >/dev/null
2,90GiB 0:00:10 [ 296MiB/s] [      <=>      ]

Ach, ich kann nicht klagen… ;-)

[(prx) A. K. (prx)]

Das kann von Kernelversion und Processor abhängen.

[Norbert (Gast)]

(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?

[Εrnst B. (ernst)]

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

# cryptsetup benchmark
...
#   Algorithmus | Schlüssel | Verschlüsselung | Entschlüsselung
        aes-cbc        128b      1178,9 MiB/s      3451,0 MiB/s
    serpent-cbc        128b        96,6 MiB/s       751,9 MiB/s
    twofish-cbc        128b       216,1 MiB/s       394,1 MiB/s
        aes-cbc        256b       886,7 MiB/s      2780,8 MiB/s
    serpent-cbc        256b       100,6 MiB/s       749,2 MiB/s
    twofish-cbc        256b       221,6 MiB/s       391,5 MiB/s
        aes-xts        256b      3166,7 MiB/s      3071,9 MiB/s
    serpent-xts        256b       725,2 MiB/s       715,6 MiB/s
    twofish-xts        256b       397,8 MiB/s       399,7 MiB/s
        aes-xts        512b      2582,6 MiB/s      2635,1 MiB/s
    serpent-xts        512b       730,5 MiB/s       718,8 MiB/s
    twofish-xts        512b       397,7 MiB/s       397,2 MiB/s


# 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


# dd if=/dev/zero of=/dev/null bs=1M count=10240 
..
10737418240 Bytes (11 GB, 10 GiB) kopiert, 0,491239 s, 21,9 GB/s

[Norbert (Gast)]

Ε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.

[(prx) A. K. (prx)]

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.

[Norbert (Gast)]

(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…

[(prx) A. K. (prx)]

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.

[Norbert (Gast)]

(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… ;-)

[(prx) A. K. (prx)]

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)

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Ε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.

[Εrnst B. (ernst)]

(prx) A. K. schrieb:
> Hier wirds bizarr.

durchaus:

AMD EPYC 7452      :  47,7 MB/s
AMD EPYC 7402      :  15,6 MB/s
XEON E5-2630 v3    : 224,0 MB/s
Ryzen 5 3400G      :  38,8 MB/s
XEON Silver 4114   : 147,0 MB/s
i7-6700K           :  38,1 MB/s
i7-8550U (*)       :  37,7 MB/s

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...

[Norbert (Gast)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Ε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

[Εrnst B. (ernst)]

(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...

[Norbert (Gast)]

(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.

[(prx) A. K. (prx)]

Ε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.

[(prx) A. K. (prx)]

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.

[Εrnst B. (ernst)]

(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...