View previous topic :: View next topic |
Author |
Message |
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Wed May 28, 2014 6:03 pm Post subject: Wie 4TB Laufwerk mit cryptsetup am besten einrichten? |
|
|
Will ein 4TB Laufwerk verschlüsseln und als Datengrab benutzen.
Code: | fdisk /dev/sd[BUCHSTABE] ( n p 1 w )
cryptsetup -v -c aes-cbc-essiv:sha256 -h sha -s 256 luksFormat /dev/sd[BUCHSTABE]1
cryptsetup luksOpen /dev/sd[BUCHSTABE]1 verschluesstefestplatte--sd[BUCHSTABE]1
mkfs.ext4 /dev/mapper/verschluesstefestplatte--sd[BUCHSTABE]1
mount /dev/mapper/verschluesstefestplatte--sd[BUCHSTABE]1 /mnt/verschluesstefestplatte--sd[BUCHSTABE]1
dd if=/dev/zero of=/mnt/verschluesstefestplatte--sd[BUCHSTABE]1/grosseleeredatei
rm -f /mnt/verschluesstefestplatte--sd[BUCHSTABE]1/grosseleeredatei |
So würde ich jetzt meine neuen 4TB Laufwerke einrichten.
Bin mir aber bei ein paar Dingen unsicher.
1.
muss ich bzgl der größe von 4tb etwas beachten? 4KB Sektoren Emulation (512e) ?!
(Es handelt sich bei meinen Laufwerken um Seagate NAS HDD 4TB (ST4000VN000) Festplatten)
2.
Kommt cryptsetup mit 4TB in einem Stück zurecht ?!
3.
Ich denke wenn ich das Laufwerk mit cryptsetup eingerichtet habe und dann eine riesen leere Datei darin erstelle die das gesammte Laufwerk füllt sollte es keine leeren Bereiche mehr geben die von einem eventuelem Angreifer als Ziel genutzt werden könnten ?! Bringt die Methode etwas ?!
4.
Wie sollte ich das mit mkfs.ext4 und dem Journaling bei 4TB machen ?!
5.
Welche Optionen sollte ich mkfs.ext4 mitgeben damit es nicht unnötige GigaBytes reserviert die nur root benutzen kann ?!
6.
Was sollte ich beim meinem setup mit den 4TB Laufwerken noch beachten ?!
Hoffe Ihr könnt mir etwas weiterhelfen.... |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Fri May 30, 2014 5:10 am Post subject: |
|
|
Huhu? |
|
Back to top |
|
|
cryptosteve Veteran
Joined: 04 Jan 2004 Posts: 1169 Location: GER
|
Posted: Fri May 30, 2014 7:33 am Post subject: |
|
|
Selber Huhu!
Ich kann Dir dazu nicht viel sagen, weil ich selbst kein 4TB-Laufwerk besitze. Mein 3TB-Laufwerk läuft allerdings ziemlich gut mit cryptsetup, von daher sehe ich
eigentlich keine Schwierigkeiten bei 4TB.
Das Ausnullen der Datenbereiche bringt eigentlich nichts, wenn nicht vorher schonmal unverschlüsselte Daten auf der Platte waren. Wenn Du das Erkennen von beschriebenen und unbeschriebenen Bereichen erschweren willst, bist Du mit random-Daten besser dran. Das dauert allerdings bei der Plattengröße noch länger. Ich halte das Ausnullen der Datenbereiche für übertrieben, denn einem normalen Angreifer dürfte das keinen Erkenntnisgewinn bringen, während Du vermutlich sowieso einknickst, wenn die NSA durchs Oberlicht einsteigt und Dich unter Druck setzt. Aber das musst Du für Dich selbst entscheiden - hier dient die Vollverschlüsselung nur dazu, dass ich mich bei Hardware-Diebstahl entspannt zurücklehnen kann (hinsichtlich meiner Daten)
Das Journaling habe ich auf Standard gelassen, habe da bislang keine Nachteile gefunden.
Als ext4-Option habe ich "-m 0" via tune2fs mitgegeben, weil es sich bei mir um eine reine Backupplatte handelt, bei der root keine reservierten Bereiche braucht.
Mit fdisk wirst Du allerdings nicht glücklich werden, das funktioniert nur bis zu 2TB. Bei der Laufwerksgröße brauchst Du gpt. Daher ist sys-block/parted hier wohl das Mittel der Wahl. _________________ - born to create drama -
gpg: 0x9B6C7E15
CS Virtual Travel Bug: VF6G5D |
|
Back to top |
|
|
Josef.95 Advocate
Joined: 03 Sep 2007 Posts: 4536 Location: Germany
|
Posted: Fri May 30, 2014 10:08 am Post subject: |
|
|
cryptosteve wrote: | Mit fdisk wirst Du allerdings nicht glücklich werden, das funktioniert nur bis zu 2TB. Bei der Laufwerksgröße brauchst Du gpt. Daher ist sys-block/parted hier wohl das Mittel der Wahl. | Alternativ gibt es auch noch sys-apps/gptfdisk
Und bei GPT bitte
CONFIG_EFI_PARTITION=y Support im Kernel nicht vergessen |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Fri May 30, 2014 11:56 am Post subject: |
|
|
Danke für die Infos Jungs.
Also wenn ich sicher gehen will, sollte ich erst das Laufwerk zu nullen, und dann verschlüsseln? Diese random-Geschichten dauern immer so extrem lange, gibt es für mein vorhaben keinen schnelleren weg zufallswerte zubekommen?
Ich will nicht von der 4TB Festplatte booten, ich will sie als Datengrabe benutzten, kann ich sie dann in meinem fall doch mit fdisk einrichten oder brauche ich in jedemfall bei Laufwerken über 2TB sys-apps/gptfdisk und CONFIG_EFI_PARTITION=y ? |
|
Back to top |
|
|
cryptosteve Veteran
Joined: 04 Jan 2004 Posts: 1169 Location: GER
|
Posted: Fri May 30, 2014 12:43 pm Post subject: |
|
|
Ja, brauchst Du auf jeden Fall. Sonst ist - wie bei mir geschehen - nach einem Reboot die Platte scheinbar leer und die Daten wie durch Zauberhand verschwunden. Hat mich 'ne ganze Zeit und zwei Dutzend deftiger Flüche gekostet, bis ich da drauf gekommen bin. _________________ - born to create drama -
gpg: 0x9B6C7E15
CS Virtual Travel Bug: VF6G5D |
|
Back to top |
|
|
py-ro Veteran
Joined: 24 Sep 2002 Posts: 1734 Location: Velbert
|
Posted: Fri May 30, 2014 12:47 pm Post subject: |
|
|
MBR verwaltet die Partitionen als Offset und Größe, der maximale Offset liegt bei 2TB und die Größe ebenso, sprich theoretisch könntest zwei Partitionen anlegen, eine bei 0 und eine bei 2TB(-1 Sektor) mit jeweils 2TB Länge.
Lass es lieber, ist den Ärger nicht Wert und neben dem hat GPT noch andere Vorteile, wie redundante Datenstrukturen.
Das Nullen vorher ist übrigens Kontraproduktiv, aber du kannst problemlos /dev/urandom nehmen, sollte auch nicht wesentlich langsamer sein und ist im Ergebnis annähernd das selbe wie mit /dev/random
Bye
Py |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Fri May 30, 2014 4:46 pm Post subject: |
|
|
OK, das mit dem partinionieren ist nun klar, danke für die Infos.
Meine mich zu errinern das /dev/urandom und oder /dev/random irgendwie mit 10 MB/s nur zugange waren. (Core i7 2600 mit 3,4 GHz hier).
/dev/zero dagegen war mit über 100 MB/s deutlich schneller, benötige ich besondere Kernel oder Gentoo-Optionen damit es mit /dev/urandom und /dev/random besser läuft? |
|
Back to top |
|
|
py-ro Veteran
Joined: 24 Sep 2002 Posts: 1734 Location: Velbert
|
Posted: Fri May 30, 2014 5:08 pm Post subject: |
|
|
/dev/random hängt von der "echten Entropy" ab, aber urandom sollte eigentlich schnell sein. |
|
Back to top |
|
|
kurisu Apprentice
Joined: 19 Jan 2011 Posts: 159 Location: Munich, Germany
|
Posted: Fri May 30, 2014 5:27 pm Post subject: |
|
|
Weshalb eigentlich cbc-essiv als Modus und nicht xts-plain64? Hast du einen triftigen Grund dafür? |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Fri May 30, 2014 9:48 pm Post subject: |
|
|
War nicht aes-cbc-essiv:sha256 am sichersten und zugleich auch noch am schnellsten?! |
|
Back to top |
|
|
kurisu Apprentice
Joined: 19 Jan 2011 Posts: 159 Location: Munich, Germany
|
Posted: Fri May 30, 2014 11:14 pm Post subject: |
|
|
Das dürfte überholt sein. Gemäß Changelog ist seit cryptsetup 1.6 aes-xts-plain64 Standard. Grund dürfte schlicht die bessere Performance gegenüber cbc sein, die xts ungeachtet der doppelten Schlüssellänge mit sich bringt, nachdem das deutlich weniger aufwendige plain respektive plain64 hier als Initialisierungsvektor genügt.
Edit: Von /dev/random mit dem Ziel zum Überschreiben der ganzen Platte ist dringlich abzuraten, sofern du nicht Jahre dafür aufwenden willst. Selbst das Erstellen eines kleinen Keyfiles kann da, bedingt durch „echte“ Entropie, durchaus länger dauern. Ein frisch erstelltes Dateisystem unter LUKS zu „nullen“ und die korrespondierende Datei danach wieder zu löschen dürfte am Ende locker dem Überschreiben eines unverschlüsselten Dateisystems mittels /dev/urandom gleichkommen. Ist die Platte jedoch neu, so sind, wie bereits gesagt, sämtliche Schritte entbehrlich. |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3922 Location: Hamburg
|
Posted: Sat May 31, 2014 2:35 pm Post subject: |
|
|
py-ro wrote: | Das Nullen vorher ist übrigens Kontraproduktiv | Inwiefern ? Ich halte es eigentlich für "nur" überflüssig. |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Mon Jun 02, 2014 6:04 pm Post subject: |
|
|
Hab mir per emerge -av gptfdisk es gezogen, aber ehm, wie benutze ich das denn?!
Wie muss ich in meinem Fall das 4TB Laufwerk damit einrichten?! |
|
Back to top |
|
|
py-ro Veteran
Joined: 24 Sep 2002 Posts: 1734 Location: Velbert
|
Posted: Mon Jun 02, 2014 6:17 pm Post subject: |
|
|
funktioniert im prinzip wie
sogar die meisten Kommandos haben die selbe Kürzel.
Oder nimmst
Dann hast ne curses basierte Oberfläche.
Bye
Py |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Wed Jun 04, 2014 2:48 pm Post subject: |
|
|
OK
Die Jungs von Gigabyte konnten mir nicht sagen ob mein P67 Mainboard 4TB Laufwerke verwalten kann.
Muss das Mainboard/Bios für Festplatten dieser größe irgendwas besonderes haben?
Oder kommt es nur auf das Betriebssystem an? |
|
Back to top |
|
|
py-ro Veteran
Joined: 24 Sep 2002 Posts: 1734 Location: Velbert
|
Posted: Wed Jun 04, 2014 3:08 pm Post subject: |
|
|
Eigentlich sind die GB Jungs recht informiert, aber nein, normal musst da nichts besonderes haben.
Bye
Py |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Wed Jun 04, 2014 3:19 pm Post subject: |
|
|
Beim booten von Laufwerken über 2TB wird ein UEFI Bios benötigt |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Wed Jun 04, 2014 6:25 pm Post subject: |
|
|
Macht euch keine Stress, wie groß die Platte sein darf. Das wird nicht vom Mainboard bestimmt sondern von der Partitionierung. Also mit GPT geht das. Die Sache ist nur die, dass Windows GPT nur mit UEFI unterstützt und nicht mit BIOS. Das trifft auf Linux aber nicht zu. Dort funktioniert GPT auch mit BIOS.
Hat man wohl so gemacht, um wenigstens einen Grund zu haben, damit man den Leute UEFI aufs Auge drücken kann. Und deshalb hält sich bei vielen das Gerücht, man bräuchte für große Platten UEFI. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1923 Location: Schweiz
|
Posted: Wed Jun 04, 2014 6:28 pm Post subject: |
|
|
Ab EFI/UEFI sollten Festplatten >2TB kein Problem mehr sein aber beim klassischen BIOS ist es leider eine ungewisse Sache.
Die grösste Gefahr besteht darin das ein BIOS die Festplatte fehlerhaft erkennt und dadurch auch eine fehlerhafte Basis dem Programmcode (z.B: Der Bootloader aus dem ersten Sektor der zu bootenden Festplatte) liefert der nach dem BIOS ausgeführt werden soll.
Beispiel: Ein BIOS welches nicht mit solchen Festplatten umgehen kann startet einen Bootloader der sich auf eben diese Basis vom BIOS verlässt und dadurch die Daten auf der Festplatte beim Zugriff eventuell schrottet.
Wenn du also ein BIOS hast das mit Festplatten dieser Größe nicht umgehen kann dann solltest du es vermeiden direkt davon zu booten, sondern den bootloader mitsamt Kernel auf ein Medium (z.B: eine kleinere Festplatte) auslagern das vom BIOS sauber erkannt wird. Denn sobald der Kernel, also das Betriebssystem, startet dürfte es egal sein was das BIOS erkannt oder eben nicht erkannt hat.
So sehen meine Erfahrungen zu diesem Thema aus. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5171
|
Posted: Wed Jun 04, 2014 7:43 pm Post subject: |
|
|
schmidicom wrote: |
Beispiel: Ein BIOS welches nicht mit solchen Festplatten umgehen kann startet einen Bootloader der sich auf eben diese Basis vom BIOS verlässt und dadurch die Daten auf der Festplatte beim Zugriff eventuell schrottet.
Wenn du also ein BIOS hast das mit Festplatten dieser Größe nicht umgehen kann dann solltest du es vermeiden direkt davon zu booten, sondern den bootloader mitsamt Kernel auf ein Medium (z.B: eine kleinere Festplatte) auslagern das vom BIOS sauber erkannt wird. |
Oder einen boot loader verwenden, welche die daten über Festplattengröße vom BIOS scheiß egal sind
Wobei es meist ausreichen sollte, wenn alle notwendigen daten, welche zum booten des eigentlichen systems benötigt werden, innerhalb des vom BIOS adressierbaren Bereichs liegt.
Z.b. in dem man eine kleine "Boot" Partition als erste MBR Partition anlegt.
Bei GPT Partitionsshema muss nur der Bootloader und das zu startende System GPT unterstützen. Für BIOS ohne GPT Unterstützung existiert die Möglichkeit GPT mit fake MBR zu erstellen.
Dadurch kann das BIOS dann zu mindestens den Bootloader laden. _________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Wed Jun 04, 2014 8:04 pm Post subject: |
|
|
Ihr sprecht hier immer nur von Festplatten von denen gebootet werden soll.
In meinem Fall soll das 4TB Laufwerk nur als Datengrab arbeiten.
Mein System bootet einem 256GB SSD Laufwerk.
Mein BIOS hat kein EFI/UEFI. AHCI und SATA3 hat es. |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Thu Jun 05, 2014 6:02 am Post subject: |
|
|
@firefly: BIOS ohne GPT Unterstützung gibt es? Ich dachte bislang immer, diese Meinung kommt daher, weil Windows kein GPT bei BIOS kann.
@SarahS93: Man denkt hier an alles |
|
Back to top |
|
|
|