Verschluesselte Backup-Platte revisited

  • Impressum
  • Administration
  • Kontaktformular
  • Jabber
  • Tagcloud
  • Twitter
  • Soup
  • Github

roothausen

Verschluesselte Backup-Platte revisited

19:07

Friday, July 20. 2007

Vorwort:

Vielen werden grosse Teiles dieses Howtos wohl bekannt vorkommen. Mittlerweile sind schon ein paar Monate vergangen, seit ich das letzte cryptsetup-LUKS Howto geschrieben habe. Ich habe mir hier beim Ueberarbeiten auch mehr Zeit genommen als beim eigentlichen Howto.
Eigentlich war noch ein Howto zum Verschluesseln aller Partitionen geplant, aber ich habe nun erstmal beschlossen das bestehende zu erweitern. Dieses hatte noch ein paar Macken und daher bin ich der Meinung, dass es sich lohnt es nochmals zu ueberarbeiten und neue Erkenntnisse einfliessen zu lassen. Ein paar Rechtschreibfehler wurden nebenbei auch korrigiert.
Ausserdem war, je nach System, auf technischer Seite zu viel Handarbeit beim Backup notwendig. Ich habe mir Gedanken gemacht, wie man die Vorgaenge der Verschluesselung moeglichst einfach automatisieren koennte und zum Entschluss gekommen, dass udev-Regeln, ein Eintrag in der /etc/fstab und die Arbeit mit zusaetzlichen Keyfiles das Ganze weitgehend optimieren und automatisieren koennen.

Das Howto:

Das Backup wichtig ist und die vorhandenen Daten auf einem Computer prinzipiell immer den Wert einer zusaetzlichen Festplatte uebersteigen, sollte wohl den meisten klar sein. Wer mit seinem PC arbeitet und damit vielleicht sogar sein Geld verdient kann sicherlich bestaetigen von was ich rede. Auch bei privaten Daten bin ich der Meinung, dass sich eine Sicherung lohnt.
Allerdings ist eine externe Festplatte auch ein Sicherheitsrisiko: Prinzipiell koennte jeder die Festplatte an seinen PC anschliessen und haette Zugriff auf alle gespeicherten Daten. Dieses Problem laesst sich mit der Verschluesselug der betroffenen Daten loesen - wenn man bereit ist einen etwas geringeren Datendurchsatz in Kauf zu nehmen. Doch ganz ehrlich: Wer legt bei einer Sicherungsfestplatte schon einen hoeheren Wert auf ein paar MB/s mehr Datendurchsatz wenn die Daten dafuer nicht gegen unbefugten Zugriff geschuetzt sind?

Vorbereitung

Zuerst muss im Kernel dm_mod und dm_cypt sowie aktiviert sein. Dies ist bei den meisten Distributionen sowieso der Fall. Bei einem selbst gebauten Kernel benoetigt man folgende Optionen:

Device Drivers  --->
Multi-device support (RAID and LVM)  --->
    [*] Multiple devices driver support (RAID and LVM)
    <>   RAID support
    <M>   Device mapper support
    <M>    Crypt target support
Cryptographic options  --->
  --- Cryptographic API
   <M>   SHA256 digest algorithm
   <M>   Blowfish cipher algorithm
   <M>   AES cipher algorithms (i586)

Zusaetzlich benoetigt man noch cryptsetup-LUKS. Dieses wird wird bei den meisten Distributionen ueber das Paketmanagement installiert werden koennen. Im Fall von Arch Linux waere das mit pacman moeglich:

pacman -S cryptsetup

Bei anderen Distributionen heisst das Paket entweder auch cryptsetup oder cryptsetup-luks. Dieses laesst sich dann mit apt, yum, portage etc. problemlos nachinstallieren. Wichtig ist nur, dass die notwendigen Kernelmodule vorhanden sind.

