Das Rootserver-Experiment

Erlebnisse eines Rootserver (Beinahe-) Neulings

Verantwortlich für den Inhalt dieser Seite ist Mattias Schlenker, Inhaber Mattias Schlenker IT-Consulting Mattias Schlenker work Dietrich-Bonhoeffer-Str. 3, 40667 Meerbusch. Germany work Fon +49 341 39290767. Meine USt-ID (VATIN) lautet: DE240998538. http://www.mattiasschlenker.de

Diese Seite läuft unter Wordpress 2.x.x. News und Kommentare können als RSS-2.0-Feed abonniert werden.

Linux: Verschlüsselte und komprimierte Backups auf DVD

Ich sichere nach wie vor geschäftsrelevante Daten auf DVD, allerdings stellte mich keine der fertigen Lösungen vollkommen zufrieden. Meine Anforderungen:

  • Starke Verschlüsselung: Das Backup muss sicherer sein als diese unsägliche ZIP-Verschlüsselung hinreichend sicher sein und ein statistischer Angriff soll keinen Erfolg versprechen.

  • Gute Komprimierung: Ich möchte in kurzer Zeit das Backup klein eindampfen können und beim Zugriff effizient entpacken, also nur die Dateien, die ich benötige.

  • Mountbares Backup: Ganz ohne vorheriges Entpacken soll ein sofortiger Zugriff auf alle Dateien im Backup möglich sein.

  • Keine unverschlüsselten temporären Dateien: Weder beim Packen noch beim Entpacken sollen unverschlüsselte temporäre Dateien anfallen, einerseits aus Sicherheitsgründen, andererseits weil eine temporäre Datei auf einem zufällig verschlüsselten Dateisystem Prozessorlast erzeugt.

Bis vor kurzem habe ich einfach Archive mit Tarballs mit Twofish verschlüsselt (openssl bietet ein komfortables Subkommando) und diese auf DVD gebrannt. Neben den oben genannten Nachteilen kam das Problem dazu, dass auf einem ISO-9660-Dateisystem die Dateigrößengrenze bei 2GB lag.

Meine Lösung sah eine Kombination aus bekannten Technologien vor: Eine Containerdatei sollte per losetup zum blockorientierten Gerät mutieren, dort wiederum sollte mit cryptsetup ein verschlüsselter Datenträger entstehen, der wiederum ein komprimiertes Squashfs-Dateisystem aufnehmen sollte. Klingt kompliziert? Ist es aber nicht:

Benötigt werden die im Tutorial /home reisetauglich verschlüsselt erwähnten Pakete und die squashfs-tools sowie SquashFS-Module für den laufenden Kernel.

Anlegen des Containers und Befüllen mit Daten

Zuerst wird ein Container angelegt, verschlüsselt und dann mit Daten gefüllt

  • Erstellen des Containers: Ein Sparse-File mit der maximal zulässigen Größe einer DVD5 (4700372992 Bytes oder 2295104 Blöcke — bei einer DVD9 müssten es 4150388 Blöcke sein) entsteht mit dem folgenden Befehl. Die Datei belegt am Anfang nur 2048 Byte, angezeigt wird dennoch die maximale Größe:

    dd if=/dev/zero bs=2048 count=1 seek=2295103 of=crypt_squash.data
  • Erstellen eines Loop-Devices: Mittels losetup entsteht jetzt eine der Datei zugeordnete Blockdevice:

    losetup /dev/loop0 crypt_squash.data

    Sollte /dev/loop0 bereits besetzt sein, zeigt losetup -f freie Loop-Devices.

  • Erstellen des Containers: Auf der Loop-Datei wird nun das verschlüsselte Blockgerät vorbereitet:

    cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y /dev/loop0
  • Öffnen des verschlüsselten Gerätes: Nun wird die verschlüsselte Gerätedatei geöffnent. Das Resultat ist ein Blockdevide /dev/mapper/cryptdvd auf das geschrieben werden und von dem gelesen werden kann. Die Verschlüsselung erfogt hier komplett transparent:

    sudo cryptsetup luksOpen /dev/loop0 cryptdvd
  • Erstellen des komprimierten Dateisystems: In /dev/mapper/cryptdvd entsteht nun das komprimierte Dateisystem SquashFS. Weil wir in eine Gerätedatei schreiben, muss explizit -noappend angegeben werden, um diese zu überschreiben. Die restlichen Parameter sind Kosmetik: Ich bevorzuge noch aus Kompatibilitätsgründen Komprimierung mit gzip und möchte nur einen Prozessor einspannen.

    mksquashfs Projekte WichtigeDaten /dev/mapper/cryptdvd  -nolzma -check_data -noappend -processors 1

