ubuntuusers.de

martingr schrieb:

daniel.L schrieb:

Achja: Dattenrettungsunternehmen können natürlich auch verschlüsselte Daten retten - nur eben verschlüsselt. Technisch gibts da meines Wissens keinen Unterschied zur normalen Datenrettung - die Retter können nur eben nicht sagen, was genau sie da retten.

Stimmt nicht ganz: ist der Datenblock physikalisch zerstört an dem die Layout Informationen stehen ist alles andere nur noch binärer Müll.

Ist damit der Header des Containers gemeint? Davon bin ich bisher ausgegangen und habe daher auch ein Backup davon. Wenn nicht, bin ich jetzt schlauer und belehrt 😉

@Chrissss: Soweit ich weiß, wird bei zB Truecrypt und dm-crypt sektorweise verschlüsselt. Von umgekippten Bits ist somit nur der jeweilige Sektor betroffen und für die verlorenen Daten hat man dann ja seine Backups. Bei Zip-Archiven etc werden die Daten als ganzes verschlüsselt, weshalb sich ein umgekipptes Bit dort auch so fatal auswirkt.

daniel.L schrieb:

martingr schrieb:

daniel.L schrieb:

Achja: Dattenrettungsunternehmen können natürlich auch verschlüsselte Daten retten - nur eben verschlüsselt. Technisch gibts da meines Wissens keinen Unterschied zur normalen Datenrettung - die Retter können nur eben nicht sagen, was genau sie da retten.

Stimmt nicht ganz: ist der Datenblock physikalisch zerstört an dem die Layout Informationen stehen ist alles andere nur noch binärer Müll.

Ist damit der Header des Containers gemeint? Davon bin ich bisher ausgegangen und habe daher auch ein Backup davon. Wenn nicht, bin ich jetzt schlauer und belehrt 😉

ja den meinte ich.

@Chrissss: Soweit ich weiß, wird bei zB Truecrypt und dm-crypt sektorweise verschlüsselt. Von umgekippten Bits ist somit nur der jeweilige Sektor betroffen und für die verlorenen Daten hat man dann ja seine Backups. Bei Zip-Archiven etc werden die Daten als ganzes verschlüsselt, weshalb sich ein umgekipptes Bit dort auch so fatal auswirkt.

kann aber auch schon problematisch sein. Angenommen deine Festplatte ist so beschädigt, dass du ungefahr 1-5 gekippte Bits in jedem Sektor hast, dann ist die komplette Platte hinüber. Bei einer unverschlüsselten, fallen davon dann ca 60-70 % in unbenutzte Bereiche und die Daten sind noch korrekt, oder lassen sich über einfache Korrekturmaßnahmen wiederherstellen.

martingr schrieb:

daniel.L schrieb:

martingr schrieb:

daniel.L schrieb:

Achja: Dattenrettungsunternehmen können natürlich auch verschlüsselte Daten retten - nur eben verschlüsselt. Technisch gibts da meines Wissens keinen Unterschied zur normalen Datenrettung - die Retter können nur eben nicht sagen, was genau sie da retten.

Stimmt nicht ganz: ist der Datenblock physikalisch zerstört an dem die Layout Informationen stehen ist alles andere nur noch binärer Müll.

Ist damit der Header des Containers gemeint? Davon bin ich bisher ausgegangen und habe daher auch ein Backup davon. Wenn nicht, bin ich jetzt schlauer und belehrt 😉

ja den meinte ich.

Okay, dann ist ja gut.

@Chrissss: Soweit ich weiß, wird bei zB Truecrypt und dm-crypt sektorweise verschlüsselt. Von umgekippten Bits ist somit nur der jeweilige Sektor betroffen und für die verlorenen Daten hat man dann ja seine Backups. Bei Zip-Archiven etc werden die Daten als ganzes verschlüsselt, weshalb sich ein umgekipptes Bit dort auch so fatal auswirkt.