Ist cryptsetup-luks installiert, sollte man die Daten auf der zu verwendeten Festplatte zerstoeren. Also nicht nur loeschen oder die Festplatte neu formatieren, denn da besteht immer noch die Moeglichkeit, dass sich die Daten teilweise wiederherstellen lassen. Einen guten Artikel zum Loeschen von Daten findet man bei pro-linux.

Wird eine neue, ungebrauchte Festplatte verwendet, kann dieser Schritt uebersprungen werden.

Fuer die meisten duerfte hier dd das Tool der wahl sein. /dev/sdc1 ist in diesem Fall das Device ueber das ich meine Backupplatte anspreche. Welches das ist, sollte man genau (!!) wissen, da es sonst zu boesen Ueberraschungen in Verbindung mit den folgenden Aufrufen kommen koennte. Wer also kein Lust hat aus Versehen die falsche Platte zu loeschen, sollte hier lieber mehrfach pruefen.

Mit dd kann man die Festplatte sowohl mit Zufallswerten wie im ersten Aufruf oder mit Nullen wie im zweiten Aufruf ueberschreiben. Letzteres ist schneller aber dafuer unsicherer.

dd if=/dev/urandom of=/dev/sdc1
dd if=/dev/zero of=/dev/sdc1

dev/sdc1 ist hierbei das Device der verwendeten Festplatte. Ich empfehle hierzu die Manpage von DD. Alternativ kann man auch mit dem Befehl shred arbeiten. Hier gibt "-n" die Anzahl der Vorgaenge an. In diesem Fall wird die Platte 10x ueberschrieben:

shred -fv -n 10 /dev/sdc1

Verschluesseln:

Ist die Festplatte sauber, kann man mit sie cryptsetup formatieren:

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sdc1

Hiermit wird eine AES-Verschluesselung, SHA256 Hashes, ESSIV in Verbindung mit einem 256-Bit Schluessel verwendet.
Die Option "-s" gibt die Laenge des Schluessels an und die Option "-y" fordert den User auf eine Passphrase zu waehlen. Alternativ kann man mit "-d" auch ein Keyfile statt der Passphrase verwenden.
Weitere Optionen findet man in der Manpage.

Nun legt man sein Crypto-Device an:

cryptsetup luksOpen /dev/sdc1 backup

An dieser Stelle wird man nach der Passphrase gefragt, die man beim Formatieren eingegeben hat. Verwendet man ein Keyfile, muss man dieses ebenfalls mit "--key-file" angeben.
Der Befehl legt ein neues Device unter /dev/mapper an. In unserem Fall /dev/mapper/backup. Dieses kann man nun wie ein normales Blockdevice formatieren, mounten und beschreiben. Die Ver- und Entschluesselung laeuft transparent im Hintergrund ab.

Formatieren:

mkfs.ext3 /dev/mapper/backup

Mounten:

mount -t ext3 /dev/mapper/backup /mnt/tmp

Alle Daten die man in /mnt/tmp speichert, landen nun verschluesselt auf der Platte.
Will man die Platte wieder abhaengen geht man folgernder massen vor:

Festplatte unmounten:

umount /mnt/tmp

Un danach Crypto-Device schliessen:

cryptsetup luksClose /dev/mapper/backup

Jeder der jetzt auf die Daten der Festplatte zugreifen will, braucht die Passphrase bzw. das Keyfile.

Automation

Um diese komplette Prozedur nicht jedes mal aufs neue ausfuehren zu muessen, kann man das ganze auch automatisieren. Waere ja Unsinn, wenn man die ganzen Sachen von Hand ausfuehren muesste, wenn man die Moeglichkeiten hat dies mit ein paar Kniffen weitgehend zu automatisieren.

Vorerst lege ich noch einen Eintrag in der /etc/fstab fuer das Backupsystem an:

/dev/mapper/backup   /backup        ext3  noatime,noauto,noexec         0  0

