Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Wie 4TB Laufwerk mit cryptsetup am besten einrichten?
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Wed May 28, 2014 6:03 pm    Post subject: Wie 4TB Laufwerk mit cryptsetup am besten einrichten? Reply with quote

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
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Fri May 30, 2014 5:10 am    Post subject: Reply with quote

Huhu?
Back to top
View user's profile Send private message
cryptosteve
Veteran
Veteran


Joined: 04 Jan 2004
Posts: 1169
Location: GER

PostPosted: Fri May 30, 2014 7:33 am    Post subject: Reply with quote

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
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4536
Location: Germany

PostPosted: Fri May 30, 2014 10:08 am    Post subject: Reply with quote

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
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Fri May 30, 2014 11:56 am    Post subject: Reply with quote

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
View user's profile Send private message
cryptosteve
Veteran
Veteran


Joined: 04 Jan 2004
Posts: 1169
Location: GER

PostPosted: Fri May 30, 2014 12:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1734
Location: Velbert

PostPosted: Fri May 30, 2014 12:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Fri May 30, 2014 4:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1734
Location: Velbert

PostPosted: Fri May 30, 2014 5:08 pm    Post subject: Reply with quote

/dev/random hängt von der "echten Entropy" ab, aber urandom sollte eigentlich schnell sein.
Back to top
View user's profile Send private message
kurisu
Apprentice
Apprentice


Joined: 19 Jan 2011
Posts: 159
Location: Munich, Germany

PostPosted: Fri May 30, 2014 5:27 pm    Post subject: Reply with quote

Weshalb eigentlich cbc-essiv als Modus und nicht xts-plain64? Hast du einen triftigen Grund dafür?
Back to top
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Fri May 30, 2014 9:48 pm    Post subject: Reply with quote

War nicht aes-cbc-essiv:sha256 am sichersten und zugleich auch noch am schnellsten?!
Back to top
View user's profile Send private message
kurisu
Apprentice
Apprentice


Joined: 19 Jan 2011
Posts: 159
Location: Munich, Germany

PostPosted: Fri May 30, 2014 11:14 pm    Post subject: Reply with quote

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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3922
Location: Hamburg

PostPosted: Sat May 31, 2014 2:35 pm    Post subject: Reply with quote

py-ro wrote:
Das Nullen vorher ist übrigens Kontraproduktiv
Inwiefern ? Ich halte es eigentlich für "nur" überflüssig.
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Jun 01, 2014 9:51 am    Post subject: Reply with quote

toralf wrote:
py-ro wrote:
Das Nullen vorher ist übrigens Kontraproduktiv
Inwiefern ? Ich halte es eigentlich für "nur" überflüssig.


yo,

falls das Nullen bzw. Beschreiben mit "random" Zeugs evtl. doch präferiert sein sollte:

https://wiki.archlinux.org/index.php/frandom

frandom dürfte das um einiges Beschleunigen



aes-xts-benbi , aes-xts-plain64 - keine Ahnung, welches davon besser ist, ich verwende das Erstere


bei Einsatz von einigermaßen schneller Hardware schadet ein

Code:
cryptsetup benchmark


nicht, um herauszufinden, welcher Algorithmus der beste Kompromiss zur Geschwindigkeit ist
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Mon Jun 02, 2014 6:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1734
Location: Velbert

PostPosted: Mon Jun 02, 2014 6:17 pm    Post subject: Reply with quote

Code:
gdisk


funktioniert im prinzip wie

Code:
fdisk


sogar die meisten Kommandos haben die selbe Kürzel.

Oder nimmst

Code:
cgdisk


Dann hast ne curses basierte Oberfläche.

Bye
Py
Back to top
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Wed Jun 04, 2014 2:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1734
Location: Velbert

PostPosted: Wed Jun 04, 2014 3:08 pm    Post subject: Reply with quote

Eigentlich sind die GB Jungs recht informiert, aber nein, normal musst da nichts besonderes haben.

Bye
Py
Back to top
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Wed Jun 04, 2014 3:19 pm    Post subject: Reply with quote

Beim booten von Laufwerken über 2TB wird ein UEFI Bios benötigt
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Wed Jun 04, 2014 5:31 pm    Post subject: Reply with quote

SarahS93 wrote:
Beim booten von Laufwerken über 2TB wird ein UEFI Bios benötigt


nicht wirklich

ich hatte eine 3 TB Platte (GPT Format) mit BIOS am laufen

das Problem ist, glaub ich, eher - dass die System-Partition innerhalb der 2 TB sein muss
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Klaus Meier
Advocate
Advocate


Joined: 18 Apr 2005
Posts: 2908
Location: Bozen

PostPosted: Wed Jun 04, 2014 6:25 pm    Post subject: Reply with quote

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
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1923
Location: Schweiz

PostPosted: Wed Jun 04, 2014 6:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
firefly
Watchman
Watchman


Joined: 31 Oct 2002
Posts: 5171

PostPosted: Wed Jun 04, 2014 7:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
SarahS93
l33t
l33t


Joined: 21 Nov 2013
Posts: 693

PostPosted: Wed Jun 04, 2014 8:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
Klaus Meier
Advocate
Advocate


Joined: 18 Apr 2005
Posts: 2908
Location: Bozen

PostPosted: Thu Jun 05, 2014 6:02 am    Post subject: Reply with quote

@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 :lol: :lol: :lol:
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum