# Wie 4TB Laufwerk mit cryptsetup am besten einrichten?

## SarahS93

Will ein 4TB Laufwerk verschlüsseln und als Datengrab benutzen.

```
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....

----------

## SarahS93

Huhu?

----------

## cryptosteve

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.

----------

## Josef.95

 *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  :Smile: 

----------

## SarahS93

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 ?

----------

## cryptosteve

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.  :Smile: 

----------

## py-ro

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

----------

## SarahS93

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?

----------

## py-ro

/dev/random hängt von der "echten Entropy" ab, aber urandom sollte eigentlich schnell sein.

----------

## kurisu

Weshalb eigentlich cbc-essiv als Modus und nicht xts-plain64? Hast du einen triftigen Grund dafür?

----------

## SarahS93

War nicht aes-cbc-essiv:sha256 am sichersten und zugleich auch noch am schnellsten?!

----------

## kurisu

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.

----------

## toralf

 *py-ro wrote:*   

> Das Nullen vorher ist übrigens Kontraproduktiv

 Inwiefern ? Ich halte es eigentlich für "nur" überflüssig.

----------

## kernelOfTruth

 *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

```
cryptsetup benchmark
```

nicht, um herauszufinden, welcher Algorithmus der beste Kompromiss zur Geschwindigkeit ist

----------

## SarahS93

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?!

----------

## py-ro

```
gdisk
```

funktioniert im prinzip wie 

```
fdisk
```

sogar die meisten Kommandos haben die selbe Kürzel.

Oder nimmst

```
cgdisk
```

Dann hast ne curses basierte Oberfläche.

Bye

Py

----------

## SarahS93

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?

----------

## py-ro

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

Bye

Py

----------

## SarahS93

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

----------

## kernelOfTruth

 *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

----------

## Klaus Meier

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.

----------

## schmidicom

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.

----------

## firefly

 *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  :Wink: 

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.

----------

## SarahS93

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.

----------

## Klaus Meier

@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  :Laughing:   :Laughing:   :Laughing: 

----------

## py-ro

Es ist eher so, wie bei meinem bescheurten Thinkpad, dass manche BIOSe versuchen den MBR auszuwerten, was bei GPT halt schief gehen kann. Mein Thinkpad weigert sich z.B. im BIOS Modus von einer Platte zu starten wo keine Partition als Boot markiert ist, es rührt dann den Code im MBR gar nicht an...

----------