Dann lege ich ebenfalls mit dd ein 256Bit grosses Keyfile an. Da bei mir das root-Filesystem verschluesselt ist, kann ich den Schluessel, der fuer die Backup-Festplatte gebraucht wird, auf diesem ablegen. Ist dies nicht der Fall, sollte aus Sicherheitsgruenden eher weiter mit einer Passphrase gearbeitet werden. Eine Alternative waere es, das Keyfile zu erstellen und nun mit GPG zu ver/entschluesseln. Darauf moechte ich allerdings nicht weiter eingehen. Also wird das Keyfile nun erstmal erstellt:

dd if=/dev/urandom of=/etc/crypto/backuphdd.key bs=256 count=1

Nun muss cryptsetup-luks noch Bescheid wissen, dass sowohl die Passphrase als auch das Keyfile verwendet werden kann:

cryptsetup luksAddKey /dev/sdc1 /etc/crypto/backuphdd.key

War dies Erfolgreich schaut das ganze etwa so aus:

Enter any LUKS passphrase:                    
key slot 0 unlocked.
Command successful.

Jetzt kann mal testweise auf die Platte zugegriffen werden:

cryptsetup luksOpen /dev/sdb1 backup --key-file /etc/crypto/backuphdd.key

Und siehe da: "key slot 1 unlocked.". Es musste also keine Passphrase eingegeben werden. Somit ist schonmal der erste Schritt der Automation vollstaendig. Nun kann das Crypto-Device wieder ausgehaengt werden:

cryptsetup luksClose backup

Allerdings steht man nun vor einem Problem: Wechselnde Device-Nodes. Bei USB-Datentraegern unterscheiden sich, je nach Reihenfolge in der sie eingesteckt werden, die Devices ueber die man die Platte ansprechen kann. Zudem ist ja erwuenscht, dass beim Einstecken der Festplatte automatisch mit dem Keyfile das crypto-Device erstellt wird. Danach soll die Platte, ebenfalls automatisch, gemountet werden. Somit hat man nichts weiter zu tun als die Platte einzustecken und man kann sofort darauf zugreifen, obwohl sie komplett verschluesselt ist.

Alles was dazu gebraucht wird ist udev und eine Regel.

Also brauche ich, wie beim vorherigen Udev-Howto beschrieben, erstmal ein Identifikationsmerkmal mit dem ich die Festplatte von anderen unterscheiden kann:

udevinfo -a -p `udevinfo -q path -n /dev/sdc` | grep ATTRS{serial}
    ATTRS{serial}=="1234567898253894C400000123456789"
    ATTRS{serial}=="0000:00:1d.7"

Nun wird mit diesen Infos eine Udev-Regel erstellt. In meinem Fall lege ich dazu die Datei /etc/udev/rules.d/00.rules an.

ACTION=="add", BUS=="usb", ATTRS{serial}=="1234567898253894C400000123456789", KERNEL=="sd?1", NAME="%k", SYMLINK+="ext/backup", GROUP="storage", RUN+="/etc/crypto/scripts/backuphdd", ENV{ACTION}="add"

Mit diesen Regeln wird ein Symlink fuer die Festplatte auf /dev/ext/backup erstellt. Da man die Festplatte beim Einstecken im Normalfall einhaengen moechte, wird das Script /etc/crypto/scripts/backuphdd beim Einstecken gestartet. Dieses Script schaut folgendermassen aus:

#!/bin/bash
# check action
if [ $ACTION = "add" ];
then
   #pause
   /bin/sleep 2
   # create cryptodevice
   /usr/sbin/cryptsetup -c aes-cbc-essiv:sha256 --key-file /etc/crypto/backuphdd.key -h sha256 luksOpen /dev/ext/backup backup
   # and mount it
   /bin/mount /backup
fi
exit 0

Dieses Script pausiert kurz, legt dann das mit Hilfe des Keyfiles das Cryptodevice an und haengt die Platte am richtigen Punkt ein. Somit wird die Festplatte nun sofort beim Anstecken automatisiert eingehaengt. An diesem Punkt ist es auch kein Problem weitere Aktionen ins Script einzubinden. So koennte zum Beispiel nach dem Mounten auch automatisch ein Backup loslaufen.

