Grundsatzüberlegungen vor Neuinstallation

[NAB]

Ich überlege nur mittlerweile, ob es einfachere Ansätze gibt, als das komplette System zu verschlüsseln. Z.B. nur /home verschlüsseln. Dann kann der Rechner problemlos z.B. per WOL hochfahren und alle Dienste laufen lassen, die gewünscht sind, er kann halt nur auf das verschlüsselte /home nicht zugreifen.

Ein weiterer Ansatz hierfür ist "ecryptfs":
http://wiki.ubuntuusers.de/ecryptfs
(Achtung, der Link dient nur der Information und ist so vermutlich nicht 1:1 auf Debian anwendbar. Ich hab nur sonst nix auf Deutsch gefunden)

Der wichtige Unterschied ist, dass nicht das gesamte "/home" verschlüsselt wird (dann wäre das System nämlich wieder ohne Passwort nicht bootbar), sondern nur dein Home-Verzeichnis unter /home/ - das wird erst beim Login gebraucht.

Dasselbe kannst du dir aber auch mit cryptsetup selber basteln. Du kannst mit Cryptsetup sowohl ganze Partitionen verschlüsseln (das Dateisystem kommt dann nachher auf die verschlüsselte Partition) als auch eine Container-Datei, die als großer Datenklumpen im Dateisystem liegt. So ein Container wird dann auch mit einem Dateisystem beschrieben und nachher gemounted - zum Beispiel in ein Unterverzeichnis deines Home-Verzeichnisses.

Solche Basteleien erhöhen aber im Zweifelsfall wieder die Komplexität - ein verschlüsseltes "/" ist die simpelste Lösung.

Und du solltest dir genau überlegen, was du für "verschlüsselungswürdig" hältst. Unter /var/ legt "locate" zum Beispiel eine Liste sämtlicher Dateinamen an, die es im System findet, und unter /tmp/ finden sich mitunter komplette Dateien. Wenn man sich darüber keine Gedanken machen will, bietet sich wieder die Vollverschlüsselung per cryptsetup an.

Solange du nur "ausgebaute Festplatten" schützen willst, spricht auch nichts dagegen, die Schlüsseldatei auf einem USB-Stick oder einer CD-R unterzubringen. Solange der Schlüssel im System steckt, bootet es, aber eine einzelne Festplatte enthält nur Datenmüll.

Ein weiterer Trick, um ein bootendes System zu haben: Du installierst Debian zwei mal. Einmal verschlüsselt, und einmal unverschlüsselt. Die Vorauswahl in Grub lässt das unverschlüselte System automatisch starten. Dann stehen nach einem Stromausfall wenigstens Dienste wie DHCP automatisch wieder zur Verfügung, nur die verschlüsselten Dateien nicht.

Und wie üblich steckt der Teufel im Detail: "ecryptfs" ist langsamer - nach einem Test von Phoronix:
http://www.phoronix.com/scan.php?page=a ... rypt&num=1

Generell sollte man den Einfluss von Verschlüsselung auf die Geschwindigkeit nicht unterschätzen. Unter Squeeze auf einem alten 2 GHz AMD Zweikerner limitiert die Verschlüsselung die Festplatten auf ca. 40 MB/s beim Lesen. Beim Kopieren von einer Festplatte auf eine andere geht's dann runter auf unter 20 MB/s. Unter Wheezy müsste es dann theoretisch doppelt so schnell sein, dann ist der Prozessor aber auch mit nichts anderem als "Daten entschlüsseln" voll ausgelastet.

Wenn eh ein Neukauf ansteht, würde ich dringend empfehlen, auf das Feature "AES-NI" beim Prozessor zu achten. Dieses wird von "ecryptfs" allerdings erst ab Kernel 3.10 ausgenutzt.Das spricht wieder für cryptsetup.

[wanne]

Generell sollte man den Einfluss von Verschlüsselung auf die Geschwindigkeit nicht unterschätzen. Unter Squeeze auf einem alten 2 GHz AMD Zweikerner limitiert die Verschlüsselung die Festplatten auf ca. 40 MB/s beim Lesen.

Wie hast du das geschaft? Kein einziger, der eine CPU mit mehr als 2 GHz hst ist im Benchmark derartig langsam. Hast du noch einen mit 32Bit?

[NAB]

Wie hast du das geschaft? Kein einziger, der eine CPU mit mehr als 2 GHz hst ist im Benchmark derartig langsam. Hast du noch einen mit 32Bit?

Wenn du mal genau hinguckst, liegt der AMD Turion 64 mit 1,8 GHz ungefähr in dieser Leistungsklasse.

Ansonsten verwende ich aes-xts-plain und echte HDDs statt einer Ramdisk und ein verschlüsseltes System mit einem Dateisystem statt einer linearen Testdatei. Dieser Benchmark ist im praktischen Betrieb ziemlich aussagelos.

[syssi]

Ansonsten verwende ich aes-xts-plain und echte HDDs statt einer Ramdisk und ein verschlüsseltes System mit einem Dateisystem statt einer linearen Testdatei. Dieser Benchmark ist im praktischen Betrieb ziemlich aussagelos.

Dieser Benchmark soll aufzeigen, wo die obere Schranke "einer CPU" liegt. Das tut er. Nicht mehr und nicht weniger... auch im praktischen Betrieb.

[tex]

In Zeiten von quasi "volatilen" VMs in diversen Clouds klingen diese Erwägungnen schon fast nostalgisch.

[wanne]

Wenn du mal genau hinguckst, liegt der AMD Turion 64 mit 1,8 GHz ungefähr in dieser Leistungsklasse.

Ok, ein Mobiler... Die sind gerne mal gemächlicher unterwegs.

Ansonsten verwende ich aes-xts-plain

Das sollte kaum was ausmachen. Zumal cbc-essiv:sha256 auch nicht vollständig schlank ist.

echte HDDs statt einer Ramdisk

Da sollte wurst sein, solang die HDD das mit macht. (Das muss leider nicht sein.) sollte das kein Problem sein.

verschlüsseltes System mit einem Dateisystem statt einer linearen Testdatei.

Das macht ordentlich was aus. Aber im Normalfall kopiert man wenn man große Datenmengen kopiert doch wenige große Dateien und nicht wenige kleine. Und dann ist sowieso die IO der HD der limiteirende Faktor. bis die geseekt hat kann man gerade noch ein nickerchen machen...

Beim Kopieren von einer Festplatte auf eine andere geht's dann runter auf unter 20 MB/s

Das ist komisch. Wozu hat das ding denn nen 2. Kern?

[ChronoBoost]

Ansonsten verwende ich aes-xts-plain

Das sollte kaum was ausmachen. Zumal cbc-essiv:sha256 auch nicht vollständig schlank ist.

Bei meinen Tests mit Wheezy war aes-xts-plain64 sogar ein paar Prozent schneller als aes-cbc-essiv:sha256.

[dirk11]

Leute, BITTE!

Es ist KEIN Neukauf geplant, und was auf Turions o.ä. passiert, ist hier nicht von Belang; ich habe schon geschrieben, dass es ein Athlon64 ist.

Ich bin mir mittlerweile überhaupt nicht mehr sicher, ob ich überhaupt und wenn ja welche Art der Verschlüsselung ich nutzen will.
Momentan sind bei mir exakt zwei Dateien mit GnuPG verschlüsselt, bei beiden handelt es sich um "private" Daten - so etwas wie eingescannte Versicherungsverträge o.ä.. Es ist schon richtig, ein im Betrieb entschlüsselter Server würde derlei Daten natürlich wieder unverschlüsselt zur Verfügung stellen, wenn ich sie nicht nochmal separat verschlüssele. Die Verschlüsselung hilft halt nur für den "Nicht-Betrieb".

Es steht auch noch eine für mich neue Frage im Raum: was passiert eigentlich bei einem Systemausfall in Form von Kernelhänger, Stromausfall oder sonstigem Hardwarefehler mit den verschlüsselten Daten? Sind die Hops? Kann ich die einfach so beim nächsten Booten wieder entschlüsseln? Oder wie wird garantiert, dass die "Daten-Integrität" nicht leidet? Ich meine, theoretisch könnte ein verschlüsseltes System unter so einem harten Abschalten doch so leiden, dass es sich nicht mehr entschlüsseln lässt. Oder ist das eine unberechtigte Sorge?

[wanne]

Eher unwahrscheinlich. Das sollte nicht viel mehr passieren, als wenn das Dateisystem direkt geschrieben wird. (Zumal Dateissysteme in 4K Blöcken arbeiten, dürfte da selbst bei cbc nie größere Teile kaputt gehen als normal.) Wirklich sensiebel ist nur der Header. Und der wird ja nur einmal beim Formatieren geschrieben. (Mach trotzdem ein backup...) Sonst geht wenn irgend wo ein Fehler auftritt nur der eine (bzw. bei cbc 2) 16Byte Block kaputt. Das ist im Vergleich zu den 512byte Blöcken der HD oder den 4K Blöcken des Dateisystems verschwindend gering.

[NAB]

Bei meinen Tests mit Wheezy war aes-xts-plain64 sogar ein paar Prozent schneller als aes-cbc-essiv:sha256.

Das könnte daran liegen, dass du mit der default keysize von 256 mit aes-cbc bei AES256 landest, bei aes-xts aber nur bei AES128. Das ist weniger sicher, rechnet sich aber schneller.

Es steht auch noch eine für mich neue Frage im Raum: was passiert eigentlich bei einem Systemausfall in Form von Kernelhänger, Stromausfall oder sonstigem Hardwarefehler mit den verschlüsselten Daten? Sind die Hops? Kann ich die einfach so beim nächsten Booten wieder entschlüsseln? Oder wie wird garantiert, dass die "Daten-Integrität" nicht leidet? Ich meine, theoretisch könnte ein verschlüsseltes System unter so einem harten Abschalten doch so leiden, dass es sich nicht mehr entschlüsseln lässt. Oder ist das eine unberechtigte Sorge?

Völlig unberechtigt ist die Sorge nicht ... ein Hardware-Ausfall kann deine Daten immer ins Nirvana reißen, egal ob verschlüsselt oder nicht. Ein backup empfiehlt sich so oder so.

Aus praktischer Erfahrung kann ich dir zu cryptsetup sagen: Da passiert nichts bei Abstürzen, Stromausfällen etc. Im Crypto-Container befindet sich ja ein komplettes Dateisystem, vorzugsweise mit Journal, das stellt einen Absturz fest, stellt den letzten konsistenten Zustand wieder her ... da gibt es keinen Unterschied zu einem unverschlüsselten System.

Mit ecryptfs habe ich keine Erfahrungen, aber das tut seit Jahren unter Ubuntu gute Dienste.

[wanne]

ich habe schon geschrieben, dass es ein Athlon64 ist.

Dann ist im Rechner wahrscheinlich alt und hat sowieso nur langsame Festplatten?
Am besten testet du einfach mal die Geschwindigkeit wie im benchmark und dann einmal die des RAIDs. (einfach dd if=/dev/mapper/md0 of=/dev/null bs=4k count=125000)
Dann siehts du, ob die CPU dich Begrenzt. (Echtbetrieb mag nochmal anders sein. aber das fällt garnatiert eher zu gunsten der CPU und nicht der HD aus.)

PS: Ein etwas freundlichereren Umgangston fände ich angebracht.

Das ist weniger sicher

Dem würde ich widersprechen. Gegen AES256 sind erheblich bessere Angriffe bekannt. Und das ist bei Keylängen über der Blocklänge finde ich so rein intitiv nicht verwunderlich.

Das könnte daran liegen, dass du mit der default keysize von 256 mit aes-cbc bei AES256 landest, bei aes-xts aber nur bei AES128.

Interessant. Wie setzt cryptsetup die Keysize fest, wenn man kein -s angibt?

[NAB]

Dem würde ich widersprechen. Gegen AES256 sind erheblich bessere Angriffe bekannt. Und das ist bei Keylängen über der Blocklänge finde ich so rein intitiv nicht verwunderlich.

Aha? Erzähl mehr!

Das könnte daran liegen, dass du mit der default keysize von 256 mit aes-cbc bei AES256 landest, bei aes-xts aber nur bei AES128.

Interessant. Wie setzt cryptsetup die Keysize fest, wenn man kein -s angibt?

Wie geschrieben ... per "default".

[peschmae]

PS: Ein etwas freundlichereren Umgangston fände ich angebracht.

Ich auch...

Dem würde ich widersprechen. Gegen AES256 sind erheblich bessere Angriffe bekannt. Und das ist bei Keylängen über der Blocklänge finde ich so rein intitiv nicht verwunderlich.

Aha? Erzähl mehr!

Wikipedia sagt

Die Forscher Alex Biryukov und Dmitry Khovratovich veröffentlichten Mitte des Jahres 2009 einen Angriff mit verwandtem Schlüssel[11] auf die AES-Varianten mit 192 und 256 Bit Schlüssellänge. Dabei nutzten sie Schwächen in der Schlüsselexpansion aus und konnten eine Komplexität von 2119 erreichen. Damit ist die AES-Variante mit 256 Bit Schlüssellänge formal schwächer als die Variante mit 128 Bit Schlüssellänge.[12] Ende 2009 wurde mit einer Verbesserung des Angriffs eine Komplexität von nur noch 299,5 erreicht.

Ist also durchaus verhandelbar...

MfG Peschmä

[wanne]

Ist also durchaus verhandelbar...

Ja, zumal wos einen Angriff gibt oft andere folgen. Wir hatten das an anderer stelle. Das ist nicht ohne. Nach Moors law ist AES256 glaube ich in 50 Jahren mit vertretbarem Geld und Zeitaufwand knackbar. (Als richtlinie habe ich den verlauf dessen genommen was die RSA-Challanges (RC5) so geknackt haben.) – Ohne weitere Cryptoanalyse.

Aber so langsam wird's offtoppic

[NAB]

Jetzt muss mir noch wer erklären, wie bei einer Festplattenverschlüsselung ein Angreifer zu diesen "verwandten Schlüsseln" kommen soll, sonst war wannes Einwand wirklich völlig off-topic.

[ChronoBoost]

Bei meinen Tests mit Wheezy war aes-xts-plain64 sogar ein paar Prozent schneller als aes-cbc-essiv:sha256.

Das könnte daran liegen, dass du mit der default keysize von 256 mit aes-cbc bei AES256 landest, bei aes-xts aber nur bei AES128.

Daran lag es nicht, denn die xts-keysize war 256 bzw. 512 und die cbc-keysize war 128 bzw. 256 beim Test.

[dirk11]

Dann ist im Rechner wahrscheinlich alt und hat sowieso nur langsame Festplatten?

Na ja, alt ist relativ. Er bekommt nigelnagelneue Toshiba 3TB-HDDs, die habe ich heute gekauft. Ich hoffe, die kann ich problemlos nutzen in der Kiste...

Am besten testet du einfach mal die Geschwindigkeit wie im benchmark und dann einmal die des RAIDs. (einfach dd if=/dev/mapper/md0 of=/dev/null bs=4k count=125000)

Da bis jetzt noch gar nichts drin ist, kann ich auch nichts testen. Davon ab ist es sowieso wurscht, weil die Hardware gegeben ist und nicht geplant ist, da noch umzuschwenken. Wie gesagt, derzeitiger Server ist ein Pentium-3 ohne Verschlüsselung, der wartet die meiste Zeit seines Lebens nur so vor sich hin. Ich kann mir ehrlich gesagt nicht vorstellen, dass ich nur mit einem verschlüsselten Dateisystem einen Athlon64 3800+ an seine Grenzen bringe, es soll ja auch Leute geben, die sowas auf nicht so performanter MiniITX-Hardware mit Netbook-Prozessoren laufen haben.

PS: Ein etwas freundlichereren Umgangston fände ich angebracht.

Ja, mag sein, ich fände es auch angebracht, wenn nicht ständig auf Nebenschauplätze abgebogen würde...

Interessant. Wie setzt cryptsetup die Keysize fest, wenn man kein -s angibt?

Muss ich beim Aufsetzen des Systems darauf irgendwie achten? Was für eine Verschlüsselungsstärke nehme ich denn? Wirkt die sich auch auf die Geschwindigkeit aus, oder geht es da nur um das initiale Entschlüsseln des Containments?

[NAB]

Daran lag es nicht, denn die xts-keysize war 256 bzw. 512 und die cbc-keysize war 128 bzw. 256 beim Test.

Also bei dir war xts mit -s 512 leicht schneller als cbc mit -s 256? Das finde ich ja nun sehr interessant und würde gerne wissen, welche Hardware/welcher Kernel das war? Ob du dazu einen eigenen Thread aufmachen kannst?

Ich kann mir ehrlich gesagt nicht vorstellen, dass ich nur mit einem verschlüsselten Dateisystem einen Athlon64 3800+ an seine Grenzen bringe,

Der Punkt ist, dass Verschlüsselung halt einiges an Rechenkraft kostet. Soweit ich dich verstehe, ist ein Raid1 mit _einer_ Verschlüsselung drauf geplant, ein Umkopieren von einer verschlüsselten Platte zu einer anderen verschlüsselten Platte also eher selten der Fall. Außerdem geht es um (langsame) HDDs und der Prozessor soll sonst nichts Aufwändiges erledigen.

Ich denke, unter diesen Annahmen und mit einem aktuellen Kernel wird dein Prozessor die Sache mit der Verschlüsselung spielend erledigen.

Muss ich beim Aufsetzen des Systems darauf irgendwie achten? Was für eine Verschlüsselungsstärke nehme ich denn?

Nein, darauf musst du nicht achten. Du hast (vereinfacht ausgedrückt) die Wahl zwischen AES 128 und AES 256, und bei beiden geht der geschätzte Zeitaufwand zum "knacken" in die Millionen Jahre. Wenn AES an sich irgendwann mathematisch gebrochen wird, wirst du es aus den Nachrichten erfahren. Bis dahin sind beide ausreichend sicher, solange du nicht erwartest, dass sich eine wohlhabende Regierung brennend für deine Daten interessiert.

Wirkt die sich auch auf die Geschwindigkeit aus, oder geht es da nur um das initiale Entschlüsseln des Containments?

Es gibt kein "initiales Entschlüsseln des Containers". Jedes Byte von der Festplatte wird im laufenden Betrieb beim Schreiben verschlüsselt und beim Lesen entschlüsselt. Das bedeutet fortwährenden Arbeitsaufwand für die CPU. Beim "initialen Entschlüsseln" wird nur der Anfang des Dateisystems gelesen (und dabei entschlüsselt) damit das System weiß, welche Verzeichnisse sich darauf befinden.

[wanne]

Am besten testet du einfach mal die Geschwindigkeit wie im benchmark und dann einmal die des RAIDs. (einfach dd if=/dev/mapper/md0 of=/dev/null bs=4k count=125000)

Da bis jetzt noch gar nichts drin ist, kann ich auch nichts testen.

Nichts drin geht nicht. Irgend was steht immer auf der Festplatte und um die Lesegeschwindigkeit zu testen ist dir ja wurst ob das nur müll ist. Und auch der Xryptotest ist nur das was man maximal verschlüsslen kann.

Davon ab ist es sowieso wurscht, weil die Hardware gegeben ist und nicht geplant ist, da noch umzuschwenken. Wie gesagt, derzeitiger Server ist ein Pentium-3 ohne Verschlüsselung, der wartet die meiste Zeit seines Lebens nur so vor sich hin. Ich kann mir ehrlich gesagt nicht vorstellen, dass ich nur mit einem verschlüsselten Dateisystem einen Athlon64 3800+ an seine Grenzen bringe, es soll ja auch Leute geben, die sowas auf nicht so performanter MiniITX-Hardware mit Netbook-Prozessoren laufen haben.

Unteschätze das nicht. Neuere Hardware ist extra darauf ausgelegt, AES zu verschlüsseln. (Und AES ist darauf ausglegt das man einfach Hardware bauen kann, die sowas schnell erledigt.) Dein P-III kennt sowas noch nicht. Und muss das mühsam von hand machen. Und es wird natürlich auch weiterhin so sein, dass die meiste zeit nichts los ist, die Frage ist ob der Prozessor hinterher kommt, wenn du dir mit maximaler Geschwindigkeit ne Große Datei runterkopierst. Das geht dann im Zweifelsfall langsamer auch wenn der Prosessor den 99% der Zeit nciht genutzt wird.

Interessant. Wie setzt cryptsetup die Keysize fest, wenn man kein -s angibt?

Muss ich beim Aufsetzen des Systems darauf irgendwie achten? Was für eine Verschlüsselungsstärke nehme ich denn? Wirkt die sich auch auf die Geschwindigkeit aus, oder geht es da nur um das initiale Entschlüsseln des Containments?

Was du da nimmst wirkt scih enorm auf die Geschwindigkeit aus, sobalt die CPU langsamer verschlüsselt als man auf die Festplatte schreiben kann wird dein System beim Abspeichern von Dateien langsamer. Ich würde dir empfehlen bei den Defaults zu bleiben. (Die leute die die gewählt haben haben sich da schon was bei gedacht.) AES ist so ziemlich die schnellste Verschlüsslung die als sicher gilt. Und neben bei garantierd die meist untersuchteste. Die Keysize auf 192 oder 128 zu verkürzen könnte aber tatsächlich geschwindigkeitstechnisch was bringen. Und ob die längere mit mehr Runden wirklich sicherer ist, ist auf jeden fall fraglich.
Hier ein benchmark auf meinem Rechner: viewtopic.php?f=28&t=119251&hilit=bench ... 30#p768635

[wanne]

Daran lag es nicht, denn die xts-keysize war 256 bzw. 512 und die cbc-keysize war 128 bzw. 256 beim Test.

Also bei dir war xts mit -s 512 leicht schneller als cbc mit -s 256? Das finde ich ja nun sehr interessant und würde gerne wissen, welche Hardware/welcher Kernel das war?

-s 512 Bei AES finde ich sowieso sehr interessant den gibt's nur in 128,192 und 256 Bit. Das sieht der Kernel auch so:

Code: Alles auswählen

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : kernel
priority     : 200
refcnt       : 13
selftest     : passed
type         : givcipher
async        : no
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : eseqiv

Ob du dazu einen eigenen Thread aufmachen kannst?

Oder vielleicht das ganze Thema abtrennen?

[dirk11]

Hi Leute,

nachdem ich ja am Anfang auch hier im thread und dort doch sehr gegen LVM war, habe ich heute die Information bekommen, das ich bei einer Vollverschlüsselung jede Partition einzeln (also auch das verschlüsselte swap) beim Start des Rechners durch Eingabe von PW oder Key entschlüsseln muss.

Das war mir so nicht bewusst, und wenn diese Information so richtig ist, dann ist es doch wieder sehr überlegenswert, doch ein LVM einzurichten. Das mache ich nämlich erstmal nur einmal, während ich den Rechner wohl öfter mal einschalten muss. Und ich will nur einmal das PW eingeben müssen!

Dazu habe ich aber noch einige für mich wichtige offene Fragen:

1. Wie komme ich denn an ein verschlüsseltes und mit LVM versehenes System dran, wenn ich z.B. eine GRML boote, weil ich einen filesystem-check machen will? Ich muss ja dann auch LVM und crypt haben.

2. SWAP gehört dann auch mit in das LVM, richtig? Sprich, in meinem speziellen Fall meine Platten brauchen nur noch 1MB-Partition "reserviert für BIOS", damit grub das System starten kann, eine unverschlüsselte /boot, und der gesamte Rest kommt in das LVM, korrekt?

3. Da ich vom Gedanken, BTRFS zu nutzen, abgekommen bin: XFS oder ext4? Gibt es auch da etwas, was ich übersehen habe? ext4 hat den Vorteil, das ich es später in BTRFS umwandeln kann, XFS hat dafür den Vorteil, das ihm nicht die inodes (heißt das so?) ausgehen können, und ich dann trotz freiem Speicher nichts mehr speichern kann. Da ich sicherlich nicht einfach so das FS wechseln werde, würde ich so aus dem Bauch heraus dann bei XFS bleiben.

Und es stellt sich immer noch die Frage der korrekten Reihenfolge.
a) MBR/GPT->md->LVM->Crypt->FS
b) MBR/GPT->md->Crypt->LVM->FS
oder
c) doch ganz anders?
Momentan würde ich Variante a) bevorzugen.

Frage am Rande zur Verschlüsselung: wenn ich das System so einrichte, dass ein keyfile eingelesen wird, z.B. von einem USB-Stick, kann ich dann trotzdem noch ein PW eingeben, wenn der Stick gerade nicht vorhanden ist? Also sprich, wird die Auswahl am Anfang gemacht: Stick vorhanden=einlesen, wenn nicht vorhanden, dann Eingabe?
Muss bzw. sollte ich bei der Einrichtung an irgendeiner Stelle des Installers von den defaultwerten abweichen? Nehme ich lieber den grafischen Installer, oder den Text-Installer in der extended-version?

Falls sich jemand fragt, was all diese Fragen zu bedeuten haben: ich nutze Debian seit Version 3, aber ich habe ebenso seit dieser Version nie wieder ein Debian neu installiert. Ich habe immer nur von einem "Mutter-System" kopiert und angepasst. Ich will jetzt neu installieren, weil ich auf 64Bit umsteigen und alte Conf-Leichen loswerden will, und das will in meinen Augen wohlüberlegt sein.

[NAB]

nachdem ich ja am Anfang auch hier im thread und dort doch sehr gegen LVM war, habe ich heute die Information bekommen, das ich bei einer Vollverschlüsselung jede Partition einzeln (also auch das verschlüsselte swap) beim Start des Rechners durch Eingabe von PW oder Key entschlüsseln muss.

Jein ... gerade bei Swap bietet sich decrypt_derived an:
http://wiki.ubuntuusers.de/LUKS/Schl%C3%BCsselableitung

Und ansonsten kannst du es generell so einrichten, dass du ein Passwort für deine "/"-Partition eingeben musst, und die weiteren Passwörter für die restlichen Partitionen in dieser verschlüsselten "/"-Partition liegen und die restlichen Partitionen damit automatisch gemounted werden. Das ist zwar vom Sicherheitsaspekt her nicht ganz so fein, sollte aber bei deinem erwarteten "Bedrohunsszenario" völlig ausreichen.

Die LVM-Lösung hat sich Debian einfallen lassen, um elegant um die Sache herumzukommen. Immerhin muss der Installer das alles "idiotensicher" einrichten können, da ist die Lösung mit LVM einfach "einfach".

Die ist aber "vermeidbar", insbesondere wenn du nur eine verschlüsselte Partition für "/" einrichtest (ich denke, das war eh in deinem Sinne, möglichst wenige Partitionen). Die Swap-Partition richtest du dann erst mal gar nicht ein, und bindest sie nach der Installation per decrypt_derived ein.

