Rekonstruierbarkeit gelöschter Daten

[wasserschlange]

Hallo,

ich habe mal eine kleine Frage zur Rekonstruierbarkeit von gelöschten Daten auf verschlüsselten Platten.

Und zwar geht es dabei um folgenden Sachverhalt:

Ich habe einen Laptop mit verschlüsselter Platte, auf dem sich eine Reihe nicht ganz unwichtiger und teils doch recht sensibler Daten befinden.

Von diesen Daten muss ich natürlich auch Backups anlegen, denn sonst sieht's schlecht aus für mich, wenn die Platte mal den Geist aufgibt.

Da nun jetzt einfach die Dateien auf DVD zu brennen, ohne weitere Sicherheitsvorkehrungen zu treffen, wäre ziemlich blauäugig.
Deshalb hab ich mir mal ein Shellskript gebastelt, dass alle gewünschten Daten in einem TAR-Archiv ablegt, das ganze komprimiert und anschließend mit meinem GPG-Schlüssel verschlüsselt und signiert.

Ich habe also am Ende mehrere Dateien in meinem Backup-Ordner:

- das TAR-Archiv (wird beim komprimieren nicht entfernt)
- das komprimierte TAR-Archiv
- das verschlüsselte und komprimierte Archiv
- den Datei-Index, der während des Backup-Vorgangs geschrieben wurde


Nun sollen alle Dateien, bis auf das verschlüsselte Archiv sicher gelöscht werden.

Dabei stellt sich mir nun die Frage:

rm -r * oder wipe * ?

Ich bin mir nicht ganz sicher ob hier ein mehrfaches Überschreiben überhaupt nötig ist, weil die Platte ja eben verschlüsselt ist.

Wenn der Laptop aus ist, besteht also praktisch schonmal keine Chance bspw. das unkomprimierte TAR-Archiv zu rekonstruieren.
Dafür müsste ja jemand den Schlüssel kennen.

Die Frage ist jetzt, was ist, wenn sich der Computer im laufenden Betrieb befindet. Kann man dann als Angreifer gelöschte Daten genauso "leicht" wiederherstellen (würde für wipe sprechen), wie bei einer unverschlüsselten Platte oder ist das erheblich aufwendiger (würde für rm und einen riesen Zeitgewinn sprechen).

Wäre schön, wenn ihr das mal irgendwie kommentieren könntet.
Vielen Dank!

PS: Erspart euch die Frage, ob ich paranoid bin.

 

[supersucker]

Kann man dann als Angreifer gelöschte Daten genauso "leicht" wiederherstellen (würde für wipe sprechen), wie bei einer unverschlüsselten Platte

Ja, denn im laufenden Betrieb ist das Ding ja im Prinzip unverschlüsselt.

Von welchem Filesystem sprechen wir hier? ext3?

 

[wasserschlange]

Ja, das ist ein ext3-Dateisystem.

 

[supersucker]

Naja,

im Prinzip gibt es für ext3 etliche Tools mit denen das theoretisch wiederherstellbar ist.

Wenn du also wirklich sicher gehen willst, solltest du shred oder wipe nehmen.

Wobei das dann schon extrem paranoid ist, weil das ja bedeuten würde, das dir jemand den Laptop im laufenden Betrieb klauen müsste.....

 

[saeckereier]

Allerdings sollen Tools wie shred bei Dateisystemen mit Journal nicht funktionieren, steht z.B. in der Manpage von Shred. Da ext3 eines dieser Dateisysteme ist sieht's schlecht aus. Aber in dem Tar File sind ja eh nur Dateien aus dem verschlüsselten Dateisystem? Wenn ich dann das Tarfile extrahieren kann (müsste ich Zugriff auf das Device haben) kann ich ja auch genausogut die Dateien einfach kopieren ohne Tarfile.. Alternative: Leg das Tar auf ner separaten verschlüsselten Partition an und unmounte diese wenn fertig
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Noch was: WARUM legst du denn dann diese Dateien überhaupt erst an? Es macht doch gar keinen Sinn überhaupt das unverschlüsselte und das unkomprimierte Tarfile irgendwohin zu speichern??

 

[JBR]

