AzzraelDLX
Cadet 3rd Year
- Registriert
- Feb. 2005
- Beiträge
- 62
Hallo zusammen,
aus aktuellem Anlass habe ich ueberlegt, auf welche Art und Weise Daten absichtlich oder versehentlich zerstoert bzw. unbrauchbar gemacht werden koennten und was man (vorbeugend) dagegen tun kann.
Die Situation ist folgende:
Daten werden von HDD-1 mit Allway Sync auf HDD-2 gesichert.
Nun sind vor kurzem die Partitionen der Quell-Festplatte mit GParted vergroessert/verkleinert worden.
Ein Backup der wichtigsten Daten wurde vorher gemacht, doch nach dem erfolgreichen Vorgang schien ohnehin alles gut zu sein. Die Daten waren allesamt noch vorhanden und augenscheinlich auch intakt.
Wochen spaeter ist von der veraenderten Partition das Installationspaket von VMware Server 2.0.1 ausgefuehrt worden, doch das System meldete einen Fehler.
Also erneut heruntergeladen und beim Ueberschreiben der Datei deutete nichts auf Unterschiede hin: bis aufs Byte genau gleich gross, etc.
Keine weiteren Auffaelligkeiten, bis dann in einem Ordner von mehreren Gigabyte Fotos einige JPG-Dateien keine Vorschau anzeigten und sich auch mit den entsprechenden Tools nicht oeffnen liessen: Datei korrupt. Schock! Wer weiss, wieviele korrupte Dateien da noch schlummern...?!
Nun wurde genau kontrolliert und am Ende waren von etlichen zigtausend zum Glueck nur ein paar Dutzend Dateien betroffen, die allesamt gerettet werden konnten! (Es zeigt sich mal wieder, wie gut ein Backup ist.)
Nun mache ich mir mehr Gedanken darueber, was den Backup-Daten wiederfahren kann und wie verschiedene Schutzmassnahmen aussehen koennten.
Die Backup-Festplatte HDD-2 ist mit TrueCrypt 6.1a verschluesselt. Da gibt es ja drei verschiedene Moeglichkeiten:
1) TrueCrypt-Container mit maximaler Groesse.
2) Festplatte - KOMPLETTE Verschluesselung
3) Festplatte - nur Partition verschluesseln
Option 1 schied aus, da das Hantieren mit mehreren Laufwerksbuchstaben nicht gewuenscht ist: Ein Laufwerksbuchstabe fuer die Festplatte selbst und ein Laufwerksbuchstabe fuer das gemountete TC-Volume.
Option 2 schied aus, da es auch von TrueCrypt nicht empfohlen ist. Die Festplatte wird ohne Partitionierung direkt und komplett verschluesselt.
In TrueCrypt wuerde man beim Mounten "\Device\Harddisk2" oder dergleichen Auswaehlen, da keine Partitionen existieren.
Man hantiert hier mit einer sowieso sehr unueblichen Festplattenkonfiguration, die keinen logischen und strukturierenden "Rahmen" fuer die Daten bietet. Viele Betriebssysteme koennen mit derartigen Datentraegern wenig anfangen und erwarten zumindest eine Partitionstabelle. Es geht zwar prinzipiell, ich bin mir aber auch nicht sicher, ob das Signieren oder Initialisieren der Laufwerke, wie Windows es gerne bei neuen Datentraegern macht, die logische Struktur nicht sogar beschaedigen koennte...Es reichen hier ja schon ein paar Schreibvorgaenge am Anfang der Festplatte, da die Nutzdaten (das TrueCrypt-Volume) ja direkt dort beginnt.
Die Option 3 ist daher die sicherste. Die Festplatte sieht aus "wie jede andere", sie hat eine Partitionstabelle, kann sogar eine paar andere Partitionen (sogar bootbare) aufweisen, etc.
In TrueCrypt waehlt man z.B. "\Device\Harddisk2\Partition1" (= 3. Festplatte, 1. Partition). In der Windows-Datentraegerverwaltung hat man eine Primaere Partition angelegt, ggf. formatiert und dann in TrueCrypt die Partition (nicht das ganze Laufwerk) verschluesselt. Die Datentraegerverwaltung zeigt dann kein Dateisystem, sondern "RAW" an.
Das Laufwerk selbst benoetigt man eigentlich gar nicht, es ist ja verschluesselt, also kann man auch den Laufwerksbuchstaben entfernen.
Meines Erachtens ist das der erste Schritt, um dieses Backup-Laufwerk vor unnoetigen und/oder unberechtigten Zugriffen zu schuetzen.
Das Laufwerk ist nicht als logische Einheit im Dateisystem vorhanden, es wird von TrueCrypt nur ueber seinen Device-Pfad eingebunden: \Device\Harddisk\2
Momentan ist diese Backup-Festplatte ebenso wie die Quell-Festplatte per SATA direkt ans System angeschlossen.
Direkt angeschlossen soll sie auch bleiben, denn per Skript wird das TC-Volume gemountet und die Backup-Synchronisation wird durchgefuehrt. (Passwort-Bedenken und dergleichen bitte aktuell aussen vor lassen!)
Allerdings mache ich mir nun Gedanken, was bei diesem System einer Festplatte noch so passieren kann und ob nicht die Auslagerung in ein USB-Gehaeuse (trotz Performance-Einbussen) eine bessere Moeglichkeit waere.
Denn schon bei der Reinstallation des Betriebssystems muss man hoellisch aufpassen, was man tut. Bei vielen Boards wechseln die angeschlossenen Festplatten in der Auflistung munter hin und her - in diesem Fall ein Gigabyte Micro-ATX mit aktuellem AMD 780G-Chipsatz.
Anmerkung: Die aufgedruckte Beschriftung der Massenspeicher-Schnittstellen gibt (auch unter Beruecksichtigung des vorhandenen ATA-Ports und des eSATA-Ports) mitnichten die Reihenfolge im System wieder.
Und der eine oder andere mit mehreren Festplatten im System hat sicher auch schonmal die Erfahrung gemacht, dass zwar von Festplatte 0 gebootet wird, die Partitions- und Festplattennummerierung aber durchaus fuer ein D:\Windows verantwortlich sein kann.
Wie auch immer - hier kann man ggf. die gefaehrdeten Laufwerke abklemmen und installieren, damit nicht eine einzige Schreibaktivitaet (Bootsektor, Partitionstabelle, Initialisierung, etc.) die Daten gefaehrdet.
Vista erkennt im Uebrigen auch USB-Festplatten und listet sie bei der Auswahl, wo Windows denn installiert werden soll, mit auf...
Schritt 1: Laufwerksbuchstabe bzw. -pfad in der Datentraegerverwaltung entfernen.
Schritt 2: Bootsektor und MBR der Festplatte sichern.
Die meisten Tools sichern die ersten 512 Byte des angegebenen Laufwerks. Soweit ich weiss, ist damit alles wesentliche fuer die Festplattenkonfiguration beruecksichtigt (Bootsektor, MBR, Partitionstabelle).
Ein praktisches Tool ist der HDHacker von Dimio, bei dem man sowohl nach Laufwerksbuchstaben als auch nach Laufwerks-ID (MBR) gehen kann und das unter Windows lauffaehig ist. Da die Daten Sektor-Dumps sind, sollten sie mit jedem anderen Tool auch unter DOS zurueckgeschrieben werden koennen. Aber daran sollte es eh nicht scheitern.
Schritt 3: TrueCrypt-Header sichern!
Ist der TC-Header dahin, sind es auch alle Daten! Das Wichtigste hierbei: Wenn man einen Header sichert und danach das TC-Passwort aendert, ist nach Wiederherstellen des alten Headers auch das alte Passwort wieder aktiv. Also gut merken/nicht vergessen!
Eine weitere Gefahr droht durch das Festplatten-Passwort, dass ausser bei Notebook-Festplatten mittlerweile auch so gut wie jede 3,5"-Festplatte unterstuetzt. Durch das Setzen eines Passworts kommt man an die Daten nicht mehr ran. Gedacht ist, dass das BIOS diese Funktion nutzt und verwaltet. Wenn ein bestimmtes Freeze-Kommando naemlich nicht ausgefuehrt wird, dann kann ein Angreifer ein neues Passwort setzen. Von Heise gibt es hierzu ein paar Berichte und Tools, die das verhindern sollen, u.a. einen Windows-Service und eine Bootdisk. Ich vermute, dass aktuelle BIOSse das Freeze-Kommande mittlerweile aber richtig handhaben und die Festplatte vor Passwort-Manipulation schuetzen.
Demnach:
Schritt 4: Manipulation des Festplatten-Kennworts verhindern.
Nun, nach 200 Zeilen, stellt sich mir die Frage, was sonst noch passieren kann?
Wie wahrscheinlich ist es, dass der Festplatte etwas passiert, was nicht durch o.g. Massnahmen abgesichert ist?
Gibt es Viren/Malware oder sogar ganz "harmlose" Tools, die auch ohne Laufwerksbuchstaben und dergleichen gerne mal ein Laufwerk anpacken und in diesem Fall ggf. unbrauchbar machen (koennten)?
Wie oben angemerkt ist auch der Anschluss per USB in Erwaegung gezogen worden, eine Abschaltung (Powerschalter) ist aber ausgeschlossen. Eine Skript-gesteuerte Verriegelung/Sperrung waere eine hilfreiche Gegenmassnahme.
Mir ist leider nichts bekannt und die zuhauf im Internet beschriebene Vorgehensweise, die USB-Laufwerke per "WriteProtect"-Registrykey zu schuetzen, ist zu unausgegoren, zu wenig umfassend, zu leicht zu umgehen und nicht fuer jedes Laufwerk einzeln anwendbar.
(eSATA ist keine Alternative, da die Probleme gleich zu SATA sind.)
Ich bin fuer Vorschlaege, Warnungen, Alternativen, blosse Vermutungen oder sonstige Denkanstoesse sehr dankbar!!!
Vielleicht kristallisiert sich ja eine Art "Best Practice"-Guide heraus bzw. man kann Sicherheit und Handhabung besser gegeneinander abwaegen.
Gruss,
Azze
Hmmm, vielleicht doch ein Thema für das Unterforum "Sicherheit"? - Vllt. kann das dahin verschoben werden?
Ergänzung:
Evtl. hilft ja schon, wenn jemand (Freeware-)Tools kennt, mit denen sich der Zugriff auf Laufwerksebene verhindern lässt? (Also auch, wenn kein LW-Buchstabe vergeben wurde und/oder pro USB-Device.)
Azze
aus aktuellem Anlass habe ich ueberlegt, auf welche Art und Weise Daten absichtlich oder versehentlich zerstoert bzw. unbrauchbar gemacht werden koennten und was man (vorbeugend) dagegen tun kann.
Die Situation ist folgende:
Daten werden von HDD-1 mit Allway Sync auf HDD-2 gesichert.
Nun sind vor kurzem die Partitionen der Quell-Festplatte mit GParted vergroessert/verkleinert worden.
Ein Backup der wichtigsten Daten wurde vorher gemacht, doch nach dem erfolgreichen Vorgang schien ohnehin alles gut zu sein. Die Daten waren allesamt noch vorhanden und augenscheinlich auch intakt.
Wochen spaeter ist von der veraenderten Partition das Installationspaket von VMware Server 2.0.1 ausgefuehrt worden, doch das System meldete einen Fehler.
Also erneut heruntergeladen und beim Ueberschreiben der Datei deutete nichts auf Unterschiede hin: bis aufs Byte genau gleich gross, etc.
Keine weiteren Auffaelligkeiten, bis dann in einem Ordner von mehreren Gigabyte Fotos einige JPG-Dateien keine Vorschau anzeigten und sich auch mit den entsprechenden Tools nicht oeffnen liessen: Datei korrupt. Schock! Wer weiss, wieviele korrupte Dateien da noch schlummern...?!
Nun wurde genau kontrolliert und am Ende waren von etlichen zigtausend zum Glueck nur ein paar Dutzend Dateien betroffen, die allesamt gerettet werden konnten! (Es zeigt sich mal wieder, wie gut ein Backup ist.)
Nun mache ich mir mehr Gedanken darueber, was den Backup-Daten wiederfahren kann und wie verschiedene Schutzmassnahmen aussehen koennten.
Die Backup-Festplatte HDD-2 ist mit TrueCrypt 6.1a verschluesselt. Da gibt es ja drei verschiedene Moeglichkeiten:
1) TrueCrypt-Container mit maximaler Groesse.
2) Festplatte - KOMPLETTE Verschluesselung
3) Festplatte - nur Partition verschluesseln
Option 1 schied aus, da das Hantieren mit mehreren Laufwerksbuchstaben nicht gewuenscht ist: Ein Laufwerksbuchstabe fuer die Festplatte selbst und ein Laufwerksbuchstabe fuer das gemountete TC-Volume.
Option 2 schied aus, da es auch von TrueCrypt nicht empfohlen ist. Die Festplatte wird ohne Partitionierung direkt und komplett verschluesselt.
In TrueCrypt wuerde man beim Mounten "\Device\Harddisk2" oder dergleichen Auswaehlen, da keine Partitionen existieren.
Man hantiert hier mit einer sowieso sehr unueblichen Festplattenkonfiguration, die keinen logischen und strukturierenden "Rahmen" fuer die Daten bietet. Viele Betriebssysteme koennen mit derartigen Datentraegern wenig anfangen und erwarten zumindest eine Partitionstabelle. Es geht zwar prinzipiell, ich bin mir aber auch nicht sicher, ob das Signieren oder Initialisieren der Laufwerke, wie Windows es gerne bei neuen Datentraegern macht, die logische Struktur nicht sogar beschaedigen koennte...Es reichen hier ja schon ein paar Schreibvorgaenge am Anfang der Festplatte, da die Nutzdaten (das TrueCrypt-Volume) ja direkt dort beginnt.
Die Option 3 ist daher die sicherste. Die Festplatte sieht aus "wie jede andere", sie hat eine Partitionstabelle, kann sogar eine paar andere Partitionen (sogar bootbare) aufweisen, etc.
In TrueCrypt waehlt man z.B. "\Device\Harddisk2\Partition1" (= 3. Festplatte, 1. Partition). In der Windows-Datentraegerverwaltung hat man eine Primaere Partition angelegt, ggf. formatiert und dann in TrueCrypt die Partition (nicht das ganze Laufwerk) verschluesselt. Die Datentraegerverwaltung zeigt dann kein Dateisystem, sondern "RAW" an.
Das Laufwerk selbst benoetigt man eigentlich gar nicht, es ist ja verschluesselt, also kann man auch den Laufwerksbuchstaben entfernen.
Meines Erachtens ist das der erste Schritt, um dieses Backup-Laufwerk vor unnoetigen und/oder unberechtigten Zugriffen zu schuetzen.
Das Laufwerk ist nicht als logische Einheit im Dateisystem vorhanden, es wird von TrueCrypt nur ueber seinen Device-Pfad eingebunden: \Device\Harddisk\2
Momentan ist diese Backup-Festplatte ebenso wie die Quell-Festplatte per SATA direkt ans System angeschlossen.
Direkt angeschlossen soll sie auch bleiben, denn per Skript wird das TC-Volume gemountet und die Backup-Synchronisation wird durchgefuehrt. (Passwort-Bedenken und dergleichen bitte aktuell aussen vor lassen!)
Allerdings mache ich mir nun Gedanken, was bei diesem System einer Festplatte noch so passieren kann und ob nicht die Auslagerung in ein USB-Gehaeuse (trotz Performance-Einbussen) eine bessere Moeglichkeit waere.
Denn schon bei der Reinstallation des Betriebssystems muss man hoellisch aufpassen, was man tut. Bei vielen Boards wechseln die angeschlossenen Festplatten in der Auflistung munter hin und her - in diesem Fall ein Gigabyte Micro-ATX mit aktuellem AMD 780G-Chipsatz.
Anmerkung: Die aufgedruckte Beschriftung der Massenspeicher-Schnittstellen gibt (auch unter Beruecksichtigung des vorhandenen ATA-Ports und des eSATA-Ports) mitnichten die Reihenfolge im System wieder.
Und der eine oder andere mit mehreren Festplatten im System hat sicher auch schonmal die Erfahrung gemacht, dass zwar von Festplatte 0 gebootet wird, die Partitions- und Festplattennummerierung aber durchaus fuer ein D:\Windows verantwortlich sein kann.
Wie auch immer - hier kann man ggf. die gefaehrdeten Laufwerke abklemmen und installieren, damit nicht eine einzige Schreibaktivitaet (Bootsektor, Partitionstabelle, Initialisierung, etc.) die Daten gefaehrdet.
Vista erkennt im Uebrigen auch USB-Festplatten und listet sie bei der Auswahl, wo Windows denn installiert werden soll, mit auf...
Schritt 1: Laufwerksbuchstabe bzw. -pfad in der Datentraegerverwaltung entfernen.
Schritt 2: Bootsektor und MBR der Festplatte sichern.
Die meisten Tools sichern die ersten 512 Byte des angegebenen Laufwerks. Soweit ich weiss, ist damit alles wesentliche fuer die Festplattenkonfiguration beruecksichtigt (Bootsektor, MBR, Partitionstabelle).
Ein praktisches Tool ist der HDHacker von Dimio, bei dem man sowohl nach Laufwerksbuchstaben als auch nach Laufwerks-ID (MBR) gehen kann und das unter Windows lauffaehig ist. Da die Daten Sektor-Dumps sind, sollten sie mit jedem anderen Tool auch unter DOS zurueckgeschrieben werden koennen. Aber daran sollte es eh nicht scheitern.
Schritt 3: TrueCrypt-Header sichern!
Ist der TC-Header dahin, sind es auch alle Daten! Das Wichtigste hierbei: Wenn man einen Header sichert und danach das TC-Passwort aendert, ist nach Wiederherstellen des alten Headers auch das alte Passwort wieder aktiv. Also gut merken/nicht vergessen!
Eine weitere Gefahr droht durch das Festplatten-Passwort, dass ausser bei Notebook-Festplatten mittlerweile auch so gut wie jede 3,5"-Festplatte unterstuetzt. Durch das Setzen eines Passworts kommt man an die Daten nicht mehr ran. Gedacht ist, dass das BIOS diese Funktion nutzt und verwaltet. Wenn ein bestimmtes Freeze-Kommando naemlich nicht ausgefuehrt wird, dann kann ein Angreifer ein neues Passwort setzen. Von Heise gibt es hierzu ein paar Berichte und Tools, die das verhindern sollen, u.a. einen Windows-Service und eine Bootdisk. Ich vermute, dass aktuelle BIOSse das Freeze-Kommande mittlerweile aber richtig handhaben und die Festplatte vor Passwort-Manipulation schuetzen.
Demnach:
Schritt 4: Manipulation des Festplatten-Kennworts verhindern.
Nun, nach 200 Zeilen, stellt sich mir die Frage, was sonst noch passieren kann?
Wie wahrscheinlich ist es, dass der Festplatte etwas passiert, was nicht durch o.g. Massnahmen abgesichert ist?
Gibt es Viren/Malware oder sogar ganz "harmlose" Tools, die auch ohne Laufwerksbuchstaben und dergleichen gerne mal ein Laufwerk anpacken und in diesem Fall ggf. unbrauchbar machen (koennten)?
Wie oben angemerkt ist auch der Anschluss per USB in Erwaegung gezogen worden, eine Abschaltung (Powerschalter) ist aber ausgeschlossen. Eine Skript-gesteuerte Verriegelung/Sperrung waere eine hilfreiche Gegenmassnahme.
Mir ist leider nichts bekannt und die zuhauf im Internet beschriebene Vorgehensweise, die USB-Laufwerke per "WriteProtect"-Registrykey zu schuetzen, ist zu unausgegoren, zu wenig umfassend, zu leicht zu umgehen und nicht fuer jedes Laufwerk einzeln anwendbar.
(eSATA ist keine Alternative, da die Probleme gleich zu SATA sind.)
Ich bin fuer Vorschlaege, Warnungen, Alternativen, blosse Vermutungen oder sonstige Denkanstoesse sehr dankbar!!!
Vielleicht kristallisiert sich ja eine Art "Best Practice"-Guide heraus bzw. man kann Sicherheit und Handhabung besser gegeneinander abwaegen.
Gruss,
Azze
Ergänzung ()
Hmmm, vielleicht doch ein Thema für das Unterforum "Sicherheit"? - Vllt. kann das dahin verschoben werden?
Ergänzung:
Evtl. hilft ja schon, wenn jemand (Freeware-)Tools kennt, mit denen sich der Zugriff auf Laufwerksebene verhindern lässt? (Also auch, wenn kein LW-Buchstabe vergeben wurde und/oder pro USB-Device.)
Azze
Zuletzt bearbeitet:
