partition verschlüsseln mit dmcrypt

[toskala]

für alle die schon immer ganz leicht ihren festplatten inhalt verschlüsseln wollten, hier ein howto wie das mittels dm-crypt klappt.

UPDATES:

• 2004-06-12 -- portage overlay verweis eingelinked
  2004-04-12 -- tips/tools erklärt nun wie man udev verwendet
  2004-04-12 -- portage overlay informationen erweitert
  2004-04-12 -- neue version von crypto_mount verfügbar
  2005-08-30 -- neue version von crypto_mount verfügbar

inhalt
1. vorwort
2. todo-liste
3. vorraussetzungen
4. kernel kompilieren mit den benötigten features
4.1. device mapper support
4.2. cipher algorithms
5. benötigte software
6. backup der daten-partition machen
6.1 vorbereitungen für die crypto-partition
7. das mapper-device verwenden
8. zusätzliche tips/tools
9. performance
10. FAQ


1. vorwort
bevor ihr das howto anfangt solltet ihr ein backup der daten anlegen, welche auf der zu verschlüsselnden partition liegen. die partition wird neu formatiert, die daten sind sonst futsch! wie das genau geht ist in dem howto beschrieben.

für fragen, klagen, anträge bin ich natürlich immer offen und würde mich freuen, wenn es konstruktive beiträge gibt

achja, selbstverständlich passiert das alles hier auf eigene gefahr, ich kann nur sagen, dass alles genau so funktioniert hat, wie ich es hier aufgeschrieben habe. ich hoffe ich habe alles so einfach und transparent als möglich geschildert, aber sollte dennoch ein unfall passieren, dann kann ich nix dafür.

2. todo liste
derzeit ist alles fein


3. vorraussetzungen:
- device mapper support
- crypt target support
- aes cipher algorythmls
- cryptosetup
- installiertes gpg (gnu privacy guard)

4. kernel kompilieren
4.1. device mapper und crypt target:
unter dem kernel 2.6 findet man den "device mapper support" und den "crypt target support" als unterpunkt von "device drivers -> multi-device support (raid and lvm)"

anzuschalten ist hierbei das folgende:

Code: Select all

[*] Multiple devices driver support (RAID and LVM)
<*>   Device mapper support
<*>     Crypt target suppor

4.2. aes cipher algorithms:

unter dem kernel 2.6 findet man den support hierfür unter "cryptoghraphic options".

anzuschalten ist hierbei das folgende:

Code: Select all

<*>   AES cipher algorithms (i586)

man könnte das alles auch als modul bauen, da ich aber davon ausgehe, dass man das device sowieso bei nahezu jedem reboot benutzen möchte ist das wenig sinnbringend. wers dennoch will muss eben mit modprobe die module nachladen.

mit diesen einstellungen den kernel neu übersetzen und den rechner rebooten, danach gehts weiter.

5. benötigte software
cryptsetup installieren

bevor mit cryptsetup gearbeitet werden kann, muss es installiert werden. schlicht und ergreifend

Code: Select all

emerge sys-fs/cryptsetup

für dieses howto ist es erforderlich, dass ihr gpg (gnu privacy guard) installiert habt. falls das nicht eh schon der fall ist, installieren via

Code: Select all

emerge app-crypt/gnupg

installieren.

6. backup der daten-partition machen

wie im vorwort bereits erwähnt, ist es ratsam vor dem folgenden prozedere ein backup aller daten auf der platte zu machen, welche in zukunft verschlüsselt werden soll.

szenario:
/dev/hda5 ist gemounted auf /mnt/dump
in zukunft soll der inhalt von /mnt/dump aber verschlüsselt werden, kein problem, nur vorher sollte alles auf /mnt/dump mittels tar gesichert werden.

zuerst muss geprüft werden ob wir ungefähr soviel freien speicherplatz haben wie ein backup von /mnt/dump benötigt, wohlgemerkt auf einer anderen partition

nachdem diese prüfung erfolgreich war, mit tar ein backup erzeugen, das geht so:

Code: Select all

tar -cvpf /mnt/backup/dump.tar /mnt/dump

das kann durchaus lange dauern... je nachdem wie gross die datenmenge ist, die es zu sichern gilt.

wenn dieser vorgang durchgelaufen ist, sollte man sich noch vergewissern ob das archiv auch funktioniert und nicht beschädigt ist, dies prüft man mittels:

Code: Select all

tar -tvpf /mnt/backup/dump.tar

wenn hier nichts von einem error berichtet wird, dann hat alles geklappt und es kann weitergehen.


6.1. vorbereitungen für die crypto-partition
key erzeugen

Code: Select all

head -c 1000 < /dev/urandom | uuencode -m - | grep -v begin | head -c 32 >NAME.key

hierbei sollte "NAME" durch den gewünschten namen ersetzt werden, den man dem key geben möchte.

das keyfile brauchen wir als eine art "zündschlüssel" für die partition. der zugang zu der festplatte wird nur freigegeben wenn man das richtige keyfile hat und das dazugehörige kennwort.

den key verschlüsseln

Code: Select all

gpg -c NAME.key

ACHTUNG! die sicherheit der ganzen verschlüsselung liegt selbstverständlich in der stärke des kennworts welches du hier bei gpg vergibst. ich schlage vor, du überlegst dir ein mantra. ein mantra ist eigentlich ein kurzer gebetsspruch.

naja, nimm einen satz den du dir leicht merken kannst und verwende gross und kleinschreibung. ein kennwort von 8 oder 10 zeichen ist relativ leicht zu knacken, ein satz wie "Morgen früh hab ich bestimmt Muskelkater vom vielen Steine klopfen!" jedoch nicht. also im eigenen interesse: mantra verwenden

den key löschen

Code: Select all

shred NAME.key
rm NAME.key

7. device mapper konfigurieren
das device an den device mapper koppeln

ACHTUNG! WER JETZT NOCH KEIN BACKUP GEMACHT HAT SOLLTE ES DEFINITIV VORHER TUN!

Code: Select all

gpg --quiet -d NAME.key.gpg | cryptsetup -h plain create MAPPERNAME /dev/hdXX

hierbei ist natürlich wieder zu beachten, dass NAME.key mit dem entsprechenden namen deines erzeugten keys ersetzt wird. MAPPERNAME ist der name des gewünschten mapperdevices und hdXX muss durch deine zu mappende echte festplattenpartition ersetzt werden.

beispiel:

Code: Select all

gpg --quiet -d dump.key.gpg | cryptsetup -h plain create dump /dev/hdd1

alles klar? gut, weiter also.

das mapperdevice formatieren

Code: Select all

mke2fs -j /dev/mapper/MAPPERNAME

beispiel:

Code: Select all

mke2fs -j /dev/mapper/dump

mounten des mapperdevices

naja, jetzt wie gewohnt mounten, nur nicht die eigentliche partition sondern das mapper device

Code: Select all

mount -t ext3 -o user /dev/mapper/MAPPERNAME /mnt/MOUNTPOINT

beispiel:

Code: Select all

mount-t ext3 -o user /dev/mapper/dump /mnt/cryptodump

so, eigentlich wars das.
jetzt ist das mapperdevice gemounted und die daten werden verschlüsselt darauf abgespeichert.

zu beachten ist allerdings, dass nach jedem reboot das mapper device entfernt wird, es muss also neu angelegt werden.

8. zusätzliche tips/tools

crypto-mount
hier das in-offizielle ebuild für anarcho's script "crypto-mount".
aktuelle version:

http://www.daniundmaz.de/gentoo/crypto- ... .1a.ebuild

http://www.daniundmaz.de/gentoo/crypto- ... .1a.tar.gz

jetzt muss nur noch das crypto-mount ins portage overlay gesteckt und emerged werden.

Code: Select all

mkdir /usr/local/portage/sys-apps/crypto-mount
cd /usr/local/portage/sys-apps/crypto-mount
mv crypto-mount-<version>.ebuild .
emerge crypto-mount-<version>.ebuild digest
emerge crypto-mount

für weitere infos zum thema portage_overlay clickst du hier: http://de.gentoo-wiki.com/HOWTO_Portage ... figurieren

erzeugen einer regel für udev, um den usbstick immer an der selben stelle zu haben

wichtig: damit das hier mit udev funktioniert muss natürlich udev installiert werden. wie das geht erklärt der gentoo udev-guide, zu finden hier: http://www.gentoo.org/doc/de/udev-guide.xml
alternativ ist auch eine anleitung auf dem gentoo-wiki zu finden:
http://de.gentoo-wiki.com/HOWTO_von_dev ... v_wechseln

nun aber los...
zuerst mal den usbstick umounten und ausstöpseln, falls er noch irgendwie in benutzung sein sollte. danach als root

Code: Select all

octane root # tail -f /var/log/messages

eintippen und den usbstick einstecken. dann scrolled ungefähr der folgende output runter:

Code: Select all

Dec  5 20:08:12 octane usb 1-6: new high speed USB device using address 15
Dec  5 20:08:12 octane scsi13 : SCSI emulation for USB Mass Storage devices
Dec  5 20:08:12 octane Vendor: SONY      Model: Storage Media     Rev: 1.00
Dec  5 20:08:12 octane Type:   Direct-Access                      ANSI SCSI revision: 02
Dec  5 20:08:12 octane SCSI device sdb: 253952 512-byte hdwr sectors (130 MB)
Dec  5 20:08:12 octane sdb: assuming Write Enabled
Dec  5 20:08:12 octane sdb: assuming drive cache: write through
Dec  5 20:08:12 octane sdb: sdb1
Dec  5 20:08:12 octane Attached scsi removable disk sdb at scsi13, channel 0, id 0, lun 0
Dec  5 20:08:12 octane Attached scsi generic sg4 at scsi13, channel 0, id 0, lun 0,  type 0
Dec  5 20:08:12 octane USB Mass Storage device found at 15
Dec  5 20:08:12 octane scsi.agent[12893]: disk at /devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/host13/13:0:0:0

naja, wichtig ist hierbei erstmal folgendes:

Code: Select all

Dec  5 20:08:12 octane sdb: assuming Write Enabled
Dec  5 20:08:12 octane sdb: assuming drive cache: write through
Dec  5 20:08:12 octane sdb: sdb1

das verrät, dass der usbstick nach /dev/sdb1 gemapped wurde.
nun brauchen wir einen eindeutigen identifier für den stick. das findet man recht fix raus mittels:

Code: Select all

octane root # udevinfo -a -p /sys/block/sdb/sdb1 | grep product
    SYSFS{product}="Storage Media"
    SYSFS{product}="Intel Corp. 82801DB (ICH4) USB2 EHCI Controller"

jetzt muss man nur noch eine regel verfassen, die den usbstick auch immer brav an die gewünschte stelle mounted

Code: Select all

octane root # vi /etc/udev/rules.d/50-udev.rules 

die default rules anpassen und hier:

Code: Select all

# cdrom symlinks and other good cdrom naming
BUS="usb", SYSFS{product}="Storage Media", KERNEL="sd*", NAME="%k", SYMLINK="usbstick"

eintragen. das sorgt nun dafür, dass der usbstick nach /dev/usbstick gemapped wird. das muss man nun nur noch in der /etc/fstab anpassen und natürlich auch in der /etc/crypto-mount.conf wenn man das script von anarcho benutzt.

nun den usbstick wieder einstecken und kucken ob das device /dev/usbstick erzeugt wird. wenn alles geklappt hat, dann ist man auf jeden fall die querelen los, dass der usbstick (wie bei mir) immer von /dev/sda1 über sdb1, sdc1 und sdd1 wieder zurück auf sda1 gewandert ist.

9. performance

viele beschäftigt auch die frage nach der performance, ich habe mich das auch gefragt und nach dem "ausprobieren" festgestellt, dass es eigentlich alles recht flott geht.

ich habe einen pentium4, 2,4ghz, 1gb ram und die verwendete festplatte ist eine 7200rpm samsung 120gb platte.

ohne verschlüsselung schafft mein system auf dieser platte beim kopieren von grossen dateien (2gb files) laut mc (midnight commander) ca 38mb / sec.

beim schreiben und lesen auf die verschlüsselte partition schaffe ich zwischen 14 und 15mb / sec.

vollkommen ausreichend für die meisten anwendungsfälle, aber man muss sich bewusst sein, dass es durchaus eine cpu intensive geschichte ist, diese verschlüsselei.

10. FAQ

Q: ich habe mal gehört dass, wenn man festplattenverschlüsselung einsetzt, alle daten zu matsch verarbeitet werden, wenn der strom ausfällt, stimmt das?
A: es besteht immer das risiko, dass das dateisystem schaden abbekommt wenn es unsauber unmounted wird, jedoch ist das risiko bei einer verschlüsselten partition afaik nicht höher, mir ist zumindest noch nichts passiert.

Q: stimmt es, dass der akku des notebooks schneller leer wird beim verwenden einer verschlüsselten partition?
A: naja, das stimmt insofern, als dass das lesen und schreiben auf so eine partition mehr cpu last verursacht und dadurch mehr strom verbraucht. wieviel mehr kann ich leider nicht sagen, aber bei meinem system produziert das schreiben grosser dateien durchaus eine load von 1,2...

[ank666]

falls jemand ergänzungen, korrekturen oder ähnliches hat, einfach posten, ich pflege das dann gerne in das howto ein

Hallo,

ich hätte eine Frage und zwar habe ich mal gehört dass,
wenn man Festplattenverschlüsselung einsetzt, alle Daten zu Matsch verarbeitet werden,
wenn der Strom ausfällt bzw. der Akku schneller leer ist als gedacht.

Stimmt das oder ist das eher Quatsch?

[toskala]

das die daten automatisch zu matsch verarbeitet werden halte ich für unsinn (ich habe jedenfalls nie was drüber gelesen und beim letzten mal hart resetten ist mir nix passiert), dass der akku schneller leer wird, naja, dazu kann ich nicht viel sagen da ich derzeit kein notebook benutze, aber es gibt natürlich einen gesteigerten stromverbrauch, da das wegschreiben und lesen der daten die cpu fordert.

[AnubisTheKing]

wie sieht es denn mit der Preformance aus? Ist die viel niedriger als bei einer nicht verschlüsselten Platte?

Bis dann
AnubisTheKing

[toskala]

also was das thema performance angeht bin ich recht zufrieden.

ich habe einen p4 mit 2,4ghz und benutze für die crypto platte eine samsung 120gb platte die mit udma 66 rennt.

ich schaffe ohne cryptographie ca 38mb / sec beim kopieren und mit eingeschalteter crypterei ca 15mb / sec.

man merkt den unterschied schon, aber wenn man das problem mal realistisch betrachtet siehts doch so aus:

anwendungsfall, mp3s, divx, dvds, etc.:

du schaufelst das ding voll und spielst es mit mplayer ab. dafür reicht die performance allemal aus.

anwendungsfall, als fileserver:

einmal vollschaufeln, deine 100mbit karte packt sowieso meist keine 15mb / sec... von daher reichts auch hier.

das einzige was man beachten sollte ist eben, einen einigermaßen schnellen rechner zu haben. also auf einem p2 233 würde ich keine performance wunder erwarten.

[oscarwild]

vielen Dank für dieses wirklich gelungene Howto

[toskala]

hihi, danks fürs lob

es gibt noch eine sache, über die ich mir den kopf zerbreche. ich würde folgende zwei dinge ermöglichen:

- mount der partition beim booten mit abfrage.

- mount der partition als user, mittels sudo.

beides zickt derzeit noch. falls da jemand mitbasteln will?...

[Haldir]

Zum boot start:
ich hab meinen code in /etc/conf.d/local.start

#!/bin/sh
modprobe dm-crypt
cryptsetup create crypted /dev/sda4
mount /crypted

Das ist für Crypto ohne gpg, gpg geht dann analog

Perfomance seitig brauchst du gut 1ghz rechenleistung rein für crypto.
Beim crashen passiert nicht viel, da es eh eine Sektorbasierte Verschlüsselung ist, gibt aber auch keine große Überprüfung. also entweder er mounted die Platte oder du kriegst z.b. ne FS - Fehlermeldung das er den Superblock usw nicht finden konnte, dann weißt das dein Passwort falsch ist

[toskala]

Zum boot start:
ich hab meinen code in /etc/conf.d/local.start

#!/bin/sh
modprobe dm-crypt
cryptsetup create crypted /dev/sda4
mount /crypted

Das ist für Crypto ohne gpg, gpg geht dann analog

Perfomance seitig brauchst du gut 1ghz rechenleistung rein für crypto.
Beim crashen passiert nicht viel, da es eh eine Sektorbasierte Verschlüsselung ist, gibt aber auch keine große Überprüfung. also entweder er mounted die Platte oder du kriegst z.b. ne FS - Fehlermeldung das er den Superblock usw nicht finden konnte, dann weißt das dein Passwort falsch ist

