Linux Vollverschlüsselung - einfachster Weg?

Dafür müsste ein potentieller Angreifer Benutzername und Kennwort kennen. Logins kann man beispielsweise mit dem Google Authenticator PAM Plugin/Modul auch bei lokalen Anmeldungen einrichten.
 
Oder einen Weg finden anders ins System zu kommen. Aber genau darum geht es ja, dass ein potentieller Angreifer, wenn(!) er ins System kommt trotzdem nichts mit den Daten anfangen kann. Und das geht halt nur, solange der Container zu ist. Jetzt über die möglichen Einfallstore bei den nicht näher benannten Diensten zu spekulieren bringt uns da allerdings nicht weiter.
Wenn sowieso keiner das System infiltrieren kann, brauche ich ja auch nichts verschlüsseln ;)
 
snaxilian schrieb:
Vollzitat entfernt.
Hi,

also wenn jemand schon so eine Angst hat, dann kann er rein theoretisch ja auch dem Hoster nicht trauen und müsste sich sein eigenes Rechenzentrum aufbauen. Der Hoster könnte ja beliebigen Aufwand fahren.

Aber wozu? Wenn sich beide also Hoster und Kunde an Recht und Ordnung halten gibt es diesen Grund nicht. Da fragt man sich doch glatt, was der TO da nun für Daten hat.
 
Zuletzt bearbeitet von einem Moderator:
Sommersocke schrieb:
genau darum geht es ja
Nein, es gibt nicht den allumfassenden aus jeder Richtung kommenden bösen Angreifer. Man muss Bedrohungen/Bedrohungsszenarien konkret benennen denn je nach Situation sind andere Maßnahmen zum Schutz notwendig. Ebenso sollte man die Eintrittswahrscheinlichkeit abwägen und kann sich je nach Aufwand dann dazu entschließen das Risiko zu akzeptieren oder eben nicht.
fischfilet schrieb:
Der Hoster könnte ja beliebigen Aufwand fahren.

Aber wozu? Wenn sich beide also Hoster und Kunde an Recht und Ordnung halten gibt es diesen Grund nicht.
Vertrauen ist gut, Kontrolle ist besser.

Selbst wenn sich das Unternehmen im Allgemeinen daran hält, gibt es einen gelangweilten und neugierigen Admin hat man ein Problem oder um es mit einem Sprichwort zu sagen: "Gelegenheit macht Diebe."

Es geht den Hoster und dessen Mitarbeiter schlicht nichts an was ich in einem vServer dort hoste. FDE + TRESOR ist eine guter Kompromiss um solche Gelegenheiten zu unterbinden. Ebenso sind die Backups meiner privaten Bilder in $Cloud ebenso verschlüsselt. Misstraue ich dem Anbieter deshalb? Nein aber im Worstcase gibt's ein Datenleck und ich möchte trotzdem, dass meine privaten Daten privat bleiben ohne dass ich mir in Übersee eine handvoll Server hinstellen muss damit ich gewisse Redundanzen habe und die Daten per S3 API sichern kann.

Klar könnte man auch eigenes Blech kaufen und per Colocation/Housing in ein RZ stellen lassen. An die Front kommt eine Blende mit Schloss und die 'Chassis Intrusion', die Server oft haben, wird mit der Stromversorgung verbunden. Wenn Server physikalisch geöffnet wird -> Poweroff. Bedrohung: Evil Maid Attack. Hilft das gegen ein abschnorcheln der Daten oder "Hack" des laufenden Systems? Nein, denn das ist schließlich eine andere Bedrohung, da müssen entsprechend andere Maßnahmen ergriffen werden.
fischfilet schrieb:
Da fragt man sich doch glatt, was der TO da nun für Daten hat.
Auch hier gilt wieder Abwägung der Wahrscheinlichkeiten. Hat man da ein paar Warez o.ä. und die Bedrohung ist die Staatsanwaltschaft als Handlanger der Contentindustrie reicht vermutlich schon die reine FDE weil sich ggf. niemand den Aufwand mit Memory-Dump etc. machen wird.
Hat man gerade die Seeds von RSA abgeschnorchelt oder irgendwelche Staatsgeheimnisse ist die Bedrohung eine ganz andere und erfordert andere Schutzmaßnahmen.
 
  • Gefällt mir
Reaktionen: fischfilet
Hi,

ja du hast Recht, aber dann muss man sich überlegen ob man nicht besser selfhosting betreibt.
Vollverschlüsselung eines Linux-Servers ist ja schon komisch, da müssen Verrenkungen her um per SSH beim Booten das dmcrypt Passwort einzutippen. Wenn man dann nur verschlüsselte Datencontainer hat, die man nach jedem reboot manuell per Passwort mounten muss bringt das ja auch nichts, ein rogue admin im RZ könnte das OS kompromittieren und dann an das Passwort kommen.