1. Wie komme ich denn an ein verschlüsseltes und mit LVM versehenes System dran, wenn ich z.B. eine GRML boote, weil ich einen filesystem-check machen will? Ich muss ja dann auch LVM und crypt haben.

cryptsetup luksOpen /dev/sdX1 target
Dann taucht unter /dev/mapper/target das entschlüsselte LVM auf.
Das kannst du mit "pvscan" und "lvscan" untersuchen, und dann mit lvchange -ay das gewünschte Volume aktivieren.
Das taucht dann auch unter /dev/mapper auf und kann von dort gemountet werden.

2. SWAP gehört dann auch mit in das LVM, richtig? Sprich, in meinem speziellen Fall meine Platten brauchen nur noch 1MB-Partition "reserviert für BIOS", damit grub das System starten kann, eine unverschlüsselte /boot, und der gesamte Rest kommt in das LVM, korrekt?

_Falls_ du dem Weg des automatischen Debian-Installers folgst, ist das so richtig, ja.

3. Da ich vom Gedanken, BTRFS zu nutzen, abgekommen bin: XFS oder ext4? Gibt es auch da etwas, was ich übersehen habe? ext4 hat den Vorteil, das ich es später in BTRFS umwandeln kann, XFS hat dafür den Vorteil, das ihm nicht die inodes (heißt das so?) ausgehen können, und ich dann trotz freiem Speicher nichts mehr speichern kann. Da ich sicherlich nicht einfach so das FS wechseln werde, würde ich so aus dem Bauch heraus dann bei XFS bleiben.

Ich habe es im Haus- und Büro-Gebrauch noch nie erlebt, dass mir die inodes ausgehen, trotz Standardeinstellungen und umfangreicher Dateisysteme. Ich bastele allerdings auch keine gigantischen Raid6 mit zig TB Größe. Mit XFS fehlt mir die Erfahrung.

Und es stellt sich immer noch die Frage der korrekten Reihenfolge.
a) MBR/GPT->md->LVM->Crypt->FS
b) MBR/GPT->md->Crypt->LVM->FS
oder
c) doch ganz anders?
Momentan würde ich Variante a) bevorzugen.

Tja, blöd ... b) ist richtig
Bei a) würdest du jedes Logical Volume im LVM einzeln verschlüsseln, hättest also wieder das Problem mit mehreren Passwörtern.

Frage am Rande zur Verschlüsselung: wenn ich das System so einrichte, dass ein keyfile eingelesen wird, z.B. von einem USB-Stick, kann ich dann trotzdem noch ein PW eingeben, wenn der Stick gerade nicht vorhanden ist? Also sprich, wird die Auswahl am Anfang gemacht: Stick vorhanden=einlesen, wenn nicht vorhanden, dann Eingabe?

Gute Frage ... ich weiß es nicht.
Wenn du das System mit dem Installer einrichtest, hast du meines Wissens eh keine Wahl - er fragt nach einem Passwort. Die Nutzung eines Keyfiles müsstest du also eh nachher manuell einrichten.
Die Logik "wenn Keyfile, dann nimm das, sonst frage nach Passwort" lässt sich garantiert irgendwie in den Bootprozess reinpfrickeln, ich hab sowas aber noch nie gemacht.

Muss bzw. sollte ich bei der Einrichtung an irgendeiner Stelle des Installers von den defaultwerten abweichen? Nehme ich lieber den grafischen Installer, oder den Text-Installer in der extended-version?

Was du machen "musst" hängt davon ab, was du haben "willst".

Und ich zitiere noch kurz aus deinem BIOS-Thread:

- 16GB für SWAP (ich gehe momentan davon aus, dass ich die Kiste niemals im Leben auf mehr als 8GB RAM bringen werde, der frißt nur DDR2). Oder sollten es 17GB sein, um sicher zu gehen, das es nicht zu wenig ist für z.B. Suspend to Disk?

Die Rechnung geht so nicht auf ... wenn dein System 8 GB RAM und 16GB Swap nutzt, dann ist es erstens stinkend langsam und hat zweitens trotzdem keinen Platz mehr auf der Swap-Partition, um seine 8 GB RAM auszulagern. Wenn das System eh nie mehr als 8GB RAM haben soll, sollten 9GB Swap für den üblichen Gebrauch locker ausreichen. Nur wenn du doch noch eine Aufrüstung auf 16GB in Erwägung ziehst, dann machen die 17GB Sinn ... für die seltenen Fälle, in denen wirklich die 16GB RAM komplett ausgenutzt werden.

- 14GB für /boot (ist viel, ich weiß, in meinem momentanen /boot sind 17MB belegt, aber damit habe ich die Möglichkeit, darauf notfalls ein komplettes System zu installieren)

Das halte ich für eine ganz schlechte Idee, in die /boot/-Partition noch ein System hineinzuinstallieren. Dann lass lieber eine extra 13GB-Partition frei für die Installation eines Rettungs-Systems.

[liNixchecker]

Hi,

1. Wie komme ich denn an ein verschlüsseltes und mit LVM versehenes System dran, wenn ich z.B. eine GRML boote, weil ich einen filesystem-check machen will? Ich muss ja dann auch LVM und crypt haben.

Ist kein Problem, GRML Bespielsweise hat die Pakete cryptsetup und lvm2 von Haus aus mit drin, mehr brauchst du dafür nicht. Du kannst dir aber auch eine "Maintenance"-Partition erstellen; Eine kleine Nur-Konsolen-Installation mit Scripten für Backup, Fs-Check usw...