Die englischsprachige manpage(LC_ALL=EN man shred) ist hier ein wenig genauer:

In the case of ext3 file systems, the above disclaimer
applies (and shred is thus of limited effectiveness) only in
data=journal mode, which journals file data in addition to
just metadata. In both the data=ordered (default) and
data=writeback modes, shred works as usual. Ext3 journaling
modes can be changed by adding the data=something option to
the mount options for a particular file system in the
/etc/fstab file, as documented in the mount man page (man
mount).

 

[supervisor]

Allerdings sollen Tools wie shred bei Dateisystemen mit Journal nicht funktionieren, steht z.B. in der Manpage von Shred. Da ext3 eines dieser Dateisysteme ist sieht's schlecht aus.

Wenn er nur die genannten Dateien auf der Festplatte lassen will, brauch er einfach nur diese Dateien extern speichern und dann das gesamte Dateisystem löschen u. mit wipe bzw. shred die festplatte überschreiben. wenn das dateisystem weg is, dann is auch das Journal weg, folglich is es dann auch egal, was er fürn dateisystem hatte.

 

[wasserschlange]

Noch was: WARUM legst du denn dann diese Dateien überhaupt erst an? Es macht doch gar keinen Sinn überhaupt das unverschlüsselte und das unkomprimierte Tarfile irgendwohin zu speichern??

Wenn ich wüsste, wie ich das unterbinden könnte, würde ich das gerne so machen.
Aber wie soll GPG ein Archiv verschlüsseln, dass gar nicht gespeichert wurde?

Vielleicht ist eine einfachere Variante, sich eine schon große Backup-Platte zu holen und die einfach zu verschlüsseln. Da kann ich die Sicherungsarchive immer gleich dort drauf anlegen und muss mir keine Gedanken darüber machen, wie ich das Zeug wieder von meiner Laptop-Platte verschwinden lasse.
Was nimmt man denn da am besten? Gibt's da nicht irgendwelche "unverwüstlichen" Massenspeicher? Werd mal scrooglen...

Wobei das dann schon extrem paranoid ist, weil das ja bedeuten würde, das dir jemand den Laptop im laufenden Betrieb klauen müsste.....

Es kann ja aber auch sein, dass jemand versucht übers Netzwerk in mein System einzudringen.

 

[Mike1]

ein nettes kleines Script das ich für so etwas verwende:

#!/bin/bash
DATE=$(date +%d.%m.%Y_%H:%M)

#Directory where the backup-archive should be stored.
# Path shouldn't end with "/"
BACKUP_DIR="/media/sda1/backup"

#Directories which should be backuped
#Paths shouldn't end with "/"
#Paths shouldn't start with "/" because if they start with "/" the original files could be overwritten, when unpacking
SOURCE="home etc boot"

echo "Will make backup of $SOURCE to $BACKUP_DIR"
cd /
tar cz $SOURCE | gpg --compress-level 0 -c > $BACKUP_DIR/backup-$DATE.tar.bz.gpg

#Decrypting with:
#gpg --output backup-DATE.tar.bz --decrypt backup-DATE.tar.bz.gpg
#Unpacking with
#tar -xzpf backup-DATE.tar.bz

 

[saeckereier]

Du kannst das Tar Kommando mittels der Pipie ( | ) direkt an gpg ausgeben lassen. Damit wird verschlüsselt ohne dass Dateien angelegt werden. Lies dir mal an, was Output Redirection ist. In dem Skript was hier gepostet wurde wird auch die Pipe benutzt.

 

[rikola]

Die Frage ist jetzt, was ist, wenn sich der Computer im laufenden Betrieb befindet. Kann man dann als Angreifer gelöschte Daten genauso "leicht" wiederherstellen (würde für wipe sprechen), wie bei einer unverschlüsselten Platte oder ist das erheblich aufwendiger (würde für rm und einen riesen Zeitgewinn sprechen).

Wenn jemand an das laufende Laptop rankommt, kann er Deine Platte spiegeln und danach die Daten finden, sofern sie noch nicht ueberschrieben worden sind. Dagegen hilft dann schon einmaliges Ueberschreiben, da dd ja tatsaechlich bits kopiert und nicht den magnetischen Zustand der Platte.
Ob man forensische Mittel (mit denen man auch mehrfach ueberschriebene Daten rekonstruieren kann) auf eine laufende Platte anwenden kann, weiss ich dagegen nicht.

 