Test des Containers

Nun ist der Test des Containers dran. Funktioniert das Backup so, wie wir es uns vorgestellt haben?

  • Mounten des Containers: Das Cryptdevice existiert ja noch, mounten wir es einfach:

    mkdir /tmp/cryptdvd
    mount /dev/mapper/cryptdvd /tmp/cryptdvd/

    Falls ein unbekanntes Dateisystem angegeben wird, sollten Sie sicherstellen, dass das SquashFS-Modul geladen ist und gegebenenfalls den Dateisystemtyp angeben:

    mount -t squashfs /dev/mapper/cryptdvd /tmp/cryptdvd/
  • Unmounten:

    umount /dev/mapper/cryptdvd
  • Auflösen des Cryptdevices:

    cryptsetup luksClose /dev/mapper/cryptdvd
  • Lösen des Loop-Devices: So stellen wir sicher, dass auch alle Daten im Container gelandet sind und wir gefahrlos brennen können:

    losetup -d /dev/loop0

Brennen der DVD

  • Brennen der DVD: cdrecord ist es herzlich egal, was für Daten da gebrannt werden, es bannt unseren Container 1:1 auf den optischen Datenträger:

    cdrecord -v -speed=4 -dev=/dev/scd1 crypt_squash.data

Test der gebrannten DVD — Mounten und Unmounten des Backups

  • Loop-Device erstellen: Zunächst entsteht ein Loopdevice auf der gebrannten DVD. Es könnte eigentlich auch ohne funktionieren:

    losetup /dev/loop1 /dev/scd1
  • Öffnen des Crypt-Devices: Jetzt wird die Datei /dev/mapper/cryptdvd erzeugt, welche die Entschlüsselung transparent macht. Hier ist die Eingabe des Passwortes erforderlich:

    sudo cryptsetup luksOpen /dev/loop1 cryptdvd
  • Mounten des Dateisystems: Möglicherweise ist die Angabe des Dateisystemtyps erforderlich:

    mount /dev/mapper/cryptdvd /tmp/cryptdvd/
  • Unmounten wie oben:

    umount /dev/mapper/cryptdvd
  • Lösen des Crypt-Devices:

    cryptsetup luksClose /dev/mapper/cryptdvd
  • Lösen des Loop-Devices:

    losetup -d /dev/loop1

    Nun kann die DVD entnommen werden.

Die meisten der angegebenen Schritte lassen sich leicht automatisieren, so dass sichere Backups sehr einfach durchgeführt werden können und der Zugriff genauso einfach möglich ist. Ein Manko bleibt: Für das Hinzufügen neuer LUKS-Schlüssel muss der Container natürlich mit dd auf Festplatte transferiert und in ein Loop-Device überführt werden, bevor er neu gebrannt wird.

Nachtrag I: Ich stelle diesen Artikel hiermit unter BY-SA zur Verfügung. Wer möchte, kann ihn also per Copy und Paste ins UbuntuUsers-Wiki (oder andere Wikis) übernehmen und dort weiterbearbeiten, solange auf mich als Urheber verwiesen wird. Viel Spaß damit! creativecommons.org/licenses/by-sa/3.0/de/

Nachtrag II: Da einige Community-Wikis NC-BY-SA verwenden und BY-SA nicht nach NC-BY-SA überführt werden kann, zusätzliche Bereitstellung unter NC-BY-SA. Viel Spaß damit! creativecommons.org/licenses/by-nc-sa/3.0/de/