nein, mit gpg geht leider nicht analog, weil es dann meckert, von wegen, dass es nicht die nötigen pfade finden würde wonach denen gpg gestartet werden möchte.
schön wärs, auf die idee bin ich auch schon gekommen

[Haldir]

Hmm das ist komisch, bei local.start sollten doch schon alle Pfade usw gesetzt worden sein.

[toskala]

jar, aber es will einen user unter dessen ~/.gpg das ganze geraffel liegt und das funktioniert so irgendwie nicht.

ich muss mich mal drum kümmern, dass ich das hinbekomme. der plan für das tool hier ist sowieso noch ein ordentliches init-script, welches die arbeit erledigt und evtl. ein k-dialog frontend für das mount script pro user.

also mal sehen was das wird... so viel kram und so wenig zeit

[abcd]

Hallo,

wozu ist es eigentlich erforderlich, die Festplatte zu verschluesseln?

Mfg, abcd.

[Haldir]

vielleicht mit sudo oder su - user -c probieren ?
Ansonsten kann man bei gpg sicher noch das keyring dir spezifizieren
steht glaubi im loop-aes tutorial drin, da gibts ein Beispiel wie man loop-aes und gnupg zusammen benützt: http://loop-aes.sf.net


Die Frage ist in der heutigen Zeit eher, wieso nicht verschlüsseln

Ich will z.b. nicht das jeder meine E-Mails liest der irgendwann mal access zu meinem computer hat usw, Passwörter in home Verzeichnissen usw.
Ich denk z.b. nen Laptop unverschlüsselt in der Öffentlichkeit mitzunehmen ist fahrlässig
Gründe gibts genug, nicht jeder der verschlüsselt ist gleich Krimineller

[daff]

Das Howto sieht sehr gut aus, werd das sehr bald brauchen müssen. Und zwar für einen Firmen-Backupserver, und da hab ich gleich eine Frage, vielleicht kennt sich ja jemand aus (ist vermutlich aber nicht ganz das richtige Forum dafür).

Habe vor Bacula zu verwenden und für die Backups ein Raid aus 2 SCSI-Platten anzulegen. Dieses Array will ich mit dm-crypt verschlüsseln. Hab noch nicht viel Ahnung davon wie Bacula funktioniert bzw konfiguriert wird, aber naja.

Jetzt ist die Frage: Wird es funktionieren, eine verschlüsselte Backuppartition zu haben, auf die jede Nacht ein inkrementelles Backup geschrieben wird? Kann Bacula (oder jedes andere Backuptool) damit umgehen, bzw wie würde der Betrieb von sowas aussehen? Wenn die Partition gemounted ist, dann ist sie doch lesbar für jeden der darauf zugreifen kann, richtig? (Daten werden beim Lesen entschlüsselt) So könnte doch jeder, der Zugang zum Rechner bekommt die Backups lesen und entfernen und wwi noch alles? Damit die Backups wirklich sicher sind müsste ich wohl ein Skript schreiben, das das Array vor dem Backupvorgang mounted und danach wieder unmounted, oder?

Oder ist das alles viel simpler und ich bin durcheinander, weil ich noch nicht sehr weit in die Materie eingetaucht bin (die Komponenten für den Rechner werden erst geliefert)? Bitte um ein paar sachdienliche Hinweise oder Links, wenn jemand welche hat

Danke!

[Haldir]

Yup du mußt die Partition jeweils mounten und unmounten, was automatisch relativ dumm ist, nachdem du ja das passwort irgendwo ins script schreiben mußt

Einziger weg der mir einfällt ? (Jetzt wirds kompliziert :/)

Du mußt den Katalog, also die Information welche Dateien gespeichert wurden mit mtime etc, uncrypted speichern, mit dem Ziel, daß du keinen Zugriff auf das original crypted backuparchiv mehr brauchst.

Dann hast du nur noch das Problem die Incrementalarchive crypted zu speichern, mit Passwörtern die ein möglicher Datenklauer nicht hat.
Mögliche Methode:
dein Password wird von einem Script erzeugt, dann gehashed und per Mail/ssh an einen anderen Rechner gesendet., dieses Passwort wird dann entsprechen für ein Inkrementelles Backup verwendet.