Es bleibt eigentlich wie immer, wer physischen Zugriff auf die Kiste hat, kann jede Sicherheit aushebeln.
 
fischfilet schrieb:
ja [...] aber [...]
Ja aber ist so eine Worthülse, da kann man auch direkt und einfach 'nein' schreiben...
fischfilet schrieb:
dann muss man sich überlegen ob man nicht besser selfhosting betreibt.
Welchen Teil von "erst Bedrohungszenario vor dem man sich schützen will und dann Maßnahmen abwägen und umsetzen" hast du nicht gelesen? Es gibt genug Situationen wo FDE sinnvoll ist und man trotzdem Hostingdienste Dritter in Anspruch nehmen kann.
Betreibe ich beispielsweise einen kleinen Webshop wo meine Kunden sich ein Kundenkonto anlegen können oder ggf. müssen, dann speichere und verarbeite ich als Betreiber des Webshops personenbezogene Daten. Diese habe ich zu schützen und Verschlüsselung ist eine gute Möglichkeit dazu. Encrypted Database ist möglich aber der key zum öffnen und lesen steht idR ja in Configdateien des Webshops. Da ist es einfacher wenn Webshop und Datenbank auf einem Server mit FDE liegen.
Datenreichtum oder gelangweilter rogue admin ist damit aufgehalten. Besteht ein Restrisiko gegen gezielte Attacken? Ja. Wie wahrscheinlich ist es, dass dies eintritt? Sehr überschaubar.
fischfilet schrieb:
Vollverschlüsselung eines Linux-Servers
Gegenfrage: FDE mit Bitlocker oder Veracrypt für eine Windows-VM braucht genauso eine Eingabe der Credentials wenn die Bedrohung "evil maid/rogue admin" ist. Ist es wahrscheinlicher, dass dieser sich ein Image der vDisk macht und es in Ruhe zuhause lesen will? Ohne RAM-Dump nutzlos und Schutz dagegen siehe oben. Wird der deshalb einen riesen Aufwand betreiben um irgendwie im laufenden Betrieb an die Daten im Register der CPU zu kommen? Eher weniger oder es wäre deutlich auffälliger.
fischfilet schrieb:
wer physischen Zugriff auf die Kiste hat, kann jede Sicherheit aushebeln.
Auch dies gilt nicht pauschal. Wenn ich dir einen ausgeschalteten PC mit FDE in die Hand gebe, dann brauchst du schon enorm viel Zeit und Geld um dies auszuhebeln, vorausgesetzt ich habe eine entsprechend lange Passphrase und keine Ciphers verwendet, die als schwach gelten und die Implementierung der FDE ist technisch korrekt umgesetzt.
Mit unendlich viel Zeit und technischem sowie personellem Aufwand kann man jede beliebige Sicherheitsmaßnahme aushebeln aber darum geht es ja auch nicht. Will ich wirklich Zugriff haben, brauche ich nicht einmal physischen Zugriff auf den Server sondern mache dies: https://xkcd.com/538/

Es baut sich ja auch niemand einen 10 Meter hohen Zaun mit Nato-Draht um sein Haus und Zutritt nur durch eine Sicherheitsschleuse, Fenster müssen schusssicher sein, usw. um ein paar wichtige Dokumente zu sichern oder den durchschnittlichen Einbrecher aufzuhalten.
Überlegung der Bedrohungsszenarien und daraus ergeben sich die Schutzmaßnahmen, die technischer und/oder organisatorischer Natur sein können. Bankschließfach wäre da eine Option bzw. Fenster, Türen und Schlösser entsprechender Widerstandsklassen.
Natürlich könnte man jetzt schreiben: "ja du hast Recht, aber dann muss man sich schon überlegen ob man nicht besser selbst ein tiefes Loch im Keller buddelt und einen Safe da einbaut weil so ein Bankschließfach also da könnte ja schon ein Einbrecher ankommen und alles mit einer Flex aufbrechen und überhaupt."
Ist das denn noch verhältnismäßig vom Aufwand ggü. dem Nutzen und den Anforderungen? Eher nicht mehr...
Gleiches gilt für selfhosting. Da wäre der Aufwand für Redundanzen der Hardware, Admins inkl. Bereitschaft oder man muss sich selbst um alles kümmern, Stromversorgung inkl. Redundanz, USV und ggf. Notstromaggregate, Internetanbindung der Systeme, usw.
Ist das dann noch verhältnismäßig?