26 Antworten auf “Linux: Verschlüsselte und komprimierte Backups auf DVD”

  1. eeeeeeeee (February 4th, 2009 um 8:06 pm)

    Diese unsägliche ZIP-Verschlüsselung ist normales AES. Wenn da was unsicher ist, dann deine Passwörter.

  2. Administrator (February 4th, 2009 um 8:55 pm)

    War ZIP immer schon immer AES-versschlüsselt? Ich meine nicht und glaube mich erinnern zu können, dass aus Gründen der Abwärtskompatibilität einige Tools DES/TripleDES verwenden.

    Das “unsäglich” streiche ich schonmal. An der Sicherheit von AES gibt es ja nichts auszusetzen.

  3. eeeeeeeee (February 4th, 2009 um 9:07 pm)

    Ob es schon immer so war, weiß ich auch nicht. Aber vor 15 Jahren war DES auch noch akzeptabel.

    Heute ist es auf jeden Fall AES. Wenn manche Tools das veraltete DES benutzen, würde ich das nicht auf das Format an sich schieben.

    Ich persönlich bin aber sowieso lieber für tar+bz2+openssl/gnupg zu haben.

  4. Administrator (February 4th, 2009 um 9:12 pm)

    Es ist Geschmackssache. Mit wenig Hirnschmalz kann man die Kombi tar/bzip2/openssl direkt zum Brenner oder Bandlaufwerk durchpipen, was dann die im obigen Beispiel angelegte Containerdatei erspart.

    Der Nachteil einer solchen Lösung ist natürlich, dass man den gesamten Datenstrom entschlüsseln muss, wenn man an eine einzige Datei herankommen will.

    Die hier vorgestellte Lösung spielt Ihre Vorteile also nicht beim normalen Backup (alles rücksichern oder nicht), sondern bei der Archivierung aus.

  5. labiculum (February 4th, 2009 um 10:15 pm)

    Die hier vorgestellte Methode entspricht ganz meiner Vorstellung, gerade zu Archivierungszwecken. Ich habe sie noch nicht selbst getestet, frage mich aber, ob sie ohne weiteres mit den (auch von mir) selten genutzten DVD-RAM umsetzbar wäre. Damit müsste man dann nicht zurückspielen, sondern könnte direkt im Backup schreiben, oder?

  6. DrScott (February 6th, 2009 um 9:38 am)

    Wirklich eine Klasse Anleitung! Hättest Du nicht Lust, das ganze als Wikiartikel bei uu.de einzustellen?

  7. Mattias (February 6th, 2009 um 9:43 am)

    Ich stelle diesen Artikel hiermit unter CC-BY-SA zur Verfügung. Wer möchte, kann ihn also per Copy und Paste ins UbuntuUsers-Wiki übernehmen und dort weiterbearbeiten, solange auf mich als Urheber verwiesen wird:

    http://creativecommons.org/licenses/by-sa/3.0/de/

  8. DrScott (February 6th, 2009 um 9:21 pm)

    by-sa: Gut gemeint, aber knapp daneben ;-) Die by-sa verträgt sich mit der von uu.de gewählten Lizenz leider gar nicht. Das kannst Du hier nachsehen: http://wiki.creativecommons.org/Frequently_Asked_Questions#If_I_use_a_Creative_Commons-licensed_work_to_create_a_new_work__.28ie_a_derivative_work_or_adaptation.29.2C_which_Creative_Commons_license_can_I_use_for_my_new_work.3F

    Die Lizenzierung unter by-sa kannst Du nicht mehr zurücknehmen, daher bliebe Dir nun nur noch die Wahl einer Doppellizenzierung by-sa und by-sa-nc.

  9. Administrator (February 6th, 2009 um 9:56 pm)

    Siehe den Nachtrag vom frühen Nachmittag. Ich hab es selbst bemerkt.

  10. Hagis (February 10th, 2009 um 2:03 pm)

    Die Methode gefällt mir! Evtl. gäbe es auch eine Möglichkeit über TrueCrypt, man müsste dann allenfalls den Truecrypt-Container ins SquashFS packen.

  11. Karsten (March 11th, 2009 um 5:00 pm)

    Hallo!
    Vielen Damk erstmal für die Anregungen, die mir dieser Artikel gegeben hat! Ich finde er beschreibt eine geniale Kombination verschiedener Einzeltechniken, die zusammen eine interessante Lösung bilden.
    Zuerst hatte ich gedacht, die Methode sei nichts für mich, weil mich das Brennen auf DVD nicht interessiert, aber nach einiger Zeit fand ich die Methode auch für reguläre Backups interessant. Damit habe ich jetzt also einen riesigen verschlüsselten Backupcontainer, mit dem ich beliebig verfahren kann.

    Ich habe mir ein Skript geschrieben, das das Öffnen/Schließen übernimmt und dazwischen ggf. rsnapshot aufruft oder auch neue Container erstellt.

    Ich denke, das ist insgesamt eine ansprechende Lösung für meine Backupstrategie!

    Also vielen Dank nochmals!


    Karsten