Für die Lösung brauchst aber kein dm-crypt sondern ein file basiertes crypt tool.
Im Readme von aes-pipe (loop-aes.sf.net) gibts nen Beispiel für encrypted tar archive, ich hab mal sowas testweise mit dar und aes-pipe gemacht aber dann wieder verworfen, jedoch ohne Inkrementielle/differential backups.
Ich zumindest glaube, dass du mit einer filebasierten crypto Lösung besser dran bist wenn du die Backups eh in einen/mehrere große Files packst. Imho ist Bacula eh overkill.
Ich mach 1tb Backup immernoch mit dar

[daff]

Danke mal für die Antwort!

Bacula möcht ich verwenden, weil der Hauptprojektserver von der Firma, der gebackupped werden muss, ein Powermac mit MacOS X ist, und soweit ich weiß Bacula eins der wenigen vernünftigen Tools ist, mit dem man crossplattformmäßig und übers Netzwerk backuppen kann.

Deine Vorschläge klingen in der Tat ziemlich kompliziert Ich schätze ich muss mir das nochmal genau überlegen, eine verschlüsselte Backuppartition wollen die Typen aber haben. Mal sehen was es noch so gibt. Vielleicht ist ja eine filebasierte Verschlüsselungsmethode besser, aber Bacula kann mit sowas auch nicht wirklich umgehen soweit ich gesehen hab...Mist.

Wäre es wohl ein brauchbarer Kompromiss die mount-Skripte mit entsprechenden Permissions (chmod 100 oder so ) zu versehen und von root ausführen zu lassen (cronjob oder so)? Grundsätzlich steht der Server eh relativ sicher im Keller und hinter zwei Routern, aber ideal ist die Methode natürlich nicht.

Vielleicht sollt ich nen eigenen Thread starten in einem passenderen Subforum um das hier nicht zusehr OT werden zu lassen.

Danke auf jeden Fall mal für die Hilfe!

[toskala]

so, jetzt war ich gestern ja ein wenig abwesend und habe nix dazu gesagt

zuerst einmal die frage warum sollte man crypten?
nun, ich für meinen teil habe ein grosses interesse, dass meine daten auch wirklich meine daten bleiben. einfaches beispiel: benutze ich ein notebook und verwende es oftmals unterwegs und es wird gestohlen. alle meine mails, alle meine persönlichen daten, vertrauliche dokumente, meine irc logs und was nicht alles... das geht niemanden was an ausser mir.

man muss ja nicht gleich eine riesen partition verschlüsseln, es reicht ja im prinzip vollkommen eine "crypto-partition" zu machen auf der man sensible inhalte speichert und die hat nach meiner erfahrung jeder.

oder nimm das beispiel "multi-user umgebung" du wohnst in einer wg, familie, etc. ich arbeite grundsätzlich nicht an solchen maschinen ohne die gewissheit zu haben, sicherstellen zu können, dass meine daten exklusiv für mich zugänglich sind.


so, dann die dinge bezüglich sudo und gpg und mounten.
haldir, ja ich dachte auch schon an sudo problematisch an der ganzen kiste ist immer gpg. gpg wirft hässliche fehlermeldungen wenn es via sudo aufgerufen wird, von wegen ob man wirklich root sei etc. pp.

ich werde versuchen mich mal dieses WE damit intensiver zu beschäftigen und evtl. einen weg versuchen das ding via sudo aufzurufen und den ganzen blabla kram zu unterdrücken. mal sehen...



das verschlüsseln von backups:
ja, das halte ich auch für sehr sinnvoll, aber die diskussion über das mounten entzieht sich meinem verstehen ein wenig. ich denke mir das so: du machst ein backup von einigen systemen (vermutlich wird es einen backup-server geben) der backup server rennt ja sowieso 24/7. also das mounten der backup-partition erledigst du einmal, dann bleibt die gemounted und gut ist.
wird der server geklaut, resetted, runtergefahren, etc. was automatisch passiert wenn sich jemand zugriff verschaffen will (bootdisk, etc) dann ist die backup-partition ja unmounted worden und gesichert.

die alternative hierzu wäre gpg für file verschlüsselung mit einem public key. dann brauchst du nur dafür zu sorgen, dass der private key nicht auf dem server liegt, sondern eben nur aufm usb stick plus zwei drei cds in einem safe... sonst ist evtl. essig mit backup restore