Backupsystem

Fuer die eigentlichen Backups kommt bei mir rsnaphot zum Einsatz. Dies ist ein Perl-Script welches auf rsync basiert und in der Lage ist sowohl Vollbackups als auch inkrementelle Sicherungen auf Festplatten oder entfernte Rechner durchzufuehren. Zudem laesst es sich vernuenftig konfigurieren.

rsnapshot is a filesystem snapshot utility for making backups of local and remote systems. Using rsync and hard links, it is possible to keep multiple, full backups instantly available. The disk space required is just a little more than the space of one full backup, plus incrementals.

Installieren kann man das Ganze unter Arch Linux mit "pacman -S rsnapshot".

Ein ausfuehrliches Howto findet man auf der offiziellen Seite. Ich moechte hier eher auf die Automation in Verbindung mit der verschluesselten Festplatte eingehen. Hier werden die Optionen in der /etc/rsnapshot.conf festgelegt:

# Specify the path to a script (and any optional arguments) to run right
# before rsnapshot syncs files
#
# cmd_preexec
# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
cmd_postexec   /bin/umount /backup &&amp; /bin/sleep 1 &&amp; /bin/cryptsetup luksClose backup

Hier muessen zwischen cmd_[pre|post]exec und dem eigentlichen Befehl TABs und keine Leerzeichen stehen, da rsnapshot seinen Dienst verweigert wenn letztere eingesetzt wurden. Im beschriebenen Fall wurde die Festplatte schon automatisch eingehaengt. Also kann man das preexec-Kommando auslassen. Im postexec-Kommando muss das Cryptodevice zuerst ausgehaengt und dann wieder geschlossen werden, vorrausgesetzt man will die Festplatte nach dem erfolgreichen Backup einfach wieder abziehen.

Nun ein finaler Testlauf:

[root@wopr:~]# rsnapshot hourly
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.

Nachdem das Backup also moeglichst automatisiert und sicher vonstatten geht, kann man nun seine wichtigen Daten regelmaessig sichern und ist in der Lage boesem Datenverlust vorzubeugen. Wer nun immer noch der Meinung ist, dass er kein Backup braucht, ist selbst schuld.

Weiterfuehrende Links:

  • DM-Crypt im Gentoo-Wiki
  • DM-Crypt im Ubuntuusers-Wiki
  • Luks Website
  • weiteres DM-Crypt Howto
  • LUKS encrypted Root im Archwiki
  • Erstellen der udev-Regeln
  • rsnapshot howto

Wichtig:

Ich uebernehme keine Verantwortung fuer Datenverlust oder sonstige Verluste. Ihr solltet euch beim Durchfuehren dieses Howtos, insbesondere beim Loeschen und Formatieren absolut sicher sein was ihr tut. Vor allem solltet ihr genau pruefen, dass ihr das richtige Device verwendet und sich auf der Platte keine wichtigen Daten befinden!

Hilfestellung:

Ich habe das beschriebene Setup bei mir am Laufen und soweit funtioniert es auch. Einziges Manko: Wenn das Script ueber den Udev-Event aufgerufen wird, dauert es ca. 5min bis die Platte eingehaengt ist. Ruft man das Script von Hand auf, dauert es ein paar Sekunden. Vielleicht kann mir ja hier einer der Leser beim Debuggen helfen.

Posted by admin in computer | Comments (3) | Trackbacks (2)
Defined tags for this entry: computer, howto, linux&unix, security, software
Related entries by tags:
  • Scala - A Scalable Language
  • CPU-Frequency-Scaling Probleme
  • Feedchecker Version 0.4
  • Feeds ausmisten
  • Jetzt auch in audio
< Abgelehnt | White & Nerdy >

Trackbacks
Trackback specific URI for this entry