2. SWAP gehört dann auch mit in das LVM, richtig? Sprich, in meinem speziellen Fall meine Platten brauchen nur noch 1MB-Partition "reserviert für BIOS", damit grub das System starten kann, eine unverschlüsselte /boot, und der gesamte Rest kommt in das LVM, korrekt?

Kannst du so machen. Es ist aber auch möglich der Swap-Partition einen zufälligen Schlüssel zu verpassen. Der wird dann bei jedem Mounten neu erzeugt.

Zum FS:
ext4 ist stabil und reicht imho aus. Für meine /tmp benutze ich sogar nur ext2.
Damit wären wir auch schon beim Vorteil von lvm:

Und es stellt sich immer noch die Frage der korrekten Reihenfolge.
a) MBR/GPT->md->LVM->Crypt->FS
b) MBR/GPT->md->Crypt->LVM->FS
oder
c) doch ganz anders?

Bei Verwendung von LV's kannst Du für verschiedene Verzeichnisse eigene Volumes einrichten, so dass du jedem eigene Rechte/ Mountoptionen zuordnen kannst. (http://www.debian.org/doc/manuals/secur ... .html#s3.2)
Außerdem besteht Möglichkeit, Mirror-LVs anzulegen. Entspricht dann (Soft-) RAID-1 ohne md, dh. Daten sind immer 1:1 gleich in beiden LVs.
Bei Variante a hasst du dann aber ein Probelm: Du musst tasächlich jedes LV einzeln verschlüsseln und jedes mit einem eigenen Passwort entschlüsseln... LVM auf Crypt ist da einfacher und variabler: Die ganze Platte ist mit einer Passphrase ver-/ entschlüsselt und du kannst einfach und beliebig die LVM konfiguration ändern.

Frage am Rande zur Verschlüsselung: wenn ich das System so einrichte, dass ein keyfile eingelesen wird, z.B. von einem USB-Stick, kann ich dann trotzdem noch ein PW eingeben, wenn der Stick gerade nicht vorhanden ist?

Bei LUKS kannst du einer Verschlüsselten Partition acht Schlüssel zuordnen, das können Passphrasen oder Keyfiles sein. Dh. du hast immer (ist auch empfehlenswert) ein Fallback auf die Passphrase.

Hoffe geholfen zu haben,
MfG,
Martin

[dirk11]

Hi,

hatte ein wenig gehofft, dass Du auch antwortest

Jein ... gerade bei Swap bietet sich decrypt_derived an:
http://wiki.ubuntuusers.de/LUKS/Schl%C3%BCsselableitung
[...]
Das ist zwar vom Sicherheitsaspekt her nicht ganz so fein, sollte aber bei deinem erwarteten "Bedrohunsszenario" völlig ausreichen.

Die LVM-Lösung hat sich Debian einfallen lassen, um elegant um die Sache herumzukommen. Immerhin muss der Installer das alles "idiotensicher" einrichten können, da ist die Lösung mit LVM einfach "einfach".

Mal ehrlich, ist das mit LVM nicht insgesamt auch vorteilhafter, weil ich dann wirklich noch die Möglichkeit habe, mittels LVM meine /-Partition unter Zuhilfenahme einer neuen Platte zu vergrößern, ohne dass es ein neues device dafür gibt?
Mir scheint gerade die LVM-Lösung die einfachere zu sein, bisher war ich auch nur deshalb gegen LVM, weil ich die leise Befürchtung habe, das bei einem upgrade von Wheezy auf das nächste Stable eine Schicht mehr vorhanden ist, die Probleme bereiten kann. Ich bin wie man sieht immer noch im Findungsprozeß...

(ich denke, das war eh in deinem Sinne, möglichst wenige Partitionen).

Jipp. Ich sehe keinerlei Vorteile in mehreren Partitionen, bis dato ist auch noch nie ein Prozeß so explodiert, das er mir eine Platte bis zum bitteren Ende vollgeschrieben hätte. Und das wäre IMHO der einzige Vorteil einer Aufteilung.

cryptsetup luksOpen /dev/sdX1 target
Dann taucht unter /dev/mapper/target das entschlüsselte LVM auf.
Das kannst du mit "pvscan" und "lvscan" untersuchen, und dann mit lvchange -ay das gewünschte Volume aktivieren.
Das taucht dann auch unter /dev/mapper auf und kann von dort gemountet werden.

Ok. Und sowas wie cryptsetup und der LVM-Kram ist mittlerweile standardmäßig in jeder halbwegs brauchbaren Live-Distribution enthalten? Also grml, knoppix oder was es da sonst noch gibt.

a) MBR/GPT->md->LVM->Crypt->FS
b) MBR/GPT->md->Crypt->LVM->FS

Tja, blöd ... b) ist richtig
Bei a) würdest du jedes Logical Volume im LVM einzeln verschlüsseln, hättest also wieder das Problem mit mehreren Passwörtern.

Ok, das ist logisch. Also wäre die optimale Reihenfolge die von b) - wobei sich mir da bei näherem Hinsehen die Frage stellt, wie ich ein crypt über mehrere physikalische Devices mache, wenn ich z.B. eine Platte zur Vergrößerung eines LVM-Volume hinzufügen will. Oder geht das dann wieder nicht?
Beispiel: in einem Jahr gibt es billige 8TB-Platten, ich will mein 3TB-/ vergrößern, also kaufe ich zwei 8TB-Platte für ein zusätzliches RAID-1-md - und dann? Das LVM kann ich ja über mehrere physikalische Devices erstrecken, wenn ich das richtig verstanden habe, aber wie sieht es mit crypt aus?