[Haldir]

Ja ich schließ mich hier mal toskala wegen dem Crypto Backup an, mein Vorschlag umgeht primär das Problem wenn der Angreifer schon im Netz ist oder physikalischen Zugriff auf den laufenden Server hat und an die Daten kommt ohne den Server herunterzufahren.
Bei einer lokalen Lösung wo der Backup Server vor Ort relativ sicher ist, reicht dm-crypt dann locker aus .
Das Hauptproblem bei scripten die mounten ist halt immer das gespeicherter Passwort das ein möglicher Angreifer dann halt auch hat.
Daher würde ich, wie Toskala schon sagte, die Backup Platte einmal mounten und dann nicht wieder unmounten, also immer mounted lassen. Damit umgehst du das "Passwort speichern" Problem.
Backup Verzeichnis mit passenden Rechten versehen und das sollte reichen

[zielscheibe]

Hi,

1. Ein Dankeschön für das gute HowTo.

Habe einmal nach bereits vorhandenen Lösungen für das Usermountproblem gegoogelt. Dabei bin ich auf ein Perlscript gestoßen, welches die Lösung des Problems verheißt.

http://einsteinmg.dyndns.org/projects/c ... onf_0.7.0/

Das Problem ist nur, daß dieses Script hier nicht laufen möchte.

Code: Select all

./cryptoconf.pl 
Can't locate object method "instance" via package "cryptoconf::strictConfig" (perhaps you forgot to load "cryptoconf::strictConfig"?) at ./cryptoconf.pl line 48.
BEGIN failed--compilation aborted at ./cryptoconf.pl line 49.

Meine Perlkenntnisse belaufen sich leider in der Summe auf 0, sodaß ich mit der Fehlermeldung nichts anfangen kann.
Kann sich vielleicht ein kompetenter Gentoouser dieses Script anschauen?

[toskala]

1. danks

du brauchst das cryptoconf package, das müsstest du evtl. emergen schau mal unter /usr/portage/dev-perl/ obs da was passendes gibt.

[Anarcho]

Hi!

Da nun meine Windows-Partition entgültig dicht gemacht wird, werde ich den Space für ne crypto-partition verwenden.
Dann werde ich mir das script mal ansehen, werde das mount-problem ja dann auch haben, da der rechner nicht 24/7 on ist.

[toskala]

ich habe mir zu der ganzen "sicherheits und unbequemlichkeits sache" mal ein wenig gedanken gemacht.

es ist einfach so, dass vollständige automation sehr bequem ist, aber eben ein sicherheitsrisiko birgt.
gute/sehr gute sicherheit ist unbequem, da man selbst interagieren muss und in diesem fall ein mantra eingeben muss.

ich bemühe mich zu verinnerlichen, dass ich eben für eine sichere sache meinen arsch bewegen muss, sprich etwas eintippen soll, beim onlinebanking speicherst du ja auch nicht benutzername und passwort im mozilla-form-manager ab.

und wenn man ehrlich ist... meist läufts doch so: man booted nen rechner und dann läuft er stundenlang... und die 5 sekunden zeit die man vielleicht braucht um das mantra einzutippen sind eher albern im vergleich dazu

[Anarcho]

Das finde ich auch! Ich werde es aber auch auf jedenfall so machen, das man beim hochfahren das pw eingeben muss, sonst macht das ja kaum sinn.

[Bender007]

Hi ich habe gestern meine 110 GB PLatte mit dm-crypt verschlüsselt jetzt habe ich allerdings noch ein paar fragen.

1.Und zwar ist es egal ob ich im kernel alle möglichen verschlüsselungs algorithmen kompiliert habe oder benutzt dm-Crypt automatisch AES ? bzw. wie kann ich den algorithmus wählen habe gehört Twofish soll schneller sein?

2.Und mit wieviel Bit ist die Platte standartmäßig (siehe oben how to) verschlüsselt 256 oder 128?

3.Ich habe ein Kennwort mit einer Zeichenlänge von 40 Zeichen es beinhaltet normale buchstaben groß-kleinschreibung nummern und n paar sonderzeichen das sollte doch als guter verschluesselungsschlüssel reichen ?