[wasserschlange]

Ich hab nochmal eine Frage zur Ausgabeumleitung in meinem Backup-Skript:

Wenn ich bspw. Folgendes ausführe, funktioniert die Sache ganz wunderbar:

user@debian:~/Backup$ tar -czf * | gpg -r user --encrypt --sign > backup.tar.gz.gpg

Aber, wenn ich z.B.

user@debian:~/Backup$ tar -czf Dokumente/ | gpg -r user --encrypt --sign > backup.tar.gz.gpg

ausführe, sagt tar:

tar: Anlegen eines leeren Archivs wird feige verweigert.

Warum macht tar denn Probleme, wenn ich da ein Verzeichnis statt dem Sternchen reinschreibe, obwohl es im Ordner Backup momentan nur das Verzeichnis Dokumente/ gibt.
Das eigentliche Skript funktioniert dann logischerweise auch nicht, weil alle Daten von $HOME/Ordner1/ $HOME/Ordner2/ usw. geholt werden müssen.

 

[saeckereier]

Hat nix mit dem Originalthread zu tun. Bitte für solche Fragen einen neuen Thread aufmachen!

Lass in beiden Fällen das f in den Tar Optionen weg. Die erste Variante wird wahrscheinlich die erste Datei, die ls * zurückgibt überschrieben haben mit dem Tar Archiv und wenn du deine Backup.tar.gz mal entschlüsselst wirst du feststellen, dass sie leer ist. Hast du jemals versucht so ein Backup wiederherzustellen???

 

[Gast1]

Fürs Protokoll:

Mit cryptsetup kann man auch "Container" anlegen, die als Loopback-Device wie eine Partition angesprochen werden können.

Backup = das gesamte Image sichern und schon kann man sich diese ganzen, seltsamen Aktionen von weiter oben sparen.

 

[saeckereier]

Ja aber wenn du nicht dauernd den Container vergrößern willst, musst du nen Riesencontainer sichern, statt dem kleinen Anteil an Nutzdaten da drin. Außerdem lassen sich verschlüsselte Daten tendenziell sch*** komprimieren. Wir reden hier von nem kompletten System. Dazu kommt: Loopback kostet Performance und eine Partition ist auch nix anderes als ein Container..

 

[marcellus]

Wenn du schon so schön am pipen bist kannst du auch gleich das backup über ssh übertragen.

Ich kann dir für backups empfehlen dir ein verschlüssteltes software raid anzulegen, grad backups sollten etwas ausfallssicher sein.

 

[saeckereier]

Wenn du schon so schön am pipen bist kannst du auch gleich das backup über ssh übertragen.

Ich kann dir für backups empfehlen dir ein verschlüssteltes software raid anzulegen, grad backups sollten etwas ausfallssicher sein.

Ein Raid ist kein Backup, es sei denn du hast mehrere :-)
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Ach ja, nette Idee, das mit dem über ssh pipen. Wie sähe das denn dann aus?

tar -cj * | gpg .... | ssh -l root serverxyz "cat > test"

Oder wie bekommt man das dann in eine Datei? Hab sowas noch nie gemacht, aber die Idee klingt für nen Server von mir ganz interessant..

 

[marcellus]

Ein raid ist dann ein backup wenn du die backups anderer Platten draufhaust.

Und ja die ssh zeile haut so hin.

 

[Gast1]

Gentlemen - start up your tin-foil hats ....

Ja aber wenn du nicht dauernd den Container vergrößern willst, musst du nen Riesencontainer sichern, statt dem kleinen Anteil an Nutzdaten da drin.

Und wo ist das Problem?

Jemand der sich solche "Sorgen" macht sollte mehr als genügend Backupspace haben (eigentlich immer mehr als der Platz, den es zu sichern gilt.).

Aber das liebe ich an solchen Aluhut-Threads, vor lauter Paranoia leidet dann meist die Logik ein wenig.