kann aber auch schon problematisch sein. Angenommen deine Festplatte ist so beschädigt, dass du ungefahr 1-5 gekippte Bits in jedem Sektor hast, dann ist die komplette Platte hinüber. Bei einer unverschlüsselten, fallen davon dann ca 60-70 % in unbenutzte Bereiche und die Daten sind noch korrekt, oder lassen sich über einfache Korrekturmaßnahmen wiederherstellen.

Gut, in solch einem Fall hat man dann Pech gehabt. Daher gehört zu einer guten Backup-Strategie ja auch das mehrfache Vorhalten eines Backups (optimalerweise an unterschiedlichen Orten zur Verminderung der Wahrscheinlichkeit physischer Schäden an allen Backups).

Hallo,

zum Ursprung zurück: Im Rahmen und Kontext des Artikels halt ich den Satz für ausreichend. Es geht ja darum, "seinen" Rechner zu schützen, falls ein Dritter unerlaubt davor sitzt.

Rechner-Klau und Co. ist ein Thema für sich.

Gruß, noisefloor

Hab einen Artikel zu einem ähnlichem Thema erstellt, wobei mir der Artikel zunächst ähnlich erschien, die Diskussion aber doch ineine deutlich andere Richtung zu gehen scheint.

Kann ich den Artkle trotzdem verlinken? Baustelle/Zugriff auf PC einschränken

Grüße, Nils

nilleholger schrieb:

Kann ich den Artkle trotzdem verlinken? Baustelle/Zugriff auf PC einschränken

Ich denke schon. Allerdings erst, wenn der Artikel aus der Baustelle ist. ☺

Gruß
kaputtnik

Moin,

ich lese da gerade im 2. Absatz folgenden Text:

Besitzen Benutzer des Systems physikalischen Zugang zum Computer, können sie z.B. den Rechner mit einer Live-CD oder einer Boot-Diskette starten oder sogar die Festplatten ausbauen. So kann man jederzeit an die Daten des Rechners gelangen und kein Betriebssystem der Welt kann vor solchen Manipulationen schützen.

was ist, wenn man seine Daten verschlüsselt also verschlüsseltes /home/BENUTZER hat? da können sie mir doch die Platte mopsen, oder mit ner Live-CD oder LiveUSB Booten. Ein dran kommen an diese Daten ist doch dann trotzdem nicht möglich, oder?

Besitzen Benutzer des Systems physikalischen Zugang zum Computer, können sie z.B. den Rechner mit einer Live-CD oder einer Boot-Diskette starten oder sogar die Festplatten ausbauen. So kann man jederzeit an die Daten des Rechners gelangen und kein Betriebssystem der Welt konnte bisher vor solchen Manipulationen schützen – es sei denn, man hat die Daten verschlüsselt oder benutzt Secure Boot.

Absatz ergaenzt - es handelt sich halt um einen Artikel, der schon etwas aelter ist.

+1

Vorschläge für die Erweiterung/Aktualisierung des Artikels:

• Absicherung des USB-Ports eines laufenden Systems (z.B. mit usbguard), s. z.B. auch https://www.heise.de/security/meldung/USBHarpoon-Gefaehrliche-USB-Ladekabel-vorgestellt-4142285.html)

• Verschlüsselung der Daten über Festplatten-Firmware (für SSDs s. z.B. https://www.thomas-krenn.com/de/wiki/ATA_Security_Feature_Set ); somit kann relativ einfach eine Vollverschlüsselung erreicht werden, entgegen der Aussage im Artikel.

• Nutzung von Secure-Boot / UEFI. Damit ist der Kernel auf der unverschlüsselten Boot-Partition nicht manipulierbar, entgegen der Aussage im Artikel.

• Warnhinweise auf Seitenkanalangriffe / Van-Eck-Phreaking etc. die der Aussage im Artikel widersprechen ("... eigenen vier Wänden ...")

Viele Grüße, Roland

Hallo,

technisch gesehen ist der Stand des Artikels... alt, min 5 Jahre oder so. Du kannst gerne eine Baustelle für den Artikel haben, um das zu aktualisieren.

Bedenke: es ist ein Übersichtsartikel. Konkrete Lösung für einzelne Problem / Sicherheitsfeature gehören in eigene Artikel, die dann hier verlinkt werden.

Gruß, noisefloor