4.Und die letzte frage den key den ich mit gpg also z.B. server.key.gpg erstellt habe den ich zum mounten brauche brauch ich doch net verstecken oder so also wenn jemand an den key kommt kann er dann die entschlüsselung beschleunigen ?

5.axo noch eine in wie fern ist es wichtig beim verschlüsseln daten auf der platte zu haben und bringt es vergleichbar vielmehr sicherheit als eine leere PLatte die verschlüsselt wird?

AXO ja was soll diese Fehlermeldung ?

mounting crypted partition
gpg: WARNING: message was not integrity protected


Wäre nett wenn mir jemand diese Fragen beantworten könnte sonst komm ich net weiter....

[toskala]

Und zwar ist es egal ob ich im kernel alle möglichen verschlüsselungs algorithmen kompiliert habe oder benutzt dm-Crypt automatisch AES? bzw. wie kann ich den algorithmus wählen habe gehört Twofish soll schneller sein?

also per default benutzt cryptsetup aes mit 256bit verschlüsselung. du kannst aber auch einen beliebigen anderen algorithmus verwenden, dazu siehe:

Code: Select all

octane linux # cryptsetup --help
Usage: cryptsetup [OPTION...] <action> <name> [<device>]
  -v, --verbose               Shows more detailed error messages
  -c, --cipher=STRING         The cipher used to encrypt the disk (see
                              /proc/crypto) (default: "aes")
  -h, --hash=STRING           The hash used to create the encryption key from
                              the passphrase (default: "ripemd160")
  -y, --verify-passphrase     Verifies the passphrase by asking for it twice
  -d, --key-file=STRING       Read the key from a file (can be /dev/random)
  -s, --key-size=BITS         The size of the encryption key (default: 256)
  -b, --size=SECTORS          The size of the device
  -o, --offset=SECTORS        The start offset in the backend device
  -p, --skip=SECTORS          How many sectors of the encrypted data to skip
                              at the beginning

interessant sind für dich dann -c und -s, das stellt sowohl den cipher als auch die bitrate ein.

Und mit wieviel Bit ist die Platte verschlüsselt 256 oder 128?

naja, wenn du nix weiter angegeben hast, 256bit.

Ich habe ein Kennwort mit einer Zeichenlänge von 40 Zeichen es beinhaltet normale buchstaben groß-kleinschreibung nummern und n paar sonderzeichen das sollte doch als guter verschluesselungsschlüssel reichen ?

definitiv.

Und die letzte frage den key den ich mit gpg also z.B. server.key.gpg erstellt habe den ich zum mounten brauche brauch ich doch net verstecken oder so also wenn jemand an den key kommt kann er dann die entschlüsselung beschleunigen ?

naja, im prinzip schon. also der punkt ist der folgende. bei verschlüsselung geht es im grunde immer um etwas, dass du hast, etwas was du weisst.
wenn ein potenzieller bösewicht weder das key-file hat, noch das passphrase weiss, dann muss er sich direkt mit dem AES auseinandersetzen und noch dazu mit GPG.
gpg verschlüsselt das keyfile und erst aus einem korrekt entschlüsselten keyfile lässt sich dann der aes kram auf der platte entschlüsseln.

wenn du jetzt das keyfile rumfliegen hast, dann reduzierst du die schwierigkeit natürlich auf die länge deines mantra. bei 40 zeichen mit folgendem vorrat [A-Za-z0-9] hast du 62^40 möglichkeiten ein passwort zu produzieren (afaik), naja, plus leerzeichen und sonderzeichen die du evtl. eingebaut hast. das ist zwar recht gut, reicht in allen fällen wohl auch aus, aber natürlich ist das schwächlich im vergleich zu brechen deiner verschlüsselung wenn jemand weder keyfile noch das passphrase kennt.

hmm, also laut bc sind das 496212362459367066914366580195701544604991251555593230875525121862270976 möglichkeiten, recht viel also

je weniger ein angreifer also hat, desto schwerer wird die aufgabe die cryptographie zu brechen.

letzten endes liegt es natürlich in deinem persönlichen ermessen, wieviel sicherheit du brauchst, im normalfall reicht es aber, dass 40character mantra ist stark genug.

axo noch eine in wie fern ist es wichtig beim verschlüsseln daten auf der platte zu haben und bringt es vergleichbar vielmehr sicherheit als eine leere PLatte die verschlüsselt wird?

nein, das ist vollkommen egal.