Ohne konkrete Benennung wovor man sich schützen will sind solche Diskussionen halt sinnfrei.
 
snaxilian schrieb:
Ja aber ist so eine Worthülse, da kann man auch direkt und einfach 'nein' schreiben...

Welchen Teil von "erst Bedrohungszenario vor dem man sich schützen will und dann Maßnahmen abwägen und umsetzen" hast du nicht gelesen?

Wie musst du mir jetzt eigentlich so ans Bein pinkeln? Gehts noch?


snaxilian schrieb:
Auch dies gilt nicht pauschal. Wenn ich dir einen ausgeschalteten PC mit FDE in die Hand gebe, dann brauchst du schon enorm viel Zeit und Geld um dies auszuhebeln

An die Daten eines vollverschlüsselten ausgeschalteten Rechners, in dem die Platten per dmcrypt gesichert sind kommst du auch nicht ran. Was soll das also bitte mit FDE?


Mit dem 5$ Schraubenschlüssel kannst du alles rechtfertigen oder schlechtreden.

snaxilian schrieb:
Ohne konkrete Benennung wovor man sich schützen will sind solche Diskussionen halt sinnfrei.

Eben. Dann definiere doch wie schon erwähnt für dich deine Sicherheitsstufe ohne anderen ans Bein zu pinkeln. Und wer seinem Hoster nicht vertraut hat da schon nach seiner Argumentation einen Fehler.
Vertraust du denn den Hardwareherstellern? Nicht dass Intel oder AMD mit ihren MEs deine Backdoors sind und all deine Versuche für die Katz sind.
 
nocie schrieb:
Ich möchte aber auch bei Linux ganz einfach mein System verschlüsselt haben, sodass wenn ich mein Server neustarte, direkt das Passwort zum entschlüsseln eingeben kann, woraufhin dann das System mit allen Services gestartet wird.


Man muss vorher die Daten sichern. Die PE erstellen, dann LV, dann VG, siehe lvm2. Darin setzt man einen luks container in welchen dann ext4 sitzt. kopiert werden die daten mittels cp -avr. ich sehe es als gegeben an welches man ein initramfs erstellen bzw. raubkopieren kann vom netz. ich sehe es auch als gegeben an welches man einen kernel kompilieren kann und weis was man dort tut. Ich sehe es auch als gegeben an weches man einen bootloader konfigurieren kann. falls nein sollte man sich das wissen sich anlesen bzw. das mit der verschlüsselung sein lassen. die ausdauer sollte man auch mitbringen um so etwas umzusetzen. Aufgrund der Fragestellung sehe ich es als gegeben an welches eine teilverschlüsselung gewünscht ist, d.h. die sektoren für das laden des initramfs liegen unverschluesselt am physischen datenträger. Grundlegende Kenntnisse wie bootet ein gnu linux, usw. kann man nachlesen und werde ich hier nicht erläutern.

Die commands habe ich mir sauber ueber die Jahre zusammengeschrieben sind circa 10 Stueck, mit texterklärung sind es 4 A4 Seiten, aber diese will ich nicht kostenlos veröffentlichen. Es ist dann Egal ob man dann die Festplatten wechselt oder von unverschluesselten gnu linux auf verschluesseltes Gnu linux wechselt. die festplatten sind bootfaehig, man wird nach einem passwort gefragt und das system ist ansonsten nicht zu unterscheiden wie vorher. Ich führe diese Prozedur 1x im Monat laut meiner selbst erstellten Anleitung durch via CLI.

edit: kleiner hinweis: https://wiki.gentoo.org/wiki/Full_Disk_Encryption_From_Scratch_Simplified
edit: es hat einen sinn warum ich die pe sichbar haben will und nicht im luks container, ist anders als im link oben. der wechsel auf verschluesselung ist keine kunst eher mehr eine geduldsfrage und ob man lust hat sinnerfassend quellcode und manpages zu lesen
 
Zuletzt bearbeitet:
_roman_ schrieb:
Die PE erstellen, dann LV, dann VG, siehe lvm2.
Nope. Erst PE, dann VG, dann LV.

_roman_ schrieb:
es hat einen sinn warum ich die pe sichbar haben will und nicht im luks container
Vermutlich wirst den auch nicht kostenlos verraten?

Na ein Glück, das es schon mehr als eine vollständige und erklärende Anleitung zu dem Thema gibt, da muss man dich nicht mit Geld bewerfen. :)
 
  • Gefällt mir
Reaktionen: sedot, Garmor und cloudman
Zurück
Oben