Und natürlich ist es absolut _keine_ Option sich bei Bedarf weitere Container anzulegen, die man dann auch noch bei nicht allzu übermässiger Größe vor allem _mehrfach_ und _dezentral_ sichern kann. Wenn es wirklich um wichtige Daten geht, dann sollte dieser Punkt im Vordergrund stehen und nicht irgendwelche Ängste, daß irgendein böser "H4xxor" die nach 4,2x10^23 (8ung, versteckte Botschaft inside!) Jahren munterem bruteforce vielleicht wieder herstellen kann.

Außerdem lassen sich verschlüsselte Daten tendenziell sch*** komprimieren.

Ja, das ist aber bei den unverschlüsselten "Nutzdaten" auch so, oder es kann nicht so viel sein.

Nun mal ernsthaft. welche "sensiblen, persönlichen Daten" sollen so viel Platz wegnehmen? Gigabitweise Bauzeichnungen vom Atomkraftwerk in der Nachbarschaft für den Geheimdienst von Greenpeace gesichert?

Und sollten unter den Nutzdaten z.B. persönliche Photos o.ä. sein, die lassen sich genau so im unverschlüsselten Zustand nahezu gar nicht komprimieren, so what?

Persönliche Dokumente sind im "schlimmsten" Fall PDF, wie gut lässt sich das komprimieren? (wo es doch eh schon meist komprimiert ist).

Wir reden hier von nem kompletten System.

1. Ich bin mir zwar nicht 100% sicher, ob das aus diesem ersten Post so abzuleiten ist, aber wäre das System komplett verschlüsselt, dann gäbe es nirgends "Klartextdaten" die der TE "sicher" gelöscht haben will/muss/mag/wasweißich.

2. Wenn es so wäre, dann mal eine Frage an unsere "Sicherheitsäggsbärden" hier:

Welchen Sinn soll das machen ein komplettes System zu verschlüsseln?

Auf die Antwort aus der Aluhutfraktion bin ich gespannt (kleiner Tipp, die verschlüsselten Anwendungen auf der Kiste kann sich der CIA auch -sogar im Quellcode- bei Sourceforge kernel.org und co besorgen).

Dazu kommt: Loopback kostet Performance und eine Partition ist auch nix anderes als ein Container..

Köstlich.

1. Gerade bei sensiblen Nutzdaten ist das sowas von schnurzpiepegal (und die wichtigen Dokumente, die belegen, WER JFK wirklich gekillt hat und von welchem Planeten sie kamen, laufen da sicher schnell genug).

2. Verschlüsselung kostet natürlich keine "Performance" (Doch tut sie, zu 99,99% genau so gut messbar wie die Sache mit dem Container, im Alltagsbetrieb GAR NICHT)

3. Ja, und diesen Container könnte man sogar im Bedarfsfall (wenns mal wieder "Pörformänz" braucht) mit dd auf eine echte (und damit auch automatisch verschlüsselte) Partition knallen.

Ach ja und der Performanceverlust macht im Vergleich zu der Zeit, die man beim Einpacken, Verschlüsseln usw. der regelmässigen Backups aufwenden muss (sic!, Sorgfalt ist da erste Bürgerpflicht, egal ob verschlüsselt oder nicht) in etwa so viel aus, wie der Bodensee durch eine hineingefallene Laugenbrezel zum Salzsee wird.

So und jetzt weiter machen und passt auf, SIE sind unter uns und vielleicht bin ich sogar einer von IHNEN!11111

 

[saeckereier]

Und wo ist das Problem?
[...]

So und jetzt weiter machen und passt auf, SIE sind unter uns und vielleicht bin ich sogar einer von IHNEN!11111

Ob das jetzt Paranoia ist oder nicht interesiert hier keinen.

Backupspace sind bei mir zum Beispiel WORMs und die gibts noch nicht in erschwinglicher Größe um immer ne komplette Partition die nur zu 40% oder so gefüllt ist zu sichern. Außerdem ist das ne Zeitfrage.

EDIT: Das ganze System zu verchlüsseln ist daher angebracht, weil man so nichts vergessen kann und die Lösung am unkompliziertesten ist. Dich zwingt keiner dazu, ich hab auch nur mien /home verschlüsselt.