joka
Anmeldungsdatum: 8. Dezember 2007
Beiträge: 21
|
DasIch hat geschrieben: Auf einem bootbaren USB Stick kann man selbstverständlich /boot auslagern, das Problem ist was ist wenn du den verlierst? Am besten hat man einen zweiten und dann fängts schon an mit der Frage wo man den versteckt...
Den Verlust des USB-Sticks sehe ich nicht als Problem, vorausgesetzt man hat ein Backup der /boot-Partition auf der verschlüsselten Root-Partition hinterlegt. In diesem Unterforum gibt es ja einige Threads, in denen erklärt wird, wie man mit Hilfe einer Live-CD wieder an die verschlüsselte Root-Partition ran kommt. Nur das LUKS-Passwort darf man nicht vergessen.
|
hakaishi
Anmeldungsdatum: 28. April 2008
Beiträge: 525
Wohnort: Yokkaichi(Japan)
|
Hi zusammen, also, wenn ich das recht verstehe, dann will man die Daten vor dem Internetzugriff und "Passwort-mitspeicherung" schützen, ja? Mit z.B. TrueCrypt könnte man die Daten schützen, aber das Passwort kann über die Tastatureingabe "geklaut" werden, richtig? Man müsste es also irgendwie schaffen das OS gleichzeitig vor einem fremd Zugriff zu schützen, während man im Internet surft;
>Man könnte die Daten auf einer zweiten Festplatte speichern, die man nur anschließt bzw. anschaltet, wenn das Internet aus ist. (Natürlich ist das nervig, wenn man die Daten gerade auf dieser Festplatte speichern will.)
Meine Frage: Schützt ein, nehmen wir an, "vollkommen" sicheres LUKS-System vor dem Zugriff aus dem Internet, beim Surfen?
Wenn ich versuche es bildlich zu sehen, wäre das perfekte System ein Fenster: Das Licht (=Internet) fällt durch (=greift auf eine Patition oder Ordner zu), während der Fensterrahmen (=das OS) unveränderlich ist.
Die Vorstellung klingt gut, denke ich, aber wie umsetzen.
PS: Ich arbeite erst seit einiger Zeit mit Linux (seid nicht zu streng mit mir \^^ )
Grüße Hakaishi
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
Es geht um den physischen Schutz (oder eben auch nicht), wenn sich jemand ganz real an dem Rechner zu schaffen macht. Mit Schutz vor Angriffen aus einem WAN (Internet) hat das nichts zu tun.
|
hakaishi
Anmeldungsdatum: 28. April 2008
Beiträge: 525
Wohnort: Yokkaichi(Japan)
|
Gut, ein fremder hockt vor meinem PC, und will an meine Daten. Da /boot die einzige unverschlüsselte Patition ist und die, nehmen wir an, auf einem USB-Stick ist (der nicht steckt), ist es doch unmöglich das Passwort zu "klauen", ist somit also unantastbar, da nichts gelesen oder geschrieben werden kann.
>Bleibt also nur die Gefahr aus dem Internet -.-
Eine konkrete Idee?
|
Blattlaus
Anmeldungsdatum: 29. März 2006
Beiträge: 1399
|
hakaishi hat geschrieben: Meine Frage: Schützt ein, nehmen wir an, "vollkommen" sicheres LUKS-System vor dem Zugriff aus dem Internet, beim Surfen?
Natürlich nicht, warum sollte es auch?!? Solange die Daten entschlüsselt eingehängt sind, können sie selbstverständlich gelesen und verändert werden. Davor kann dich keine Software schützen.
|
xabbuh
Anmeldungsdatum: 25. Mai 2006
Beiträge: 6411
|
hakaishi hat geschrieben: >Bleibt also nur die Gefahr aus dem Internet -.-
Gleichzeitig bleibt selbstverständlich auch die Gefahr, dass ein Angreifer mit physikalischem Zugriff, die Hardware deines Rechners manipuliert, um beispielsweise einen Keylogger zu installieren und so die Passphrase abzufangen.
|
BNDBernd
Anmeldungsdatum: 28. April 2008
Beiträge: 7
|
Idee zur Integritätsprüfung von /boot: Auf der verschlüsselten Partition liegt der sha1 von /boot. Beim Booten / Mounten (der verschlüsselten Partition) soll das erste Startscript sha1(/boot) machen und mit dem auf der verschlüsselten und gemounteten Partiion abgelegten sha1-Wert vergleichen. Manipulation wäre dann ja schwer, denn dazu müßte man den Hash, welcher auf der verschlüsselten Partition liegt, wissen. Zur Vermeidung des Szenarios, dass der Angreifer den Hash von Boot selbst errechnet und dann per brute force versucht, ebenso den gleichen Hash für das manipulierte neue /boot zu erzeugen, empfielt es sich, den eigentlichen Hash mit einem Geheimnis zu initialisieren, also z.B.: SHA1 von ("dlfbm.,6sdf0sg4f9hfgh2kdi" + Inhalt von /boot).
|
teddy19
Anmeldungsdatum: 27. Februar 2008
Beiträge: Zähle...
|
Bevor sich jemand die Mühe macht die Checksumme von einem manipulierten /boot so anzupassen, dass sie der Alten entspricht würde er wohl eher den Besitzer entführen und so lange foltern oder sonstwas tun bis dieser das Passwort rausrückt. Und das machen Menschen numal ab einer bestimmten Grenze;-) Aber mal ehrlich, selbst wenn man /boot auf einem Stick hat, während du schläfst hast du deine Hose nicht an oder?!->Manipulationsgefahr! Wenn man sich einigermaßen gegen Keylogger gesichert hat (ich denke an Siegel, Wachsverschläge mit Haaren oder Fingerabdrücken ▶ alles was man halt so aus Filmen kennt) ist es billiger ein neues Guantanamo zu bauen und das Passwort aus dir rauszuquetschen als einen Techniker anzustellen, der sich monatelang damit beschäftigt dein System zu knacken! Wer Angst vor der Polizei hat: Ein verschlüsseltes System ist absolut sicher Wer Angst vor dem BND hat: Benutz Linux, technisches Wissen scheint dort ja nicht sehr weit verbreitet zu sein\^^ Wer Angst vor Wirtschaftsspionage hat: Vergisses, bring dich um oder Lebe mit dem Risiko entführt zu werden! Wer den ein oder anderen illegalen Aktivitäten im Netz nachgeht aber keine Feinde bei der Mafia hat, für den ist es genug zu Verschlüsseln und ggf. /boot auf einen Stick zu tun! Alles andere ist praktisch gesehen Bullshit, theoretisch natürlich ein schönes Gedankenexperiment voller schöner Überraschungen!☺ Temporäre Ironie ist in diesem Beitrag nicht auszuschließen!
|
Blattlaus
Anmeldungsdatum: 29. März 2006
Beiträge: 1399
|
BNDBernd hat geschrieben: Idee zur Integritätsprüfung von /boot: Auf der verschlüsselten Partition liegt der sha1 von /boot. Beim Booten / Mounten (der verschlüsselten Partition) soll das erste Startscript sha1(/boot) machen und mit dem auf der verschlüsselten und gemounteten Partiion abgelegten sha1-Wert vergleichen. Manipulation wäre dann ja schwer, denn dazu müßte man den Hash, welcher auf der verschlüsselten Partition liegt, wissen. Zur Vermeidung des Szenarios, dass der Angreifer den Hash von Boot selbst errechnet und dann per brute force versucht, ebenso den gleichen Hash für das manipulierte neue /boot zu erzeugen, empfielt es sich, den eigentlichen Hash mit einem Geheimnis zu initialisieren, also z.B.: SHA1 von ("dlfbm.,6sdf0sg4f9hfgh2kdi" + Inhalt von /boot).
Das ist nicht sicher: Wenn ich die Möglichkeit habe den Kernel zu verändern, dann kann ich ihn auch so verändern, dass er dem Programm das die Prüfsumme verifiziert immer ein unverändertes /root vorgaukelt. Du musst den Kernel verifizieren bevor du ihn benutzt, sonst kannst du keine Chain of Trust bilden. Man kann sich ja auch nicht selbst an den Haaren aus dem Sumpf ziehen.
|
TutEnchAnon
Anmeldungsdatum: 19. Mai 2008
Beiträge: Zähle...
|
Also bleibt für Privatanwender wohl nur die Auslagerung von /boot auf einen USB Stick? Gerade ältere Bios Versionen unterstützen kein Booten von USB. Ist denn prinzipiell auch ein Iomega Zip Drive 100 als Boot Device denkbar?
|
Mike1
Anmeldungsdatum: 2. Januar 2008
Beiträge: 2092
Wohnort: Niederösterreich
|
TutEnchAnon hat geschrieben: Also bleibt für Privatanwender wohl nur die Auslagerung von /boot auf einen USB Stick? Gerade ältere Bios Versionen unterstützen kein Booten von USB. Ist denn prinzipiell auch ein Iomega Zip Drive 100 als Boot Device denkbar?
mein selbst konfigurierter Kernel würde beinahe auf eine normale 1,44MB Diskette passen. Disketten wären, abgesehen von der schlechten Geschwindigkeit überhaupt eine gute Möglichkeit für so ein "ausgelagertes" /boot, schliesslich kann man auch leicht mehrere solche /boot-Disketten anfertigen und z.b- an Personen die das System ebenfalls benutzen müssen weitergeben, oder z.b. im Tresor als Sicherheitskopie einsperren usw. Das Vergleichen von Kernel-Prüfsummen dürfte doch aber auch schon einigermaßen Sicherheit bieten, denn so einfach dürfte es nicht sein, dass mit einem manipulierten Kernel auszuhebeln... (vorallem weil der Angreifer ja nicht wissen kann was alles überprüft wird...)
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
Mike1 hat geschrieben: Das Vergleichen von Kernel-Prüfsummen dürfte doch aber auch schon einigermaßen Sicherheit bieten, denn so einfach dürfte es nicht sein, dass mit einem manipulierten Kernel auszuhebeln... (vorallem weil der Angreifer ja nicht wissen kann was alles überprüft wird...)
Wieso sollte das schwer sein? Wenn die Prüfsumme innerhalb des Kernels verglichen wird, ist die Manipulation denkbar einfach, der Angreifer kommentiert im günstigsten Fall einfach nur eine If-Abfrage aus und übersetzt den Code neu. Theoretisch lässt sich das sogar ohne Neukompilierung erledigen, in dem man den Kernel disassembliert, die entsprechenden Instruktionen durch NOOPs ersetzt und den Kernel wieder assembliert. Wird die Überprüfung innerhalb einer Software vorgenommen, wird die Sache schwieriger, weil der Kernel den Ablauf eines Programms nicht ohne aufwändige Analyse des Assemblercodes ändern kann. Allerdings kontrolliert der Kernel in den syscalls _sämtliche_ Daten, die das Programm sieht. Ein entsprechendes Rootkit würde dafür sorgen, dass der Prozess, der die Checksummen verifiziert, beim Lesen der Daten aus /boot über die syscalls "open" und "read" genau solche Daten liest, die eine bekannte Checksumme ergeben. Ferner würde der Kernel dafür sorgen, dass das Programm genau diese Checksumme auch aus "/boot_checksum" liest. Der Vergleich müsste dann gar nicht mehr manipuliert werden, da die hinein gereichten Daten ausreichend manipuliert sind. Die einzige Schwierigkeit wäre, herauszufinden, aus welcher Datei die Prüfsumme gelesen wird und welche Dateien in /boot in die Berechung der Prüfsumme miteinbezogen werden. Die denkbare Individualität der verschiedenen Lösung erschwert zwar einen automatisierten Angriff auf viele Systeme, ein einzelnes System allerdings lässt sich zur Genüge analysieren, so dass auch diese scheinbare "Security by obscurity" keine echte Sicherheit bringt. Man kann es drehen und wenden, wie man möchte: Allein aus Software lässt sich keine sichere Chain-Of-Trust bauen, es braucht zwingend ein Stück vertrauenswürdiger Hardware, welches die initiale Überprüfung vornimmt. Als Beispiel für die nahezu perfekte Umsetzung einer solchen Chain-Of-Trust dient die XBox 360, die sogar dem eigenen Mainboard nicht vertraut, weil die meisten Datenbusse abgehört werden können, wenn man die Hardware nur weit genug zerlegt.
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
Mike1 hat geschrieben: Das Vergleichen von Kernel-Prüfsummen dürfte doch aber auch schon einigermaßen Sicherheit bieten, denn so einfach dürfte es nicht sein, dass mit einem manipulierten Kernel auszuhebeln... (vorallem weil der Angreifer ja nicht wissen kann was alles überprüft wird...)
Doch, das ist sehr einfach, und in diversen Rootkits der Vergangenheit bereits mehrfach implementiert. Der Trick ist einfach, die Originaldatei irgendwo versteckt zu speichern, (z.B. in ein paar als defekt markierten Blöcken der Festplatte,) und immer dann, wenn der trojanisierte Kernel eine Leseanforderung für diese Datei erhält, besorgt er sich das Original. Man muss also die Prüfsumme gar nicht wissen, um das Prüfprogramm zu überlisten. Aber wo es um USB-Sticks und um ältere Geräte, die nicht von USB sondern nur von Diskette booten können, ging, fiel mir noch etwas ein. Man könnte den Kernel in /boot ganz normal unverschlüsselt auf der Platte lassen, aber sich eine abgespeckte Linux-Version auf einem beliebigen bootbaren Medium erstellen, die bloß einen Minimal-Kernel, die allernötigsten Tools, und eine Prüfsoftware wie AIDE oder Tripwire (oder ein paar selbstgestrickte Skripte) enthält. Jedesmal, wenn man den Rechner aus den Augen gelassen hatte, bootet man erstmal von diesem Medium und überprüft /boot. Und wenn man das Teil verliert, ist auch nicht so schlimm, denn das System bootet immer noch. Die Prüfsummen könnte man sich ja sogar ausdrucken und bei jedem Boot vom Prüfmedium mit eigenen Augen vergleichen. Gegen Hardware-Keylogger hilft das natürlich trotzdem nicht.
|
klein-ich
Anmeldungsdatum: 15. März 2006
Beiträge: 37
|
könnte man nicht über ein read only medium sicherstellen das der unverschlüsselte teil nicht manipuliert wird also ich lege meine cd ein von der wird gebootet alle daten werden auf die /boot partition kopiert und davon wird dann gestartet? wenn man jetzt sicher stellt das die daten auch wirklich von der cd kamen und es eine nicht manipulierte cd ist, kann ein angreifer doch eigentlich nur noch mit hardwarekeylogger oder ähnlichem arbeiten
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
klein-ich hat geschrieben: könnte man nicht über ein read only medium sicherstellen das der unverschlüsselte teil nicht manipuliert wird also ich lege meine cd ein von der wird gebootet alle daten werden auf die /boot partition kopiert und davon wird dann gestartet? wenn man jetzt sicher stellt das die daten auch wirklich von der cd kamen und es eine nicht manipulierte cd ist,
Klar. Aber ein USB-Stick ist bedeutend einfacher mit sich herum zu schleppen, als eine CD, und wenn du die deswegen neben dem Rechner liegen lässt, könnte sie ja wiederum ausgetauscht werden. 😉
|