[OT-Frage] Sicherer Speicher für wichtige Daten...

[Michael Schwingen]

On 2022-11-17, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

Jeder Sektor, den Du schreibst, gibt einen Sektor im
alten Block frei, der nicht umkopiert werden muss. Wo sollen da auf einmal
in Summe mehr Daten herkommen?

Der Unterschied zwischen Block (Win: Cluster) und Sektor.
Solange der alte Block noch Daten enthält, ist er nicht frei. Im
schlimmten Fall ist noch 1 Sektor pro Block belegt und alle übrigen
wurden auch schon einmal geschrieben, dann ist kein Block mehr frei (zum
Löschen).

Dann hat die Firmware vorher schon was falsch gemacht. Wenn nur noch 1 Block
frei ist, muss man halt umkopieren, und dadurch wird der alte Block wieder
frei. Einfach nur den neuen (letzten) Block mit Daten belegen geht nicht.

SSD-Blöcke sind nochmal was anderes als Cluster - das ist aber egal, die
Firmware muss dafür sorgen, daß immer mindestens einer frei ist, damit sie
alte Daten umkopieren kann.

cu
Michael

 

[Michael Schwingen]

On 2022-11-17, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:

Ich habe hier das Gegenteil - das war eine SSD, die durch Betrieb in
einem dauerlaufenden Router mit reichlich logging schnarchlangsam
geworden war. Überschreiben mit Nullen hilft nicht. Nach einem secure
erase ist die wieder flott.

\"Möglicherweise\" hat die das Überschreiben mit Nullen als
\"Vollschreiben\" interpretiert, weil sie als Zustand \"gelöscht\" evtl.,
wie bei \"vielen\" elektronischen Festwertspeichern, den ansieht, in dem
alle Bits gesetzt (\"1\", \"high\") sind.

Oder sie sieht sich die Daten überhaupt nicht an und schreibt die immer 1:1,
und man braucht halt trim oder secure erase, um Blöcke wirklich wieder
freizugeben. Zu den Interna der SSD-Firmwaren gibt es kaum detaillierte
Angaben.

Das ist aus meiner Sicht auch OK: trim und secure erase existieren und
funktionieren, das Überschreiben war nur ein Test um zu sehen, wie sich das
Teil verhält.

cu
Michael

 

[Bernd Laengerich]

Am 18.11.2022 um 18:35 schrieb Michael Schwingen:

Oder sie sieht sich die Daten überhaupt nicht an und schreibt die immer 1:1,
und man braucht halt trim oder secure erase, um Blöcke wirklich wieder
freizugeben. Zu den Interna der SSD-Firmwaren gibt es kaum detaillierte
Angaben.

Sich die geschriebenen Daten nicht anzusehen wäre in erster Näherung ja auch
sinnvoll und viel einfacher zu implementieren. Denn sonst müsste sich der
SSD-Controller ja merken, daß Sektoren mit lauter 0en existieren die er
recyclet hat. Und die beschreibbare Größe könnte die tatsächliche Größe
übersteigen, je nach Inhalt. Und der Controller könnte dann out of memory
laufen wenn jemand in die \"leeren\" Blöcke mal ein 1-Bit schreibt.

Bernd

 

[olaf]

Bernd Laengerich <Bernd.Laengerich@web.de> wrote:

sinnvoll und viel einfacher zu implementieren. Denn sonst müsste sich der
SSD-Controller ja merken, daß Sektoren mit lauter 0en existieren die er
recyclet hat. Und die beschreibbare Größe könnte die tatsächliche Größe

Solche Sektoren wird es nicht geben. DAs was eine SSD nach aussen hin
als Sektor darstellt wird erheblich von den inneren Dastellungen
abweichen. Da wird es immer noch Zusatzdaten fuer Pruefsummen
Korrekturwerte geben.

Olaf

 

[Michael Schwingen]

On 2022-11-18, Bernd Laengerich <Bernd.Laengerich@web.de> wrote:

Sich die geschriebenen Daten nicht anzusehen wäre in erster Näherung ja auch
sinnvoll und viel einfacher zu implementieren. Denn sonst müsste sich der
SSD-Controller ja merken, daß Sektoren mit lauter 0en existieren die er
recyclet hat.

Das geht im Aufwand der sowieso vorhandenen internen Verwaltung (wear
levelling, garbage collection etc.) vermutlich unter. In realen
Nutzungsszenarien kommt das aber vermutlich so selten vor, daß es nicht
lohnt, dafür so eine Optimierung einzubauen (und potentielle Fehlerquellen).

Bei Dateisystemen sind solche Optimierungen für Dateien mit 0 oder wenigen
Bytes durchaus gängig, d.h. man bringt die Daten im Verzeichniseintrag unter
und belegt keinen Datensektor.

Und die beschreibbare Größe könnte die tatsächliche Größe
übersteigen, je nach Inhalt. Und der Controller könnte dann out of memory
laufen wenn jemand in die \"leeren\" Blöcke mal ein 1-Bit schreibt.

Andersrum: die so geparten Blöcke werden dem Reservepool zugeschlagen, der
Benutzer merkt nichts davon, aber die SSD hat intern mehr Platz zum
ummappen.

Eine SSD hat *immer* intern deutlich mehr Blöcke als die nach aussen
sichtbare Kapazität, alleine, um im Betrieb ausfallende Blöcke ersetzen zu
können (und für eine effiziente garbage collection, wear-levelling etc).

cu
Michael

 

[Rolf Bombach]

Peter Heirich schrieb:

Gerrit Heitsch wrote:

Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber bisher noch
nicht aufgefallen ist weil der defekte Bereich schon länger nicht mehr gelesen
wurde. Beim Resync wird aber alles gelesen und dann fällt es auf.

M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte minimal 1x die Woche der Virenscanner alles mal prüfen.

Erinnert mich an die Story eines IT-Journalisten, welcher
anno dunne diverse Virenscanner \"testete\". Ein Scanner hat ihm
besonders gefallen, da er Virensignaturen in einer Tabelle
abspeichern konnte. Blöderweise hat in diesem Moment ein
ebenso blöderweise parallel laufender anderer Virenscanner
diese Tabelle gefunden und einen digitalen hysterischen
Anfall bekommen: Er hat sofort für jede Signatur je ein
Warn- EMail an alle auf dem PC auffindbaren Mailadressen
gesendet.

--
mfg Rolf Bombach

 

[Volker Bartheld]

On Tue, 22 Nov 2022 22:02:52 +0100, Rolf Bombach wrote:

Peter Heirich schrieb:
Gerrit Heitsch wrote:
Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber
bisher noch nicht aufgefallen ist weil der defekte Bereich schon
länger nicht mehr gelesen wurde. Beim Resync wird aber alles
gelesen und dann fällt es auf.
M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem
sollte minimal 1x die Woche der Virenscanner alles mal prüfen.
Erinnert mich an die Story eines IT-Journalisten, welcher
anno dunne diverse Virenscanner \"testete\". Ein Scanner hat ihm
besonders gefallen, da er Virensignaturen in einer Tabelle
abspeichern konnte. Blöderweise hat in diesem Moment ein
ebenso blöderweise parallel laufender anderer Virenscanner
diese Tabelle gefunden und einen digitalen hysterischen
Anfall bekommen: Er hat sofort für jede Signatur je ein
Warn- EMail an alle auf dem PC auffindbaren Mailadressen
gesendet.

Das mit diesen Heuristiken ist eh amüsant.

Für einen ehemaligen Arbeitgeber hatte ich mal Software geschrieben, die
in regelmäßigen Abständen einen http-Request mit Hashes über die
Lizenznummer, gewisse Hardwareparameter, etc. raushaut und anfragt, ob
es ein Update gibt. Nichts Aufregendes also. Irgendwann ergab sich die
Erweiterung des Funktionsumfangs, daß quasi ein \"Bootloader\" als
http-Payload empfangen und auf dem Client ausgeführt werden sollte,
zwecks Einleitung des Updatevorgangs.

Klassische Backdoor also.

Ich habe mir, etliche Jahre, nachdem die o. g. Firma pleite und das
Produkt in anderen Händen war, eher zufällig und zur Gaudi das
Access-Log angeschaut. Denn die Daten für den ftp-Zugang des Webservers
hatte man nicht zu ändern für nötig erachtet. Das war noch im Putty
hinterlegt und eigentlich nur falsch geklickt. Kaum zu glauben, welche
Kunden da noch längst abgekündigte Software am Start haben, die
ungefragt Binaries runterladen und ausführen kann.

Ach ja: Keiner der üblichen Virenscanner (https://www.virustotal.com)
hatte an dem .exe je was auszusetzen. Compiliert mit MSVS/C++ 2005
IIRC.

Volker

 

[Holger Schieferdecker]

Am 23.11.2022 um 17:13 schrieb Volker Bartheld:

On Tue, 22 Nov 2022 22:02:52 +0100, Rolf Bombach wrote:
Erinnert mich an die Story eines IT-Journalisten, welcher
anno dunne diverse Virenscanner \"testete\". Ein Scanner hat ihm
besonders gefallen, da er Virensignaturen in einer Tabelle
abspeichern konnte. Blöderweise hat in diesem Moment ein
ebenso blöderweise parallel laufender anderer Virenscanner
diese Tabelle gefunden und einen digitalen hysterischen
Anfall bekommen: Er hat sofort für jede Signatur je ein
Warn- EMail an alle auf dem PC auffindbaren Mailadressen
gesendet.

Das mit diesen Heuristiken ist eh amüsant.

Naja, amüsant, neulich wurde mir meine Cygwin-Installation von Avira
geschrottet. Da war auch nichts mit aus der Quarantäne wiederherstellen,
ich mußte neu drüber installieren.

Holger

 

[Volker Bartheld]

On Thu, 24 Nov 2022 09:22:15 +0100, Holger Schieferdecker wrote:

Am 23.11.2022 um 17:13 schrieb Volker Bartheld:
On Tue, 22 Nov 2022 22:02:52 +0100, Rolf Bombach wrote:
Erinnert mich an die Story eines IT-Journalisten, welcher
anno dunne diverse Virenscanner \"testete\". Ein Scanner hat ihm
besonders gefallen, da er Virensignaturen in einer Tabelle
abspeichern konnte. Blöderweise hat in diesem Moment ein
ebenso blöderweise parallel laufender anderer Virenscanner
diese Tabelle gefunden und einen digitalen hysterischen
Anfall bekommen: Er hat sofort für jede Signatur je ein
Warn- EMail an alle auf dem PC auffindbaren Mailadressen
gesendet.
Das mit diesen Heuristiken ist eh amüsant.
Naja, amüsant, neulich wurde mir meine Cygwin-Installation von Avira
geschrottet. Da war auch nichts mit aus der Quarantäne wiederherstellen,
ich mußte neu drüber installieren.

Hatte ich den schon erzählt, mit einem MSVS2019-Binary für Unit- und
Integrationstests, das ich nichtsahnend dllhost.exe nannte? Lief nicht.
Nicht bei mir, nicht beim Kollegen. Doppelklick, nix. F5 in der IDE.
Nix passiert. Manchmal blitzt kurz die Konsole auf, manchmal obskure
Fehlermeldungen.

10 Minuten später Anruf von der Zentral-ID, was ich denn da täte?
Software entwickeln natürlich. Ja, aber es hätte da einen Virenalarm
gegeben.

Stellt sich raus, daß der Big Brother auf meinem Entwicklungs-PC
irgendwelche Executables gar nicht leiden kann, wenn sie Namen von Zeugs
haben, das bei MS in Benutzung ist. dllhost.exe ist so eines.
regedit.exe vermutlich auch. Oder calc.exe vielleicht?

Ja, aber dieses meine dllhost.exe sei doch digital signiert und würde
außerdem nicht irgendwo unter %SYSTEMROOT% leben, sondern in meinem
Userverzeichnis. Egal. Das sei suspekt und es gäbe keine Ausnahme.

Je nun. Kam der Berg halt zum Propheten und das Tool wurde in
MyFancyDllTestApp64.exe umbenannt.

Neulich ging der Newsreader @work nicht mehr. 40tude Dialog.
Investigativrecherche mit Putty: Sobald auf Port 119 mit AUTH/USER was
aufgebaut wird, unterbricht die Verbindung. Mit einer Testversion vom
Forte Agent funktionierte es aber.

Auf meine Frage was das soll die Antwort: Usenet/NNTP sei ein
\"High-Risk-Protocol\", deswegen keine Firewallausnahmen. Forte Agent...?
Nein, keine Ausnahmen. Äh. Ja.

Gut, daß HTTP so gutartig ist. Wo kämen wir denn da hin, wenn die
Malware über den Internetbrowser...

Volker

 

[Rolf Bombach]

Volker Bartheld schrieb:

Für einen ehemaligen Arbeitgeber hatte ich mal Software geschrieben, die
in regelmäßigen Abständen einen http-Request mit Hashes über die
Lizenznummer, gewisse Hardwareparameter, etc. raushaut und anfragt, ob
es ein Update gibt. Nichts Aufregendes also. Irgendwann ergab sich die
Erweiterung des Funktionsumfangs, daß quasi ein \"Bootloader\" als
http-Payload empfangen und auf dem Client ausgeführt werden sollte,
zwecks Einleitung des Updatevorgangs.

Klassische Backdoor also.

Alsobitte! Das ist ein Fernwartungstool und keine Backdoor.

Wobei ich mich immer gefragt habe, was diese Fernwartungstools so
genau auf meinem Rechner im Insti getrieben haben. Der lokale
Supporter meinte lakonisch, das wäre unsere NSA, natürlich als
Witz, klar, logo, echt.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Volker Bartheld schrieb:

Und über Layer-8-Einflüsse à la \"erst löschen, dann kopieren\" oder
robocopy /mir bzw. rsync --delete mit versehentlich vertauschtem Quell-
und Zielverzeichnis oder ein SSD-Secure-Erase auf dem falschen Gerät
haben wir noch gar nicht gesprochen.

Das kann gar nicht oft genug genannt werden.
Der grösste Feind der Daten sitzt vor der Tastatur. Hören viele
nicht gern und verzerren dann die Risikofaktoren.

Wenn Du dann nicht einen richtig guten Plan zur Datenwiederherstellung
hast, ist Deine digitale Existenz in Sekundenbruchteilen vernichtet.

Ein erster, offenbar gar nicht so einfacher Schritt ist es,
diese Daten überhaupt noch irgendwo zu haben. Aber erklär
das mal einem Theoretiker.

--
mfg Rolf Bombach

 

[Gerrit Heitsch]

On 11/27/22 16:17, Rolf Bombach wrote:

Volker Bartheld schrieb:

Und über Layer-8-Einflüsse à la \"erst löschen, dann kopieren\" oder
robocopy /mir bzw. rsync --delete mit versehentlich vertauschtem Quell-
und Zielverzeichnis oder ein SSD-Secure-Erase auf dem falschen Gerät
haben wir noch gar nicht gesprochen.

Das kann gar nicht oft genug genannt werden.
Der grösste Feind der Daten sitzt vor der Tastatur. Hören viele
nicht gern und verzerren dann die Risikofaktoren.

Deshalb scripte ich solche Dinge wann immer möglich.

Gerrit

 

[Volker Bartheld]

On Sun, 27 Nov 2022 16:17:47 +0100, Rolf Bombach wrote:

Volker Bartheld schrieb:
Und über Layer-8-Einflüsse à la \"erst löschen, dann kopieren\" oder
robocopy /mir bzw. rsync --delete mit versehentlich vertauschtem Quell-
und Zielverzeichnis oder ein SSD-Secure-Erase auf dem falschen Gerät
haben wir noch gar nicht gesprochen.

Und kaum gepostet, isses mir auch schon selbst passiert.

Hatte ich eben fix auf einer extern via USB-Dock angeschlossenen SSD
(Samsung 850 EVO 250GB) einen Secure Erase gemacht:

https://wiki.ubuntuusers.de/SSD/Secure-Erase/

Besitze einen Linux Mint Mate Bootstick, also kein Problem. Oder? Doch.
Ich _glaubte_ auf einer extern via USB-Dock angeschlossenen SSD einen
Secure Erase zu machen. Tatsächlich war sda aber die Boot-SSD, nicht
die über USB gemountete. War die komplette Windows 7 Bootpartition weg.

BRAVO HERR BARTHELD! Exzellente Arbeit. Ganz toll.

Könnte zur Ehrenrettung noch folgende Info nachreichen:
Bootdisk: Samsung 860 Pro 250GB
----------------------^--^^^
Externe SSD: Samsung 850 Evo 250GB
----------------------^--^^^
, trotzdem megapeinlich und eigentlich unentschuldbar.

Passiert, wenn man nebenher noch am Laptop daddelt und 1\'001 andere
Sachen im Kopf hat. Also genau das klassische Datenzerstörungsszenario.

War aber eine gute Übung. Partitionsbackup (Drive Image XML) hatte ich
vom September 2022, konnte also nochmals vom Linux-Stick booten, mit
GParted eine neue NTFS-Partition anlegen, mich mit dem NAS verbinden
und dann das Image auf die eben erstellte Partition rüberziehen.

Bootete dann (natürlich) immer noch nicht, weil der Windows Bootmanager
unbedingt möchte, daß die Partition auch auf \"Active\" gestellt wird.
Sowas macht man normalerweise mit DISKPART, nur ist das halt ein
Windows-Tool, war auf der Wine-Umgebung des Bootsticks nicht drauf.

Windows 7 Rescue Disk hatte ich auch keine.

Aber, Glück im Unglück: Auf der bootbaren Windows-7-Installations-DVD
gab es einen Wiederherstellungsmodus, der hat das Problem gelöst. So
war ich keine 30 Minuten nach meinem Hoppala wieder am Start.

Und habe dann sdc einer sicheren Löschung unterzogen. Mannomann.
Nahtoderlebnis. Aber lehrreich - und wenn es nur die Info ist, daß meine
Boot-SSD durchaus abrauchen darf (aber bitte nich klammheimlich die
Daten korrumpieren), ohne daß die Welt untergeht.

Das kann gar nicht oft genug genannt werden.
Der grösste Feind der Daten sitzt vor der Tastatur. Hören viele
nicht gern und verzerren dann die Risikofaktoren.

Genau so isses doch. Und Helmu^W pardon: Hochmut kommt vor dem Fall.
SCNR, das Bonmot war einfach zu naheliegend.

Wenn Du dann nicht einen richtig guten Plan zur Datenwiederherstellung
hast, ist Deine digitale Existenz in Sekundenbruchteilen vernichtet.
Ein erster, offenbar gar nicht so einfacher Schritt ist es,
diese Daten überhaupt noch irgendwo zu haben. Aber erklär
das mal einem Theoretiker.

.... dessen Argumentationsgrundlage irgendwelche MTBF-Zahlen,
RAID-Levels, aus der Nase gezogene Wahrscheinlichkeiten von
Seriendefekte, usw. sind. Wenn Du lokal (versehentlich) Daten löscht,
das aufs NAS rübersynchronisierst, davon ein Backup ziehst und kein Repo
mit Snapshots hast, ist Scheiße Trumpf.

Volker

 

[Rolf Bombach]

Volker Bartheld schrieb:

Auf meine Frage was das soll die Antwort: Usenet/NNTP sei ein
\"High-Risk-Protocol\", deswegen keine Firewallausnahmen. Forte Agent...?
Nein, keine Ausnahmen. Äh. Ja.

Weit verbreitete Ausrede, um den Dienst abzustellen respektive nicht
mehr durchzuleiten.
Andere Ausrede: Das braucht keiner mehr.
Rückfrage: Ich bin also keiner?

Swisscom: NNTP abgestellt
PSI: NNTP abgestellt

--
mfg Rolf Bombach