Muss bzw. sollte ich bei der Einrichtung an irgendeiner Stelle des Installers von den defaultwerten abweichen? Nehme ich lieber den grafischen Installer, oder den Text-Installer in der extended-version?

Was du machen "musst" hängt davon ab, was du haben "willst".

Manchmal bieten Installer einem nur eine einfache oder Standardlösung als Vorschlag. Ich möchte Optimum. Beispiel aus dem WLAN-Bereich: aus Kompatibilätsgründen wird überall 802.11b/g/n voreingestellt. Ich habe aber kein b-Gerät mehr, also ist 802.11g/n zu bevorzugen. Oder es wird immer WPA+TKIP voreingestellt, WPA2+AES/CCMP ist aber sicherer.
An solche Hinweise hatte ich da gedacht.

- 16GB für SWAP (ich gehe momentan davon aus, dass ich die Kiste niemals im Leben auf mehr als 8GB RAM bringen werde, der frißt nur DDR2). Oder sollten es 17GB sein, um sicher zu gehen, das es nicht zu wenig ist für z.B. Suspend to Disk?

Die Rechnung geht so nicht auf ... wenn dein System 8 GB RAM und 16GB Swap nutzt, dann ist es erstens stinkend langsam und hat zweitens trotzdem keinen Platz mehr auf der Swap-Partition, um seine 8 GB RAM auszulagern. Wenn das System eh nie mehr als 8GB RAM haben soll, sollten 9GB Swap für den üblichen Gebrauch locker ausreichen. Nur wenn du doch noch eine Aufrüstung auf 16GB in Erwägung ziehst, dann machen die 17GB Sinn ... für die seltenen Fälle, in denen wirklich die 16GB RAM komplett ausgenutzt werden.

Neinneinnein, das stammt auch noch aus Vorüberlegungen. Wenn ich swap im LVM habe, kann ich das ja quasi dynamisch anpassen, oder? Bei der Plattenpartitionierung ginge das ja nicht mehr.
Und die avisierte Größe stammt aus folgenden Gedanken:
der neue Server hat momentan 3GB RAM. Ich nutze seit ca. 13 Jahren Linux, ich glaube seit 10 Jahren habe ich kein einziges System mehr swappen sehen, selbst mein aktueller Server mit 768MB RAM hat noch nie geswappt. Aber es hieß früher mal swap=2xRAM. Der neue Server hat vier DDR2-Steckplätze. Gesetzt den Fall, er kann das und ich käme mal durch irgendwelche Umstände an 2GB-Riegel, dann könnte ich maximal 8GB RAM einbauen. 2x=swap, also swap 16GB, und auch das eigentlich leicht mehr, damit ich auch Suspend to Disk machen kann und mir nicht plötzlich 20MB fehlen. Ich gehe nicht davon aus, dass das System jemals auslagert. So entstand (unter dem Grundgedanken, dass ich die Partitionsgröße des swap nachträglich nicht mehr ändern kann) die Größe.

Das halte ich für eine ganz schlechte Idee, in die /boot/-Partition noch ein System hineinzuinstallieren. Dann lass lieber eine extra 13GB-Partition frei für die Installation eines Rettungs-Systems.

So war das auch nicht gemeint. Es ging darum, die Partition aus irgendwelchen Gründen anstatt als /boot komplett als / zu verwenden, nicht "und". Von dem Rettungs-System auf Platte bin ich eigentlich wieder weg, weil ich denke, wenn ein Livesystem auf einem Stick crypt und LVM kann, dann sollte das als Rettungs/Wartungssystem locker ausreichend sein.

[dirk11]

Ist kein Problem, GRML Bespielsweise hat die Pakete cryptsetup und lvm2 von Haus aus mit drin, mehr brauchst du dafür nicht. Du kannst dir aber auch eine "Maintenance"-Partition erstellen; Eine kleine Nur-Konsolen-Installation mit Scripten für Backup, Fs-Check usw...

Von einer Maintenance-Partition will ich ja eigentlich eher weg, weil die von Platte gebootet langsamer ist als vom Stick.

Es ist aber auch möglich der Swap-Partition einen zufälligen Schlüssel zu verpassen. Der wird dann bei jedem Mounten neu erzeugt.

Das wäre natürlich noch geiler! Geht das mit dem Installer denn? Wie muss ich vorgehen, um das zu erreichen?

Bei Verwendung von LV's kannst Du für verschiedene Verzeichnisse eigene Volumes einrichten, so dass du jedem eigene Rechte/ Mountoptionen zuordnen kannst.

Hab ich noch nie vermisst.

Außerdem besteht Möglichkeit, Mirror-LVs anzulegen. Entspricht dann (Soft-) RAID-1 ohne md, dh. Daten sind immer 1:1 gleich in beiden LVs.

Macht keinen Sinn, wenn alles auf einer Platte liegt.

LVM auf Crypt ist da einfacher und variabler: Die ganze Platte ist mit einer Passphrase ver-/ entschlüsselt und du kannst einfach und beliebig die LVM konfiguration ändern.

Und wenn ich wg. LVM crypt über mehrere physikalische Platten brauche? Geht das auch?

Bei LUKS kannst du einer Verschlüsselten Partition acht Schlüssel zuordnen, das können Passphrasen oder Keyfiles sein. Dh. du hast immer (ist auch empfehlenswert) ein Fallback auf die Passphrase.

Die Frage ist, ob man das so einrichten kann, das erst nach einem File geschaut wird, und wenn das nicht vorhanden ist, wird auf die Eingabe der Passphrase gewartet.