Cryptsetup und verschlüsselte DVD-Backups
...weil ich gerade darüberstolpere - und gerade so eines (verschlüsseltes DVD-Backup) angefertigt habe: mit growisofs lassen sich Cryptopartitionen, die kleiner als das zu beschreibende Medium sind (z.B. "on-the-fly" eingehängtes Imagefile via Loop) prob
Weblog: AX11s BlinkenBlog
Tracked: Jun 03, 07:09
Verschluesselte Backup-Festplatte
Achtung: Eine neuere Version dieses Artikel findet ihr hier Das Backup wichtig ist und die vorhandenen Daten auf einem Computer prinzipiell immer den Wert einer zusaetzlichen Festplatte uebersteigen, sollte wohl den meisten klar sein. Allerdings ist e
Weblog: roothausen
Tracked: Aug 09, 16:37

Comments
Display comments as (Linear | Threaded)

*[...] ja, wo wir schon gerade bei Linux sind, auf roothausen beschäftigte man sich nochmals mit der verschlüsselten Backup-Festplatte - hochinteressant, [...]
#1 day of the UNIX bits auf F!XMBR (Homepage) on 2007-08-08 20:21 (Reply)
*[...] [in german] Verschluesselte Backup-Platte revisited [...]
#2 bensKnowledgeBlog - mooh.it&#8230;&#8230;&#8230;&#8230;. &raquo; [just links] en (Homepage) on 2007-08-20 21:29 (Reply)
*Sehr, sehr gut geschriebenes Howto zu dem Thema.

Noch ein paar Gedanken meinerseits:

Bei der Backup Automation ist es wichtig wirklich zwei Schlüssel (passphrase + keyfile) zu benutzen. Sonst schaut man blöd aus der Wäsche, wenn man auf die Backupplatte zugreifen möchte, nachdem das Hauptsystem gecrasht ist...

Solange auf der Backuppartitionen wirklich nur Backups der einen Haupplatte liegen, ist es völlig gefahrlos ein und dieselbe passphrase für System und Backup zu benutzen. Liegen auf der Backupplatte noch andere Daten (z.B. Backups anderer Systeme!), sollte man u.U. eine extra passphrase benutzen.
#3 Lore (Homepage) on 2008-01-06 18:29 (Reply)

Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

BBCode format allowed
You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.
 
 

Calendar

« July '10 »
Mo Tu We Th Fr Sa Su
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Quicksearch

Kategorien

  • XML computer
  • XML misc
  • XML web
  • XML zeitgeist


All categories

Archiv

  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • Recent...
  • Older...

Feeds

  • XML RSS 2.0 feed
  • ATOM/XML ATOM 1.0 feed
  • XML RSS 2.0 Comments

Links

Shackspace
Yaxim
Radio Tux
Kais Blog
Blumen Pfleiderer
Alk
paxos
filzo
Marc Seeger
polzifer

Previous | Next

Tags

android bad world blog blogging browser changes code comic computer contentmanagement encryption feedreader firefox free fun google gui hardware howto html im jabber java life lighttpd linux&unix media misc mobile murphy networking newsbeuter opensource picture politics presentation privacy programming regular expression rss ruby s9y screenshot sdk security server shortys software stuff tail -f /var/log/life test tool tv video web webdesign webwide windows xml zeitgeist

del.icio.us

  • Appcelerator Developer Center - Documentation
  • Coderspiel — Rewiring Android for type-safe layout resources
  • pkrumins's stackvm at master - GitHub
  • Netty - the Java NIO Client Server Socket Framework - JBoss Community
  • Learn Your Motherf#@kin' Science: A Textbook for Juggalos | Cracked.com
  • The C Book - Table of Contents
  • andrewvc's node-streamlogger at master - GitHub
  • Setting up a JavaScript Build Process – JavaScriptr
  • js-build-tools - Project Hosting on Google Code
  • YUI Compressor
  • JsUnit
  • InfoQ: Ralph Johnson, Joe Armstrong on the State of OOP
  • ztellman's aleph at master - GitHub
  • Clojure - home
  • Mac OS X keyboard shortcuts

(More)

Lizenz

Creative Commons License - Some Rights Reserved